Cleaning Up Sony’s Rootkit Mess

Benjamin Edelman — Mon, 21 Nov 2005 05:00:00 +0000

Late last month, Windows expert Mark Russinovich revealed Sony installing a rootkit to hide its “XCP” DRM (digital rights management) software as installed on users’ PCs. The DRM software isn’t something a typical user would want; the “rights” it manages are Sony’s rights, i.e. by preventing users from making copies of Sony music, and this protection for Sony comes at the cost of 1%-2% of CPU time (whether or not users are playing a Sony CD). Notably, Sony didn’t disclose its practices in its installer or even in its license agreement. At least as bad, Sony initially provided no uninstall for the rootkit, and when Sony added an uninstaller, the process was needlessly complicated, prone to crashing, and a security risk. See timeline & index, parts 1 and 2.

Having bungled this situation, Sony has recalled affected CDs and announced an exchange program to swap customers’ affected CDs for XCP-free replacements. For savvy consumers who have followed this story, the exchange looks straightforward. But what about ordinary users, who don’t read the technology press and aren’t likely to learn their rights?

As it turns out, there’s a clear solution: A self-updating messaging system already built into Sony’s XCP player. Every time a user plays a XCP-affected CD, the XCP player checks in with Sony’s server. As Russinovich explained, usually Sony’s server sends back a null response. But with small adjustments on Sony’s end — just changing the output of a single script on a Sony web server — the XCP player can automatically inform users of the software improperly installed on their hard drives, and of their resulting rights and choices.

Sony’s Messaging System; A Demonstration Message

The Sony messaging system works as follows: Whenever a user plays an affected XCP CD, and whenever a user browses within certain sections of the player, the player sends a message to Sony’s connected.sonymusic.com server. A typical outbound message is shown below. A “uId” parameter (yellow) marks the CD being played and the specific section of the player in use.

GET /toc/Connect?type=redirect&uId=1171 HTTP/1.1
Accept: application/*, audio/*, image/*, message/*, model/*, multipart/*, text/*, video/*
User Agent: SecureNet Xtra
Host: connected.sonymusic.com
Connection: Keep Alive
Cache Control: no cache

Sony’s web server typically replies with a reference to a “nobanner.xml” file (green).

HTTP/1.1 302 Moved Temporarily
Set Cookie: ARPT=JKXVXZS64.14.39.161CKMJU; path=/
Date: Sat, 12 Nov 2005 18:36:49 GMT
Server: Apache/1.3.27 (Unix) mod_ssl/2.8.14 OpenSSL/0.9.7d
Location: http://www.sonymusic.com/access/banners/nobanner.xml
Keep Alive: timeout=10
Connection: Keep Alive
Transfer Encoding: chunked
Content Type: text/plain
302 Moved Temporarily

This document you requested has moved temporarily.

It’s now at nobanner.xml“>http://www.sonymusic.com/access/banners/nobanner.xml.

In place of this “nobanner” response, what if Sony’s connected server instead replied by sending a reference to a XML file that included relevant, timely disclosures? Using the HOSTS file on a test PC, I caused my test PC to think the connected.sonymusic.com server was at an IP address I controlled (rather than on a real Sony server). I then wrote a replacement /toc/Connect?… script that sent back a reference to an XML file I wrote, rather than the ordinary reference to Sony’s nobanner.xml file. Finally, I posted an XML banner configuration file. Notice my inclusion of a banner image (blue) and a hyperlink (red).

http://www.benedelman.org/sony/image1.jpg” href=”http://cp.sonybmg.com/xcp/” time=”4000″ />

In my test environment, Sony’s XCP player automatically retrieved my XML file, then retrieved the banner and showed it within the large banner box at the bottom of the player. Clicking the banner opened a browser window to the URL specified in the HREF parameter.

A notification banner shown in my Sony XCP Player, demonstrating the feasibility of using the banner system to notify users of the software installed on their computers.

For a very few artists, Sony already uses the notification system to provide updates to the XCP player’s information screens. Fortunately, the banner system explicitly anticipates placing multiple pieces of information in a single banner space. Notice the “rotatingbanner” and “time” constructs in the XML banner file above. If the tag is repeated, the XCP player automatically rotates between the specified images.

Implications and Discussion

Sony’s recall of affected CDs is a sensible start in undoing the harm and ill will XCP has caused. But for the recall to make a meaningful difference — in actually helping ordinary users, not just in improving Sony’s PR standing — Sony needs to spread the word widely.

Unlike Amazon (which already emailed users who bought an affected CD), Sony does not know the names or addresses of affected customers. But Sony’s existing banner messaging system gives Sony an easy, cost-effective way to reach them. Sony should implement the method described above. Via these banners, Sony can assure that as many affected consumers as possible have timely, authoritative information about what has been done to their computers and about how Sony offers to make them whole.

What I propose is not an auto-updater as that term is generally used. A “real” auto-updater downloads and installs executable program code onto a user’s computer. In contrast, my demonstration downloads only data — a single XML configuration file and a single graphic image. The difference has substantial implications for computer security and user control: Downloading and running executable code risks a substantial intrusion onto users’ PCs, for lack of any technology-enforced limit to what the auto-updater can do. In contrast, merely updating graphics entails no clear harms to computer security or reliability.

Sony’s initial inclusion of self-updating message screens entails clear privacy consequences — transmissions to Sony servers that report users’ IP addresses, playing habits, and CDs on hand. But these transmissions occur whether Sony sends a null “nobanner” answer or sends a useful banner with information users urgently need. Under the circumstances, Sony might as well put the notification system to use.

Sony Takes My Suggestion (This section added on December 17, 2005.)

Sony has accepted my suggestion of using XCP’s existing banner system to notify users about the XCP software. Today, upon inserting an affected Sony XCP CD, I received the banner shown below. Clicking the banner led me to http://cp.sonybmg.com/worldwide and onwards to instructions to update XCP (including removing the XCP rootkit) or to remove XCP altogether.

An actual banner shown in my Sony XCP Player on December 17, 2005.

WhenU Security Flaw

Benjamin Edelman — Tue, 01 Jun 2004 04:00:00 +0000

Every program installed on users’ PCs exposes users to potential security risks — for any program can contain design flaws that let attackers take control of a user’s computer. But experience shows some kinds of programs to be far more risky than others. Frequent readers of my site won’t be surprised to learn that software from WhenU, distributed on WhenU’s own web site until mere weeks ago, is among the programs with security vulnerabilities that let attackers take over users’ PCs.

For details, see my new WhenU Security Hole Allows Execution of Arbitrary Software. I explain the specific WhenU software found to be vulnerable, and I show what an attacker would have to do to take advantage of the vulnerability.

Among advertisement-display programs, WhenU is not alone in its security vulnerabilities. Earlier this year, researchers from the University of Washington found similar vulnerabilities in software from Claria and eZula. (See their Measurement and Analysis of Spyware in a University Environment (PDF).)

Before releasing this research to the public, I alerted WhenU staff to the flaw in their software. WhenU staff acknowledged the security risks of the software I identified — saying the program was “obsolete” and claiming it was taken out of public distribution in September 2002, even as it remained on WhenU’s ordinary public web site until I brought it to their attention. In any event, my testing indicates that the vulnerable code has now been removed from WhenU’s site, and that vulnerable software installed on users’ PCs has been patched via WhenU’s auto-update system.

I’m releasing this research in preparation for tomorrow’s hearing entitled “Who Might Be Lurking at Your Cyber Front Door? Is Your System Really Secure?,” convened by the House Committee on Government Reform‘s Subcommittee on Technology, Information Policy, Intergovernmental Relations, and the Census. Spyware poses serious security risks of which users and policy-makers should be aware.

Privacy & Security Violations at Buy.com

Benjamin Edelman — Thu, 12 Oct 2000 04:00:08 +0000

In October 2000, I noticed that buy.com‘s product return system allowed any Internet user to view prepaid UPS return labels intended for use by some 45,000+ Buy.com customers. Labels included customers’ names, addresses, and phone numbers. Buy.com has since fixed the problem, replacing the information with an error message, but I kept a sample of the data that was temporarily publicly accessible. See coverage of the story in major media.

security flaws – Ben Edelman

Cleaning Up Sony’s Rootkit Mess

WhenU Security Flaw

Privacy & Security Violations at Buy.com