Sister CISA CISSP

Jan 22 2009   5:49PM GMT

When a Patch is Not a Fix – We Have the Downadup Worm



Posted by: Arian Eigen Heald
Tags:
Microsoft Windows
Security
Tearing My Hair Out

If you haven’t heard by now, the “downadup” worm (renamed various other things by competing vendors) is propagating itself like crazy across the Internet. Various software vendors have added some artificial hype about how fast it is spreading, but I didn’t get sweaty palms until I read that US_CERT is now saying that the patch/Technote Microsoft released to address the issue doesn’t work.

Here’s how it’s going so far – the worm installs itself via the “autorun” feature that is enabled whenever removable device is connected to a computer. This includes, but is not limited to, inserting a CD or DVD, connecting a USB or FireWire device, or mapping a network drive. This connection can result in code execution without any additional user interaction.

So Microsoft issued an out-of-cycle patch that wasn’t really a patch or a fix – just a workaround. The patch/fix/workaround involves disabling the autorun function inside the Windows registry. The instructions in the Technet article 91525 were incorrect, and did not disable autorun.

So if you’ve done this on your network, and think you are safe…..you’re not.

A newer Microsoft Technet article is available here.

At first I was confused, because the article provides instructions for a way to disable autorun as a “workaround” against the worm propagating itself. The information does not address the vulnerability the worm is actually designed to exploit.

After some more digging, the actual vulnerability we should be concerned about is that the worm employs an attack against the “server” service listed as a Bulletin in October 2008. The exact details from the Security Bulletin MS08-067 are as follows:

“This is a remote code execution vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system remotely. On Microsoft Windows 2000-based, Windows XP-based, and Windows Server 2003-based systems, an attacker could exploit this vulnerability over RPC without authentication and could run arbitrary code. If an exploit attempt fails, this could also lead to a crash in Svchost.exe. If the crash in Svchost.exe occurs, the Server service will be affected. The Server service provides file, print, and named pipe sharing over the network. The vulnerability is caused by the Server service, which does not correctly handle specially crafted RPC requests.”

It seems the only “solution” we are offered from Microsoft for users of anything other than Server 2008 is a manual fix to try and stop propagation.

Where’s the real fix? Not the workaround (which didn’t work). Am I missing something? “Where’s the beef?”

1  Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • SAPjava74
    This is what I referred to in my blog entry yesterday. [A href="http://itknowledgeexchange.techtarget.com/it-trenches/microsoft-guidelines-for-turning-off-windows-autorun-do-not-work-properly/"]Microsoft guidelines for Turning off Windows AutoRun do NOT work properly![/A] This is a BIG concern!
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: