SQL-UDP

Conclusion

To digress into the social issues around vulnerability research for a moment, the frightening thing about the SQL-UDP bug was the speed with which the stack overflow was found; literally five minutes of investigation was all it took. It was obvious to us that if we could find the bug this quickly, other, perhaps less responsible, people would also be very likely to find it and possibly use it to compromise systems. We reported the bug to Microsoft in the usual manner, and both we and Microsoft were extremely vocal about trying to get organizations to apply the patch and block UDP 1434 (it's only used if an SQL client is unsure of how to connect to an SQL Server instance).

Unfortunately, a large number of organizations did nothing about the bug and then, exactly six months after the patch was released, some (as yet unknown) individual decided to write and release the Slammer worm, causing significant Internet congestion and imposing an administrative headache on thousands of organizations.

While it's true that the Slammer worm could have been much worse , it was still depressing that people didn't protect themselves sufficiently to thwart it. It's difficult to see what security companies can do to prevent this kind of problem from occurring in the future. In all the most widely reported casesSlammer, Code Red (based on the IIS .ida bug found by another of this book's co-authors, Riley Hassel), Nimda (the same bug), and the Blaster worm (based on the RPC-DCOM bug that The Last Stages of Delirium group found)the companies involved worked responsibly with the vendors to ensure that a patch and good-quality workaround information was available before publishing information about the vulnerabilities. Yet, in each case someone built a worm that exploited the bug and released it, and caused massive damage.

It's tempting to stop researching software flaws when this kind of thing happens, but the alternative is far worse. Researchers don't create the bugs, they find them. Microsoft released 72 distinct security patches in 2002, some of them to fix multiple bugs. The count for 2003 is currently 38 and rising . At the beginning of 2002, all Windows systems were vulnerable to about 100 bugs , some of which would allow an attacker to gain complete control of the machine.

If you are a Linux user , don't be too dismissive of these problems. According to the ICAT metabase, Linux had 109 flaws during the same period, although this figure is somewhat difficult to pin down, because it depends on how you search. The recent SSH and Apache SSL and chunked-encoding bugs are good examples of Linux problems.

If you are a Macintosh user, you still cannot dismiss Microsoft with its viruses and worms and Linux with its SSH and SSL flaws and multitude of privilege elevation issues. The number of people actively researching and publishing flaws on the Mac platform is currently extremely small, but just because no one is looking for bugs doesn't mean that they aren't there. Time will tell.

If you imagine a world in which no one had carried out any vulnerability researcheither for legal reasons or because they just couldn't be botheredall these phenomenally dangerous bugs would still be there and available for use by anyone who wanted to take control of our machines and networks for whatever reason. We would have little hope of defending ourselves against criminals, governments , terrorists, and even commercial competitors because of the absence of information. Because people have found these bugs, vendors have had to fix them, and we therefore have had some measure of defense.

Vulnerability research is simply a process of understanding what's running on your machine. Researchers don't create flaws where previously there were none. They simply shed light on what we (and our customers) are running in our networks. Hopefully, this book will help you understand the problems and further illuminate the subject.