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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:37:05 PDT