Hi Alan,
My inetd is not the old one, it is in Slackware 10.0..
apparently 1.79s, still works here. (the s added by
The slackware group according to the readme:
/* $Slackware: inetd.c 1.79s 2001/02/06 13:18:00 volkerdi Exp $ */
/* $OpenBSD: inetd.c,v 1.79 2001/01/30 08:30:57 deraadt Exp $ */
/* $NetBSD: inetd.c,v 1.11 1996/02/22 11:14:41 mycroft Exp $ */
/*
It still dies pretty fast :( Willy is probably right, in that
the bug is application level in this case. Can you explain
though, how it is appropriate to have no timeout on CLOSE_WAIT.
Lets assume (such as the case with the mysql bug), that it is
created, and for some reason never addressed.. The end case being
mysql reporting "Too many Connections". That would make me assume
these connections are still "alive" (perhaps I am assuming wrong?)
and could still cause issues with other services, if the volume of
them was to get too high.
It still seems prudent to me to have some kind of timeout (2 hours,
or something?) to have it expuldge the connection, because obviously,
it isn't going to voluntarily close.
This bug also exists with Apache, the default config of SSH,
and anything controlled by inetd. This is the vast majority of
popular services on a regular internet server.. That is bad, no?
D.
> -----Original Message-----
> From: Alan Cox [mailto:[email protected]]
> Sent: Sunday, September 12, 2004 11:17 AM
> To: Willy Tarreau
> Cc: Wolfpaw - Dale Corse; [email protected]; Linux Kernel
> Mailing List; [email protected]
> Subject: Re: Linux 2.4.27 SECURITY BUG - TCP Local and
> REMOTE(verified)Denial of Service Attack
>
>
> On Sul, 2004-09-12 at 18:59, Willy Tarreau wrote:
> > The problem is within inetd. In my case it could be because it was a
> > bit old (1999), but since you have it too,
>
> Ancient inetd had several fd leak bugs fixed over time and
> some other problems with built in services. Not much of a
> suprise that a 1999 inetd has it.
>
> Alan
>
>
> --------------------------------------------------------------
> --------------
> -
> This message has been scanned for Spam and Viruses by ClamAV
> and SpamAssassin
> --------------------------------------------------------------
> --------------
> -
>
>
>
>
>
On Sul, 2004-09-12 at 19:40, Wolfpaw - Dale Corse wrote:
> This bug also exists with Apache, the default config of SSH,
> and anything controlled by inetd. This is the vast majority of
> popular services on a regular internet server.. That is bad, no?
I'm unable to duplicate any such problems with xinetd, or with thttpd,
or with apache. Apache will wait a short time then timeout connections
if you've configured it right. If you can continue making millions of
connections a second you can DoS the server the other end, not exactly
new news. The alternative is that you have an infinite number of running
services and you run out of memory instead.
Thats a high level property of any protocol which allows commitment of
resource without being able to do the security authentication first. Its
very hard to create ones that don't however, thus most devices in life
(eg your telephone) have this form or DoS attack.
My sshd also doesn't show this problem and the manual page indicates it
has a 120 second grace timeout for authentication.
The sshd manual page says:
Gives the grace time for clients to authenticate themselves
(default 120 seconds).
On Sun, Sep 12, 2004 at 12:40:56PM -0600, Wolfpaw - Dale Corse wrote:
> It still seems prudent to me to have some kind of timeout (2 hours,
> or something?) to have it expuldge the connection, because obviously,
> it isn't going to voluntarily close.
Dale,
forgive me for insisting, but it would be criminal to do this. You think
that it's sort of closed while it is not. Consider CLOSE_WAIT as ESTABLISHED.
It is not because one end sends a FIN (shutdown(WRITE)) that the connection
is about to end. The culprit really is the application. It is the application
which trusts the other end too much. The system lets the application work as
it expects it, and should never try to cut the grass below the application's
feet.
You must understand how it is supposed to work, basically like this :
A B
shutdown(WRITE)
A enters FIN_WAIT1
------- ACK + FIN ----------> select(in[fd],out[fd],) returns in[fd]
B enters CLOSE_WAIT
<------ ACK + data ----------- read(fd) returns 0
shutdown(SHUT_RD)
Then remove fd from read list.
<---- ACK + data ------------- select(NULL, out[fd],...)
(...) write(fd, data)...
<---- ACK + data ------------- select(NULL, out[fd],...)
<---- ACK + FIN -------------- shutdown(SHUT_WRITE) or close(fd)
close(fd)
------- ACK ----------------->
If the system closed anything, on B side, since the select() does not check
read events anymore, it would only be woken up for a write even, which could
crash the application in a SIG_PIPE if the writer does not check the error
condition on the socket before writing (like most applications do).
So, let me insist, your proposal is not the right solution to this. The
right solution is to carefully check every application and fix them, the
same way you would fix them to handle time-outs on ESTABLISHED connections.
> This bug also exists with Apache, the default config of SSH,
> and anything controlled by inetd. This is the vast majority of
> popular services on a regular internet server.. That is bad, no?
You didn't wait long enough for each of them. I bet that if you wait up
to 2 minutes, SSH will close, and if you wait 5 or 10 minutes, apache
will close too. As to mysql, I have no idea, and inetd, we obviously both
have a buggy version.
I hope this clarifies a bit the situation,
Willy
On Sun, Sep 12, 2004 at 12:40:56PM -0600, Wolfpaw - Dale Corse wrote:
> the bug is application level in this case. Can you explain
> though, how it is appropriate to have no timeout on CLOSE_WAIT.
See TCP/IP Illustrated, Volume 1 by W. Richard Stevens (ISBN
0-201-63346-9), page 238: "TCP Half-Close".
In short, you don't have a timeout on CLOSE_WAIT for the same reason you
don't have a timeout on ESTABLISHED.
--
Jurjen Oskam
"I often reflect that if "privileges" had been called "responsibilities" or
"duties", I would have saved thousands of hours explaining to people why
they were only gonna get them over my dead body." - Lee K. Gleason, VMS sysadmin