System administrators who oversee SQL Servers have a manic Monday on their hands today.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The Slammer worm continued to attack vulnerable SQL Servers and installations of Microsoft Desktop Engine (MSDE) worldwide today, two days after its initial outbreak around midnight Saturday. Attacks have slowed as Internet service providers worldwide started blocking traffic on UDP port 1434. Vincent Gullotto, vice president of McAfee's Antivirus Emergency Response Team (AVERT), estimates anywhere from 200,000 to 375,000 SQL Servers may have been compromised thus far.
In the meantime, SQL admins are faced with the task of patching vulnerable servers and third-party applications that also may be compromised by Slammer.
Slammer exploits a 6-month-old buffer overflow vulnerability in the SQL Server 2000 Resolution Service. A patch has been available from Microsoft since July 24, 2002 when the company released a critical bulletin detailing the flaw. The worm overruns the service with code and uses UDP port 1434 to search for other vulnerable SQL Servers. This probing generates massive amounts of traffic that succeeded in shutting down major ISPs in the Eastern Europe and Asia, in particular in South Korea and Slovenia, which were essentially unreachable for hours on Saturday.
Gullotto said ISPs are not longer experiencing the latency they were during the attack's peak hours on Saturday.
Chip Andrews, a Gainesville, Ga.-based independent developer who runs a labor-of-love site called SQLSecurity.com, said there is no reason for port 1434 to be open to the Internet. SQL Server defaults to TCP port 1433 as its session port. Only named instances listen on 1434. SQL Resolution Service operates on port 1434 and enables clients to query for the appropriate network endpoints to use for a particular SQL Server instance.
"Most people don't use a named instance," Andrews said. "If port 1434 is exposed to the Internet, there's no call for it." Andrews recommends blocking port 1434 at the firewall and added that most administrators should have done that by this morning.
SQL Server Service Pack 3 contains the patch and hotfixes and administrators should be applying SP3 to vulnerable servers immediately, Andrews said. However, that is not the case for MSDE installations and that could complicate matters for administrators.
MSDE is a data engine based on core SQL Server technology, according to Microsoft. It is a storage engine and query processor for desktop extensions of enterprise applications. Users interact with MSDE through the application in which it is embedded.
As a result, administrators may be unaware they are running vulnerable versions of SQL Server and need to patch those as well, said Russ Cooper, Surgeon General at TruSecure Corp., a Herndon, Va. managed security services provider.
SQLSecurity.com lists 51 applications this morning on its site that may install an MSDE/SQL Server for use as a data source. Andrews said today that the list is growing as users submit suggestions for other affected applications. Among those on the list are: Microsoft Biztalk Server, Visual Studio.NET, .NET Framework SDK, Office XP Developer Edition, MSDN Universal and Enterprise Edition, Compaq Insight Manager, Dell OpenManage, HP Openview Internet Services, SalesLogix, Compaq Insight Manager v7, Patchlink Patch Management System and Microsoft SharePoint Portal Server, among many others. Also on the list are security software products like McAfee Centralized Virus Admin, Chubb security system, McAfee Epolicy Orchestrator and Trend Micro Damage Cleanup Server 1.0.
Andrews and Cooper said that Microsoft makes patching SQL Server difficult, and therefore, busy network or system administrators may not respond immediately, even to announcements of critical flaws.
"The manual is this multi-step readme file and it involves moving files around, registry changes and permissions," Andrews said. "It's ugly and liable to introduce human error at any step."
Andrews echoes the sentiments of many Windows admins that Microsoft should automate the patch-installation process.
"This isn't something open source that I downloaded and that I should be writing script for. This is something people pay a lot of money for and Microsoft should make the installer handle these steps rather than make it a manual process," he said.
FOR MORE INFORMATION:
- FEEDBACK: Share some of your Microsoft patching nightmares.
Send your comments to News Editor Michael S. Mimoso