RE: Linux 2.4.27 SECURITY BUG - TCP Local andREMOTE(verified)Denial of Service Attack

RE: Linux 2.4.27 SECURITY BUG - TCP Local andREMOTE(verified)Denial of Service Attack

[Wolfpaw - Dale Corse]

> 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.

Slackware doesn't use xinetd, but rather inetd. Is inetd an
old version which is no longer maintained? Apache, it didn't
kill, but slowed it down quite a bit. You are correct for sure
on that point though, there is nothing that can be done about
connection floods.

> 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.

Very true :(

> 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).

Again - likely a connection flooding DoS there.. Which can't be helped
Unless you use ipchains to limit the amount of connections per ip
address.

Thanks for the reply :)
D.

RE: Linux 2.4.27 SECURITY BUG - TCP Local andREMOTE(verified)Denial of Service Attack

[Wolfpaw - Dale Corse]

> On Sul, 2004-09-12 at 19:52, Wolfpaw - Dale Corse wrote:
> > > > A) Why are the timeouts so long?
> > > 
> > > So you don't get random corruption
> > 
> > Hmm. I'll take your word for it, I'm not quite grasping it, but you
> > know quite a bit more about it then I do :) I would have 
> thought once 
> > a close is sent, the data has all been received and/or sent 
> anyway, so 
> > what would corrupt?
> 
> It has all arrived at least once. However you don't know if a 
> retransmitted packet took a long trip round the world and 
> popped out later. When that happens you need to be sure you 
> can tell old and new apart. The TIME_WAIT state is basically 
> "don't use this identical set of port/address data for long 
> enough to be sure any prior use has exited the internet in 
> its entirety.

That makes sense :)

> 
> > It _appears_ that when we close a socket (ie with 
> mysql_close) on the
> > client side, the client side closes the FD properly (though Mysql
> 
> socket != fd. If you close an fd and open you may get the 
> same fd but its a different socket. If its getting stuck 
> closing could you have another copy of the fd left open 
> somewhere or have passed it to a process you forked (thats a 
> classic nasty to track down error) ?

The way it generally works, is the daemon opens quite a few
sql connections for different reasons. It stores all of them
in a linked list (a somewhat implementation of persistent
connections, since the c API doesn't provide for it)

Every 60 seconds, the list is scanned for "unused" sql
connections, and calls mysql_close on them. The instance
of the actual list entry is not deleted until the next
run to give things 60 seconds to clear up. The issue
we were having is this..

Mysql connection: descriptor 3 (from mysql.net.fd)
Mysql connection closed (desc 3) (goes into CLOSE_WAIT now)
New connection (outbound) for regular proxy on Desc 3
  (this was created by a call to socket, and then connect)

Now the only way to get mysql to actually CLOSE the connection,
is go call close(mysql.net.fd) before destroying the structure.
This would have the effect of clearing the CLOSE_WAIT entry
from the netstat table, but it would also close the active
connection that was made with socket/connect (they have the
same FD). This is why I said they are being reused .. Our
software (being the client) has requested the connection closed,
and mysql hasn't closed it (unsure why.. Maybe data from the db
query still sitting on the SQL side?), so it then reuses what it
thinks is a clean FD, and it ends up needing to be closed AGAIN
to stop the other bug..

The other bug being, if I simply leave them, in a short time, MySQL
is saying "too many connections", and we can't query any data from
it. This also occurs with FIFO sockets (such as /tmp/mysql.sock)
wherein the connection simply sits as "ESTABLISHED".

I have been unable to find any sort of "flush" command to issue to
the SQL server on the socket, to tell it that I am done with whatever
data it has pulled out of the DB. This is obviously an SQL bug.

I assumed it an OS bug, mostly because the "socket" that used to
belong to the FD is still open at least on one side, I was thinking
this needs to be checked for somehow. What do you think?

> 
> > doesn't), and then if we call connect (which it does a lot, being a
> > proxy
> > server) it will reuse that FD. At this point, the Mysql 
> side still hasn't
> > closed it, and it is sitting in CLOSE_WAIT, where it 
> remains forever,
> since
> > it is in use by the client side elsewhere already. Should 
> connect be 
> > checking the "list of not connected, but state other then 
> CLOSED" list 
> > before it decides to use a particular FD? Or is this behavior 
> > intentional?
> 
> Sockets are two way at the TCP layer. "close" really means 
> "have finished sending". When both ends have finished sending 
> the connection is complete but not before. Thus if Mysql 
> daemon says "I am done" but you have open references to the 
> handle then it will stay open one way still.

So something needs to trigger a "flush" of the left over data
on the SQL side before closing the connection - yes?

Again - thank you for your input :)
D.

RE: Linux 2.4.27 SECURITY BUG - TCP Local andREMOTE(verified)Denial of Service Attack

[Alan Cox]

On Sul, 2004-09-12 at 20:36, Wolfpaw - Dale Corse wrote:
> Mysql connection: descriptor 3 (from mysql.net.fd)
> Mysql connection closed (desc 3) (goes into CLOSE_WAIT now)
> New connection (outbound) for regular proxy on Desc 3
>   (this was created by a call to socket, and then connect)

fd != socket. Thats really important to realise. What you get on 
fd 3 from the new connection isn't the same as you had before. 
The one you closed has been handed off to the kernel to clean up
as and when everyone who has a copy has finished using it. Thats
why I asked about fork() - because you can end up giving handles
by mistake to other processes you create which don't close them

> The other bug being, if I simply leave them, in a short time, MySQL
> is saying "too many connections", and we can't query any data from
> it. This also occurs with FIFO sockets (such as /tmp/mysql.sock)
> wherein the connection simply sits as "ESTABLISHED".

I'd say your code is buggy then

> So something needs to trigger a "flush" of the left over data
> on the SQL side before closing the connection - yes?

That will occur anyway for you. I think you need to find out where the
other copies of the same fd went and how mysql manages them