The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Denial-of-service attack against INETD. Redhat 4.X and others...



-----BEGIN PGP SIGNED MESSAGE-----

Gentle People,

I recently discovered a problem with the "inetd" running on RedHat
Linux version 4.x that makes all services launched from inetd vulnerable
to a denial-of-service attack.  I obtained a copy of the inetd
source code, made changes to fix the problem, and am hereby releasing
those changes back to the public.

Note that I have only observed this problem in RedHat 4.X because that
is all that I run at my site.  However the source code that I changed
is generic BSD code from the 1980s.  I suspect that other Linux
distributions, and other Unix systems, are running the same version
of inetd and suffer from the same problem.

The following TCL script illustrates the denial-of-service attack
that my changes are intended to address:

   for {set i 0} {$i<100} {incr i} {
     set s [socket 127.0.0.1 23]
     close $s
   }

Executing the above script will cause "telnet" service on the local
host to be shutdown for 10 minutes.  It is a simple matter to attack
other services or hosts by changing the TCP port number or IP address.

This attack originates from a "misfeature" of inetd.  (I call the
problem a "misfeature" rather than a "bug" since someone went to a
lot of trouble to put it in.)  If more than a given number (default 40)
of requests for a service arrive within a 60 second interval, that
service is shutdown.  The listening socket is closed.  Attempts to
use that service will result in a "Connection refused" error message.
The service remains off for 10 minutes.  A system administrator
can increase the turn-off threshold to a larger value (by adjusting
the "max" parameter in /etc/inetd.conf), but the mechanism cannot be
completely disabled.

I have implemented changes to the inetd program that address this
problem, as follows:  The program still limits the number of services
that will be launched within a 60 second window, but it does so by
refusing to "accept()" new connections too rapidly.  The listening
socket is never closed, and users never get a "Connection refused"
error.  They just see a slower response.  For the default value of
40 services/second, inetd will now wait 1500 milliseconds after
doing an accept() before doing another accept() on that same service.
All services are handled independently, so an accept() for "ftp" will 
not impede a subsequence accept() calls on "telnet", for example.
Furthermore, the throttling mechanism can be completely disabled by 
setting the "max" parameter to "0" in /etc/inetd.conf.

In the course of making this change, I discovered and fixed another 
small problem with inetd.  It used to be that inetd would sleep
(ignoring all connection attempts) for one second after receiving
any signal.  This effectivelly limited the number of services that
inetd can launch to less than 1 per second, since inetd gets a
SIGCHLD signal for every service launched.

One other change: it used to be that if bind() fields when setting
up a socket, inetd would wait 10 minutes before trying again.  I
lowered this value to 10 seconds.

The source code that I modified was obtained from the NetKit-B-0.08
package.  All of my changes are restricted to the inetd subdirectory
of that package.  A copy of my revisions can be obtained from

   http://users.vnet.net/drh/inetd.fix.tar.gz

The md5sum for this archive is e2f1ab88af8aaa5524de683c149b39f6.  
I have made no attempt to repackage these changes back into NetKit-B-0.08
or to reassemble them back into the RPM from which I obtained them.
My hope is that these steps will be undertaken by someone who knows
better than I how such things are done.

D. Richard Hipp
Charlotte
Aug 16, 1997.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNAMlLjM03TfL2vVNAQEaggP/XrAkNF7d/h0IGRomRfrl8/68qXG/hWjY
DjgDH5npl8SSvCInf2wxk17JErp7/+bLTuNl5c8fLdJ43fRHYlMG/5CGxCzUzmQg
tOa3qEQ2i/pbzosegUX/XvQNkuhZ1GkyFZX1IOl8AgisqnaMTCzweFarCZdIB+tB
Rd9eKurA+Ro=
=Kg9I
-----END PGP SIGNATURE-----


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .