Re: [Full-Disclosure] SQL Slammer - lessons learned

• Previous message: bugzilla@redhat.com: "[Full-Disclosure] [RHSA-2003:056-08] Updated kernel-utils packages fix setuid vulnerability"
• Maybe in reply to: John.Airey@rnib.org.uk: "[Full-Disclosure] SQL Slammer - lessons learned"
• Next in thread: Schmehl, Paul L: "RE: [Full-Disclosure] SQL Slammer - lessons learned"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: "David Howe" <DaveHowe@gmx.co.uk>
To: "Email List: Full Disclosure" <full-disclosure@lists.netsys.com>
Date: Fri, 7 Feb 2003 17:52:43 -0000

at Friday, February 07, 2003 11:47 AM, John.Airey@rnib.org.uk
<John.Airey@rnib.org.uk> was seen to say:
>> -----Original Message-----
>> From: David Howe [mailto:DaveHowe@gmx.co.uk]
>> Sent: 07 February 2003 11:09
>> To: John.Airey@rnib.org.uk
>> Subject: Re: [Full-Disclosure] SQL Slammer - lessons learned
>>
>>
>> at Friday, February 07, 2003 10:11 AM, John.Airey@rnib.org.uk
>> <John.Airey@rnib.org.uk> was seen to say:
>>> Like I said, the probability of it affecting you is 64,511/1 per DNS
>>> query.
>> Hmm. not exactly - its a bit more complex. if you block port 'n',
>> then the (n-1024)th time a program requests a random port (assuming
>> it is running no services on ports between 1024 and 'n') it should
>> be assigned
>> it.
> Not at all. Neither a DNS server or a workstation will assign a
> "privileged" port dynamically. It's still 64,511/1 that it
> dynamically assigns the port you block. The probability goes down the
> more ports you block. Ideally 49152 onwards would be used for dynamic
> allocation, but they aren't.
That would require that dynamic ports are allocated randomly - but they
aren't. they are allocated sequentially by the os starting at 1025, so
port 1050 is almost guaranteed to be hit within ten minutes of a
reboot.....

> There's no reason to insist an IP stack would re-use it ever.
Fairly common - particularly in download managers and/or multthreaded
ftp clients.
what will normally happen is that the controller app will start one or
more worker threads - each one of which will obtain one or two ports,
and request from the controller app a task (a specific download).
Because it is inefficient to release those ports then request another
from the os, they don't - they simply re-use the ports (ideally in the
case of ftp retaining the control channel intact) until they are shut
down. The IP stack isn't insisting on *anything* - the programs are
simply performing their tasks as programmed.

> In fact, the only way to reuse a port under a random assignment
> system would be to leave it open, which breaks the RFCs.
what RFC does port re-use break? and just how long has every server on
the planet been breaking it?

> I think you are making this up. A random assignment (which is what is
> required to prevent attacks coming back through open ports) would
> take any of the ports above 1024.
Indeed it would. I am unaware of *any* os that uses random assignment.

> Even if what you are saying is
> true, the effects of what I am saying would be far worse. I've just
> checked our email server, and it appears to be using ports
> sequentially for outgoing mail. The ports are currently over 35,000.
> It's been up a couple of days, as I installed a new kernel recently
> (ie Sendmail on Linux)
yep, that is common for a server. for a user workstation typically shut
down at night? ports below 2000 are almost guaranteed to be used once
per day, ports above 65,000 usually have no chance at all of usage.

> It's the recursive resolution that is the issue here (with UDP
> blocking). In some cases these have to use a different "source" port
> for queries to a "destination" udp port 53. Remember too that
> oversized queries (larger than a UDP packet) will come back on a tcp
> port.
That's interesting - about time I reread the RFCs then, as i thought tcp
was only used for zone transfers.

> Which brings me back to the point. Either every IP stack is rewritten
> to use the alleged "dynamic range" only (unlikely but it may be fixed
> with IPv6. I haven't looked as my ISP won't connect us to the "6bone"
> anyway)
Not a problem - plenty of places will allow you dial-in access to the
6bone using 6over4. IIRC all recent linuxen are compiled in for that,
and the Win2K support is bunded into XP.

> ), or you block SYN, RST and SYN-ACK (ie step 4, figure 7 of
> RFC793) from the outside for TCP and block the creation of UDP
> connections from the outside. That is what "stateful inspection" does.
Interesting sidebar - IE will attempt a "quick connect" to IIS servers
by not doing the usual SYN/SYN+ACK/ACK sequence. from the outside this
looks like an attempt to ACKscan :)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

• Next message: Len Rose: "[Full-Disclosure] Administrivia: Instability/Emergency Maintenance"
• Previous message: bugzilla@redhat.com: "[Full-Disclosure] [RHSA-2003:056-08] Updated kernel-utils packages fix setuid vulnerability"
• Maybe in reply to: John.Airey@rnib.org.uk: "[Full-Disclosure] SQL Slammer - lessons learned"
• Next in thread: Schmehl, Paul L: "RE: [Full-Disclosure] SQL Slammer - lessons learned"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]