AntiPiracy Macrovision Bug is Actually Six Years Old

twitter writes "A recently reported Macrovision bug has actually been around for six years, according to Computerworld. 'Flawed antipiracy software now being exploited by attackers has been bundled with Windows for the last six years to protect game publishers, Macrovision Corp. said today. The "secdrv.sys" driver has shipped with all versions of Windows XP, Windows Server 2003 and Windows Vista ... users do not have to play a SafeDisc-protected game to be vulnerable.' The article goes on to play down danger and claim that Vista is safe, but ZDNet notes: 'Malware authors are actively exploiting a zero-day privilege escalation vulnerability ... [which] can be exploited overwrite arbitrary kernel memory and execute arbitrary code with SYSTEM privileges. This facilitates the complete compromise of affected computers.'"

Comments

Here is update (Macrovision SECDRV.SYS Driver)

[holywarrior21c]

Upgrade your driver here: http://www.macrovision.com/promolanding/7352.htm
Microsoft Security Advisory(944653)http://www.microsoft.com/technet/security/advisory/944653.mspx

I've played this game from both sides.

[argent]

Every time this is discussed on Slashdot there are comments from Slashdotters who legitimately purchase games and then download cracked versions because the crippled, boxed versions are too much hassle.

I did that around 1981 when I went to the local "unlicensed software distributors" at the University to get a cracked copy of Wizardry written out on top of my gold-labeled store-bought floppy because the copy protection had made the original unplayable... which meant I may have had the only "legal" cracked copy in existence. I ran into the author of the game online many years later, and he thought that was pretty amusing.

Several years later a friend and I released a game for the Amiga and since the publisher required copy protection we came up with a copy protection scheme for it that didn't require modifying the OS or bypassing the driver, and allowed the protected disks to be created using a regular script. Since we knew that copy protection was a speedbump, we came up with some speedbump-quality protection that would still do a better job at blocking the most common cracking tools than the "professional" and more intrusive protection schemes.

What we did was take advantage of the way the Amiga identified disks by using a unique ID in the disk header. All copy protection cracking tools we knew of generated a new ID by default, so that the user wouldn't get an error from the OS if they left the original and the copy both in the drives after they exited the program. We stored an obfuscated copy of the ID in file comments, and ran in "demo mode" if they didn't match. It didn't pop up any warning screens, it just wouldn't let you get past the 'attract mode' display. This meant that most people just using a "raw" copier would get an apparently "damaged" copy that still kind of worked... we figured this was unintrusive and at least as good a speedbump as you got from a scheme that had defeat code preprogrammed into the copying tools, for the week or so before it got figured out and our scheme got added to the rest.

We provided our publisher with detailed instructions, explanations, and a set of disks to use to create the copies if they didn't use an image duplicator. They fobbed production off on another company who blithely used one of the cracking tools we were targeting to do the production run. If they'd used a normal image duplicator or our scripts everything would have been fine, but instead all the shipped copies came up in demo mode. Of course the game had to be recalled, and we missed the Christmas launch.

Copy protection (whether you call it copy protection or DRM) increases the costs and risks of production and just plain doesn't do anything more than flashing a "don't pirate this game" splash screen would.

Local Exploit Only, and Very Unlikely

[ThinkFr33ly]

This can only be exploited locally, so the chances it will affect any significant number of people are very small.

Since virtually everybody who uses Windows XP runs as admin, there would be no reason to use this exploit, since if you get code to run on the target machine, it's already running as admin.

For Windows Server, a bad guy with local access is going to be rare, and most admins don't usually download and run random code on their servers. The one exception might be a server used as a terminal services provider, but I can't imagine that's particularly common. Plus, standard domain policy best practices would prevent unsigned/unapproved code from being run by any non-admin anyway, so it's really not an issue.

Lastly, Vista isn't affected, both because it includes the newer version of the DLL, and because the privilege elevation itself would not be possible thanks to some new security measures in Vista's kernel.

So while it makes a great "DRM Sucks!" story, the security ramifications of this bug are essentially zero.