[6797] in bugtraq
Re: easy DoS in most RPC apps
daemon@ATHENA.MIT.EDU (Olaf Kirch)
Mon May 18 14:12:10 1998
Date: Mon, 18 May 1998 17:45:07 +0200
Reply-To: Olaf Kirch <okir@MONAD.SWB.DE>
From: Olaf Kirch <okir@MONAD.SWB.DE>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Sun, 17 May 1998 15:48:55 EDT."
<199805171948.PAA19494@sirius.ctr.columbia.edu>
--------
On Sun, 17 May 1998 15:48:55 EDT, Bill Paul wrote:
> With these patches, you have 35 seconds to supply a valid record
> containing an RPC message header and request, otherwise the session
> is disconnected. If you enter garbage data, the connection is dropped
> immediately.
Sun's RPC code has some more problems. If you send it a continuous
stream of zero bytes, it will loop forever because it interprets them
as a sequence of zero-length record fragments. It nicely gobbles the
empty record, notices that this hasn't been the last fragment (EOR bit
is 0 of course) and goes asking for more, etc ad inf.
Concerning the 35 second timeout Bill mentions above, this can also be
stretched out quite a bit if you transmit the RPC packet byte by byte,
each 30 seconds apart.
Given the way RPC was designed, I cannot think how to work around this
problem except by handling all RPC requests in a separate thread.
Finally, here's some stuff that I haven't checked so far, but which may
be equally interesting. The RPC code is cluttered with conversions
from unsigned long to int, and I have found at least one (quite important)
routine in the RPC server code that does something like this:
int len;
get len from user request
if (len > MAX_LEN)
return FALSE;
bcopy(buf, destination, (u_int) len);
where destination is on the stack...
Cheers
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
For my PGP public key, finger okir@brewhq.swb.de.
