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.'"
Upgrade your driver here: http://www.macrovision.com/promolanding/7352.htm
Microsoft Security Advisory(944653)http://www.microsoft.com/technet/security/advisory/944653.mspx
So, the slashdot lameness filter doesn't like the the clip of the microsoft eula I posted because it has too many caps. Well I'm not retyping all of that in lower case, so I guess I'll post another part of the eula that doesn't abuse the caps lock key...
Safedisc is crap anyway. At least up to v2.x can easily be defeated by a generic unpacker, and all versions are vulnerable to loopback mounting e.g. with daemon tools + CureRom.
The 'fixed' secdrv.sys in SECDRVSYS.zip from Macrovision's web site is dated 2006-09-13.
So it has been over a year...
Local privilege escalation.
There are many files included with Windows that corporate desktops don't require. One of my past employers chose to remove any unnecessary files. Even with a large Microsoft contract, Microsoft refused to disclose the details of every bundled DLL and EXE. So a small team of people deleted each file, one by one, and tested every desktop app in use in the company, until they determined the set of files they didn't need. It's almost silly, but if you're determined Microsoft leaves little choice. (I would have used one of those apps that shows every DLL in memory, but the idea is the same.)
This of course causes problems later, like when a patch or service pack requires a DLL that it never needed before. Or one of the custom apps adds a new feature and needs an OS file that's not part of any standard desktop in the company.
Microsoft isn't interested in giving customers exactly what they need. They prefer to generalize the OS to maximize revenue. These are just some of the negative consequences.
Developers: We can use your help.
First paragraph:
...Shrinkwrap licenses are enforceable unless their terms are objectionable on grounds applicable to contracts in general (for example, if they violate a rule of positive law, or if they are unconscionable). Because no one argues that the terms of the license at issue here are troublesome, we remand with instructions to enter judgment for the plaintiff. But it seems the only aspect of the licence that was questioned was the following: This license, which is encoded on the CD-ROM disks as well as printed in the manual, and which appears on a user's screen every time the software runs, limits use of the application program and listings to non-commercial purposes. Other aspects of EULAs, specifically the arbitration clauses, have been found to be unconscionable ( http://games.slashdot.org/article.pl?sid=07/06/08/2017257 ). It all depends on which part of the EULA you're going after.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.
This is not very good legal analysis or advice. EULAs are far no "untested" (though, the same is not necessarily true for browsewrap agreements).
EULAs are very much enforceable and have definitely been held up in court. Like any contract, though, some have certainly been found to be unenforceable in their entirety or in part. Those that are denied enforceability have some other procedural or technical flaw, usually proper notice.
In addition, as between a company and a consumer, there are definitely some hurdles to enforcing certain provisions like arbitration, choice of law and choice of venue. These can frequently be much more unreasonable than a court is willing to stand. This may also be true with respect to a waiver of liability or consequential damages. That said, the issue isn't whether the EULA in and of itself is enforceable, but instead whether there is proper notice of the clauses or whether such clauses are unconscionable.
Also, despite what slashdotters like to think, EULAs almost certainly meet the requirements of contracts: offer ("take it or leave it"), acceptance (by signature or performance) and consideration (in exchange for the right to use the software at the price I'm selling it to you, you agree to these other terms).
I have never seen a coherent argument that would state a EULA was per se unenforceable. Indeed, I would doubt seriously that such an argument would pass the laugh test. Nevertheless, if you want to argue that there's no signature (a frequent comment), take a look at the definition of "electronic signature" in E-SIGN or UETA. In both cases, a "process" (think clicking "I accept") can be a signature. Finally, acceptance can also be shown by performance. Also, there's a great big body of case law that assumes acceptance of a contract where there is performance by both parties--notwithstanding the other requirements.
While IAAL, none of this is legal advice. Enforceability of a contract is very fact specific (see the guy who couldn't see the terms because his monitor wasn't working). If you have questions, definitely seek the advice of your own lawyer who will evaluate your situation under your own facts.
This issue is most likely related to the way they secure their code by assembling and creating run time executable code and then injecting it into a random portion of its own allocated kernel memory to further avoid debugging. I have seen these games fail because of this with memory protection bit turned on. I suspect their own use of randomness and polymorphic code opens the driver to malicious use and make it harder to detect between intended and malicious intent. I am curious if they can fix this without removing some of their own security.
What I have always found interesting is that it does not fail with software executable protection turned on but does with hardware. This implies Windows understands how this drivers functions and allows it. The issue may be worse that one thinks. Thanks again DRM.
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.