Invasive DRM systems are dangerous from a security perspective

In recent times, it seems to be an increasing trend for anti-copying software DRM systems to install invasive privileged software. For example, there’s the ever so infamous “Sony DRM Rootkit” that Mark Russinovich publicly exposed some time ago. Unfortunately, software like this is becoming commonplace nowadays.

Most DRM technologies tend to use unsupported and/or “fringe” techniques to make themselves difficult to understand and debug. However, more often than not, the DRM authors often get little things wrong with their anti-debug/anti-hack implementations, and when you’re running in a privileged space, “little things wrong” can translate into a security vulnerability.

Yesterday, Microsoft published a security advisory concerning a privileged DRM system (Macrovision’s SafeDisc, secdrv.sys) that happened to have a security bug in it. Security bugs in privileged parts of DRM code are certainly nothing new in this day and age, but what makes this case interesting is that here, Microsoft shipped the affected code with the operating system since Windows XP. To make matters worse, the code (a kernel driver) is running by default on all Windows XP x64 and Windows Server 2003 x64 systems. (The bug is reportedly not present in the Windows Vista implementation of the driver in question.) On x64 versions of Windows, the driver even runs if you have no programs running (or even installed) that use SafeDisc. Curiously, this does not appear to be the case for x86 versions of Windows XP and Windows Server 2003, for which secdrv is configured as a demand start driver.

I’ve always wondered how Macrovision managed to talk Microsoft into shipping a third party, software only driver, which for x64 versions of Windows is always enabled (secdrv has, as previously mentioned, been on every Windows box since Windows XP, although it is not automatically started on x86 versions of Windows). Doing so always seemed rather… distasteful to me, but the situation becomes even more unfortunate when the code in question has a security bug (a kernel memory overwrite – local privilege escalation – bug, as far as I know). I’m sure all the Windows Terminal Server admins out there will really just love having to reboot their Windows Server 2003 x64 TS boxes because a buggy video game DRM system was shipped with the OS and is on by default, despite the fact that there’s almost zero chance that any software that would have used Macrovision would possibly ever end up on a server OS install.

In this respect, I think that DRM systems are going to be high priority targets for security bugs in this increasingly digitally-restricted world. With more and more content and software being locked up by DRM, said DRM systems become increasingly widespread and attractive targets for attack. Furthermore, from observing the seemingly never-ending wars between Sony, Macrovision, and others against persons who reverse engineer the DRM systems these companies distribute, it would seem that there is in fact already a fair amount of incentive for “unsavory” individuals to be taking these DRM systems apart, security bugs nonwithstanding.

To make matters worse, due to their extremely secretive nature, it’s highly questionable whether DRM systems get proper (and effective) code and design reviews. In fact, this point is even more worrisome (in my opinion) when one considers that software DRM systems are virtually by definition engineered to be difficult to understand (so as to be more resilient to attack through security by obscurity).

The worst thing about bugs with DRM systems is that for a “legitimate” customer that obeys the “rules” and happily installs DRM-ware on their box, they generally can’t ever mitigate the risk by simply disabling the “affected component” without breaking their DRM’d content or software (and good luck trying to ask technical support how to get the protected content to work without DRM, security bugs or not). Most ironically, “unscrupulous” individuals who have hacked around their DRM systems might be more secure in the end than paying customers, if they can access the protected content without involving the DRM system.

Now to be fair, in this case, I’d imagine most users could probably disable the secdrv driver if they wanted to (I doubt anyone running Windows Server 2003 would miss it at all, for one). Still, the fact remains that the vast majority of DRM systems are of amazingly poor quality in terms of robustness and well written code.

This is one of the reasons why I personally am extremely wary of playing games that require administrative privileges or install administrative “helper services” for non-administrative users, because games have a high incidence of including low quality anti-cheat/anti-hack/anti-copying systems nowadays. I simply don’t trust the people behind these systems to get their code right enough to be comfortable with it running with full privileges on my box. From a software security perspective, I tend to rank most DRM technologies right up there with anti-virus software and other dregs of the software security world.

Update: Changed to note that secdrv is configured as auto start only for Windows XP x64 and Windows Server 2003 x64. On x86 versions of these operating systems, it is a demand start driver. The reason for this discrepancy is not known, although one would tend to suspect that it is perhaps an oversight given the behavior on x86 machines.

Tags: ,

13 Responses to “Invasive DRM systems are dangerous from a security perspective”

  1. I rank DRM as being even more vile than AV software simply because AV software rarely blue-screens my machines, whereas certain DRM tends to do so constantly. I bought a copy of Heroes of Might and Magic 5, grabbed all the latest patches, and it blue screens within 5-30 minutes like clockwork on my Vista installs (though it claims Vista compatibility). It’s almost always a different blue screen, too — which is quite a trick! But I eventually traced it down to the SecuROM crap from Sony causing the crashes every time. Needless to say, I won’t be purchasing anything else from Ubisoft in the future (or recommending an otherwise good game). :: sighs ::

    It’s awfully sad when *legitimate* customers actually need to find a way to remove a faulty DRM system from some software simply to get it to work, or to feel secure. Irony?

  2. ase says:

    It is highly ironic.

    You buy it, they still tell you it is THEIR system, and you are not only monitored and data is collected about your habits with personalized … ah well you know what I want to write.
    No need to repeat it over and over again.

    One chance is to inform customers in honest ways how this could lead to potential problems.

  3. Kemp says:

    I’ve noticed recently that several game companies are shipping games without copy protection (or severly cut-down copy protection) and releasing patches for existing games to remove copy protection. Some remove the copy protection after a certain length of time because by that point everyone will have “acquired” a copy by some method anyway (the initial presence of the protection simply being to limit zero-day pirate copies), and some seem to have simply developed a real distaste for it. I know at least two games I own have had it removed due to the sheer number of complaints on the official forums (where legal copies were failing and pirate copies were fine, having had the protection stripped). I feel it is a positive move by the companies as they stop clogging our systems up with the stuff, and hopefully there will be more of a drive to produce better games to actually make them worth our money.

  4. Skywing says:

    Yep, that is definitely a positive move forward. BioWare did this with Neverwinter Nights 1 around 1.64 or so if memory serves; unfortunately, that was on the order of years after the initial release.

  5. James S. says:

    I’m not at all surprised that it was shipped with the 64bit operating systems, given Microsoft’s commitment to compatibility. The products that use it didn’t ship with a compatible version and can’t run without it, so Microsoft had little choice. It’s no less unfortunate, of course.

  6. Yuhong Bao says:

    That is where open source DRM can help.

  7. Yuhong Bao says:

    Even if modification is prohibited, a security review still can be done.

  8. ddebug says:

    Can virtualization provide a solution here? Suppose you have
    several copies of virtual guest OS : one for games and DRM infected stuff, another one “clean”. Swap them easily as often as you want.
    All the DRM infected drivers will be jailed in a VM.

  9. Skywing says:

    You can try. However, lots of games don’t perform well in present day virtualized environments due to a lack of performant video card virtualization.

  10. Yuhong Bao says:

    Plus a VM helps a lot in reverse engineering the copy protection.
    BTW, I think these kinds of copy protection is a good example of “security by obscurity”

  11. Yuhong Bao says:

    Plus, one of them, StarForce, don’t seem to care about future hardware compatiblity at all:

  12. Yuhong Bao says:

    That is where PatchGuard may be a good thing. It discourages these kind of hacks.

  13. […] explanation from Microsoft on how parts of the DRM system work click here). A good example is the Macrovision bug that Microsoft built into the Windows XP kernel. A computer user would probably never play the game that the DRM system was designed to work with, […]