Zotob Worm Plagues Windows. Microsoft “Mobilizes War Rooms”

CNN is covering Zotob, the latest worm plaguing the Windows platform [hat tip: Slashdot]:

The director of Microsoft’s security response center, Debbie Fry Wilson, said the computer giant was in an “emergency response” mode. “Right now, we’re mobilizing our two war rooms,” she told CNN. [ Read More ]

What is this? Fox News?

Here’s the technical dirt on Zotob. Wikipedia has also initiated coverage of the Zotob worm.

It apparently does a buffer overflow exploit on Windows 2000 and XP machines running the LSASS service on TCP port 445, just as the Sasser worm did before it.

It’s a shame this service is still running on a default installation of Windows 2000 and XP. Machines with all the latest security patches should be doing OK. Update 08/18/2005: Ian Betteridge, mentions in comments:

Actually, default installs of XP – even early ones – aren’t vulnerable to Zotob. In order to be vulnerable, someone has to deliberately change settings in the register to allow the computer to list system resources without requiring a login – a scenario that’s very rare at best (I can’t think of any reason that a user would ever do this).

Operating system vendors need to distinguish between “Client” and “Server” distributions of their operating system. The vast majority of end-users, even advanced users, do not need, on a default installation, to be running any service listening on any port. They won’t get infected through a service they’re not running.

Apple has grokked this very simple philosophy a long time ago. This is why you have Mac OS X Server for people in the business of running servers. And Mac OS X Client, for the rest of us. Both are equally advanced versions of the same operating system, they’re simply configured differently for different purposes. Relatively speaking, it should be orders of magnitude harder to infect a default installation of Mac OS X Client, than it would be to infect a default installation of Mac OS X Server. In a fictitious World where Mac OS X were to be deployed on 90% of all computers out there, the vast majority of them, owned by consumers, would be running its Client version. As it has no open ports by default, it would be impossible to infect it without active user participation.

Speaking of patches, Apple has recently released a big ol’ Mac OS X Security Update, available through your Software Update. I haven’t dug through it yet, feel free to give your thoughts in comments!

Speaking of Security Update, I’ll spend a second shamelessly tooting my horn: Some time before Christmas, I’d found a security issue in Safari, through which it was possible to inject a javascript: URL to a named window or frame that lived in a different domain, thereby bypassing host-and-domain-level cross-frame/window scripting permissions built into all browsers.

Apple jumped on the issue right-away to get it fixed. At first we’d thought other browsers and platforms were affected, so Apple and I agreed on holding-off disclosing the fix with the Security Update that went out in January, to give ourselves more time to test other platforms and notify them if needed. Windows Internet Explorer didn’t seem to throw an error warning, but was instead silently crapping out. All Mozilla browsers gave a very clear error message. The threat eventually appeared to end-up being localized to Safari. It got fixed quickly. Meanwhile we all moved-on with our daily grind, and I never got around to follow-up with Apple on getting some back-credit.

I’d built a gnarly proof-of-concept exploit that added a DVD to your Amazon.com shopping cart without your knowledge, upon loading a web page on my personal web account. Needless to say, we were all insanely anxious to plug that hole. Thankfully, it was a quick and easy fix too. Shouts out to James Imajes for helping me test and refine the exploit. As a reminder, Safari’s core components are now part of the WebKit Open-Source project since WWDC 2005. The beauty of Open-Source allows anybody in the World to help strengthen Safari’s core platform.

In your Safari JavaScript console, you might one day see a message that resembles this:

Unsafe JavaScript attempt to access frame with URL [url 1] from frame with URL [url 2]. Domains must match.

Since the fix, I’ve noticed a couple of naughty ad banners served by mainstream networks trigger this warning. Those were however likely harmless.

What’s your experience communicating security issues to Apple? Get your 5-minutes of fame right here!


Comments have been disabled for this post