Re: [bug #29755] gdomap information disclosure vulnerabilities

[Dan Rosenberg]

I'm still a bit unsure about this fix.  I think that it should either
be made explicit that gdomap is never intended to be installed setuid
(and as a result, is never installed that way), or it should be fixed
so that it's completely safe to run setuid - choosing somewhere in
between leaves some users open to vulnerability.

I haven't seen the actual code of the fix, but it sounds as if it's a
good start but incomplete.  As Fred mentioned, unprivileged users
should not be able to open and parse other users' files at all, even
if the error information returned is limited.  access() is not
sufficient to prevent this - an attacker can toggle a symbolic link
between a file they own and a file they want to read, such that
access() returns ok (because at the time of the call the target points
to a file they own) and fopen() opens the target file instead.  These
sorts of race conditions can easily be exploited.

I still support the dropping of privileges - seteuid() is supported
nearly universally.  If that's really not an option, then the file
should be opened, fstat() should be called on the open file
descriptor, and its ownership should be compared to the user executing
gdomap.  Note that stat() can't be used for the same reason that
access() is ineffective - an attacker can trick it by toggling
symlinks.  Something like this should get the job done:

FILE *fptr = fopen(from, "rt");
struct stat st;
...

fstat(fileno(fptr), &st);

if(st.st_uid != getuid()) {
   [...error, close fd, exit...]
}

Thanks,
Dan

On Wed, May 5, 2010 at 5:54 AM, Richard Frith-Macdonald
<INVALID.NOREPLY@gnu.org> wrote:
>
> Follow-up Comment #4, bug #29755 (project gnustep):
>
>> In most typical GNUstep setups gdomap is no longer needed,
>> so we may just need a bit more documentation for distributions
>> about when to install it at all
>
> That's like saying the spell server and sound daemons are not needed (because
> few people use them), and therefore should not be installed by most
> distributions.
> When to install would be *always* ... otherwise networked distributed objects
> are broken.
>
> The issue is whether a distribution should install the program setuid ... and
> of course it is (and always has been) recommended that it's started at system
> boot time (in which case the setuid flag is not needed).
>
> We should perhaps change our install script to install without the setuid
> flag, forcing the distributors to do that themselves if they want it.
>
>> Otherwise the dropping of the privileges sounds like the best option.
>
> Unfortunately that's not an easy option since not all systems actually allow
> you to restore privileges once dropped, and you need to be privileged to open
> the port to work on.  I don't actually think that would improve security
> significantly (or at all as long as access() works) now that the code uses
> access() to check the files anyway.
>
>
>
>
>    _______________________________________________________
>
> Reply to this item at:
>
>  <http://savannah.gnu.org/bugs/?29755>
>
> _______________________________________________
>  Message sent via/by Savannah
>  http://savannah.gnu.org/
>
>