CD DRM Makes Computers Less Secure
Tuesday November 1, 2005 by J. Alex Halderman
http://www.freedom-to-tinker.com/?p=919
Yesterday, Sysinternals¹s Mark Russinovich posted an excellent analysis of a
CD copy protection system called XCP2. This scheme, created by British-based
First4Internet, has been deployed on many Sony/BMG albums released in the
last six months. Like the SunnComm MediaMax system that I wrote about in
2003, XCP2 uses an ³active² software-based approach in an attempt to stifle
ripping and copying. The first time an XCP2-protected CD is inserted into a
Windows system, the Windows Autorun feature launches an installer, which
copies a small piece of software onto the computer. From then on, if the
user attempts to copy or rip a protected CD, the software replaces the music
with static.
This kind of copy protection has several weaknesses. For instance, users can
prevent the active protection software from being installed by disabling
autorun or by holding the shift key (which temporarily suspends autorun)
while inserting protected discs. Or they can remove the software once it¹s
been installed, as was easily accomplished with the earlier SunnComm
technology. Now, it seems, the latest innovations in CD copy protection
involve making the protection software harder to uninstall.
What Russinovich discovered is that XCP2 borrows techniques from malicious
software to accomplish this. When XCP2 installs its anti-copying program, it
also installs a second component which serves to hide the existence of the
software. Normally, programs and data aren¹t supposed to be invisible,
particularly to system administrators; they may be superficially hidden, but
administrators need to be able to see what is installed and running in order
to keep the computer secure. What kind of software would want to hide from
system administrators? Viruses, spyware, and rootkits (malicious programs
that surreptitiously hand over control of the computer to a remote
intruder). Rootkits in particular are known for their stealthiness, and they
sometimes go to great lengths to conceal their presence, as Russinovich
explains:
Rootkits that hide files, directories and Registry keys can either
execute in user mode by patching Windows APIs in each process that
applications use to access those objects, or in kernel mode by intercepting
the associated kernel-mode APIs. A common way to intercept kernel-mode
application APIs is to patch the kernel¹s system service table, a technique
that I pioneered with Bryce for Windows back in 1996 when we wrote the first
version of Regmon. Every kernel service that¹s exported for use by Windows
applications has a pointer in a table that¹s indexed with the internal
service number Windows assigns to the API. If a driver replaces an entry in
the table with a pointer to its own function then the kernel invokes the
driver function any time an application executes the API and the driver can
control the behavior of the API.
Sure enough, XCP2 adopts the latter technique to conceal its presence.
Russinovich is right to be outraged that XCP2 employs the same techniques
against him that a malicious rootkit would. This makes maintaining a secure
system more difficult by blurring the line between legitimate and
illegitimate software. Some users have described how the software has made
their anti-virus programs ³go nuts,² caused their system to crash, and cost
them hours of aggravation as they puzzled over what appeared to be evidence
of a compromised system.
But things are even worse than Russinovich states. According to his writeup,
the XCP driver is indiscriminant about what it conceals:
I studied the driver¹s initialization function, confirmed that it
patches several functions via the system call table and saw that its
cloaking code hides any file, directory, Registry key or process whose name
begins with ³$sys$². To verify that I made a copy of Notepad.exe named
$sys$notepad.exe and it disappeared from view.
Once the driver is installed, there¹s no security mechanism in place to
ensure that only the XCP2 software can use it. That means any application
can make itself virtually invisible to standard Windows administration tools
just by renaming its files so that they begin with the string ³$sys$². In
some circumstances, real malicious software could leverage this
functionality to conceal its own existence.
To understand how, you need to know that user accounts on Windows can be
assigned different levels of control over the operation of the system. For
example, some users are granted ³administrator² or ³root² level accessfull
control of the systemwhile others may be given more limited authority that
allows them to perform every day tasks but prevent them from damaging other
users¹ files or impairing the operation of the computer. One task that
administrators can perform that unprivileged users cannot is install
software that uses the cloaking techniques that XCP2 and many rootkits
employ. (Indeed, XCP2 is unable to install unless the user running it has
administrator privileges.)
It¹s a good security practice to give users as little permission as they
need to do their jobswe call this the ³Principle of Least Privilege² in the
security tradebecause, among other reasons, it restricts the activities of
malicious software. If every user on a system has administrator access, any
malicious programs that become installed can put up their own cloaking
mechanisms using the same techniques that XCP2 uses. However, consider what
happens when there are multiple accounts on the system, some with
Administrator access and some with more limited control. Such a setup is
fairly common today, even on family computers. If the administrator uses a
CD that installs XCP2, the XCP2 cloaking driver will be available to
applications installed by any user on the system. Later, if one of the
unprivileged users installs some malware, it can use the XCP2 driver to hide
itself from the user and the Administrator, even though it wouldn¹t have
permission to perform such cloaking on its own.
This kind of security bug is called a ³privilege escalation vulnerability.²
Whenever such a vulnerability is discovered in Windows, Microsoft quickly
rolls out a patch. If Sony and First4Internet have any regard for their
customers¹ security, they must immediately issue a fix for this serious
problem.
Copy protection vendors admit that their software is merely a ³speedbump² to
copyright infringement, so why do they resort to such dangerous and
disreputable means to make their systems only marginally more difficult to
bypass? One of the recording industry¹s favorite arguments why users should
avoid P2P file sharing is that it can expose them to spyware and viruses.
Thanks to First4Internet¹s ill-conceived copy protection, the same can now
be said of purchasing legitimate CDs.
In case you haven¹t already disabled Autorun, now might be a good time.
You are a subscribed member of the infowarrior list. Visit
www.infowarrior.org for list information or to unsubscribe. This message
may be redistributed freely in its entirety. Any and all copyrights
appearing in list messages are maintained by their respective owners.
