Lucene search

K

nfsd.linux.txt

🗓️ 09 Nov 1999 00:00:00Reported by Mariusz MarcinkiewiczType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 41 Views

Bug in Linux nfsd daemon allows buffer overflow, risking root access on RedHat and Debian.

Show more

AI Insights are available for you today

Leverage the power of AI to quickly understand vulnerabilities, impacts, and exploitability

Code
`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: [email protected]  
System Administrator && Tech Support <[email protected]> http://www.zigzag.pl  
Security Advisor [email protected] 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  
  
`

Transform Your Security Services

Elevate your offerings with Vulners' advanced Vulnerability Intelligence. Contact us for a demo and discover the difference comprehensive, actionable intelligence can make in your security strategy.

Book a live demo
09 Nov 1999 00:00Current
7.4High risk
Vulners AI Score7.4
41
.json
Report