nfsd.linux.txt

1999-11-09T00:00:00
ID PACKETSTORM:11514
Type packetstorm
Reporter Mariusz Marcinkiewicz
Modified 1999-11-09T00:00:00

Description

                                        
                                            `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  
  
`