« | Home | Categories | »

Microsoft and FairUse4WM

Posted on September 7th, 2006 at 19:20 by John Sinteur in category: Microsoft, Security -- Write a comment


If you really want to see Microsoft scramble to patch a hole in its software, don’t look to vulnerabilities that impact countless Internet Explorer users or give intruders control of thousands of Windows machines. Just crack Redmond’s DRM.

Security patches used to be rare. Software vendors were happy to pretend that vulnerabilities in their products were illusory — and then quietly fix the problem in the next software release.


Since 2003, Microsoft’s strategy to balance these costs and benefits has been to batch patches: instead of issuing them one at a time, it’s been issuing them all together on the second Tuesday of each month. This decreases Microsoft’s development costs and increases the reliability of its patches.

The user pays for this strategy by remaining open to known vulnerabilities for up to a month. On the other hand, users benefit from a predictable schedule: Microsoft can test all the patches that are going out at the same time, which means that patches are more reliable and users are able to install them faster with more confidence.

In the absence of regulation, software liability, or some other mechanism to make unpatched software costly for the vendor, “Patch Tuesday” is the best users are likely to get.

Why? Because it makes near-term financial sense to Microsoft. The company is not a public charity, and if the internet suffers, or if computers are compromised en masse, the economic impact on Microsoft is still minimal.

Microsoft is in the business of making money, and keeping users secure by patching its software is only incidental to that goal.

There’s no better example of this of this principle in action than Microsoft’s behavior around the vulnerability in its digital rights management software PlaysForSure.

Last week, a hacker developed an application called FairUse4WM that strips the copy protection from Windows Media DRM 10 and 11 files.

Now, this isn’t a “vulnerability” in the normal sense of the word: digital rights management is not a feature that users want. Being able to remove copy protection is a good thing for some users, and completely irrelevant for everyone else. No user is ever going to say: “Oh no. I can now play the music I bought for my computer in my car. I must install a patch so I can’t do that anymore.”

But to Microsoft, this vulnerability is a big deal. It affects the company’s relationship with major record labels. It affects the company’s product offerings. It affects the company’s bottom line. Fixing this “vulnerability” is in the company’s best interest; never mind the customer.

So Microsoft wasted no time; it issued a patch three days after learning about the hack. There’s no month-long wait for copyright holders who rely on Microsoft’s DRM.

This clearly demonstrates that economics is a much more powerful motivator than security.

It should surprise no one that the system didn’t stay patched for long. FairUse4WM 1.2 gets around Microsoft’s patch, and also circumvents the copy protection in Windows Media DRM 9 and 11beta2 files.

And it’s clear economics dictate that Microsoft doesn’t care about their customers. Are you sure you want to buy products from a company when it is this easy to demonstrate the company doesn’t have to care if the product actually works for you?

  1. This is really slanted. I’m disappointed that Schneier is willing to ignore obvious explanations why things might work this way in order to further his agenda. In a company as large as Microsoft, a generalized patch release process necessarily has a fair bit of overhead, and a predictable pathway, QA process, and schedule make it more tractible. The DRM patch is not a patch to Windows but to a specific toolkit, and comes from a specific, small team that does not need to run the gauntlet that’s in place for general Windows patches. Hence, separate patches.

    You don’t need this B.S. to argue that Microsoft “doesn’t care if the product actually works”. All you need is to observe that they have an effective monopoly in the desktop OS market, and a competitive position in the DRM market.

  2. I’m not buying your argument. Microsoft has sent out two messages the last few years: “Dear world, security is paramount, *every* deparment is part of this new Microsoft and we really mean it this time” and two: “dear largest customers, we are listening you, want to keep you as a client, so every patch is now part of the monthly cycle so you can do your work”.

    What possible reasons are there to deviate from these two things: the first one might be argued away with the remark that this isn’t a security patch, but in that case you can also immediately argue “ah, so there’s no rush then”. The second message can only be argued away with “this patch is important enough that we’re willing to piss off our large customers”.

    So, here are the choices:

    1) microsoft was grossly incompetent and multiple departments were asleep at the wheel, and that’s why this one slipped through the process. It wasn’t meant to happen this way.
    2) microsoft was lying when they told their large customers their concerns were important enough to create the monthly patch cycle, and is only doing the patch cycle to keep up appareances, and minor patches are allowed to slip through because in the end microsoft doesn’t really care about large customers
    3) microsoft felt this patch was important enough to bypass the regular patch process. For very important patches, there must always be this bypass process.

    I don’t believe 1 or 2, so what remains is the question “why was this patch so important they decided to bypass the process”?

  3. Show me a real alternative. I have to.

  4. Patch Tuesday == Windows Update.
    DRM fix == Windows Media SDK fix.

    The two are independent, the patch bypasses the monthly release cycle because it’s not considered part of that product.

  5. Note that it is not an SDK fix. From the patch documentation:


    Content services can require that the updates be present in order to issue licenses by following the instructions below.

    (bold tags inserted by me) The patch is on a piece of client software, not SDK software. Microsoft has promised that client patches are part of patch tuesday.

  6. Microsoft is making available an updated runtime binary so that ISVs who use the binary can have their app update it on the client’s machine through a channel separate from Windows Update. You’re arguing (I think) that this breaks Microsoft promise to only release OS updates on Patch Tuesday. This becomes a semantic argument whether the limited distribution release is an OS update or a third party software component update. We’ll have to disagree there.

    But Schneier argued that this shows Microsoft’s economic incentives, and I still maintain that there are perfectly good alternate explanations why this patch can get out the door faster than a normal all-machines-everywhere patch.

  7. I agree that we disagree on this one, and it’s a very basic disagreement – if it is an OS update, there cannot be any reason not to use patch tuesday. If it is not an OS upgrade, it would still be advisable to limit it to patch tuesday except for very good alternate explanations, and although I don’t think such an explanation was given, I’ll admit that this thinking is of course influenced by my opinion on the nature of the patch.

  8. When I looked yesterday there was no WM/DRM patch available from Windows Update. You apparently only get it if you have an app installed that pushes the update to you. (FWIW, I use Real Rhapsody, which uses Windows DRM, and which hasn’t required any updating yet.)

    So most customers won’t see (*can’t* see) this patch until Patch Tuesday, in particular the IT shops that insist on regular update cycles.

  9. But some will, and it’s the unpredictability of the appearance of the patch that is killing for IT shops. Even if none of the computers that are managed by a particular IT shop see the patch ’till tuesday.

  10. You know, I can’t find it in the Patch Tuesday updates.

    Is it possible that maybe this component isn’t part of the standard WMP files and _really_ is a runtime binary distributed only as an SDK component?

  11. I don’t know. I know on the Mac there’s quite a bunch of “optional” software by Apple, software you need to pay for (like Final Cut Studio, Aperture, Logic Pro, etc) that’s part of the automatic software update process. If you don’t have that software, you won’t see the updates, but if you do have the software, you see the updates. I assume that subscribers to bulk-contracts with Apple (if such a thing exists, I don’t really know) will see the update as well and are able to control it for the clients they have. I would assume/hope that MS does the same: optional components are part of the regular update process in the same way: you’ll only see the patches if you have the component OR if you’re a large account that need to control it for lots of boxes.

  12. Except that this is supposedly a bug in Windows Media DRM, and everyone has Windows Media Player installed. Except for maybe some nutcases in the EU. 🙂 And I run Rhapsody, which certainly uses WM DRM. So I should be getting the update if there is one.

    …or maybe the Schneier rant was unwarranted…

  13. or, microsoft has been making a lot of noise about the patch to content providers but didn’t really follow-up – as in “dear mpaa/riaa, see how important we think this is, we bypassed patch tuesday for you and you alone because we love you” whilst at the same time the patch is indeed waiting for the next tuesday-set.

    By now I don’t really know what to think anymore.

previous post: Marriage

next post: Rhymes with Orange