Re: [Full-Disclosure] SQL Slammer - lessons learned
From: David Howe (DaveHowe@gmx.co.uk)
Date: 02/10/03
- Previous message: Schmehl, Paul L: "RE: [Full-Disclosure] SQL Slammer - lessons learned"
- In reply to: John.Airey@rnib.org.uk: "RE: [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: Mon, 10 Feb 2003 14:14:02 -0000
>>> 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.
> Read my sentence again. I didn't say that you couldn't reuse a port.
> I said you shouldn't insist an IP stack re-use a port.
Indeed so - however, you replied to
>a "well behaved" program may well re-use that port
> several times if it is performing sequential actions.
The fact that it doesn't insist that you re-use a port doesn't mean it
insists you don't either. The stack allows it, and it happens in the
Real World.
>> what RFC does port re-use break? and just how long has every server
>> on the planet been breaking it?
> RFC793 for a start. Even if it was random or sequential assignment,
> you'd still need to keep the port "open" to re-use it. ie the
> resources required to track all the ports you've ever opened and
> closed would be prohibitive. Name me one server that uses port re-use.
any that runs on a well-known port, or relies on RFC to locate its
service. any server daemon, in fact.
> Windows 2000 uses random assignment for passive (PASV) mode ftp.
are you sure it is windows that does that, and not the ftp server
itself? I have several ftpd which deliberately handle their own port
assignments to avoid the sequential allocation "vunerability" - this
isn't a hard task, as all you do is ask the os for port xxx (chosen at
random) and the os will say yes or no. They don't rely on the os to do
this, as sequential is usually fine, and much, much simpler to program.
> Now please name me one OS that uses sequential assignment from 1024
> other than unpatched Windows 2000 (see
> http://support.microsoft.com/default.aspx?scid=kb;en-us;260934). I've
> seen evidence of sequential assignment that started at a higher
> address.
almost any - all versions of windows I have looked at (w2K and below, I
have never checked XP) and most unixen.
> Plenty of sites have records that are too big to fit in UDP.
> Hotmail.com's MX records for one. If your DNS servers can't use a TCP
> port, then you can't email hotmail.com (some would say that isn't a
> bad thing).
I would agree, but as a email admin I sorta get the pain if mail bounces
due to server misconfiguration. do you have an RFC reference for how
this happens (I assume the udp reply indicates the port for a tcp
connect)
> Incidentally, if anyone contacts me off the list about this subject
> (for example, alleging that UDP is insecure without any evidence), my
> reply together with your message will go to the list.
UDP tends to be less secure than TCP - simply because there is no
initial handshake to prevent spoofed source addresses.
> NOTICE: The information contained in this email and any attachments is
> confidential and may be legally privileged. If you are not the
> intended recipient you are hereby notified that you must not use,
> disclose, distribute, copy, print or rely on this email's content. If
> you are not the intended recipient, please notify the sender
> immediately and then delete the email and any attachments from your
> system.
This is irritating - can't you turn it off?
> Please note that the statements and views expressed in this email
> and any attachments are those of the author and do not necessarily
> represent those of RNIB.
This however is usually a good move - better as an overridable definite
assertion (do not rather than do not neccessarily) that you can turn off
when actually speaking on behalf of your company.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Next message: I.R. van Dongen: "Re: RE: [Full-Disclosure] SQL Slammer - lessons learned"
- Previous message: Schmehl, Paul L: "RE: [Full-Disclosure] SQL Slammer - lessons learned"
- In reply to: John.Airey@rnib.org.uk: "RE: [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 ]
Relevant Pages
|
|
