[patch] add modes to open call of ismounted

Rich Felker dalias at aerifal.cx
Sat Jul 29 03:02:03 UTC 2006


On Fri, Jul 28, 2006 at 06:39:02PM -0400, Rob Landley wrote:
> On Thursday 20 July 2006 10:09 pm, Rich Felker wrote:
> > On Thu, Jul 20, 2006 at 03:24:23PM -0700, Erik Hovland wrote:
> > > The ismounted.c file makes a call to open using O_CREAT but does not
> > > specify file permission modes. This is slightly dangerous since it is
> > > plausible to exploit a file created with world writability. But is not
> > > all that dangerous since the file does not live very long. It would take
> > > a pretty savvy attacker to be able to slip in and do something bad
> > > between the open and the unlink.
> > 
> > No, it's very simple and this vuln is very serious.
> 
> I was on the fence about bothering to fix it (I'm replacing all this code in 
> 1.3 anyway), but this makes me think it's probably not even a real problem at 
> all.
> 
> Assuming that your root umask is set _stupidly_ (which it generally isn't, and 

Yes, normally root will have world write blocked in umask, but I've
never heard of someone blocking setuid with umask, even though it
would be a very good idea. :)

> Tell me how this could be exploited.  They can't do a symlink attack unless 
> they can write to / (in which case you have bigger problems).

See below.

> > It's quite  plausible that the file could be created with permissions 4777,
> > in which case it would be easy to exploit.
> 
> To do _what_?

If a file has permissions of 4777 then you can write arbitrary code
into it then exec it. So the obvious answer is "to obtain a root
shell". For instance cat /bin/sh > /bogus_perms_file

I agree that it's extremely unlikely that umask would allow world
write, but still this is a bug and should be fixed.

> > There are many standard 
> > methods to slow down a process between syscalls in order to widen the
> > window for such attacks until it's easy to exploit.
> 
> Exploit it to do _what_?
> 
> This isn't even our code, this is from the e2fsprogs which I'm replacing in 
> 1.3.  Did you see a security advisory go by about e2fsprogs?  Point me to it.

There are plenty of vulns without advisories. I know one in uClibc
right off..

Rich




More information about the busybox mailing list