Bugtraq mailing list archives
Re: Process table attack (from RISKS Digest)
From: dirk () STAF PLANETINTERNET BE (Dirk Moerenhout)
Date: Tue, 23 Feb 1999 00:11:50 +0100
While you are certainly right about the possible implications of this it looks as if you're lifting this higher than it is. You should not make an elephant from a fly. This is a possible problem but wise system-implementation can solve this easily enough.
... To launch a process table attack, the client need only open a connection to the server and not send any information. As long as the client holds the connection open, the server's process will occupy a slot in the server's process table.
This is true though a lot of services will time out after a while thus shutting down the proces and freeing the slot again. Services that wait hours without receiving a byte of data are badly coded.
... 1. Use IP spoofing so that the incoming connections appear to come from many different locations on the Internet. This makes tracking considerably harder to do.
Tracking would be harder yes. But don't you think it's pretty hard to get a full spoofed 3WHS? AFAIK most Unices pass connects after the 3WHS. And while it's easy to spoof a SYN, it's a lot harder to spoof the rest.
2. Begin the attack by sending 50 requests in rapid fire to the telnet, rlogin and rsh ports on the target machine. This will cause inetd to shut down those services on the target machine, which will deny administrative access during the attack.
The use of rlogin, rsh and telnet have long been depricated in favor of ssh.
3. Instead of initiating a new connection every 4 seconds, initiate one every minute or so. The attack slowly builds, making it more difficult to detect on packet traces.
Ok, but there aren't that many services that don't time out when receving either no data or invalid data. And if they don't they should.
There are several ways to defend against the attack: 1. inetd and other programs should check to see the number of free slots in the process table before accepting new connections. If there is less than a predefined number of free slots, new connections should be accepted. 2. Alternatively, if there are more than a preset number of network daemons for the service running, incoming requests should be queued rather than serviced. 3. Network services (such as finger) should implement timeouts. For example, the statement alarm(30) could be inserted into the finger daemon source code so that the program would stop running after 30 seconds of execution.
Stuff like this already exists in many daemons. This isn't really a case of OS-problems but rather poorly implement services. Services that handle connects in a sane way should not be an aid in performing this attack.
Simson L. Garfinkel, Sandstorm Enterprises, Inc. <www.sandstorm.net>
Dirk Moerenhout
Current thread:
- Re: Pro/wuFTPD DoS, (continued)
- Re: Pro/wuFTPD DoS Chris Wedgwood (Feb 20)
- Process table attack (from RISKS Digest) Mark Boolootian (Feb 20)
- LSOF exploit c0nd0r (Feb 21)
- Re: Process table attack (from RISKS Digest) Olle Segerdahl,D (Feb 22)
- Re: Process table attack (from RISKS Digest) Jan B. Koum (Feb 22)
- ANNOUNCE: Net::RawIP 0.06 has been released Sergey V. Kolychev (Feb 22)
- Summary: Copyright on Security advisories Aviram Jenik (Feb 22)
- Re: Process table attack (from RISKS Digest) Dug Song (Feb 22)
- NetBus client 1.x overflow Daniel Rosowski (Feb 22)
- Re: Process table attack (from RISKS Digest) James Lockwood (Feb 22)
- Re: Process table attack (from RISKS Digest) Dirk Moerenhout (Feb 22)
- Re: Process table attack (from RISKS Digest) unknown () RIVERSTYX NET (Feb 22)
- Re: Process table attack (from RISKS Digest) Andrew Hobgood (Feb 22)
- Denial of service process table attacks John Conover (Feb 23)
- Group kmem exploitable? Oliver Xymoron (Feb 23)
- Re: Pro/wuFTPD DoS Alex Belits (Feb 21)
- Re: Pro/wuFTPD DoS Chris Wedgwood (Feb 20)
- ISS install.iss security hole Fyodor (Feb 20)
- Re: ISS install.iss security hole Joel Eriksson (Feb 22)
- Preventing remote OS detection Patrick Gilbert (Feb 22)
- Re: Preventing remote OS detection James Lockwood (Feb 22)
- Re: Preventing remote OS detection route () RESENTMENT INFONEXUS COM (Feb 22)