Re: CVS commit: basesrc

[itojun%iijlab.net@localhost]

>  |    Modified Files:
>  |            basesrc/lib/libc/net: res_query.c
>  |    
>  |    Log Message:
>  |    don't look at $HOSTALIASES, if issetugid() says the binary is dirty.
>  | 
>  | i really hate this change.
>Same here.   What's the problem supposed to be, aside from FUD ?
>As long as the library routines that read $HOSTALIASES are doing it
>properly (if it wants to be super safe, abandon stdio and just malloc
>a buffer, or use the stack, read(2) into it, then zap the buffer (memset())
>before returning to user code).   But setuid() binaries that allow users
>to get access to data in their mem leave more holes than can be exploited
>via HOSTALIASES.

        there are more issues than coredump scenario (stdio buffer visible)
        jason mentioned - actually, by allowing $HOSTALIASES couple of other
        attack scenarios are possible.  basically, we can never allow fopen()
        in setuid'ed privilege here.

        there are couple of ways to fix it:
        - disallow $HOSTALIASES for setuid'ed binary - the committed one
        - open $HOSTALIASES in real uid, in library code only - very hard
          to achieve, many presented me diffs to do this but aren't very correct
        - open $HOSTALIASES in real uid, using some help from new
          openwithrealuid()-like system call - not sure if we want it now
        - assume all users of DNS resolver function to drop setuid
          before calling any name resolution functions - NO WAY

        The first solution has been in FreeBSD and OpenBSD for more than
        3 years.

>So, is this change any more than a reaction to a bug that was in SunOS?

        are you talking about coredump case?  no.

>And if not, can it be undone please?

        the situation is much worse.

itojun