Hi!
> >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$ 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.
Ok, if linux honors O_SEARCH on directories, then you found problem
with my example. Congratulations, you were the first one :-).
I could present more complex example, pavel passing guest read-only
file descriptor over unix socket. At that point, you would not be able
to play with openat. OTOH, that example would be complex & ugly :-(.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
