Re: Process table attack (from RISKS Digest)

[dirk () STAF PLANETINTERNET BE (Dirk Moerenhout)]

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