January 19, 2025

AOL, Yahoo Challenge Email Neutrality

AOL and Yahoo will soon start using Goodmail, a system that lets bulk email senders bypass the companies’ spam filters by paying the companies one-fourth of a cent per message, and promising not to send unsolicited messages, according to a New York Times story by Saul Hansell.

Pay-to-send systems are one standard response to spam. The idea is that raising the cost of sending a message will deter the kind of shot-in-the-dark spamming that sends a pitch to everybody in the hope that somebody, somewhere, will respond. The price should be high enough to deter spamming but low enough that legitimate email won’t be deterred. Or so the theory goes.

What’s different here is that senders aren’t paying for delivery, but for an exemption from the email providers’ spam filters. As Eric Rescorla notes, this system creates interesting incentives for the providers. For instance, the providers will have an incentive to make their spam filters overly stringent – so that legitimate messages will be misclassified as spam, and senders will be more likely to pay for an exemption from the filters.

There’s an interesting similarity here to the network neutrality debate. Net neutrality advocates worry that residential ISPs will discriminate against some network traffic so that they can charge web sites and services a fee in exchange for not discriminating against their traffic. In the email case, the worry is that email providers will discriminate against commercial email, so that they can charge email senders a fee in exchange for not discriminating against their messages.

Is this really the same policy problem? If you advocate neutrality regulations on ISPs, does consistency require you to advocate neutrality regulations on email providers? Considering these questions may shed a little light on both issues.

My tentative reaction to the email case is that this may or may not be a smart move by AOL and Yahoo, but they ought to be free to try it. If customers get fewer of the commercial email messages they want (and don’t get enough reduction in spam to make up for it), they’ll be less happy with AOL and Yahoo, and some will take their business elsewhere. The key point, I think, is that customers have realistic alternatives they can switch to. Competition will protect them.

(You may object that switching email providers is costly for a customer who has been using an aol.com or yahoo.com email address – if he switches email providers, his old email address might not work any more. True enough, but a rational email provider will already be exploiting this lock-in, perhaps by charging the customer a slightly higher fee than he would pay elsewhere.)

Competition is a key issue – perhaps the most important one – in the net neutrality debate too. If commercial ISPs face real competition, so that users have realistic alternatives to an ISP who misbehaves, then ISPs will have to heed their customers’ demand for neutral access to sites and services. But if ISPs have monopoly power, their incentives may drive them to behave badly.

To me, the net neutrality issue hinges largely on whether the residential ISP market will be competitive. I can’t make a clear prediction, but I know that there are people who probably can. I’d love to hear what they have to say.

What does seem clear is that regulatory policy can help or hinder the emergence of competition. Enabling competition should be a primary goal of our future telecom regulation.

Report: Many Apps Misconfigure Security Settings

My fellow Princeton computer scientists Sudhakar Govindavajhala and Andrew Appel released an eye-opening report this week on access control problems in several popular applications.

In the old days, operating systems had simple access control mechanisms. In Unix, each file belonged to an owner and a (single) group of users. The owner had the option to give the other group members read and/or write permission, and the option to give everybody read and/or write permission. That was pretty much it.

Over time, things have gotten more complicated. Windows controls access to about fifteen types of objects, with about thirty different flavors of privileges that can each be granted or denied, for any object, to any user or group of users. Privileges can be managed with great precision. In theory, this lets people grant others the absolute minimum privileges they need to do their jobs, which is good security practice.

The downside of this complexity is that if the system is hard to understand, people will make mistakes. End users will surely make mistakes. But you might think that big software companies can manage this complexity and will get the security settings on their products right.

Which brings us to Sudhakar and Andrew’s research. They built an automated tool to analyze the access control settings on files, registry entries, and other objects on a Windows machine. The tool looks at the settings on the machine and applies a set of inference rules that encode the various ways a user could try to leverage his privileges improperly. For example, one rule says that if Alice has the privilege to modify a program, and Bob runs that program, then Alice can use any of Bob’s privileges. (She can do this by adding code to the program that does what she wants; when Bob runs the program, that code will run with Bob’s privileges.) The tool looks for privilege escalation attacks, or ways for a relatively unprivileged user to gain more privilege.

Sudhakar and Andrew ran the tool on professionally-managed Windows systems, and the results were sobering. Several popular applications, from companies like Adobe, AOL, Macromedia, and Microsoft, had misconfigured their access control in ways that allowed relatively unprivileged users – in some cases even the lowliest Guest account – to gain full control of the system.

Sudhakar and Andrew notified the affected vendors well before publishing the paper, and some of the problems they found have been patched. But some problems remain, and testing on new systems tends to find still more problems.

There are two lessons here. First, complicated security mechanisms lead to mistakes, even among relatively sophisticated software developers and companies, so the desire to control privileges precisely must be tempered by the virtue of simplicity. Second, if you’re going to have a complicated system, you probably need tools to help you figure out whether you’re using it safely.

Paper Naming Contest

So our Sony CD DRM paper is virtually done, except for one thing: the title. We hope you can help us out.

We’re looking for a phrase from a song lyric, song title, or album title that is distinctive and can be read as a pithy comment on the whole Sony CD DRM incident. It should be recognizable and non-inflammatory. The title of the paper will be “ThePhrase: Lessons from the Sony CD DRM Episode”.

Please offer suggestions in the comments. Thanks!

[Update (Feb. 9): Let me emphasize that we’re looking for phrases that would be recognized instantly by most readers. We don’t want to have to explain where the title came from. (If we were wanted a phrase that we had to explain, the clear winner would be “Invisible Invasion”, which is the title of the only album we know of that was issued under both of the Sony DRM technologies.)]

What's in the Secret VEIL Test Results?

I wrote last week about how the analog hole bill would mandate use of the secret VEIL technology. Because the law would require compliance with the VEIL specification, that spec would effectively be part of the law. Call me old-fashioned, but I think there’s something wrong when Congress is considering a secret bill that would impose a secret law. We’re talking about television here, not national security.

Monday’s National Journal Tech Daily had a story (subscribers only; sorry) by Sarah Lai Stirland about the controversy, in which VEIL executive Scott Miller said “the company is willing to provide an executive summary of test results of the system to anyone who wants them.”

Let’s take a look at that test summary. The first thing you’ll notice is how scanty the document is. This is all the testing they did to validate the technology?

The second thing you’ll notice is that the results don’t look very good for VEIL. For example, when they tested to see whether VEIL caused a visible difference in the video image, they found that viewers did report a difference 29% of the time (page 4).

More interesting, perhaps, are the results on removability of the VEIL watermark (page 2). They performed ten unspecified transformations on the video signal and measured how often each transformation made the VEIL watermark undetectable. Results were mixed, ranging from 0% success in removing the watermark up to 58%. What they don’t tell us is what the transformations (which they call “impairments”) were. So all we can conclude is that at least one of the transformations they chose for their test can remove the VEIL watermark most of the time. And if you have any experience at all in the industry, you know that vendor-funded “independent” studies like this tend to pick easy test cases. You have to wonder what would have happened if they had chosen more aggressive transformations to try. And notice that they’re refusing to tell us what the transformations were – another hint that the tests weren’t very strenuous.

The VEIL people have more information about all of these tests, but they are withholding the full testing report from us, even while urging our representatives to subject us to the VEIL technology permanently.

Which suggests an obvious question: What is in the secret portion of the VEIL testing results? What are they hiding?

CD DRM: Attacks on the Player

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 later in the 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 excerpt is the last one we will post. By now, you have seen drafts of the all sections of the paper except the introduction, conclusion, and discussion of related work. The deadline for submission is (late) tomorrow night.

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.

Attacks on the Player

Increasingly, personal computers—and portable playback devices that attach to them—are users’ primary means of organizing, transporting, and enjoying their music collections. Sony and its DRM vendors recognized their trend when they designed their copy protection technologies. Rather than inhibit all use with PCs, as some earlier anti-copying schemes did~cite{}, XCP and MediaMax allow certain limited uses subject to restrictions imposed by DRM software.

XCP and MediaMax facilitate use on PCs using their own proprietary media players that are shipped on each protected CD. The schemes use active (and, with XCP, passive) protection to block other applications from accessing the CD audio, but a back door allows the scheme’s own player to bypass the protections.

The XCP and MediaMax players launch automatically using autorun when a protected disc is inserted into a PC. Both players have similar feature sets. They provide a rudimentary player interface, allowing users to listen to protected albums, and they allow access to “bonus content,” such as album art, liner notes, song lyrics, and links to artist web sites. [Footnote: Curiously, this bonus content is seldom copy protected, perhaps because it is of little value.]

XCP and MediaMax both permit users to burn copies of the entire album a limited number of times (typically 3). These copies are create using a proprietary burning application integrated into the player. They include the player applications and active (and passive, for XCP) protection as the original album, but they do not allow any subsequent generations of copying.

Another feature of the player applications allows users to rip the tracks from the CD to their hard disks, but only in DRM-protected audio formats. Both schemes support the Windows Media Audio format by using a Microsoft product, the Windows Media Data Session Toolkit [citation[, to deliver DRM licenses that are bound to the PC where the files were ripped. The licenses allow the music to be transferred to portable devices that support Windows Media DRM scheme or burned onto CDs, but the Windows Media files will not be usable if they are copied to another PC.

Attacks on Player DRM

The XCP and MediaMax players were designed to enforce usage restrictions specified by content providers. In practice, they provide minimal security, because there are a number of ways that users can bypass the limitations.

Perhaps the most interesting class of attacks targets the limited number of burned copies permitted by the players. Both players are designed to enforce this limit without communicating with any networked server; therefore, the player must keep track of how many allowed copies remain by storing state on the local machine.

It is well known that DRM systems like this are vulnerable to rollback attacks. In a rollback attack, the state of the machine is backed up before performing the limited operation (in this case, burning the copy). When the operation is complete, the old system state is restored, and the DRM software is not able to determine that the operation has occurred. This kind of attack is easy to perform with virtual machine software like VMWare, which allows the entire state of the system to be saved or restored in a few clicks. The XCP and MediaMax both fail under this attack, which allows unlimited copies to be burned with their players.

A refined variation of this attack targets only the specific pieces of state that the DRM system uses to remember the number of copies remaining. The XCP player uses a single file, %windir%system32$sys$filesystem$sys$parking, to record how many copies remain for every XCP album that has been used on the system. [Footnote: We did not determine how the MediaMax player stores the number of copies remaining.] This file is hidden and protected by the XCP rootkit. With the rootkit disabled, a user can back up the file, copy the album, and then restore the backup to set the remaining copy counter back to its original value.

A more advanced attacker can go further and modify the $sys$parking file to set the counter to an arbitrary value. The file consists of a 16 byte header followed by a series of 177 byte records. For each XCP disc used on the machine, the file contains a whole-disc record and an individual record for each track. Each disc record stores the number of permitted copies remaining for the disc as a 32-bit integer beginning 100 bytes from the start of the record.

The file is protected by primitive encryption. Each record is XORed with a repeating 256-bit pad. The pad—a single one is used for all records—is randomly chosen when XCP is first installed and stored in the system registry in the key HKLMSOFTWARE$sys$referenceClassID. Note that this key, which is hidden by the rootkit, is intentionally misnamed “ClassID” to confuse investigators. Instead of a ClassID it contains the 32 bytes of pad data.

Hiding the pad actually doesn’t increase the security of the design. An attacker who knows only the format of the $sys$parking file and the current number of copies remaining can change the counter to an arbitrary value without. Say the counter indicates that there are x copies remaining and the attacker wants to set it to y copies remaining. Without decrypting the record, she can XOR the padded bytes where the counter is stored with the value (x XOR y). If the original value was padded with p, the new value is (x XOR p) XOR (x XOR y) = (y XOR p), which is just y padded with p.

iPod Compatibility

Ironically, Sony itself furnishes directions for carrying out another kind of attack on the player DRM.

Conspicuously absent from the XCP and MediaMax players is support for the Apple iPod—by far the most popular portable music player with more than 80% of the market [citation]. A Sony FAQ blames Apple for this shortcoming and urges users to direct complaints to them:”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.” [citation]. Strictly speaking, it is untrue that Sony requires Apple’s cooperation to work with the iPod. They ship thousands of albums that work “smoothly” with iTunes every day: unprotected CDs. What Sony has difficulty doing is moving music to the iPod while keeping it wrapped in copy protection. This is because Apple has so far refused to license its proprietary DRM, a system called FairPlay.

Yet so great is consumer demand for iPod compatibility that Sony gives out—to any customer who fills out a form on its web site [citation] —instructions for working around its own copy protection and transforming the music into a DRM-free format that will work with iTunes. The procedure is simple but cumbersome: users are directed to use the player software to rip the songs into Windows Media DRM files; use Windows Media Player to burn the files to a blank CD, which will be free of copy protection; and then use iTunes to rip the songs once more and transfer them to the iPod.

XCP’s Hidden iPod Support

A further irony came to light in the weeks following the public disclosure of the XCP rootkit when it was discovered that XCP itself apparently infringes on the copyrights to several open source software projects. In one case, Sam Hocevar found strong evidence that part of XCP’s code was copied from a program called DRMS, which he co-authored with Jon Lech Johansen and released under the terms of the GPL open source license. This was particularly curious, because the purpose of DRMS is to break Apple’s FairPlay DRM. Its presence is interesting enough to warrant a brief diversion from our discussion of player-related attacks.

We discovered that XCP utilizes the DRMS code not to remove Apple DRM but to add it, as part of a hidden XCP feature that provides iTunes and iPod compatibility. This functionality shipped on nearly every XCP CD, but it was never enabled or made visible in the XCP user interface. Despite being inactive, the code appears to be fully functional and was compatible with the current version of iTunes when the first XCP CDs were released. [Footnote: XCP’s FairPlay-compatibility code works with iTunes up to iTunes version 4.8. iTunes 4.9, released June 28, 2005, included changes unrelated to FairPlay that cause the XCP code to fail. XCP CDs released after this date do not appear to contain an updated version of the code.] This strongly suggests that the apparently infringing DRMS code was deliberately copied by XCP’s creator, First4Internet, rather than accidentally included as part of a more general purpose media library used for other functions in the copy protection system.

This isn’t the first time another vendor has tried to make its DRM compatible with FairPlay. FairPlay is the only DRM compatible with iPod, and Apple has declined to license it to rival music distributors, effectively locking rivals out from the iPod platform (at least as long as the rivals insist on using DRM). In 2004, RealNetworks attempted to work around Apple and reverse engineered FairPlay so that Real Player could create FairPlay files for use with the iPod [citation]. Apple responded by making vague legal threats and updating iTunes to break this compatibility. The evidence suggests that First4Internet wanted to create their own iPod compatibility system, but rather than take the time to reverse engineer FairPlay themselves, they copied critical pieces of code from DRMS in violation of the GPL license.

Understanding how XCP uses code from DRMS requires a some background information about FairPlay. When a customer purchases a song from the iTunes Music Store, she receives a FairPlay encrypted audio file that can only be played with knowledge of a secret key assigned to her by Apple. iTunes retrieves this key from an Apple server and stores it on the hard drive in an encrypted key database (a file called SC Info.sidb). When the user plays the song again, or if she copies it to an iPod, iTunes reads her key from the database instead of reconnecting to the server.

FairPlay’s security depends on the encrypted key database being difficult anyone but Apple to decipher, so it is protected using a proprietary encryption method and a system-dependent secret key. [Footnote: As security experts predicted, this protection was quickly broken. Today DRMS is able to defeat FairPlay because Jon Lech Johansen reverse engineered the database decryption code in iTunes.] iTunes encrypts the key database using a two step process. First it pads the plaintext database by XORing it with the output of a proprietary pseudorandom number generator (PRNG) using a system-dependent seed; then it applies AES encryption in ECB mode with a system-dependent key. As a consequence of this design, the code for the PRNG is exactly the same whether the file is being encrypted or decrypted. To decrypt, iTunes applies AES decryption, then XORs the same PRNG output again. This explains why parts of the DRMS code—in particular, a function called DoShuffle, which computes the PRNG’s output—are useful for encryption as well as their original purpose, decryption.

The proprietary PRNG must have been especially difficult to reverse engineer. Rather than expend this effort themselves, XCP’s authors appear to have lifted the DoShuffle code verbatim from DRMS. XCP uses this code to manipulate the iTunes key database in the process of adding FairPlay protection. Starting with an unencrypted audio file, such as a track from a protected CD, XCP applies AAC compression in memory, then encrypts using the same algorithm as FairPlay. Instead of using an Apple-assigned user key, XCP creates a new random user key and, with the help of the DRMS code, adds it to the iTunes key database. This ensures that the song file can only be used on the computer where it was created.

The XCP FairPlay compatibility code is contained in a file named ECDPlayerControl.ocx that is installed the first time an XCP CD is played. The code can be tested by jumping to a function at debugger offset 0x10010380 (apparently the start of a thread for transferring music to iTunes). This function takes one parameter, a wide character string of the form <m P 3>< "C:test.mp3">. This syntax causes the function to convert an MP3 file to a FairPlay-protected AAC file. Variations can be used to specify other audio sources: WAV files, raw audio files, standard unprotected audio CDs, and XCP copy-protected CDs. Before calling the function, you must initialize a Windows CriticalSection object and set the ECX register to the object’s address minus 0x6C.

The parent function calls a subroutine (offset 0x10027D20) that converts an audio file into a FairPlay-protected AAC file. A second subroutine (offset 0x1008A470) reads the iTunes key database, decrypts it, and, if necessary, adds the XCP user key to the database and re-saves it in encrypted form. The iTunes database encryption function
(0x1008A0C0) and decryption function (0x1008A300) both made use of the DoShuffle routine (0x10089E00) taken from DRMS.

MediaMax Player Security Risks

Besides suffering from several kinds of attacks that expose the music content to copying, the MediaMax player make the user’s system more vulnerable to attack. When a MediaMax CD is inserted into a computer, Windows autorun launched an installer from the disc. Even before the installer displays a license agreement, it copies almost 12 megabytes of files and data related to the MediaMax player to the hard disk and stores them in a folder named
%programfiles%Common FilesSunnComm Shared. Jesse Burns and Alex Stamos of iSec partners first discovered that the MediaMax installer sets insecure permissions on this directory and the files and programs it contains [citation]. The installer grants “Everyone” (all users) the “Full Control” privilege. Normally, application files shared by all users on a Windows system can only be modified by members of the “Administrators” and “Power Users” groups.

As Burns and Stamos realized, this misconfiguration could lead to a dangerous privilege escalation attack. The incorrect permissions allow a non-privileged user to replace the executable code in the MediaMax player files. A user might plant malicious code deliberately in order to attack the system, or accidentally as the result of an email virus. The next time a user plays a MediaMax-protected CD, the attack code will be executed with that user’s security privileges. The MediaMax player requires Power User or Administrator privileges to run, so it’s likely that the attacker’s code will run with almost complete control of the system.

Normally, this problem could be fixed by manually correcting the errant permissions. However, MediaMax aggressively updates the installed player code each time the software on a protected disc autoruns or is launched manually. As part of this update, the permissions on the installation directory are reset to the insecure state.

We discovered a variation of the attack suggested by Burns and Stamos that allows the attack code to be installed and triggered even more easily—simply by inserting MediaMax CDs without ever consenting to the software’s installation. In the original attack, the user needed to accept the MediaMax license agreement before attack code could be inserted or executed, because the code was placed in a file called MMX.EXE that was not copied to the system until after the agreement was accepted. In our version, the attacker modifies a different file, MediaMax.dll, which MediaMax installs even before displaying a license agreement, and places attack code in the file’s DllMain() procedure. The next time a MediaMax CD is inserted, the installer autoruns and immediately attempts to check the version of the installed MediaMax.dll file. The installer calls the Windows LoadLibrary function on the DLL file, which causes the file’s DllMain() procedure to execute, together with any attack code inserted there.

This problem was exacerbated because part of the MediaMax software are installed automatically and without consent. Users who declined the license agreement would likely assume that MediaMax was not installed, and so most were unaware that they were vulnerable. The same installer code performs the dangerous version check as soon as the CD is inserted. A CD that prompted the user to accept a license before installing would give the user a chance to head off the attack.

Fixing the problem permanently without losing the use of protected discs requires applying a patch from MediaMax. Unfortunately, we discovered, the initial patch released by Sony in response to the iSec report was capable of triggering precisely the kind of attack it attempted to forestall. In the process of updating MediaMax, the patch checks the version of MediaMax.dll just like the MediaMax installer does. If this file has already been booby trapped by an attacker, the process of applying the security patch could execute the attack code. Prior versions of the MediaMax uninstaller had the same vulnerability, though both the uninstaller and the patch have since been replaced with versions that do not suffer from this problem.