Since Steve Gibson's web site was attacked in May 2001, I've been
getting lots of calls from reporters who were working the GRC.com
DDoS story.  I read Steve's long report of the incident, and his long
explanation of his solution: Force Microsoft to remove raw sockets
from Windows XP.

My general comments on his proposal are these:

o Steve seems to mean well.  I give him credit for recognizing the
problem of DDoS and for wanting to do something about it.
Without FUDding the subject, I do think it is one of the largest
threats to the Internet today, since it is so easy to do
with relative impunity.

I also do not want to come across as slamming Steve personally,
since I have never met him (but know his name from my own DOS/Windows
coding days long ago), and I don't have any grudge against him.
I just know a bit about the subject and some of what I know does
not match with what Steve is saying.

o This is Steve's first foray into the world of DDoS, and his
research goes back all of two or three weeks.  I'm sure he's a fast
study, but it looks like most of his time was spent coming up to speed
with IRC, coding some IRC apps, and looking only at the Windows side
of the DDoS issue.

o Steve knows Windows (and knows it pretty well), so I think to him
all DDoS problems are Windows problems, and all solutions are Windows
solutions.  Sure, Microsoft has a monopoly on consumer operating
systems (read *ALL* of Judge Jackson's findings before you say one
word about me being out of line on this, and while you're at it, tell
Microsoft to refund the several hundred dollars I've paid them when I
buy PCs that ran Linux and OpenBSD from day 1, not the Windows
pre-install I was forced to purchase!) and with numbers that large,
even a small percentage problem on their platform is a big problem in
absolute numbers.  If someone wants to argue along those lines, what
the Justice Department is proposing is a better solution in the long
run than removing raw sockets from XP.

o I think that Steve is focusing on only one issue in a very complex
set of issue (to the exclusion of a number of other equally important
issues) and is putting an overly large amount of energy into this one
issue.  My read of the comments I'm hearing from others is that this
unbalanced approach comes across to them as FUD or hype.

Now some comments on Steve's arguments.

Steve cites three "proofs" that Windows versions prior to
Win2K, and soon XP, cannot do source address forgery, and that
WinTrinoo is not as sophisticated as the original Unix Trinoo (which
Steve claims can do source address forgery and SYN flooding.) These
three "proofs" are:

1).  A comment in the source to "Skydance" (a Windows DDoS tool I'd
never head of before now, since I focus as much on Windows as
he does on Unix ;)

Comments by a DDoS coder don't seem to me to be proof, but more likely
the statement of someone who may not know how to do something beyond
what Winsock supports.  Several DDoS programs on Unix were first
efforts by their coders, and had several bugs, in some cases not even
having complete command sets.  (Believe me this is not a slam on them,
since they work pretty darn well for first coding efforts.  Better
than I could have done.)

I don't consider this "proof" in and of itself of the impossibility of
doing source address forgery, except for the case where you choose to
code by Microsoft's (WinSock, to be precise) rules.

[Note:  I was later contacted by the author of Skydance, who was
offended by my remarks.  He explained to me,

  "oh, damn i code winsock?
   And i have no idea in general?
   Let me say you some words about it.
   I knew of libpcap and winpcap for years. And indeed i played
   with winpcap already years ago.
   Whatever i got too many bluescreens so i gave it up.
   [...]
   I simply come home and have a bit fun in coding something... but
   that does not mean i'm not "able" to write a comparable thing to
   KIS (you surely know of...) for win!"

I apologized and explained that my main point was only that Steve
Gibson was saying that it is impossible to send forged packets from
Windows (unless Microsoft provides an API for it), while he and I
both knew that was not true.]


2).  Again, Steve cites another web page (CodeGuru) that says the same
thing about Winsock.

Steve claims this site has a proof of concept "attack" program that
won't work on anything other than Win2K.  Again, this is not really a
definitive non-existence proof.


3).  This is Steve's weakest argument of all.  He claims that Unix
Trinoo was capable of source address forgery (it was NOT), that it
could do SYN flooding (it only implemented UDP flooding), and that it
was ported to Windows (not really, but a plugin was written for NetBus
and/or BO2K that implemented the attack portion of Unix the trinoo
agent (I LOATH the term "zombie", by the way), without the
agent/handler control and agent discovery traffic which were replaced
by NetBus/BO2K's own control functions.)  Unix Trinoo didn't even
require root privileges to run (since it didn't use raw sockets at
all, just standard UDP.)  If he wants a model that uses source address
forgery, he wants Stacheldraht or TFN2K.

I don't think Steve ever read the analysis I did of trinoo, or else he
wouldn't be making these clearly incorrect statements as support of
a "proof":

	http://staff.washington.edu/dittrich/misc/trinoo.analysis.txt


Elsewhere in his paper, Steve entirely blows off Microsoft's claim
that it is easy to get around the "no raw sockets in Winsock" problem,
claiming it is "irrelevant" that hackers can code around this
limitation.  He also rebuts Microsoft by saying that the reason that
attackers have not coded around this limitation is the fact that it is
harder to do than Microsoft claims.  While I agree that programming
for Intel/Windows is a pain in the butt (I did it for years, and if
you have coded for Windows, VMS, and Unix too, you know what I mean),
that doesn't mean its impossible.  I asked several colleagues about
this issue and Weld Pond of the l0pht pointed out the following to me:

   L0pht's AntiSniff uses raw sockets to spoof traffic.  This is to
   see if sniffers respond to traffic they shouldn't be seeing.  We
   use bogus IP addresses and bogus MAC addresses.  We rolled our own
   raw sockets using the Microsoft sample packet driver which is
   downloadable from their web site.  It works on win9x and NT.

   For LC3 we needed to sniff promiscuously (remember that the normal
   socket interface does not do this either) so we used the winpcap
   library which has full raw socket support.  On the winpcap web page
   it even says that it was developed with a grant from Microsoft
   Research.  The other option is to use libnetNT from eEye.

   I think people are confused about how programming works to tell you
   the truth.  A program typically has 3 sources of functionality: OS
   API where the code resides in an OS supplied library, 3rd party API
   where the programmer ships an extra DLL with their product, and of
   course the code that the programmer writes which is typically in
   the EXE.  Most programs use 3rd party libraries because programmers
   don't want to write it all.  If it is in the OS most will use that.
   If it isn't they hunt for a library that they can bundle in to get
   the functionality.

   Functions not being in the OS never stopped me from getting the
   computer to do what I wanted.  It all comes down to the level of
   effort.  Since there are 3rd party libraries winpcap and libnetNT
   available right now there is no extra effort to spoof packets.

I never thought I would be one to agree with a Microsoft rebuttal to a
security issue, but I think they are right, and I have to give Weld
the nod over Steve for coding security related apps.

Steve goes on to claim that it is impossible to create a secure
consumer operating system.  Again, I don't dispute this, but one
could use Steve's own argument against him and claim that it is also
not required to HAVE raw socket capability to implement effective DDoS
attacks.  He himself shows that the response (or lack thereof) of ISPs
to respond to DDoS agents on their customer's systems is inadequate,
even if you can trace the attack agents.

So his main argument remains that you MUST remove raw sockets from
Windows XP as the only effective defense against DDoS attacks,
and this just doesn't fit with my experience.

It seems to me unwise to challenge the very community that has
produced well over a dozen DDoS tools (that I am aware of) to come up
with another tool for Windows XP that forges source addresses to prove
him wrong, since they will likely win that challenge.  At that point,
all the effort to remove raw sockets from Windows XP becomes wasted
effort on a single "solution" to a multi-facetted problem.

There is much more to DDoS than source address forgery, and I wish
Steve would join in promoting the entire suite of solutions instead of
dismissing them.  To see what these are, see:

	http://www.cert.org/reports/dsit_workshop-final.html

For more on the topic of DDoS, I am maintaining a very extensive
web page on the subject:

	http://staff.washington.edu/dittrich/misc/ddos/

Dave Dittrich <dittrich@cac.washington.edu>



Post Script.

After originally writing this piece, I sent it to Steve Gibson for his
comments and mentioned I was about to go public with it.  After an
initial greeting reply, I have not received any comments from Steve.
Since it has been several weeks, I chose to get this out and be done
with it.  I still welcome Steve's comments, only now I guess the reply
will have to be done in public.

I also learned of several other counter examples besides that
provided by Weld Pond:

 o The exists a raw socket implementation for Windows 95, Windows 98,
   Windows Millennium, Windows NT 4.0, Windows 2000, and Windows XP
   (through Beta 2) available at:

	http://www.pcausa.com/

 o The free nmap scanner, which relies on the open source WinPcap
   library, is also capable of source address forgery on Windows 95,
   Windows 98, Windows Millenium, and Windows NT.  WinPcap is
   available from this site:

	http://netgroup-serv.polito.it/winpcap/

   This web page describes WinPcap this way:

       WinPcap is an architecture for packet capture and network
       analysis for the Win32 platforms. It includes a kernel-level
       packet filter, a low-level dynamic link library (packet.dll),
       and a high-level and system-independent library (wpcap.dll,
       based on libpcap version 0.5). 

       The packet filter is a device driver that adds to Windows 95,
       Windows 98, Windows ME, Windows NT and Windows 2000 the ability
       to capture and send raw data from a network card, with the
       possibility to filter and store in a buffer the captured
       packets. 

       Packet.dll is an API that can be used to access directly the
       functions of the packet driver, offering a programming
       interface independent from the Microsoft OS.

       Wpcap.dll exports a set of high level capture primitives that
       are compatible with libpcap, the famous UNIX capture library.
       These functions allow to capture packets in a way independent
       from the underlying network hardware and operating system.

   Source code for nmap is available from:

	http://www.insecure.org/nmap/nmap_download.html

 o While I wouldn't go so far as to say Steve sucks, this web page
   does include another analysis of Steve's claims that includes yet
   more counter-examples:

	http://grcsucks.com/grcdos.htm

 o CERT Advisory 2001-20 discusses several worms affecting Windows NT
   and Windows 2000 systems running unpatched versions of IIS.  These
   incidents involved orders of magnitude more systems than were used
   against Steve's web site, and to my knowledge *none* of these
   tools required raw sockets for DoSing.  CERT notes a marked
   increase in the exploitation of home systems on DSL and cable
   modems, which is a class of systems with very little administrative
   skill and even less ability for their ISPs to contact them.

   You can find this advisory at:

	http://www.cert.org/advisories/CA-2001-20.html


One final post script. An appeals court ruled on the Microsoft Anti
Trust findings of Judge Jackson that I mentioned above.

I would like to take this opportunity to point out that the court did
NOT (as Microsoft supporters are claiming) throw out the case, nor did
it reverse Judge Jackson's findings, or even prevent a breakup from
ever occuring (in fact they supported his finding that Microsoft IS a
monopoly, and the court that will now hear the case may yet decide
to break them up.)  Judge Jackson acted improperly, and the case was
moved to another court because of his actions.  Just because he made a
mistake in speaking to reporters prior to releasing his findings,
doesn't mean his findings were incorrect (again, I challenge you to
read them and try to find untruth -- I found them to be quite
accurate, both historically and technically.)  Two wrongs does not
make Microsoft right.

I was also shocked at the claims of some in the security community
that a breakup of Microsoft would distract them and make the
security posture of their software *worse* as a result.  The
sadmind-IIS worm, the "Code Red" worm, the "Power" bot (which
uses the same IIS Unicode exploit as the sadmind-IIS worm),
all have shown that a vulnerability in a program used by a very large
population can cause a nightmare in responding to situations such as
these worms.  Claims of "no customer complaints" fly in the face
of the hundreds of thousands of person-hours spent on dealing with
these vulnerable systems, some of which sat for months and were
compromised multiple times before someone could reach the owners.

(It should also be noted that "Code Red" also compromised
Microsoft's Update web server, the site used to automatically
distribute updates to those same unskilled administrators noted
above.  The thought that a software update server was trivially
compromisable by a several month old exploit shows just how fragile
the basic infrastructure of the consumer Internet really is, and
how much larger a problem there is than a raw socket implementation.)

I seriously doubt that that a breakup could make this situation any
worse than it already is, and I've always felt that if Microsoft
took half of the money they pour into mass marketing or stock
options and put it into paying engineers to try to break their
products like hackers and companies like eEye do, their
software might actually be SAFE to use and a large amount
the DDoS problem that Steve is afraid of would never exist.

I hope this argument about Windows XP raw sockets will end now and we
can get on to what I consider to be the more important, broader issues
surrounding DDoS.


Post Post Script

Now(*) Robert X. Cringely has weighed in with his support of Steve's
effort to get raw sockets removed from Windows XP as the "solution".

Again, I believe Robert comes from the Windows world, not the Unix
world that gave birth to TCP/IP, and sees Windows (in this case end
user) solutions.

Sure, there are weaknesses in TCP/IP, but trying to prevent someone
from exploiting these by removing a capability through vendor software
design is futile.  As I've shown above, there are plenty of ways to
get Windows to do things that Microsoft doesn't code it to do (if not,
Steve Gibson wouldn't even have a software business at all.)

Again, I hope this proposed "solution" will fall off the table.

* The Death of TCP/IP: Why the Age of Internet Innocence is Over
http://www.pbs.org/cringely/pulpit/pulpit20010802.html