Pavel Machek <pa...@ucw.cz> wrote: > >pa...@toy:/tmp$ uname -a >Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel >GNU/Linux >pa...@toy:/tmp mkdir my_priv; cd my_priv
Attacker opens my_priv and waits. >pa...@toy:/tmp/my_priv$ echo this file should never be writable > >unwritable_file ># lock down directory >pa...@toy:/tmp/my_priv$ chmod 700 . ># relax file permissions, directory is private, so this is safe ># check link count on unwritable_file. We would not want someone ># to have a hard link to work around our permissions, would we? >pa...@toy:/tmp/my_priv$ chmod 666 unwritable_file >pa...@toy:/tmp/my_priv$ cat unwritable_file >this file should never be writable Attacker uses openat() to open and modify the "private" file. >pa...@toy:/tmp/my_priv$ cat unwritable_file >got you ># Security problem here > >Unexpected? Well, yes, to me anyway. Linux specific? Yes, I think so. Not quite, as described above: there's a permissions race which allowed the attacker to open the my_priv directory. Once you have an fd on a directory it's possible to open any file inside without a full-path permissions check. If you created the directory using `mkdir -m 0700` (eliminating the race) then you should be safe. Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ DOVER WIGHT: WEST OR NORTHWEST 5 TO 7 DECREASING 4, THEN BACKING SOUTHEAST LATER. MODERATE OR ROUGH. DRIZZLE LATER. GOOD, BECOMING MODERATE LATER.
