Bugtraq mailing list archives
in.comsat DoS vulnerability
From: andrewh () WPI EDU (Andrew Hobgood)
Date: Wed, 3 Sep 1997 01:01:14 -0400
Please excuse me if this has already been mentioned on the list... In the continuing saga of UDP ports sitting open on a machine, in.comsat can be exploited to cause some pretty nasty problems. For the uninitiated, in.comsat allows users who have set biff y to recieve notification of new mail messages in their mail spool. By sending UDP datagrams to port 512, in.comsat is started and breaks up the contents of the datagram. The data sent is of the format "username@linenum" where username is the user who is recieving mail, and linenum is the location in the mail spool where the new mail resides. Therefore, sending 'root@0' to port 512 will tell comsat to alert the user root that there is new mail, and it'll echo up the first couple of lines (7 lines or 560 chars, I believe) to the user's screen if A) they're logged in, and B) have biff set to y. Now, the problem occurs when comsat fork()'s off (about line 221). It does this so it can handle multiple user mail reports in a single comsat connection. Unfortunately, if you feed a huge number of username lines very quickly to the open comsat, it'll continue to fork() off things (which die quickly). As many of you can figure out from here, this can be exploited very easily over a LAN or from the local host. For instance, if you have instated process quotas to prevent users from forkbombing your machine, they can simply start up a few "yes 'root@0' | nc -u localhost 512 &" (which will allow them to run quite a few things before running out of process space), but will open up a large enough stream of garbage to comsat to make it fork() off ad infinitum. On my Linux machine, 3 or 4 of these open comsats is enough to make my system load hit >20. Even if each fork()'ed process lasts for a short time, there is still enough bandwidth over a 10Mbps LAN (or T3 for that matter) to cause a machine to run out of PID's, or force the system load to climb higher and higher until it crashes. Also, comsat does *NOT* log what is sent over the comsat connection unless there is invalid data, such as the user doesn't exist. Otherwise, the only log entry is a single "in.comsat[PID]: connect from hostname". If you do this from localhost, ESPECIALLY if it is preceded by some sort of mail delivery (perhaps just fake a mail to somewhere on the machine, or use the fun remote syslogging bug that we've all seen to fake a sendmail connect), there is very little to indicate foul play. Solutions? Well, either A) prevent comsat from fork()'ing (only allow it to handle 1 line at a time) or B) disable comsat all together. --=[ Andrew earth:~# shutdown --apocalypse 5 `/bin/cat ~/apocalype.msg` Broadcast message from god (console) Wed May 16 13:45:22 2000... Earth is shutting down in 5 minutes for a system upgrade. All users please log out or transfer to heaven.god.net or hell.god.net. Thank you.
Current thread:
- Pine's re-occuring nightmare jericho () DIMENSIONAL COM (Sep 01)
- MS responds to Exchange Server 5.0 POP3 Security problem Manley, Jim W (Sep 01)
- Re: Pine's re-occuring nightmare Mark Crispin (Sep 01)
- HP UX Bug :) Leonid S Knyshov (Sep 01)
- Re: HP UX Bug :) Brian Mitchell (Sep 02)
- in.comsat DoS vulnerability Andrew Hobgood (Sep 02)
- You can find jizz.c here T o r g (Sep 03)
- You can find jizz.c here anonymous () ANONYMOUS ORG (Sep 03)
- [linux-security] Announce: chkexploit 1.13 (fwd) iON BARRiER (Sep 04)
- Re: [linux-security] Announce: chkexploit 1.13 (fwd) W.C. Epperson (Sep 04)
- [Alert] Website's uploader.exe (from demo) vulnerable Aleph One (Sep 04)
- Overflow in one of Apache 1.1.1 (maybe later too)'s modules Matt Conover (Sep 04)
- Re: Overflow in one of Apache 1.1.1 (maybe later too)'s modules Artur Pydo - EuroBretagne (Sep 05)
- Re: Overflow in one of Apache 1.1.1 (maybe later too)'s modules Marc Slemko (Sep 05)
- Announcement: Phrack 51 Nate (Sep 01)
- Pine has a few more problems... dynamo () IME NET (Sep 01)