Linux rpc.nfsd has real_path bug. Vulnerable are RedHat 5.2 and Debian 2.1, local only in most cases.
1853738a3818451ec52cfb97c1b54df616bd2086214f56b0e53130f0dd0433fa
Hi,
this is voice of lam3rZ (.pl)
-- Introduction -
After reading lcamtuf's posts I decided write this one. Few months ago one
of my friends - digit - found bug in linux nfsd daemon. I made example
sploit about IV 1999. Now in distributions is new nfsd and nowhere was
information about security weaknes of old version!
-- Affected -
One time more affected distribution is RedHat 5.2 and Debian 2.1,
Slackware isn't vulnerable even there is *same* version of nfsd.
It's hard to say bug is local or remote, read description please.
-- Description -
Linux rpc.nfsd has real_path bug. When user has been trying access
directory with long path nfsd got SIGSEGV. There was buffer overflow which
we can exploit and get root privileges on server machine. I don't remember
all of details but I'll try write few words ;)
length of path is checked if user is trying make long-path-directory by
nfs but isn't checked when he is trying remove it. One way to exploit
this bug is creating long-path-dir localy and later rm it by nfs. In some
cases bug can be exploited remotely: if attacker has write access to
exported directories by ftpd.
that's all folks.
cya
__
Mariusz Marcinkiewicz | phone: +48 601 080 286 | mail: many@rast.lodz.pdi.net
System Administrator && Tech Support <tmogg@zigzag.pl> http://www.zigzag.pl
Security Advisor tmogg@hert.org http://www.hert.org [*] http://lam3rz.hack.pl
Concerning the problem Mariusz has been handwaving about, this is a
serious issue. It's got nothing to do with realpath(), however. The true
cause of the problem is that the code relies on the total length of a
path to not exceed PATH_MAX + NAME_MAX. I'm not sure whether this is a
common Unix problem, but at least on Linux, PATH_MAX merely seems to put
an upper limit on the length of a single path you can hand to a syscall
(size of a page - 1, i.e. 4095). However it still allows you to create
files within that directory as long as you use relative names only...
As to the impact of the problem, it's nasty, but you will need to have
a directory exported read/write to you in order to exploit it (or you're
able to impersonate a host with this kind of access).
Appended you'll find a patch against 2.2beta46 that rectifies this problem.
The full source for 2.2beta47 can be found at
ftp://mathematik.tu-darmstadt.de/pub/linux/people/okir
Another version (2.2.48) that has some additional, non-security related
fixes I have been working on can be found in the dontuse subdirectory.
Olaf