Alex and I are working on an academic paper, “Lessons from the Sony CD DRM Episode”, which will analyze several not-yet-discussed aspects of the XCP and MediaMax CD copy protection technologies, and will try to put the Sony CD episode in context and draw lessons for the future. We’ll post the complete paper here next week. Until then, we’ll post drafts of a few sections here. We have two reasons for this: we hope the postings will be interesting in themselves, and we hope your comments will help us improve the paper.
Today’s section is part of the technical core of the paper.
Please note that this is a draft and should not be formally quoted or cited. The final version of our entire paper will be posted here when it is ready.
Unauthorized Deactivation Attacks
As described previously, active protection methods rely on installing and running software components that interfere when ordinary software tries to access the disc. If an adversary can remove or deactivate the active protection software, then the DRM scheme will fail to prevent arbitrary use or ripping of the music on the disc. In this section we discuss such deactivation attacks.
One attack strategy is to manually deactivate or uninstall the active protection software. This can be done by using standard system administration tools, which are designed to find, characterize, and control the programs installed on a machine. This attack is very difficult to stop if the user has system administrator privileges on the machine.
Deactivating MediaMax
The MediaMax active protection software is simple to deactivate since it is comprised of a single device driver with a consistent service name, sbcphid. The driver can be removed by using the Windows command sc delete sbcphid to stop the driver, and then removing the sbcphid.sys file containing the driver code. Once the driver is deactivated, MediaMax-protected albums can be accessed as if they were unprotected.
Defenses Against Deactivation
To counter these deactivation attacks, a vendor might try to use technical tricks to evade detection and frustrate removal of the active protection software. The best example of this kind of defense is the rootkit-like behavior of XCP, famously discovered by Mark Russinovich [citation], as described earlier.
When XCP installs its active protection software, it also installs a second program—the rootkit—that hides the software’s presence. Specifically, it conceals any file, process, or registry key with a name that begins with the prefix $sys$. The result is that XCP’s main installation directory, and most of its registry keys, and almost all of its individual files and processes are made invisible to normal programs and administration tools.
The rootkit is installed as a kernel-level driver named $sys$aries and set to automatically load early in the boot process. When the rootkit starts, it hooks several Windows system calls by modifying the system service dispatch table, the kernel’s KeServiceDescriptorTable structure. This structure is an array of pointers to the kernel functions that implement basic system calls. The rootkit changes five of these addresses so that they point to functions within the rootkit. When an application invokes one of these patched system calls, it is handled by the rootkit instead of the original function in the kernel. The rootkit calls the real kernel function with the same parameters and filters the results before returning them to the application.
The system calls intercepted by the rootkit are:
- NtQueryDirectoryFile – This function is used to list the contents of a directory; the rootkit version filters out directory entries that begin with $sys$, rendering such files and directories invisible to applications.
- NtCreateFile – This call is used for creating and opening files. The rootkit version returns an invalid filename error when programs attempt to open existing files with names starting with $sys$, protecting XCP’s files from reading or writing by other programs.
- NtQuerySystemInformation – One use of this function is to obtain a list of running processes. The rootkit filters out any processes with names prefixed by $sys$, making them invisible to other applications.
- NtEnumerateKey – This function returns a list of the subkeys of a registry key. The rootkit filters the results to remove subkeys with names starting with $sys$. Note that it does not conceal individual fields within the registry (“values” in Windows parlance) with names starting with $sys$.
- NtOpenKey – This function opens a registry key for reading or modifying. The rootkit intercepts this function call but does not alter its behavior. Its authors may have intended to restrict access to hidden registry keys in the same way that the hooked NtQueryDirectoryFile call restricts access to hidden files, but for some reason they did not ship a working implementation of this behavior.
The rootkit begins each intercepted function by checking the name of the calling process. If the process’s name begins with $sys$, the rootkit returns the results of the real kernel function without alteration. This allows XCP’s own processes to bypass the rootkit’s filters for a complete view of the system.
The XCP rootkit increases users’ vulnerability to many kinds of attacks because it can be used to hide arbitrary software, not just XCP. The rootkit is indiscriminate about what it conceals—any files, registry keys, or processes with names beginning in $sys$ will be hidden. Spyware and malware authors can leverage this functionality on systems where the rootkit is installed. This saves attackers the trouble of installing their own rootkits, but more importantly, it gives them access to a rootkit in situations where they would not be able to install one themselves because of the system’s security policies.
Only kernel-level processes are allowed to patch the Windows system service dispatch table, and only privileged users—normally, members of the Administrators or Power Users groups—are allowed to install such processes. (XCP iteslf requires these privileges to install.) Malicious code executed by an unprivileged user wouldn’t normally be allowed to install a rootkit that intercepted system calls in the kernel. However, if the XCP rootkit is installed, its cloaking behavior applies to all users regardless of their security privileges. Unprivileged malware can adopt the $sys$ prefix to become invisible to both privileged and unprivileged users. This privilege escalation attack has already been exploited by at least two Trojan horses discovered in the wild [citations].
Another privilege escalation attack facilitated by the XCP rootkit allows an unprivileged application to crash the system. Russinovich demonstrated this problem using an automated testing program he created called NTCRASH2 [citation]. This utility makes repeated system calls with randomly generated invalid parameters. The original Windows kernel functions handle invalid inputs correctly and the system remains stable, but with the XCP rootkit installed, certain invalid inputs result in a system crash.
We investigated the specific circumstances when these crashes occur. The rootkit’s implementation of NtCreateFile can cause a crash if it is passed an invalid pointer as its ObjectAttribute argument, or if it is passed a valid ObjectAttributes structure that points to a ObjectName structure with an invalid Buffer pointer. We do not believe that an attacker could exploit these flaws to execute code; however, they do allow an unprivileged user to bring the system to a halt. As Russinovich and other have pointed out, these problem illustrates the security danger of installing software in secret. Users experiencing system instability due to these rootkit bugs would have great difficulty diganosing the problem, since they likely would be unaware of the rootkit’s presence.
Deactivating XCP
Deactivating XCP’s active protection software is more complicated because it is comprised of a number of processes that are more deeply entagled in the system configuration, and because these files are hidden by the XCP rootkit. Deactivation can be accomplished by a three-step procedure.
The first step is to deactivate and remove the rootkit. This is the same procedure used to deactivate MediaMax. The only change is that the driver’s name is aries.sys. Disabling the rootkit and then rebooting the system exposes the previously hidden files, registry entries, and processes (ones with names prefixed with $sys).
The second step is to edit the system registry to remove references to XCP’s filter drivers and CoDeviceInstallers. XCP uses the Windows filter driver facility to intercept commands to the CD drives and IDE bus. If these filter drivers are not removed, the CD and IDE device drivers will fail to initialize after the program files for the filter drivers are deleted. This can cause the CD drives to malfunction, or, worse, cause the system to fail to boot because the IDE device driver is disabled. XCP’s filter drivers can be neutralized by editing the
Windows Registry to remove any reference to a driver named $sys$cor from any registry entries named UpperDrivers or LowerDrivers. The CoDeviceInstallers can be neutralized by removing any lines containing $sys$caj from any list of CoDeviceInstallers.
The third step is to delete the XCP services and remove the XCP program files. Services named $sys$lim, $sys$oct, cd_proxy, $sys$drmserver, and $sys$cor can be deactivated using the sc delete command, and then files named crater.sys, lim.sys, oct.sys, $sys$cor.sys, $sys$caj.dll, and $sys$upgtool.exe can be deleted. After the system is rebooted, the two remaining files, named CDProxyServ.exe and $sys$DRMServer.exe can be removed.
After performing these steps, XCP will now deactivated, and only the passive protection on XCP CDs will continue to be in force. Of course, these steps could easily be automated, creating a point-and-click tool for removing XCP.
CD DRM as Spyware
Tactics like the rootkit function, and the engineering of programs so that removal attempts can system instabilty, iare often used by spyware programs. That active DRM systems would be drawn to the same tactics as spyware should come as no surprise, as the two have the same goal: to prevent a user from removing unwanted software. In both cases, the user wants to remove the software (if he can find it) because the software provides no value to the user and can only harm him.
These tactics harm users, primarily by undermining users’ ability to manage their computers. If users lose track of which programs are running on their computers, they lose the opportunity to remove or patch programs that are malfunction and to remove unneeded programs. Maintaining a secure configuration is difficult already, and spyware tactics make it even more difficult. Though it is not surprising that spyware tactics would have attraction for DRM designers, it was a bit surprising that mass-market DRM vendors chose to use those tactics despite the risk of harming users. If only one vendor had chosen to use such tactics, we could write it off as an aberration. But two vendors made that choice, which is probably not a coincidence.
We suspect that the explanation may lie in the DRM vendors’ platform building strategy, which relies on keeping the software installed on as many computers as possible, coupled with the risk tolerance of DRM startup companies. The vendors may not have realized the extent of damage they could be causing, but they must have known that they were doing some harm. Our hypothesis is that the vendors allowed the lure of platform building to override the risk to users.
Authorized Uninstallers
Once users began to complain about the spyware-like behavior of the XCP and MediaMax software, the vendors offered access to uninstallers that would remove their software from users’ systems. Uninstallers had been available previously, but they were very difficult to obtain. For example, to get the original XCP uninstaller, a user had to fill out an online form involving some personal information, then wait a few days for a reply email, then fill out another online form and install some software, then wait a few days for yet another email, and then finally click a URL in the last email. We can think of no explanation for the complexity of this procedure, other than a desire to deter users from uninstalling the software.
The uninstallers, when a user did succeed in getting one of them, did not behave like ordinary software uninstallers. Normally an uninstaller is a standalone program that the user runs, either by double-clicking it or by using a system-provided user interface to designate the program to be removed. One advantage of ordinary uninstallers is that they can be acquired and used by any user who has the software.
The first XCP uninstaller did not work this way. Instead, the uninstaller was customized for each user, so that it would work only for a limited time and only on the computer on which the user had filled out the second form. This meant, for example, that if a user uninstalled the XCP software but it got reinstalled later—as might happen if the user inserted an XCP-bearing CD—the user could not use the same uninstaller again but would have to go through the entire process again to request a new one.
Customizing the uninstaller in this way is more difficult for the vendor and increases customer support costs, compared to a more traditional uninstaller, so a rational vendor would not do it unless there was some benefit. Most likely, the benefit is to the vendor’s platform building strategy, which takes a step backward every time a user uninstalls the vendor’s software. Customizing the uninstaller allows the vendor to contol who receives the uninstaller and to change the terms under which it is delivered in the future.
As user complaints mounted, Sony-BMG announced that unrestricted uninstallers for both XCP and MediaMax would be made available to all users from the vendors’ web sites. Both vendors chose to make these uninstallers available as ActiveX controls accessed via a web site.
By an unfortunate coincidence, both uninstallers turned out to open the same serious vulnerability on any computer where they were used.
MediaMax Uninstaller Vulnerability
The MediaMax uninstaller employed a proprietary ActiveX control called AxWebRemove.ocx created and signed by MediaMax author SunnComm. When users visited the MediaMax uninstaller web page, Internet Explorer prompted them to install the control. Then the web page invoked one of the control’s methods to uninstall MediaMax. This method, Remove, took two parameters: key, and validate_url. The key parameter was a single-use code provided by MediaMax technical support, and the validate_url parameter specified a web page that would validate the key and deliver executable code to perform the actual uninstallation.
When Remove is called from the web page, is issues an HTTP GET request to the provided url to validate the key. If it is valid, the server responds with the message true, {uninstall_url, where uninstall_url is the URL of a DLL file containing code to uninstall MediaMax. The control retries this DLL file from the Internet and saves it to a temporary location, then calls a function in the DLL named ECF7() to perform the uninstallation. If the function returns sucess, the control issues a second HTTP GET request to validate_url to report that the uninstall was sucessful and that the single-use key should be retired.
This design is vulnerable because the control accepts an arbitrary validate_url parameter and does not check that the DLL specified by the key validation server is authentic. The ActiveX control is not itself removed during the uninstallation process, so its methods can be invoked later by any web page without further browser security warnings. A attacker can create a web page that invokes the Remove method and provides a validate_url pointing to a page under the attacker’s control. This page can return an uninstall_url pointing to a DLL created by the attacker. When the MediaMax control executes the uninstall function in this file, arbitrary attacker code will execute on the user’s machine.
XCP Uninstaller Vulnerability
The XCP uninstaller contains the same design flaw and is only slightly more difficult to exploit. XCP’s ActiveX-based uninstaller invokes a proprietary ActiveX control named CodeSupport.ocx. (Early versions of XCP’s rootkit removal patch utilized the same control.) Usually this control is installed when users perform the second step in the three-step XCP uninstall process. In this step, the user is prompted to explain why they are requesting to uninstall XCP. The user’s response is sent to an XCP server along with a pseudorandom code generated by the ActiveX control. The same code is written to the system registry. Eventually the user receives an email with a link to another web page that uses the ActiveX control to remove XCP, but only after verifying that the code sent with the request matches the code in the local system registry. This check ensures that the uninstaller is only used on the machine from which the uninstallation request was made. As a consequence of this design, the control may be present on a user’s system even if she never performed the step in the uninstallation process where XCP is removed.
Matti Nikki first noted that the XCP ActiveX control contains some suspiciously-named methods, including InstallUpdate(url), Uninstall(url), and RebootMachine() [citation]. He demonstrated that the control remained installed after the XCP uninstallation was complete, and that its methods (including one that restarted the computer) were scriptable from any web page without further browser security warnings.
We found that the InstallUpdate and Uninstall methods have an even more serious flaw. Each takes as an argument a URL pointing to a specially formatted archive that contains updater or uninstaller code and data files. When these methods are invoked, the archive is retrieved from the provided URL and stored in a temporary location. For the InstallUpdate() method, the ActiveX control extract from the archive a file named InstallLite.dll and calls a function in this DLL named InstallXCP().
Like the MediaMax ActiveX control, the XCP control does not validate the download URL or the downloaded archive. The only barrier to using the control to execute arbitrary code is the proprietary format of the archive file. We determined the format by disassembling the control. The archive file consists of several blocks of gzip-compressed data, each storing a seperate file and preceded with a short header. At the end of the archive, a catalog structure lists metadata for each of the blocks, including a 32-bit CRC. The control verifies this CRC before executing code from the DLL.
With knowledge of this file format, we constructed an archive containing sample (benign) exploit code. The most difficult detail was the CRC, which is computed with an apparently proprietary algorithm that proved tedious to reverse engineer. We saved the trouble by having the ActiveX control compute the CRC for us. The control checks the CRC by computing a CRC for the file data in the archive and verifying that it matches the CRC specified in the archive catalog. We inserted a break point where the comparison occurs and ran the control on an archive containing code we prepared. We then took the CRC computed by the control and placed it in the archive catalog. Thus modified, the archive passed the CRC check and the ActiveX control executed our code. (This illustrated why digital signatures, rather than CRCs, must be used to validate code from untrusted sources.)
This procedure would allow a malicious web site to execute arbitrary code on the user’s machine. Like the MediaMax uninstaller flaw, it is especially dangerous because users who have completed the uninstallation may not be aware that they are still vulnerable.
Obviously, these vulnerabilities could have been prevented by careful design and programming. But they would not have been possible at all if not for the decision to deliver the uninstallers via this ActiveX method rather than using an ordinary download. We conjecture that the vendors chose to use ActiveX in this way because they wanted to retain the ability to rewrite, modify, or cancel the uninstaller later, and that this desire was driven at least in part by the vendors’ platform building strategy.
Summary of Deactivation Attacks
When all is said and done, there is little a CD DRM vendor can do to stop users from deactivating active protection software. A user can do this via ordinary security and system administration tools; attempts by the vendor to interfere with these tools are harmful and will trigger a strong backlash from users. In practice, vendors will probably have to provide some kind of uninstaller – users will insist on it, and some users will need it to deal with the bugs and incompatibilities that crop up occasionally in any complex software. Once an uninstaller is released, users will be able use it to remove the DRM software. Ultimately, determined users will be able to keep CD DRM software off their machines.
About games requiring administrative privileges, I tried running a game as a base user and I was led by the Illegal Operation message to believe that the game couldn’t run because the OS wouldn’t let it make a log somewhere to record things; when I checked after playing in admin mode, I found out it was where it was supposed to record my score. I think the install bit is about it needing to modify the registry to say something like “Here is Game, here is Uninstall_Game, here is Game_Level_Editor”, etc.
I have to admit to wondering whether the UT program to collect how many kills you kill in each game counts as spyware.
This privilege escalation attack has already been exploited by at least two Trojan horses discovered in the wild [citations].
Breplibot Stinx, Mika, F-Secure: News from the Lab, 11 Nov 2005.
Matti Nikki first noted that the XCP ActiveX control contains some suspiciously-named methods, including InstallUpdate(url), Uninstall(url), and RebootMachine() [citation].
Muzzy’s research about Sony’s XCP DRM system, Matti Nikki, updated 2005-12-06.
Russinovich demonstrated this problem using an automated testing program he created called NTCRASH2 [citation].
Premature Victory Declaration?, Mark’s Sysinternals Blog, 30 Nov 2005
The best example of this kind of defense is the rootkit-like behavior of XCP, famously discovered by Mark Russinovich [citation], as described earlier.
Sony, Rootkits and Digital Rights Management Gone Too Far Mark’s Sysinternals Blog 31 0ct 2005.
P(WB)MF
Tactics like the rootkit function, and the engineering of programs so that removal attempts can create? system instabilty,
iare often used by spyware programs.Missing word and typo in first sentence of “CD DRM as Spyware”:
Tactics like the rootkit function, and the engineering of programs so that removal attempts can create? system instabilty,
iare often used by spyware programs.Ned,
Well, I think SCO shows actual malice in addition to stupidity, but that’s neither here nor there. 🙂
I think we all agree, basically. I find it pretty sad that still, today, in this day and age, that most vendors pay lip service (at most) to security and stability concerns. (And pitifully few vendors realize that a security concern *is* a stability concern, and vice versa.) Having friends who code at many companies in quite an array of industries, I can say that companies (and perhaps consumers) still do not want to pay what it takes to produce code that is stable and secure.
And what companies are the most resource constrained? Startups.
Zapkitty,
I like your hand grenade analogy. Especially because the entire point of MediaMax and XCP (to look at it from the consumer/security perspective and not from the media provider perspective) is to cut a hole into the security of your system to become a “man in the middle.” The filter drivers can be seen as a classic man-in-the-middle attack. When you see the right kinds of codes, you interfere with them so the message in question cannot be communicated. Thus, to code such a thing, you have to be at least a little bit in the “security attack” frame of mind. And as you say, someone who has to cut a hole in a system’s security who accidentally leaves that door open, well, that is only possible if you open that door in the first place.
Apparently Ed, Edward and Ned are someplace totally other than where I was (or at least where I thought I was 🙂 )
So I’m probably the one who’s off base here, but the idea that the uninstall vulnerabilities might be “deliberate” didn’t enter into my thoughts at all.
My concept was that if you’re playing control games and screw up, then it is not surprising when the problems that result from said screwup turn up turn out to be control problems… and it ain’t a coincidence.
I’m done 🙂
Edward,
I’ve probably just spent waaaay too much time over the past few years attempting to puzzle out the perspective of The SCO Group, et al and especially Boies, Schiller & Flexner—trying to reverse-engineer their decision making processes. Probably permanently warped my brain. Turned me into a net.kook, more than likely.
My own assessment of the risk-reward ratio would indicate that it seems most probable that the similar insecurities in the MediaMax and XCP uninstallers were just an unfortunate coincidence.
In any case, I think they’re entitled to a presumption of innocence.
Wrong-word error, in the second paragraph under “MediaMax Uninstaller Vulnerability”:
“The control retries this DLL file” should probably read “The control retrieves this DLL file”
Avoiding DRM on conventional media (ie a Redbook Audio CD) is relatively straight-forward — if you can prevent the executable code on the CD from executing (eg by disabling the Windows Autorun facility) then you have won, because the media can be interpreted and used by standard, trusted tools that are already widely available.
However, avoiding DRM on other media (for example, Windows game software) is much more difficult because there is no trusted tool that can be used to run the game software in its own compartment without gravely compromising performance (usually to a degree that makes the game unplayable).
The facilities provided by the operating system are insufficient because such games insist on having full administrative priviledges to install (and, in many cases, just to execute) so that they can introspect the state of the local system to satisfy themselves that they are running in an approved environment.
Er… my point was that when they grab control of the system, and frack it up while grabbing it, it cannot be said to be coincidental when the screwup results in control vulnerabilities.
Can the screwup result in a flaw that isn’t a control problem? Of course it can. But as the purpose of the exercise is usurping control the odds do seem to favor the resulting mess to be a control issue.
So if I came across as saying that errors resulting from the botched control attempt would always be control issues, then that wasn’t my point, and I’m sorry if I wasn’t clear enough on that.
My point was (I think 😉 that if you juggle grenades in somebody’s house and a pin gets pulled the judge will not care that the grenade could have lodged harmlessly in a ceiling fan with minimal damage…
… as far as the judge was concerned you were juggling grenades and the house blew up.
It doesn’t seem to have sunk in to the media industry yet that grabbing control of a user’s PC is a risk, and that the stakes riding on that risk can be very high, at least from the user’s perspective.
So perhaps the my point really isn’t analogous to the DRM –> spyware thesis, but I’m sure the point is still valid on its own 🙂
“Tactics like the rootkit function, and the engineering of programs so that removal attempts can system instabilty”
“can system instability”?
Typo at the end of the 2nd paragraph following “Deactivating XCP” — you refer to “$sys” instead of “$sys$”.
Ned,
I think that the surprising security failures of MediaMax and XCP (surprising to the extent that one would naively assume that someone writing “security” software would think ahead about the security of the machine they are installing software on, aka, invading) are no accident. Those failures, I think, are a natural consequence of the goals of the coding teams and the market of the software. If you are concerned with how to get your software loaded on as many platforms as possible, then it’s not that you will deliberately write insecure software, but such security won’t be a high concern. Since the home consumer was not their market, the things that are important to the home consumer were not high on their priority list. That is sadly natural and unsurprising.
I follow the “never attribute to malice that which can be adaquately explained by stupidity” motto. Here, replace “stupidity” with “outside the design intent” and the security flaws are pretty understandable. Programmers who know how to write secure code, who know how to write OS drivers, and who understand how to control and mitigate risk, are more expensive and rare than programmers in general. Small companies often don’t have the resources to find and hire and keep the most talented employees. And with these companies in specific, unless their managements understood the potential problems one gets by not hiring people with the required skills, whare are the odds that they would find people with the skills one would need to implement what they were trying to implement without causing collateral harm?
This is not to absolve anyone of blame, but simply to explain why I don’t believe the insecurity of the uninstallers indicates active malice. I believe, instead, that the “coincidental” security failures illustrates the business reality that to this day, security is not a high concern among thsoe producing software, and that the farther a vendor is from the consumer and from the consumer’s interests, the less concern that vendor will feel about security of that consumer.
In the software market, “get it done” and “by this deadline” still trump security and stability issues. This is a terribly unfortunate business reality that Sony-BMG should have taken into account, as it’s their name on every CD.
P.S. I was in a Borders a couple days ago that was still selling an XCP protected title. That is, an XCP protected title was one of the ones they were playing overhead and had available at the music desk to see what was playing. (I picked up the jewel case to see what artist it was and saw the XCP information on the back.) I informed the staff there about XCP and the supposed recall, and they had not heard about any of it. They looked at me a little bit like I was a kook when I told them about the recall.
I didn’t see that disk in the bins for sale, but I didn’t check every genre area, so I don’t know if I looked in the right area for that artist or not.
There’s no benefit to the vendor in allowing other people, without the vendor’s permission, to change around the user’s system. But both vendors allowed that to happen by mistake.
Ed,
I would agree that I can’t think of any legitimate benefit to the vendor in allowing world control over the user’s system. But I deny that there’s no conceivable benefit. The question is merely how plausible is that scenario?
DMCA aside, to me the root of this question is who has the right to modify the operating system on a computer. In the perfect world, it would always require administrator/root password/privilages. However, as a number of windows users found out with the XCP issue, most of the time you end up running as admin/root in order to do what you desire with your computer. As long as there is nothing more than a slight public outcry over the methods used (XCP or MediaMax for example) the DRM vendor community will not have a large problem selling their product. If the OS vendors begin to incorporate DRM into the OS (i.e. MS Vista) and the potential purchasers of those products happen to investigate everything about this new OS then the possibility exists for this new OS to flop.
I for one don’t expect to purchase any new electronic devices (DVD, CD, computer drives) until they have been in the public market for one year AND I can find adequate reviews indicating user happiness with said model. And you can guarantee that anything that supports DRM, TV Flags, and unauthorized Phoning Home won’t be bought.
“If an adversary can remove or deactivate the active protection software, then the DRM scheme will fail to prevent arbitrary use or ripping of the music on the disc. In this section we discuss such deactivation attacks.”
If I understand the DMCA correctly, removing or deactivating the active protection s/w would be a violation? If that is the case, the obvious question is…. would ANY activity that removes the driver, either intentionally or unintentionally also be a violation of the DMCA. If I had unrelated system problems and decided to format my hard disk and reinstall the OS, have I violated the DMCA if the driver was on the system prior to formatting?
Had Sony decided to continue using XCP or MediaMax and used the DMCA to prevent removal of the driver, some interesting legal issues would have arisen.
Zapkitty,
I do think that that particular pair of bugs were coincidentally similar. Remember, the mechanism in question was designed to give the DRM vendors the ability to change the code on users’ systems. The fact that both systems did that was not a coincidence.
What was a coincidence is that both systems allowed anyone in the world to install software on users’ systems, and that both systems suffered from the same sort of bug that allowed such installation. There’s no benefit to the vendor in allowing other people, without the vendor’s permission, to change around the user’s system. But both vendors allowed that to happen by mistake. They could have avoided it by simple use of digital signatures.
Ned Ulbricht Says:
“zapkitty,
Color me under-caffeinated, but I don’t quite see the parallel in logic here. Ed’s post “CD Copy Protection: The Road to Spyware†explains in plausible detail that the similar technical problems faced by designers of spyware and CD DRMware constrains the solution space.
Here, I just don’t quite see the argument that the designers of the XCP and MediaMax uninstallers were so constrained that they inevitably converged towards using insecure ActiveX controls.”
I realized that I should have been more specific in my wording… after I posted it 🙂
The DRM vendors were after exclusive control of a certain PC operation that required administrative rights, uninstalling a program, and thus usurped the standard user control of the uninstall process to give it over remotely to a party other than the user… themselves.
That ActiveX was the vector they used to achieve remote control of the PC, for however temporary the purpose, says worlds about Internet Exploder, but perhaps they could have chosen another attack vector?
But the fact that a screwup in the coding of such a control attempt left the user PC vulnerable to external exploitation was, again, not a coincidence.
Thus I see the logic as a parallel to Ed’s example of what happens when external parties attempt to usurp control of user privileges.
I agree with the observation of Aaron “use terminology in such a way as to reflect this user-centric perspective, instead of adopting the DRM-system-centric perspective that views users as attackers.” Though your draft notes that “These tactics harm users, primarily by undermining users’ ability to manage their computers.” this does not go far enough. I will end there to avoid repeating myself.
By the same logic that leads the people engineering DRM to use malware techniques… this was not a coincidence.
zapkitty,
Color me under-caffeinated, but I don’t quite see the parallel in logic here. Ed’s post “CD Copy Protection: The Road to Spyware” explains in plausible detail that the similar technical problems faced by designers of spyware and CD DRMware constrains the solution space.
Here, I just don’t quite see the argument that the designers of the XCP and MediaMax uninstallers were so constrained that they inevitably converged towards using insecure ActiveX controls.
The null hypothesis is that it’s just a coincidence.
Point of order:
“By an unfortunate coincidence, both uninstallers turned out to open the same serious vulnerability on any computer where they were used.”
Coincidence?
By the same logic that leads the people engineering DRM to use malware techniques… this was not a coincidence.
The point of these corporate exercises in obfuscation was to give an outside party complete control of the uninstallation process. The fact that it opened the PC to complete control by an outside attacker was not a coincidence.
Dan,
There have been some flare-ups over phone-home features in commercial software. Two recent ones involved ZoneAlarm and iTunes. Regarding rootkit-like features, I don’t recall anything nearly as flagrant as the XCP rootkit.
Some DVDs do carry software that offers to install on your computer when you insert the disc into your computer. The DVDs I have seen appear to follow a reasonable informed consent procedure before installing anything. I haven’t studied this issue in detail, though, so there could very well be something I don’t know about.
Tim,
You make a good point, which we ought to address in the next version.
Aaron and Adam,
I appreciate your concern that we might send the wrong message by our use of language. I believe that people should comply with copyright law. But to the extent that DRM goes beyond copyright and simply transfers power from law-abiding users to record labels and DRM vendors, it deserves no presumption of rightness. We’ll be sensitive to this issue in revising the paper.
Next up, DRM with two drivers employing a tweedle-dee/tweedle-dum strategy so you can’t just turn them off.
Hi Ed, Alex,
I hate to nitpick, but why is it unauthorized for me to deactivate software on my computer? Perhaps a better title would be “vendor-unauthorized deactivation attacks” or, if you’re feeling like alluding to the Princess Bride, “You’re trying to kidnap what I’ve rightfully stolen”
s/retries/retrieves
That the way it goes? 🙂
Let’s be clear. The user is BEING ATTACKED by the DRM software. If anything, an attempt to remove this software is not an attack, it is a DEFENSE. I wish Ed and Alex would use terminology in such a way as to reflect this user-centric perspective, instead of adopting the DRM-system-centric perspective that views users as attackers. I know that the “attack” terminology is a convention in your field, but it is not at all clear to me that the DRM is not in the role of the attacker. After all, users are rights holders too.
I’ve read in several other articles about the possibility of Vista containing inbuilt DRM strategies (such as only accepting signed drivers), and it’s making me consider a dual-boot Windows/Linux machine next, with Vista only used for apps that need it(e.g. games), and Linux for my music and DVDs.
Hi,
I have 2 questions that readers of this site would probably be able to answer off the top of their heads:
1 — Does anyone know if any well-known commercial *software* installation CDs install spyware / rootkits? In other words, Adobe, Microsoft, etc…. Even though the music CDs we’ve been examining are nefarious, I wonder if I have any rootkits / phone-home stuff from the software I’ve purchased from “BigCo”. After forking over big $$$ to legitimately obtain this software, I would hit the roof if I found out these companies were treating me as “guilty until proven innocent” (although the 12-step keycode / registration / etc… process is already a huge step in that direction)
2 — We’ve been discussing CDs auto-installing this crap without our knowledge/permission — is this also happening (or even possible) with DVDs? I won’t buy another Sony product in my lifetime, period, but sadly I do already possess several Sony DVD movies that have already found their way into my computer’s DVD drive. If Sony’s RIAA cabal is paranoid/self-destructive enough to try these heavy-handed techniques, how do we know their MPAA cabal hasn’t attempted similar things with DVDs. Then again, with a DVD maybe it’s not possible, I don’t know what a DVD can do when it’s inserted….
Thanks in advance to any gurus out there who answer these questions (another thing I really like & respect about this site/blog is that the content, responses & discussions are very well though-out and supported, it’s not full of unsubstantiated “facts”, speculation & armchair/self-proclaimed security experts (sorry Steve Gibson/GRC, this means you).)
Also,
s/is comprised of/comprises
Typos, vestiges of editing:
s/iare/are
s/are malfunction/malfunction/
If Windows implements a DRM technology it’s a new game. We can assume (optimistically, I know) that it will avoid security problems, but it still won’t stopped determined users from breaking it. Viruses interfere with the OS; I’d expect that someone could write a program that used similiar techniques to disable such features, and then distribute it as freeware to whoever felt their version of Windows needed such an…addin.
I think there’s a major, hidden “unless” in this statement. Determined users will be able to keep CD DRM software off their machines- unless it is placed there by the manufacturer of their operating system. This prevents deactivation attacks and makes rootkits and uninstallers unnecessar.
What are the odds that the next DRM rootkit will use the various techniques developed by worm and virus writers to frustrate removal? (Hiding the DRM drivers and/or deactivating them for later reactivation seem like obvious steps to take.) How difficult and system-destablizing could the removal process become?
It seems obvious now that the public backlash against such a move would be enormous, but memories tend to fad quickly in the business world, and the record already suggests that some DRM developers, like some spammers, may not necessarily behave as we would presume rational actors would do. Beating one’s opponent’s defense measures can become an end in itself, even if it doesn’t gain a clearly apparent advantage.