Archives for November 2005

SonyBMG and First4Internet are in the doghouse now, having been caught installing rootkit-like software on the computers of SonyBMG music customers, thereby exposing the customers to security risk. The question now is whether the companies will face up to their mistake and try to remedy it.

First4Internet seems to be trying to dodge the issue. For example, here’s part of a news.com story by John Borland:

The creator of the copy-protection software, a British company called First 4 Internet, said the cloaking mechanism was not a risk, and that its team worked closely with big antivirus companies such as Symantec to ensure that was the case. The cloaking function was aimed at making it difficult, though not impossible, to hack the content protection in ways that have been simple in similar products, the company said.

In any case, First 4 has moved away from the techniques used on the Van Zant album to new ways of cloaking files on a hard drive, said Mathew Gilliat-Smith, the company’s CEO.

“I think this is slightly old news,” Gilliat-Smith said. “For the eight months that these CDs have been out, we haven’t had any comments about malware (malicious software) at all.”

The claim that the software is not a risk is simply false, as Alex explained yesterday. And if the company is indeed working on new ways to hide the contents of your computer from you, that just shows that they haven’t learned their lesson. The problem is not that they used a particular rootkit method. The problem is that they used rootkit methods at all. Switching to a new rootkit method will, if anything, make the problem worse.

The claim that there haven’t been any complaints about the software is also false. The reviews on Amazon have plenty of complaints, and there was a discussion of these problems at CastleCops. And, of course, Mark Russinovich has complained.

The claim that this is old news is just bizarre. First4Internet is offering this system to record companies – today. SonyBMG is selling CDs containing this software – today. And this software is sitting on many users’ computers with no uninstaller – today.

If the First4Internet wants to stop spinning and address the problem, and if SonyBMG wants to start recovering consumer trust, I would suggest the following steps.

(1) Admit that there is a problem. The companies can admit that the software uses rootkit-like methods and may expose some consumers to increased security risk.

(2) Modify product packaging, company websites, and EULA language to disclose what the software actually does. Thus far there hasn’t been adequate notification. For example, the current EULA says this:

As soon as you have agreed to be bound by the terms and conditions of the EULA, this CD will automatically install a small proprietary software program (the “SOFTWARE”) onto YOUR COMPUTER. The SOFTWARE is intended to protect the audio files embodied on the CD, and it may also facilitate your use of the DIGITAL CONTENT. Once installed, the SOFTWARE will reside on YOUR COMPUTER until removed or deleted. However, the SOFTWARE will not be used at any time to collect any personal information from you, whether stored on YOUR COMPUTER or otherwise.

Clearly a rootkit neither protects the audio files nor facilitates use of the content. This is not the only misleading aspect of the description. For example, this does not convey to users that they will be unable to make lawful uses of the music such as downloading it to an iPod, or that there is no way to uninstall the software (indeed, it strongly implies the opposite), or that attempting to remove the software may make the computer’s CD drive inaccessible.

(3) Release a patch or uninstaller that lets any consumer easily remove or disable the rootkit-like functions of the software. Having caused security problems for their users, the least the companies can do is to help users protect themselves.

(4) Make clear that the companies support, and give permission for, research into the security implications of their products. Saying “trust us” won’t cut it anymore. Having betrayed that trust once, the companies should publicly welcome the Mark Russinoviches of the world to keep studying their software and publishing what they find. If you act like you have something to hide – and you have had something to hide in the past – the public will be smart enough to conclude that you’re probably still hiding something. This is especially true if you announce that you are trying to find new ways to do the thing that you were just caught doing!

Finally, let me just point out two things. First, we don’t know yet whether the First4Internet/SonyBMG software causes even more security or privacy problems for users. Given what we’ve seen so far, I wouldn’t be at all surprised if there are more problems lurking.

Second, this general issue applies not only to F4I and SonyBMG’s technology. Any attempt to copy-protect CDs will face similar problems, because this kind of copy-protection software has a lot in common with standard malware. Most notably, both types of software try to maintain themselves on a user’s computer against the user’s will – something that cannot be done without eroding the user’s control over the computer and thereby inhibiting security.

If you’re using a recent version of Windows, you can protect yourself against this type of software, and some other security risks, by disabling autorun.

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 access—full control of the system—while 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 jobs—we call this the “Principle of Least Privilege” in the security trade—because, 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.