Archives for 2005

Yesterday Alex wrote about how SonyBMG’s XCP CD copy protection software includes a feature – apparently built on illegally copied open-source code – to translate music files into the FairPlay format used by Apple’s iTunes and iPod, but the feature was not exposed to users. The details are interesting. But equally interesting, I think, is the question of how this situation came about. Why would Apple make compatibility so difficult? Why would First4Internet go to the trouble to make its software compatible? Why would First4Internet and/or SonyBMG then turn off this already-working feature? And why would SonyBMG then blame Apple for the difficulty of moving XCP files into iTunes and iPods?

Today I’ll try to answer these questions. My answers will be speculative, as I’m not privy to any special information about the companies’ plans. But the story I’ll tell should be plausible, at least, and it will shed some light on how companies use DRM (copy protection) as a weapon in struggling for market supremacy.

Let’s start by reviewing why Apple makes it hard for others to encode files in the Apple FairPlay format that is used by iTunes and the iPod. Apple could easily facilitate such encoding if it wanted to; but it doesn’t. Instead, Apple seems to be trying to ensure that customers are locked in to a particular DRM scheme. This is the strategy we would expect from a company with high market share – customers try to avoid lock-in, but if they must be locked in they typically choose to be locked in to the dominant vendor. So the dominant vendor – Apple in this market – often tries to foster market structures with lock-in.

Recall that when RealNetworks, an Apple rival, created its Harmony software, which could translate Real-format files into FairPlay, Apple cried foul. Apple hung the dreaded “hacker” label on RealNetworks and threatened to sue on some vague DMCA theory. When Real didn’t back down, Apple just changed the FairPlay format, rendering Real’s software incompatible once again. Apple was willing to use both legal threats and technical changes to frustrate compatibility.

First4Internet (F4I), in developing its XCP copy protection software, started out with no market share. F4I knew that customers wouldn’t want its software, because the main effect of the software is to stop customers from doing things they want to do. F4I wanted to reduce the unpleasantness of using its software, and one way to do that was to give customers a way to transfer XCP music files into iTunes or an iPod. And that meant translating the files into FairPlay format. To do this, F4I could have reverse-engineered iTunes and written code to do the translation. Instead, it apparently just swiped some open-source code called DRMS (written by Sam Hocevar and DVD-Jon), in violation of the DRMS license. Using this code, F4I built a working translate-to-FairPlay function as part of its software.

At some point, F4I licensed its software to SonyBMG. F4I would surely have told SonyBMG about the FairPlay compatibility feature. But when SonyBMG CDs shipped with F4I’s XCP software on them, the compatibility feature was disabled and hidden from users. Somebody must have decided to disable the feature, and it’s hard to believe it was anybody but SonyBMG. SonyBMG was F4I’s first major customer. SonyBMG was putting its name on the CDs. And SonyBMG would have been the main target for hacking accusations and/or lawsuits from Apple. So we have to conclude that SonyBMG chose not to make the software on its CDs FairPlay-compatible.

Why would SonyBMG do this? It would have been easier to retain compatibility, and SonyBMG’s customers would have benefited. So SonyBMG must have thought compatibility would hurt it, somehow. How might that happen? Perhaps SonyBMG was afraid Apple could bring a successful lawsuit against it; but that seems unlikely given the apparent weakness of Apple’s legal claims. Two other theories seem more likely.

The first theory is that SonyBMG wanted to avoid the public spectacle of two DRM companies fighting with each other. DRM advocates like to argue (against the evidence) that the only impact of DRM is to prevent infringement. When DRM companies fight over compatibility, this just emphasizes the role of DRM as a strategic tool companies use to lock other companies out of markets, and that sets back the cause of DRM. Much better from SonyBMG’s viewpoint, perhaps, to maintain the fiction of one big happy DRM family, even if customers suffer.

The second theory is that SonyBMG was trying to fragment the world of music-file formats, in order to reduce Apple’s negotiating power. Record companies have been complaining lately that Apple, as the biggest seller of Internet-delivered music, has too much market power. Apple’s market power helps it drive a hard bargain with record companies in negotiating the price and terms of Apple’s online music sales. SonyBMG, as a record company, would like to see Apple’s market power shrink.

Whichever explanation is right, it certainly appears that SonyBMG decided that XCP shouldn’t be compatible with FairPlay.

What SonyBMG did next showed a particular sort of genius. It blamed Apple for the incompatibility. Indeed, SonyBMG went so far as to ask its customers to petition Apple to solve the problem. Here’s SonyBMG’s web site:

Sony BMG wants music to be easily transferable to any device that supports secure music. Currently, music from our protected CDs may be transferred to hundreds of such devices, as both Microsoft and Sony have assisted to make the user experience on our discs as seamless as possible with their secure formats.
Unfortunately, in order to directly and smoothly rip content into iTunes it requires the assistance of Apple. To date, Apple has not been willing to cooperate with our protection vendors to make ripping to iTunes and to the iPod a simple experience.
If you believe that you should be able to easily move tracks from your protected CD to your iPod then we encourage you to use the following link to contact Apple directly and tell them so. http://www.apple.com/feedback/ipod.html

If you were SonyBMG, and you were clever but not overly concerned with telling the truth in public, this is exactly what you would say in this situation. Why pass up a chance to paint Apple as the bad guys?

Running through this whole convoluted tale are two consistent threads. DRM is used as a weapon not against infringers but against market rivals. And when companies use DRM to undermine compatibility, law-abiding customers lose.

Security vendor F-Secure contacted SonyBMG and First4Internet about the companies’ rootkit software on October 4 – about four weeks before the issue became public – according to a Business Week story by Steve Hamm.

Here’s the key part of the article’s chronology:

Nevertheless, Sony BMG asked First4Internet to investigate. Both Sony BMG and F-Secure say that it was on Oct. 17 that F-Secure first spelled out the full scope of the problem to Sony. The security company’s report on the matter, sent that day to First4Internet and Sony BMG, confirmed there was a rootkit in XCP and warned that it made it possible for hackers to hide viruses and protect them from antivirus software products. F-Secure referred to XCP as a “major security risk,” according to a copy of the e-mail supplied to BusinessWeek Online by F-Secure.

Sony BMG says it asked the two software companies to investigate and find a solution to the problem. “From the moment our people learned that F-Secure had identified a potential problem we contacted our vendor and in no uncertain terms told them you have to get with F-Secure and find out what needs to be done about it,” says Daniel Mandil, Sony BMG’s general counsel.

BOGGED DOWN. What happened next is in dispute. F-Secure had a conference call with executives of First4Internet on Oct. 20. It says First4Internet argued that there was no real problem because only a few people knew of the vulnerability XCP created, and said an update of the XCP software, due out early next year, would fix the problem on all future CDs.

At first glance, this looks like a standard story about disclosure of a security vulnerability: vendor ships insecure product; researchers report flaw privately; vendor drags feet; researchers report flaw publicly; problem fixed right away. The story features the classic vendor error of seeing insecurity as a public relations problem rather than a customer safety issue: “there was no real problem because only a few people knew of the vulnerability”.

But if we read this as just another vulnerability disclosure, we’re missing an important part of the story. In the usual case, the security vulnerability exists by mistake – the vendor doesn’t know the vulnerability exists until somebody points it out. Here, the rootkit-like functionality was not a mistake but a deliberate design decision by the vendor.

Which suggests the question of what exactly F-Secure was disclosing to Sony and First4Internet, or more precisely what it was disclosing that they didn’t already know. They must have known about the rootkit already – it was a design decision they had made – and if they had any kind of clue they would have known that users would hate having a rootkit on their machines, especially one that provided an obvious hiding place for other malware. As far as I can see, the only new information F-Secure would have disclosed was that F-Secure planned to treat the program as malware.

It’s interesting, too, that other makers of anti-malware tools didn’t seem to notice the problem until Mark Russinovich’s public disclosure. As of mid-September, this malware had been on the market for months and presumably had been installed on hundreds of thousands of computers, but still none of the anti-malware vendors had discovered it. (According to the Business Week article, F-Secure didn’t discover the malware itself, but learned of it on Sept. 30 from John Guarino, a computer technician in New York who had discovered it on several clients’ computers.) It’s not a good sign that all of the major anti-malware vendors missed it for so long.

Finally, we have to consider the possibility that Sony and First4Internet understood the significance of the rootkit, but simply felt that copy protection trumped users’ security. First4Internet probably held that view – otherwise it’s hard to explain their design decision to deploy rootkit functionality – and Sony may well have held it too. We know already that entertainment companies want to redesign our computers in the hope (which is ultimately futile) of stopping copying. From there, it’s not so large a step to decide that users’ security simply must be sacrificed on the altar of copy protection.

What did SonyBMG know, and when did it know it? We’ll find out more as the lawsuits proceed.

In an earlier post I described how MediaMax, a CD DRM system used by Sony-BMG and other record labels, behaves like spyware. (MediaMax is not the same as XCP, the technology that Sony-BMG has recalled; Sony-BMG is still shipping MediaMax discs.) MediaMax phones home whenever you play a protected CD, automatically installs over 12 MB of software before even displaying an End User License Agreement, and fails to include an uninstaller.

Part of the software that MediaMax installs is a driver meant to interfere with ripping and copying from protected discs. I had believed that MediaMax didn’t permanently activate this driver—set it to run whenever the computer starts—unless the user accepted the license agreement. As it turns out, this belief was wrong, and things are even worse that I had thought.

In the comments to our last MediaMax story, reader free980211 pointed out that the driver sometimes becomes permanently activated if the same protected CD is used more than once, even if the user never agrees to the EULA. This wasn’t apparent from my earlier tests because they were conducted under tightly controlled conditions, with each trial beginning from a fresh Windows installation and involving only carefully scripted operations. I’ve performed further tests and can now confirm that MediaMax is permanently activated in several common situations in spite of explicitly withheld consent.

When this happens depends on what version of MediaMax is being used. An older version, called CD-3, was introduced in 2003 and is present on albums released as recently as this summer. There is also a newer version, MediaMax MM-5, which has been shipping for a little over a year. You can tell which version is on a CD by examining the files in the disc’s root directory. Albums protected by MediaMax CD-3 contain a file called LAUNCHCD.EXE, while MM-5 albums include a file named PlayDisc.exe.

When you insert a CD containing either version of MediaMax, an installer program automatically starts (unless you have disabled the Windows autorun feature). This installer places the copy protection driver and other files on the hard disk, and then presents a license agreement, which you are asked to accept or decline. In the following scenarios the driver may become permanently activated even if you always decline the agreement:

• You insert a CD-3 album, then later insert an MM-5 album
• You insert an MM-5 album, then later insert a CD-3 album
• You insert an MM-5 album, reboot, then later insert the same album or another MM-5 album

These steps don’t have to take place all at once. They can happen over a period of weeks or months.

This is bad news for people who like to play CDs in their computers. Many users are unaware that their CDs contain MediaMax until the license agreement appears on their screens, but by this time it may be too late to stop the driver from being permanently activated. Even if users are careful to decline the EULA every time, the circumstances when the software becomes active anyway are common enough to be practically inevitable.

This may be an annoyance to music fans—unless you disable the driver, you’ll have a hard time playing any MediaMax-protected titles, let alone copying them to your iPod—but it’s also a security risk, since the driver is loaded as part of the Windows kernel and has the ability to control virtually any aspect of the computer’s operation. We don’t know whether the MediaMax driver contains any vulnerability that can be exploited to do further damage, but the way it is installed creates a dangerous precedent.

Is this behavior illegal? It should be. Installation of system level software where the user has explicitly denied permission raises serious security concerns and is wrong.