Microsoft gives green light on WMF to One Care

Well, after almost two days of the exploit Microsoft has come forward with Advisory 912840 that suggests several
things:

  1. This is more than just a hole in fully patched XP and 2003 (9x and 2K have been added to the list). Not much of a surprise there.
  2. The scope of the infection/attack is still vague, so there is no public advice yet on how to consistently close the hole. That’s something of a surprise, especially since Microsoft has announced that if you are part of their “One Care” program you are protected.
  3. Note: the One Care reference is wmf1228. Yet another vulnerability database…wonder what happens if you get two distinct WMF exploits on Dec 28th? Do they go to wmf1228a and wmf1228b? And next year when another WMF explot is launched on the same day? Do they switch to wmf061228a? Seems like someone isn’t thinking too carefully about even the simple things, but I digress…

  4. Microsoft really really wants you to contact the authorities, whether it be the FBI, Internet Fraud Complaint Center, or your local alternative.

So, I’m not sure I’m reading this announcement properly, but it raises an interesting question: Should a company be liable for damages from a defect if they have a fix but are not distributing it to anyone outside a subscription/maintenance program? Aside from all the details about fees and testing, etc. I am getting more and more curious why information about the patch (other than “if you use One Care and your light is green, then you are safe”) is not being released more quickly, since it obviously can’t be a good thing for Microsoft to delay and risk damage to all the non-One Care customers.

Edited to add: Some have suggested to me that the One Care fix is actually nothing more than an automated version of the suggestion on the Microsoft Alert:

Microsoft has tested the following workaround. While this workaround will not correct the underlying vulnerability, it will help block known attack vectors. When a workaround reduces functionality, it is identified in the following section.

Un-register the Windows Picture and Fax Viewer (Shimgvw.dll) on Windows XP Service Pack 1; Windows XP Service Pack 2; Windows Server 2003 and Windows Server 2003 Service Pack 1

Note The following steps require Administrative privileges.

To un-register Shimgvw.dll, follow these steps:

  1. Click Start, click Run, type “regsvr32 -u %windir%\system32\shimgvw.dll” (without the quotation marks), and then click OK.
  2. A dialog box appears to confirm that the un-registration process has succeeded. Click OK to close the dialog box.

Impact of Workaround: The Windows Picture and Fax Viewer will no longer be started when users click on a link to an image type that is associated with the Windows Picture and Fax Viewer.

Also, f-secure has said that they think this step is actually a really good idea, and that “leaving image editors out completely for the rest of the year might be a good idea.” I’ll defer to their expertise (and inside scoop) on the malware, but sometimes it is hard to tell whether they are serious or just have a really dry sense of humor.

Surveillance disobedience

Wired has an interesting write-up of the methods used by an Austrian civil liberties group to protest and monitor the use of surveillance cameras in public spaces:

Members of the organization worked out a way to intercept the camera images with an inexpensive, 1-GHz satellite receiver. The signal could then be descrambled using hardware designed to enhance copy-protected video as it’s transferred from DVD to VHS tape.

[…]

And, just for fun, the group created an anonymous surveillance system that uses face-recognition software to place a black stripe over the eyes of people whose images are recorded.

So you can check the data to see if you’ve been watched. Obviously this compromises the deterence-by-obscurity of surveillance systems, but that’s not what they’re best for anyway. In fact, although I’m a big fan of using technology for detective controls I try to always warn against trying to use cameras as a deterrent/preventive control. In other words the ability of a camera to put fear into the heart of the enemy is really a function of social engineering and has little/nothing to do with the actual (core) capabilities of surveillance systems, and moreover it can end up defeating the very purpose of the cameras — to create a space reasonably free of fear.

Oh, and if any camera vendors are reading, PLEASE stop using unique URLs for network access. I admit I had not choice but to compromise on some things in my last purchase (what’s up with the lack of native support for SSH/HTTPS?) but I would never buy a system that used a fingerprint in the URL (e.g. axis-cgi/). Talk about a reality check for those who think network video recorder obscurity is effective…

Grow your own fuel?

Whoa, the Seattle Times reports that Washington state is talking about low-interest loans for “biodiesel factories”. Just the fact that they call them factories instead of refineries means they probably are actually hoping that this will take off on a distributed level:

Gov. Christine Gregoire recently proposed low-interest loans for biodiesel factories, and a requirement that diesel sold in the state contain at least some biodiesel. State lawmakers from both parties are vowing to promote similar plans when the Legislature convenes next month. And Congress last summer included a tax credit for biodiesel in its energy bill.

Frankly, this seems very lopsided compared to the information technology revolution that led to the Personal Computer. Companies like Microsoft that kludged together some flimsy DOS system, sold it to a couple big customers and…the rest is history. But the energy age seems to be struggling with generating a reliable source of energy to be converted, rather than the efficiency of doing the conversion itself.

I think growing greens for oils (or processing fish, meat, etc.) might not be the best approach, since you could actually get another use out of the oil first and then process the remaining waste. We still find that each small restaurant produces 20 gallons of waste oil a week, with larger productions reaching 50-100 gallons a week. I will verify that this Friday, but what if you can tap into the waste issues of resort-towns with their close concentration of hotels and affiliated restaurants, or strip malls, or even large malls? It seems best for municipalities and counties to promote that for every 1,000 gallons/week of waste oils they will subsidize establishment of a bio-diesel station. Thus you are not only focusing production of the bio-diesel around a ready supply, but you are also reducing waste/land-fill issues.

I’m not suggesting that farmers shouldn’t grow their own fuel, but it seems to me that it would be better to convert to plain oil and retain flexibility by diversifying output options — they might be able to do a minor conversion to sell to restaurants, manufacturing, energy, etc.

One thing is for certain, beware the opportunists who pose as engineers:

“You have seen a lot of snake-oil salesmen come through with the next best thing,” acknowledged Conklin, the Palouse Biodiesel president.

Both examples in the story (straw-board and beets) illustrate what happens when a concept is marketed and sold as ready for production before it even has been properly tested (quality problems and equipment failures). And because that brings me back to the issues of security in a system development lifecycle (SDLC), I think I’ll categorize this post as security too.

US-CERT on the WMF exploit

At the end of the day I finally recieved a notice from US-CERT (http://www.us-cert.gov/cas/techalerts/TA05-362A.html)

Not all anti-virus software products are currently able to detect all known variants of exploits for this vulnerability. However, US-CERT recommends updating anti-virus signatures as frequently as practical to provide maximum protection as new variants appear.

US-CERT is tracking this issue as VU#181038. This reference number corresponds to CVE entry CVE-2005-4560.

Got that? This is VU#181038, filed under CVE-2005-4560 and available online as TA05-362A. Roger that.

Anyway, they supported the recommendations by F-secure and Sunbelt:

  • Do not access Windows Metafiles from untrusted sources
  • Block access to Windows Metafiles at network perimeters
  • Reset the program association for Windows Metafiles

I had a brief discussion today with some admins and told them I disagree with the latter recommendation. No one seemed to object, perhaps because it would be such a royal pain to implement thoroughly and it might not even be effective, but who knows at this point. So we’ve rolled out the top two (plus HTTP and SMTP filtering) and are observing traffic.

I posted some of the same info over on Bruce’s blog