News Stay informed about the latest enterprise technology news and product updates.

Expert: Slammer could have been worse

Bug finder David Litchfield discovered the vulnerability in SQL Servers currently being exploited by the Slammer worm and comments that the impact could have been much worse.

The discoverer of the SQL Server 2000 vulnerability being exploited by the Slammer worm said this morning that while the worm is no picnic, it could have been much worse.

While Slammer choked many Internet service providers and networks over the weekend, it didn't have a destructive payload, said David Litchfield, a well-known vulnerability-finder and co-founder of Next Generation Security Software, which is based in Sutton, England. "It could have been so much more nasty," he said. "It appears they wrote it to prove a point."

Slammer exploits the six-month-old SQL Server Resolution Service buffer overflow flaw that Litchfield discovered. While the worm isn't destructive and only attacks Windows 2000 systems, it can gum up networks by generating massive amounts of traffic. It then scans random IP addresses looking for other vulnerable servers.

The best way to prevent getting the worm would be patching the system, Litchfield said. Companies can block traffic at the firewall requesting UDP port 1434. This move may hamper some Web browsing as DNS servers often use that port when processing requests. "The user would only need to refresh their browser and then they will get through with port 1435," he said, noting administrators should evaluate how blocking port 1434 traffic would affect their specific systems before doing so.

Chip Andrews, a Gainesville, Ga.-based independent developer who runs labor-of-love Web site, urges administrators to block 1434 outright. "If port 1434 is exposed to the Internet, there's no call for it," he said. "I would imagine most administrators went in and set their firewall rules over the weekend [to block UDP port 1434]. There shouldn't be spikes today as companies get back to work."

Slammer appeared six months to the day that Microsoft released the patch for the vulnerability. Litchfield found the flaw while doing a penetration test for a bank in Germany. They wanted 'no stone left unturned,' Litchfield said, noting he found the SQL Server flaw and several other vulnerabilities while looking for new issues.

Litchfield could say, "I told you so" as he predicted last summer at the BlackHat Security Briefings that the flaw could easily be exploited by a worm. "I explained that this was ripe for exploitation by a worm and it was/is imperative that this be patched by everyone to prevent such a worm," he said.

The vulnerability itself is a classic, stacked-based buffer overflow. Essentially, attackers have to flood the allocated memory space with more data than it can hold. The excess data is then executed by the affected system. This is particularly dangerous in the case of Slammer as SQL Server and Microsoft SQL Server Desktop Engine (MSDE) usually run with local privileges. With such system privileges, attackers could, in other words, steal or manipulate data on a vulnerable SQL database, Litchfield said.

The worm could have been much worse. "If the author of the worm had written in such a way that the source UDP port of every packet it sent out was 53 (used by Domain Name System servers and left open by most enterprises) then many more SQL Servers would have been compromised exacerbating the problem," Litchfield said.

FOR MORE INFORMATION: news exclusive: "Manic Monday for SQL Server admins" news exclusive: "Update: SQL worm slows Internet; some root DNS servers down" news exclusive: "Initial SQL worm cleanup simple, patching may not be so easy"

Microsoft Security Bulletin MS02-039

  • FEEDBACK: Share some of your Microsoft patching nightmares.
    Send your comments to News Editor Edward Hurley

Dig Deeper on Malware, virus, Trojan and spyware protection and removal

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.