(For those of you that do not know bugtraq. I suggest taking a look at it. It is a moderated full disclosure security mailing list. Archives can be found on www.securityfocus.com (run by the moderator of the list, aleph1 aka elias levy.) It does have more traffic than SuSE-Secuirty, and much of it has nothing to do with whatever it is you are doing. All the same, it is interesting reading.) This is the last message on this subject I am going to forward to SuSE-security from bugtraq. I do sort of imagine this will be the last substantive message on the subject. :) ----- Forwarded message from Peter Eriksson <peter@IFM.LIU.SE> ----- Approved-By: aleph1@SECURITYFOCUS.COM Delivered-To: bugtraq@securityfocus.com X-Authentication-Warning: sharrow.ifm.liu.se: peter set sender to peter@sharrow.ifm.liu.se using -f Date: Tue, 17 Aug 1999 10:56:46 +0200 Reply-To: Peter Eriksson <peter@IFM.LIU.SE> From: Peter Eriksson <peter@IFM.LIU.SE> Subject: DOS against SuSE's identd X-To: bugtraq@securityfocus.com To: BUGTRAQ@SECURITYFOCUS.COM Hendrik Scholz <hendrik@SCHOLZ.NET> writes:
The inetd.conf starts the identd with the options -w -t120 -e. This means that one identd process waits 120 seconds after answering the first request to answer later request. Lets say we start 100 requests in a short period. Due to the fact that it takes time to answer one request more identd's will be started each eating up about 900kb memory and waiting 120 seconds before terminating. I tested this behaviour on different machines with different hardware (RAM, Swap, NIC). Each machine becomes unusable after some seconds. This bug is in _every_ SuSE Version at least since 4.4. SuSE seems not to be interested in this bug becaus they did not answer any of my mails.
This bug is probably due to some incompatibility between SuSE's inetd daemons handling of 'stream tcp' & 'wait' servers and the way Pidentd expects it to be handled. The "normal" (as normal as it can be since 'stream tcp wait' normally is not a supported configuration) thing that should happen is that Inetd should start _one_ Pidentd, which then should handle all new requests in sub-processes, which should die immediately after the request has been handled. In the Suse case it seems (my guess) that Inetd keeps on starting new Pidentd's... Anyway, I nowadays _generally_ recommend people to stay away from the "-w" stuff in Pidentd due to the problems with the behaviours of various Inetd implementations... I recommend instead that people get the latest version of Pidentd (version 3.0.7 as of this writing) which uses multithreaded instead of forking subprocesses - this can reduce the load on systems significantly). Pidentd 3.0.7 (and later) can be downloaded from: ftp://ftp.lysator.liu.se/pub/ident/servers Here's the PGP Signature of that file: -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: D750KrTMC9lSc8xPJqIOoI5ldgh6QDYj iQCVAwUAN7c0a0GVHk0UMIghAQH7/wP8DV9NyDrPxMfa8lxSRMrGK8/kNSeKU+Z0 G+eX267t7WpjlP3puVchb7lp7zbtYlJhd6jyuxzwFJrGZs6GJGgT8B6vtFYqfYFm 9n5DAylzrTezWYUEkTQpy4UV+w1gVTa7+/qJcbkTm2rJaPaxp11duf0NH9zOhGZG gzfAOgkXMrU= =Mfo4 -----END PGP SIGNATURE----- /Peter (The Pidentd author) ----- End forwarded message ----- -- Seth Arnold | ICQ 3172483 | http://cswww.willamette.edu/~sarnold/ I prosecute unsolicited bulk emails, using the RealTime BlackHole List. You should too. Ask me how, or visit http://maps.vix.com/rbl/
Hello Seth and rest of the list, Sorry to keep this thread going but I still have a question about it:
The "normal" (as normal as it can be since 'stream tcp wait' normally is not a supported configuration) thing that should happen is that Inetd should start _one_ Pidentd, which then should handle all new requests in sub-processes, which should die immediately after the request has been handled. In the Suse case it seems (my guess) that Inetd keeps on starting new Pidentd's... I'm using SuSE 6.0 and getting exactly the expected behaviour. Starting a lot of telnet's connecting to port ident like this:
khazad-dum:~ # telnet localhost ident 2>&1 >/dev/null & producing |-sshd-+-sshd---bash-+-pstree | | `-10*[telnet] I get an identd which forks children to handle the requests: |-inetd---in.identd---10*[in.identd] These quit immediately if I do khazad-dum:~ # killproc /usr/bin/telnet [1] Terminated telnet localhost ident 2>&1 >/dev/null [2] Terminated telnet localhost ident 2>&1 >/dev/null [3] Terminated telnet localhost ident 2>&1 >/dev/null [4] Terminated telnet localhost ident 2>&1 >/dev/null [5] Terminated telnet localhost ident 2>&1 >/dev/null [6] Terminated telnet localhost ident 2>&1 >/dev/null [7] Terminated telnet localhost ident 2>&1 >/dev/null [8] Terminated telnet localhost ident 2>&1 >/dev/null [9]- Terminated telnet localhost ident 2>&1 >/dev/null [10]+ Terminated telnet localhost ident 2>&1 >/dev/null khazad-dum:~ # pstree what gives me an identd which terminates the specified 120 seconds later: |-inetd---in.identd [time passes] |-inetd So where is that incompatibility and how can I reproduce it? Or did I miss something essential? Might it be that this DOS attack is more about the unlimited forking of identd which should somehow be limited to some sense making value of perhaps 10 simoultaneous connections (aka children) or so? -- bye, Michael
Michael, I ran a test about how you described -- I opened some 40 telnets to the identd port over localhost. each in.indentd takes on my machine 344k (as reported by top..) After using killall -9 telnet all the idents do die -- but while the telnets were running, it looked like I could create as many as I liked. They didn't hang around for 120 seconds, which is probably good. I think you are right, the thing to do is to either handle the requests without forking, or to have a limit on the number of forks. <shrug> (Perhaps the smarter thing to do is disable identd? :) On Thu, Aug 19, 1999 at 11:07:00AM +0000, Michael Weiser wrote:
Hello Seth and rest of the list,
Sorry to keep this thread going but I still have a question about it:
The "normal" (as normal as it can be since 'stream tcp wait' normally is not a supported configuration) thing that should happen is that Inetd should start _one_ Pidentd, which then should handle all new requests in sub-processes, which should die immediately after the request has been handled. In the Suse case it seems (my guess) that Inetd keeps on starting new Pidentd's... I'm using SuSE 6.0 and getting exactly the expected behaviour. Starting a lot of telnet's connecting to port ident like this:
khazad-dum:~ # telnet localhost ident 2>&1 >/dev/null &
producing
|-sshd-+-sshd---bash-+-pstree | | `-10*[telnet]
I get an identd which forks children to handle the requests:
|-inetd---in.identd---10*[in.identd]
These quit immediately if I do
khazad-dum:~ # killproc /usr/bin/telnet [1] Terminated telnet localhost ident 2>&1 >/dev/null [2] Terminated telnet localhost ident 2>&1 >/dev/null [3] Terminated telnet localhost ident 2>&1 >/dev/null [4] Terminated telnet localhost ident 2>&1 >/dev/null [5] Terminated telnet localhost ident 2>&1 >/dev/null [6] Terminated telnet localhost ident 2>&1 >/dev/null [7] Terminated telnet localhost ident 2>&1 >/dev/null [8] Terminated telnet localhost ident 2>&1 >/dev/null [9]- Terminated telnet localhost ident 2>&1 >/dev/null [10]+ Terminated telnet localhost ident 2>&1 >/dev/null khazad-dum:~ # pstree
what gives me an identd which terminates the specified 120 seconds later:
|-inetd---in.identd
[time passes]
|-inetd
So where is that incompatibility and how can I reproduce it? Or did I miss something essential?
Might it be that this DOS attack is more about the unlimited forking of identd which should somehow be limited to some sense making value of perhaps 10 simoultaneous connections (aka children) or so? -- bye, Michael
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
-- Seth Arnold | ICQ 3172483 | http://cswww.willamette.edu/~sarnold/ I prosecute unsolicited bulk emails, using the RealTime BlackHole List. You should too. Ask me how, or visit http://maps.vix.com/rbl/
Hello Seth, you wrote:
I think you are right, the thing to do is to either handle the requests without forking, or to have a limit on the number of forks. <shrug> Jep.
(Perhaps the smarter thing to do is disable identd? :) Almost every simple service on almost every UN*X machine can be used like that: wu.ftpd, telnet, pop3 and so on. In my quick tests using telnet only nnrpd seems smart enough not to fork and talk can't be used with telnet since it uses UDP sockets. So disabling identd you'd have to disable half your system. :-( -- bye, Michael
participants (2)
-
michael＠weiser.saale-net.de -
Seth R Arnold