Archives for December 2005

Bruce Hayden writes that MediaMax, the company associated with the CD-borne spyware product that Sony has not yet recalled, recently filed a prospectus with the SEC in connection with an upcoming stock offering. In the prospectus, the company is required to describe truthfully its business plans and associated risks. MediaMax’s prospectus is a window into the company’s business practices. It was filed on November 4, about a week before we first reported the security and privacy problems caused by MediaMax.

There’s more interesting material in the prospectus than I can cover here. Bruce Hayden describes some of it. You can read the whole prospectus yourself, but most of it is pretty dry. The most interesting parts are the discussion of business risks (note the conspicuous non-mention of security and privacy risks), and the description of the company’s products. The product description is all I’ll write about here.

Page 30 of the prospectus describes how the MediaMax CD copy protection product works. Remember, this is the company’s own description of its product. Here’s the core of the description:

When the disc is inserted, the auto launch feature will activate the MediaMax program on the second session. Depending on the DRM license implementation, this program is either activated directly or through another program. The program first determines if the LMT Software controls are installed on the computer. If not, or if the disc concerned contains a newer version, it will copy the controls from the disc concerned and will install same. The LMT Software controls consist of two dynamic link libraries. The controls are used by the MediaMax application.

Whenever the second session software is executed, the LMT Software controls will first determine if the content protection device driver is installed on the system. If not, it will extract it from the main LMT Software into a separate file and install it as a standard Windows device driver.

The driver first locates all CDROM devices installed on the computer. Then it polls each device to determine if a new disc has been inserted. If so, it reads various elements of the disc to determine if it is a MediaMax protected disc. It is important to note that the driver is completely idle (without any chance to affect the computer or CD/DVD drives), unless an actual MediaMax disc has been detected. Once detected, the driver will insert itself into the communication stream for that drive to prevent any non-authorized activities. While allowing the computer to access the second session and associated content without any limitations, the driver will interfere when applications try to access the first session only.

When the driver detects that the MediaMax disc is ejected, it will remove itself from the communication stream for that drive and switch back to the polling mode. Several enhancements have been implemented to make it very difficult to locate and/or remove the device drivers.

There are several things to note here. First, in describing the installation process, there is no mention of obtaining user consent, or of the possibility that the user might not consent, or of how the product would cope with a non-consent situation. The description is pretty straightforward: when the disc is inserted, they install the software. So the decision to install without consent seems deliberate.

Second, there is no mention of the phone-home feature, even though websites associated with the product talk about how the feature can be used to display third-party ads.

Third, they brag that “enhancements have been implemented to make it very difficult to locate and/or remove the device drivers.” So the decision to resist uninstallation seems deliberate.

Indeed, they make an even stronger statement elsewhere on page 30:

The software is designed to be completely invisible to users, programs and system components.

This is an exaggeration, but it shows that they do aspire to invisibility. Which is interesting because the only way to be “invisible to users, programs and system components” is to use rootkit methods. So it would appear that MediaMax at least planned to follow First4Internet’s lead in shipping a rootkit.

All of this just confirms what I wrote on Friday about how the technical problems with CD copy protection lead vendors to adopt spyware methods. MediaMax’s description of their own product describes software that installs without consent and resists detection and removal, along with an apparent plan to adopt rootkit methods. MediaMax set off down the road of CD copy protection, and they ended up with spyware.

Advocates of DRM (copy protection) have been keeping their heads down lately, while they try to figure out what went wrong in the SonyBMG DRM spyware fiasco. No doubt they’ll try to explain it away as an anomaly – just a little speed bump on the road to the effective, unobtrusive DRM future that they’re sure will be arriving any day now.

There are some problems with this story. For starters, we’re not talking about a single DRM system – we’re talking about two totally separate systems (XCP and MediaMax), developed by rival companies, both of which turned out to be spyware and to endanger users, in strikingly similar ways. Is this just a coincidence?

Of course it’s not. If we look carefully at CD copy protection as a technical problem, we’ll see why DRM designers are drawn to spyware tactics as their best hope of stopping copying. Let me explain why.

CDs store music files in Compact Disc Digital Audio (CDDA) format, which is easily readable by a wide range of devices. If the music is encrypted or stored in some other tricky format, ordinary audio CD players won’t be able to read it, and the disc will be useless to most customers. So backward compatibility requires that the music be stored in a format that is readable by computer software.

(Technical digression: There are actually small differences between how a computer reads a disc and how ordinary audio CD players read it. So-called passive protection technologies try to exploit these differences by putting things on the disc that try to confuse computers without affecting ordinary players. For our purposes, it will suffice to say that purely passive protection systems are not viable, because computers are not so easily confused. To my knowledge, purely passive CD DRM technologies aren’t being used any more, although some current vendors combine passive protection with active measures. For reasons too boring to go into here, passive protection doesn’t really affect my analysis; and so to streamline the discussion I’ll assume from here on that there is no passive protection.)

If the music is encoded on the disc in a format that any software program can read, the only way to stop programs from reading it is to install software on the user’s computer, and to have that software actively interfere with attempts to read the disc, for example by corrupting the data stream coming from the disc. We call this “active protection”.

For example, suppose the user wants to use iTunes to read the disc. But the DRM vendor wants to stop the user from doing this, because iTunes can be used to make copies of the disc. The active protection software will detect this and will interfere to ensure that iTunes gets a garbled copy of the music.

Here’s the key issue: Active protection only works if the DRM software is running on the user’s computer. But the user doesn’t want the software on his computer. The software provides no value to him at all. Its only effects are to stop him from doing things he wants to do (such as listening to the music with iTunes), and to expose him to possible security attacks if the software is buggy.

So if you’re designing a CD DRM system based on active protection, you face two main technical problems:

You have to get your software installed, even though the user doesn’t want it.

Once your software is installed, you have to keep it from being uninstalled, even though the user wants it gone.

These are the same two technical problems that spyware designers face.

People who face the same technical problems tends to find the same technical solutions. How do you get software installed against the user’s wishes? You mislead the user about what is being installed, or about the consequences of installation. Or you install without getting permission at all. How do you keep software from being uninstalled? You don’t provide an uninstaller. Or you provide an uninstaller that doesn’t really uninstall the whole program. Or you try to cloak the software so the user doesn’t even know it’s there.

Of course, you don’t have to resort to these tactics. But if you don’t, your software will have trouble getting onto users’ computers and staying there. If your whole business model depends on installing unwanted software and preventing its uninstallation, you’ll do what’s necessary to make that model work. You’ll resort to spyware tactics. (Or you’ll quit and go into another business.)

Having set off down the road of CD copy protection, the music industry shouldn’t be surprised to have arrived at spyware. Because that’s where the road leads.

Was anybody surprised at Tuesday’s announcement that the MediaMax copy protection software on Sony CDs had a serious security flaw? I sure wasn’t. The folks at iSEC Partners were clever to find the flaw, and the details they uncovered were interesting, but it was pretty predictable that a problem like this would turn up.

Security is all about risk management. If you’re careful to avoid unnecessary risks, to manage the risks you must accept, and to have a recovery plan for when things go wrong, you can keep your security under control. If you plunge ahead, heedless of the risks, you’ll be sorry.

If you’re a parent, you’ll surely remember the time your kid left an overfull glass of juice on the corner of a table and, after the inevitable spill, said, “It was an accident. It’s not my fault.” And so the kid had to learn why we don’t set glasses at the very edges of tables, or balance paintbrushes on the top of the easel, or leave roller skates on the stairs. The accident won’t happen every time, or even most of the time, but it will happen eventually.

If you’re a software vendor, your software creates risks for its users, and you have a responsibility to your customers to help them manage those risks. You should help your customers make informed choices about when and how to use your software, and you should design your software to avoid exposing customers to unnecessary risks. Your customers expect this from you, and they’ll hesitate to buy your product if they think you’re leaving the cyberjuice on the corner of the table.

The design of the MediaMax/Sony software is a case study in risk creation. I wrote about these risks two weeks ago:

But even if all [the software’s spyware] problems are fixed, the MediaMax software will still erode security, for reasons stemming from the basic design of the software.

For example, MediaMax requires administrator privileges in order to listen to a CD. You read that right: if you want to listen to a MediaMax CD, you must be logged in with enough privileges to manipulate any part of the system. The best practice is to log in to an ordinary (non-administrator) account, except when you need to do system maintenance. But with MediaMax, you must log in to a privileged account or you can’t listen to your CD. This is unnecessary and dangerous.

Some of the security risk of MediaMax comes from the fact that users are locked into the MediaMax music player application. The player app evades the measures designed to block access to the music; and of course the app can’t play non-MediaMax discs, so the user will have to use multiple music players. Having this extra code on the system, and having to run it, increases security risk. (And don’t tell me that music players don’t have security bugs — we saw two serious security bugs in Sony music software last week.) Worse yet, if a security problem crops up in the MediaMax player app, the user can’t just switch to another player app. More code, plus less choice, equals more security risk.

Sure enough, these risks enable the new attack, which exploits the presence of extra code on the system, and the fact that that code runs with full Administrator privileges.

The biggest risk of all, though, is that the software can install itself without the knowledge or consent of the user. When you decide to install a program on your computer, you take a security risk. But you take that risk knowingly, because you have decided the benefit provided by that program outweighs the risk. If you change your mind about that tradeoff, you can always uninstall the program.

But if you decline the MediaMax licence agreement, and the software secretly installs itself anyway, you will face risks that you didn’t choose. You won’t even know that you’re at risk. All of this, simply because you tried to listen to a compact disc.

Experience teaches that where there is one bug, there are probably others. That’s doubly true where the basic design of the product is risky. I’d be surprised if there aren’t more security bugs lurking in MediaMax.

Freedom to Tinker is hosted by Princeton's Center for Information Technology Policy, a research center that studies digital technologies in public life. Here you'll find comment and analysis from the digital frontier, written by the Center's faculty, students, and friends.