Sony, Rootkits and Digital Rights Management Gone Too Far

Mark's Sysinternals ^ | Monday, October 31, 2005 | Mark's Sysinternals

[zeugma]

From slashdot.org article:
"SysInternals.com guru Mark Russinovich has a detailed investigation of a rootkit from Sony Music. It's installed with a DRM-encumbered music CD, Van Zant's "Get Right with the Man". (Mmmm, delicious irony!) The rootkit introduces several security holes into the system that could be exploited by others, such as hiding any executable file that starts with '$sys$'. Russinovich also identifies several programming bugs in the method it uses to hook system calls, and chronicles the painful steps he had to take to 'exorcise the daemon' from his system."

Last week when I was testing the latest version of RootkitRevealer (RKR) I ran a scan on one of my systems and was shocked to see evidence of a rootkit. Rootkits are cloaking technologies that hide files, Registry keys, and other system objects from diagnostic and security software, and they are usually employed by malware attempting to keep their implementation hidden (see my “Unearthing Rootkits” article from the June issue of Windows IT Pro Magazine for more information on rootkits). The RKR results window reported a hidden directory, several hidden device drivers, and a hidden application:

[Iconoclast2]

That's what you can do when you own Congress.

[Iconoclast2]

Does one consent to this invasion by opening the CD wrapper, or is "computer crime" involved (Oregon law):

(2) Any person commits computer crime who knowingly accesses, attempts to access or uses, or attempts to use, any computer, computer system, computer network or any part thereof for the purpose of:

(a) Devising or executing any scheme or artifice to defraud;

(b) Obtaining money, property or services by means of false or fraudulent pretenses, representations or promises; or

(c) Committing theft, including, but not limited to, theft of proprietary information.

(3) Any person who knowingly and without authorization alters, damages or destroys any computer, computer system, computer network, or any computer software, program, documentation or data contained in such computer, computer system or computer network, commits computer crime.

(4) Any person who knowingly and without authorization uses, accesses or attempts to access any computer, computer system, computer network, or any computer software, program, documentation or data contained in such computer, computer system or computer network, commits computer crime.

(5)(a) A violation of the provisions of subsection (2) or (3) of this section shall be a Class C felony. Except as provided in paragraph (b) of this subsection, a violation of the provisions of subsection (4) of this section shall be a Class A misdemeanor.

[zeugma]

Bumping for some daytime visibiity.

[ShadowAce]

Thanks for the extra ping, zeugma.

[Still Thinking]

Why isn't Sony facing criminal prosecution under the various anti-digital terrorism acts?

Hadn't you heard, it's been proven incontrovertibly that large political donors are never terrorists. The are simply incapable of being.

[N3WBI3]

Normally, I'd try to post the entire article, but I had issues with trying to get it formatted properly.

That would be the DRM ;), you dont really have a right to any of that..

I hate this whole issue on one side you have people who think stealing copyright is OK and on the others people who think its OK to pull crap like this..

[Tribune7]

bump

[ShadowAce]

Also noted from the Register story--

But the most disturbing part of the tale came when Russinovich ran his standard rootkit-removal tool on the post-Sony PC.

"Users that stumble across the cloaked files with a RKR scan will cripple their computer if they attempt the obvious step of deleting the cloaked files," he writes.

Which puts it in an entirely different class of software to the copy restriction measures we've seen so far, which can be disabled by a Post-It note. Until specialist tools arrive to disinfect PCs of this particular measure. ®

[Golden Eagle]

I agree this has gone too far, which is why there needs to be a standardized DRM method for Windows PC's. Until that time, and there's a lot of pirates fighting it every step of the way, vigilante processes like this will probably become the norm. The same will eventually happen to Linux until standardized DRM is in place on that platform as well, since DRM is inevitable the smart move is to get standardized user-friendly mechanisms in place, which I'm sure you support. /sarcasm

[pillbox_girl]

Hadn't you heard, it's been proven incontrovertibly that large political donors are never terrorists. The are simply incapable of being.

And terrorists and criminals never take advantage of the huge gaping security holes large corporations secretly open in their customers computers. Terrorists and criminals respect and admire large corporations far to much to ever do that.

[Bush2000]

It's very easy to disable this behavior. Under Windows XP, simply right-click on your CDROM/DVDROM drive under My Computer and select the AutoPlay tab. Select Music CD in the dropdown list. Then, under Action to perform, select Take no action. After that point, whenever you insert a music CD, Windows will not automatically run the startup binary located on the CD.

[Bush2000]

Nah, this will undoubtedly be added to SpyBot and other tools. It's not that difficult to remove the regkeys and binaries.

[ShadowAce]

Agreed. But the point is that a third party is screwing with your computer without asking or notifying you, and screwing with it in such a way as to make removal difficult (comparatively).

That is just wrong, no matter what the motivation.

[Bush2000]

Personally, I think that Sony is opening itself up to litigation by doing this; especially if it results in harm to your computer or data. It's fairly typical for software vendors to put up some kind of license UI that requires user input before installing software. Clearly, Sony isn't interested in what you or I have to say about their installation of software. But, as I pointed out earlier, it's a simple matter to disable this behavior.

[zeugma]

I agree this has gone too far, which is why there needs to be a standardized DRM method for Windows PC's. Until that time, and there's a lot of pirates fighting it every step of the way, vigilante processes like this will probably become the norm. The same will eventually happen to Linux until standardized DRM is in place on that platform as well, since DRM is inevitable the smart move is to get standardized user-friendly mechanisms in place, which I'm sure you support. /sarcasm

Wow. I'm amazed that you're not on record as supporting the ability of a company in install, without the user's permission or knowledge, a program that changes the operating system of a computer in a fundamental way.

It's official folks, GE supports spyware and rootkits as long as it's done in the name of preventing "piracy".

Astounding. This is a keeper.

[zeugma]

you're not now on record

Geez. Need to proof better.

[monkapotamus]

Sony, Rootkits and Digital Rights Management Gone Too Far

Last week when I was testing the latest version of RootkitRevealer (RKR) I ran a scan on one of my systems and was shocked to see evidence of a rootkit. Rootkits are cloaking technologies that hide files, Registry keys, and other system objects from diagnostic and security software, and they are usually employed by malware attempting to keep their implementation hidden (see my “Unearthing Rootkits” article from thre June issue of Windows IT Pro Magazine for more information on rootkits). The RKR results window reported a hidden directory, several hidden device drivers, and a hidden application:



Given the fact that I’m careful in my surfing habits and only install software from reputable sources I had no idea how I’d picked up a real rootkit, and if it were not for the suspicious names of the listed files I would have suspected RKR to have a bug. I immediately ran Process Explorer and Autoruns to look for evidence of code that would activate the rootkit each boot, but I came up empty with both tools. I next turned to LiveKd, a tool I wrote for Inside Windows 2000 and that lets you explore the internals of a live system using the Microsoft kernel debugger, to determine what component was responsible for the cloaking.

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.

It’s relatively easy to spot system call hooking simply by dumping the contents of the service table: all entries should point at addresses that lie within the Windows kernel; any that don’t are patched functions. Dumping the table in Livekd revealed several patched functions:



I listed one of the intercepting functions and saw that it was part of the Aries.sys device driver, which was one of the images I had seen cloaked in the $sys$filesystem directory:



Armed with the knowledge of what driver implemented the cloaking I set off to see if I could disable the cloak and expose the hidden processes, files, directories, and Registry data. Although RKR indicated that the \Windows\System32\$sys$filesystem directory was hidden from the Windows API, it’s common for rootkits to hide directories from a directory listing, but not to prevent a hidden directory from being opened directly. I therefore checked to see if I could examine the files within the hidden directory by opening a command prompt and changing into the hidden directory. Sure enough, I was able to enter and access most of the hidden files:



Perhaps renaming the driver and rebooting would remove the cloak, but I also wanted to see if Aries.sys was doing more than cloaking so I copied it to an uncloaked directory and loaded it into IDA Pro, a powerful disassembler I use in my exploration of Windows internals. Here’s a screenshot of IDA Pro’s disassembly of the code that calculates the entries in the system service table that correspond to the functions it wants to manipulate:



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. Besides being indiscriminate about the objects it cloaks, other parts of the Aries code show a lack of sophistication on the part of the programmer. It’s never safe to unload a driver that patches the system call table since some thread might be just about to execute the first instruction of a hooked function when the driver unloads; if that happens the thread will jump into invalid memory. There’s no way for a driver to protect against this occurrence, but the Aries driver supports unloading and tries to keep track of whether any threads are executing its code. The programmer failed to consider the race condition I’ve described. They’ll have to come up with a new approach to their rootkit sooner or later anyway, since system call hooking does not work at all on 64-bit versions of Windows.

After I finished studying the driver's code I rebooted the system. The cloak was gone as I expected and I could see all the previously hidden files in Explorer and Registry keys in Regedit. I doubted that the files had any version information, but ran my Sigcheck utility on them anyway. To my surprise, the majority did have identifying product, file and company strings. I had already recognized Dbghelp.dll and Unicows.dll as Microsoft Windows DLLs by their names. The other files claimed to be part of the “Essential System Tools” product from a company called “First 4 Internet”:



I entered the company name into my Internet browser’s address bar and went to http://www.first4internet.com/. I searched for both the product name and Aries.sys, but came up empty. However, the fact that the company sells a technology called XCP made me think that maybe the files I’d found were part of some content protection scheme. I Googled the company name and came across this article, confirming the fact that they have deals with several record companies, including Sony, to implement Digital Rights Management (DRM) software for CDs.

The DRM reference made me recall having purchased a CD recently that can only be played using the media player that ships on the CD itself and that limits you to at most 3 copies. I scrounged through my CD’s and found it, Sony BMG’s Get Right with the Man (the name is ironic under the circumstances) CD by the Van Zant brothers. I hadn’t noticed when I purchased the CD from Amazon.com that it’s protected with DRM software, but if I had looked more closely at the text on the Amazon.com web page I would have known:



The next phase of my investigation would be to verify that the rootkit and its hidden files were related to that CD’s copy protection, so I inserted the CD into the drive and double-clicked on the icon to launch the player software, which has icons for making up to three copy-protected backup CDs:



Process Explorer showed the player as being from Macromedia, but I noticed an increase in CPU usage by $sys$DRMServer.exe, one of the previously cloaked images, when I pressed the play button. A look at the Services tab of its process properties dialog showed it contains a service named “Plug and Play Device Manager”, which is obviously an attempt to mislead the casual user that stumbles across it in the Services MMC snapin (services.msc) into thinking that it’s a core part of Windows:



I closed the player and expected $sys$DRMServer’s CPU usage to drop to zero, but was dismayed to see that it was still consuming between one and two percent. It appears I was paying an unknown CPU penalty for just having the process active on my system. I launched Filemon and Regmon to see what it might be doing and the Filemon trace showed that it scans the executables corresponding to the running processes on the system every two seconds, querying basic information about the files, including their size, eight times each scan. I was quickly losing respect for the developers of the software:



I still had to confirm the connection between the process and the CD’s player so I took a closer look at each process. Based on the named pipe handles I saw they each had opened when I looked in Process Explorer’s handle view I suspected that the player and $sys$DRMServer communicated via named pipes and so I launched Filemon, checked Named Pipes in the Volumes menu, and confirmed my theory:



At that point I knew conclusively that the rootkit and its associated files were related to the First 4 Internet DRM software Sony ships on its CDs. Not happy having underhanded and sloppily written software on my system I looked for a way to uninstall it. However, I didn’t find any reference to it in the Control Panel’s Add or Remove Programs list, nor did I find any uninstall utility or directions on the CD or on First 4 Internet’s site. I checked the EULA and saw no mention of the fact that I was agreeing to have software put on my system that I couldn't uninstall. Now I was mad.

I deleted the driver files and their Registry keys, stopped the $sys$DRMServer service and deleted its image, and rebooted. As I was deleting the driver Registry keys under HKLM\System\CurrentControlSet\Services I noted that they were either configured as boot-start drivers or members of groups listed by name in the HKLM\System\CurrentControlSet\Control\SafeBoot subkeys, which means that they load even in Safe Mode, making system recovery extremely difficult if any of them have a bug that prevents the system from booting.

When I logged in again I discovered that the CD drive was missing from Explorer. Deleting the drivers had disabled the CD. Now I was really mad. Windows supports device “filtering”, which allows a driver to insert itself below or above another one so that it can see and modify the I/O requests targeted at the one it wants to filter. I know from my past work with device driver filter drivers that if you delete a filter driver’s image, Windows fails to start the target driver. I opened Device Manager, displayed the properties for my CD-ROM device, and saw one of the cloaked drivers, Crater.sys (another ironic name, since it had ‘cratered’ my CD), registered as a lower filter:



Unfortunately, although you can view the names of registered filter drivers in the “Upper filters” and “Lower filters” entries of a device’s Details tab in Device Manager, there’s no administrative interface for deleting filters. Filter registrations are stored in the Registry under HKLM\System\CurrentControlSet\Enum so I opened Regedit and searched for $sys$ in that key. I found the entry configuring the CD’s lower filter:



I deleted the entry, but got an access-denied error. Those keys have security permissions that only allow the Local System account to modify them, so I relaunched Regedit in the Local System account using PsExec: psexec –s –i –d regedit.exe. I retried the delete, succeeded, and searched for $sys$ again. Next I found an entry configuring another one of the drivers, Cor.sys (internally named Corvus), as an upper filter for the IDE channel device and also deleted it. I rebooted and my CD was back.

The entire experience was frustrating and irritating. Not only had Sony put software on my system that uses techniques commonly used by malware to mask its presence, the software is poorly written and provides no means for uninstall. Worse, most users that stumble across the cloaked files with a RKR scan will cripple their computer if they attempt the obvious step of deleting the cloaked files.

While I believe in the media industry’s right to use copy protection mechanisms to prevent illegal copying, I don’t think that we’ve found the right balance of fair use and copy protection, yet. This is a clear case of Sony taking DRM too far.

posted by Mark Russinovich @ 11:04 AM

[Golden Eagle]

It's very easy to disable this behavior.

Nice tip, thanks!

[Golden Eagle]

It's official folks, GE supports spyware and rootkits as long as it's done in the name of preventing "piracy".

No I didn't, I specifically said I agree with you their behavior went too far. You obviously have some sort of mental disorder, I'd seriously suggest you get it checked out before you erroneously accuse someone else of something.

[zeugma]

No I didn't, I specifically said I agree with you their behavior went too far.

O.K. after looking at your comment closer, I apologize for claiming that you support this particular implementation of DRM.

My apologies.