Full Disclosure mailing list archives
Re: SQL Slammer - lessons learned
From: "David Howe" <DaveHowe () gmx co uk>
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
Current thread:
- RE: SQL Slammer - lessons learned, (continued)
- RE: SQL Slammer - lessons learned Schmehl, Paul L (Feb 09)
- Re: SQL Slammer - lessons learned Helmut Springer (Feb 09)
- Re: SQL Slammer - lessons learned Georgi Guninski (Feb 09)
- Re: SQL Slammer - lessons learned yossarian (Feb 09)
- RE: SQL Slammer - lessons learned Steve Wray (Feb 09)
- RE: SQL Slammer - lessons learned Schmehl, Paul L (Feb 09)
- Re: SQL Slammer - lessons learned Helmut Springer (Feb 09)
- RE: SQL Slammer - lessons learned Steve Wray (Feb 09)
- Re: SQL Slammer - lessons learned Helmut Springer (Feb 09)
- RE: SQL Slammer - lessons learned John . Airey (Feb 10)
- RE: SQL Slammer - lessons learned John . Airey (Feb 10)
- Re: SQL Slammer - lessons learned David Howe (Feb 10)
- RE: SQL Slammer - lessons learned Schmehl, Paul L (Feb 10)
- Re: SQL Slammer - lessons learned David LaPorte (Feb 10)
- Re: SQL Slammer - lessons learned Karl DeBisschop (Feb 10)
- Re: SQL Slammer - lessons learned David LaPorte (Feb 10)
- Re: SQL Slammer - lessons learned petard (Feb 10)
- Re: RE: SQL Slammer - lessons learned I.R. van Dongen (Feb 10)
- RE: SQL Slammer - lessons learned Schmehl, Paul L (Feb 09)