Bugtraq mailing list archives
Re: SECURITY: new nfs-server packages available (fwd)
From: paul () BOEHM ORG (Paul Boehm)
Date: Fri, 28 Aug 1998 06:38:50 +0200
On Fri, Aug 28, 1998 at 03:53:07AM +0100, Alan Cox wrote:
Expect similar announces from other Linux vendors to follow this one. The bug is in code that as far as I can tell in Linux specific portmap code so this is unlikely to affect non Linux portmappers. I'll post an explanation once the other vendor announcements are out.
i've looked through the code... I assume that everyone interested in this with a bit of C and english knowledge should be able to find out, by looking at the diffs, where in the code the mentioned problems are located and of what kind they are. To understand the following, look at the diff from the new source rpm. currently i see no way to exploit this in the way the nfs package is shipped with redhat linux(as far as i can see from the source rpm) unless the nfs or mountd get a SIGUSR1 (kill -10) signal while running. the only messages that still get logged without this are: L_WARNING L_FATAL L_ERROR. CALL_PROFILING isn't defined by default so i didn't look through what would happen if it were defined. i looked through every call to Dprintf that reaches the vulnerable code parts and found nothing dangerous(hope i didn't miss something) just as a sidenote: if CALL_PROFILING were defined we would encounter this nice goodie: nfs_dispatch.c:#define PATH_PROFILE "/tmp/nfsd.profile" (bad idea for a default) WANT_LOG_MOUNTS isn't defined by default, i didn't look through what happens when defined. i hope i didn't miss anything.. if i did, please correct me! i guess, from what i've seen, people using the binary supplied by redhat and which didn't toy around with signal's are safe from this. Ah yes, _maybe_ there's a problem when logging stuff with path's > 1024... didn't look further into it. shouldn't make problems unless the attacker gets writeable access to your filesystem... (maybe if you have a very long directory structure on your sys this could result in a DoS attack without write access.. but.. who has that big paths, and who cares?) bye, paul -- [ Paul S. Boehm | paul () boehm priv at | http://paul.boehm.org/ | infected@irc ] Money is what gives a programmer his resources. It's an exchange system created by human beings. It surrounds us. Works for us, binds the economy together.
Current thread:
- Re: News DoS using sendsys, (continued)
- Re: News DoS using sendsys Russ Allbery (Aug 26)
- Re: News DoS using sendsys Andrew V. Kovalev (Aug 27)
- Re: News DoS using sendsys Charlesw (Aug 27)
- Re: News DoS using sendsys David Shaw (Aug 27)
- SV: SV: Serious Security Hole in Hotmail (URL to sourcecode) Jonathan James (Aug 27)
- Re: News DoS using sendsys Julian Cowley (Aug 27)
- Re: News DoS using sendsys Russ Allbery (Aug 27)
- Seyon Security Vulnerability SGI Security Coordinator (Aug 27)
- Re: Seyon Security Vulnerability Alan Cox (Aug 27)
- SECURITY: new nfs-server packages available (fwd) Alan Cox (Aug 27)
- Re: SECURITY: new nfs-server packages available (fwd) Paul Boehm (Aug 27)
- Cisco response re PIX fragmentation issue Cisco Product Security Incident Response Team (Aug 27)
- NFS fix - TurboLinux 2.0 Scott Stone (Aug 27)
- StackGuard-protected Linux and a New StackGuard Compiler Crispin Cowan (Aug 27)
- Re: News DoS using sendsys Andrew V. Kovalev (Aug 27)
- Re: News DoS using sendsys Russ Allbery (Aug 26)
- Re: News DoS using sendsys Don Lewis (Aug 27)