[9767] in bugtraq
Re: Process table attack (from RISKS Digest)
daemon@ATHENA.MIT.EDU (Dirk Moerenhout)
Tue Feb 23 19:20:42 1999
Date: Tue, 23 Feb 1999 00:11:50 +0100
Reply-To: Dirk Moerenhout <dirk@STAF.PLANETINTERNET.BE>
From: Dirk Moerenhout <dirk@STAF.PLANETINTERNET.BE>
X-To: Mark Boolootian <booloo@cats.ucsc.edu>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19990220134253.A14210@muscat.UCSC.EDU>
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
