Sony DRM rootkit code (#9) System Call Hooking Sony DRM rootkit code (#9) System Call Hooking
I hate when I have to rekey something this long because blogger timed out, but... This is going to be fairly long and technical. I should note that while I have significant expertise in operating systems (OS), most of it was in older OS's than Microsoft Windows, and in particular, Windows NT, and progeny: 2000 (2K)and XP.
Let's start with virtual memory. Computer programs need two things to execute: control of a processor, and a program loaded in physical memory. But from the first, programs that need to be run have exceeded the physical memory available. This is a moving target, with program sizes growing as fast as, if not faster than, physical memories. The most successful solution to this problem is "virtual memory". Programs are allocated a (large) chunk of disk space. Fixed sized pages of a program correspond to similar sized pages on disk. This is the virtual memory image of the program. Then, when the program needs a page from its virtual memory, a page from physical memory is allocated, and the appropriate page from disk is loaded into the physical memory page. Later, the phsical memory page may be allocated to another virtual page for another program, in which case, the contents are rolled back to disk (if necessary), before the new contents are loaded there. The result is a much larger address space than is possible with phsyical memory. Indeed, it allows me to run the same OS (Win2K) on computers with physical memory ranging from 32mb to 768mb.
On to the kernel. At a minimum, the kernel is the part of the OS that needs to always be present in physical memory in order for a computer to run. At a minimum, it includes first level interrupt code, the cpu dispatcher, and memory management - all necessary to make virtual memory work. It also often includes other high security, high usage routines. Note though, that the kernel is locked into physical memory - it does not use virtual memory, but rather is necessary to implement it.
On to binding. One essential of computer programming is the concept of subroutines. A program enters a subroutine, which does some work, and then returns to the original program. The subroutine may, and ususally does, call or invoke other subroutines. OS functions in modern OS's are also typically invoked as subroutines. Binding is the determination of where subroutines are located so that they can be called. Older OS's bound their subroutines at link/edit time, requiring relinking when any changes are made. Modern OS's utilize tables of addresses to indirectly access subroutines or functions. This provides a lot more flexibility, since, instead of directly calling the routine at address 80402020, the routine at table entry #43 (that contains 80402020) can be invoked instead. Then, at the next boot, the routine may move to 80604020. But that is transparent to other routines, since they would still access it through table entry #43.
Microsoft Windows has a table of kernal routines or APIs called the "system service table". Each kernal routine has an entry in that table, and access is made by specifying its entry number in the table. The Sony DRM root kit replaces several of the entries in the system service table with addresses of Sony routines.
Note the first problem with this. The Sony routines are not located in the kernel. Thus, they are subject to virtual memory swap. And if they swap out, something else is likely to be loaded into physical memory at the location specified by those system service table entries overwritten by the Sony code. If another program is loaded there, it will be executed instead. And if it contains data or garbage, the results are liable to be even more bizarre when the APIs corresponding to those overwritten system service table entries are invoked.
Secondly, Microsoft enforces kernel security through a number of security measures. One of them is to checksum kernel routines when loaded at boot time, and check that those checksums match their expected values. This is missing for the Sony routines, since they don't reside in the kernel (and weren't written by Microsoft). They are thus significantly more vulnerable to being overwritten, linked to, etc. than the corresponding MSFT runctions. And note that any routines that utilize this security hole would execute in kernel mode, allowing almost unfettered access to the computer.
Thus, the Sony DRM root kit is likely to reduce both security and stability of Windows sytems.
Let's start with virtual memory. Computer programs need two things to execute: control of a processor, and a program loaded in physical memory. But from the first, programs that need to be run have exceeded the physical memory available. This is a moving target, with program sizes growing as fast as, if not faster than, physical memories. The most successful solution to this problem is "virtual memory". Programs are allocated a (large) chunk of disk space. Fixed sized pages of a program correspond to similar sized pages on disk. This is the virtual memory image of the program. Then, when the program needs a page from its virtual memory, a page from physical memory is allocated, and the appropriate page from disk is loaded into the physical memory page. Later, the phsical memory page may be allocated to another virtual page for another program, in which case, the contents are rolled back to disk (if necessary), before the new contents are loaded there. The result is a much larger address space than is possible with phsyical memory. Indeed, it allows me to run the same OS (Win2K) on computers with physical memory ranging from 32mb to 768mb.
On to the kernel. At a minimum, the kernel is the part of the OS that needs to always be present in physical memory in order for a computer to run. At a minimum, it includes first level interrupt code, the cpu dispatcher, and memory management - all necessary to make virtual memory work. It also often includes other high security, high usage routines. Note though, that the kernel is locked into physical memory - it does not use virtual memory, but rather is necessary to implement it.
On to binding. One essential of computer programming is the concept of subroutines. A program enters a subroutine, which does some work, and then returns to the original program. The subroutine may, and ususally does, call or invoke other subroutines. OS functions in modern OS's are also typically invoked as subroutines. Binding is the determination of where subroutines are located so that they can be called. Older OS's bound their subroutines at link/edit time, requiring relinking when any changes are made. Modern OS's utilize tables of addresses to indirectly access subroutines or functions. This provides a lot more flexibility, since, instead of directly calling the routine at address 80402020, the routine at table entry #43 (that contains 80402020) can be invoked instead. Then, at the next boot, the routine may move to 80604020. But that is transparent to other routines, since they would still access it through table entry #43.
Microsoft Windows has a table of kernal routines or APIs called the "system service table". Each kernal routine has an entry in that table, and access is made by specifying its entry number in the table. The Sony DRM root kit replaces several of the entries in the system service table with addresses of Sony routines.
Note the first problem with this. The Sony routines are not located in the kernel. Thus, they are subject to virtual memory swap. And if they swap out, something else is likely to be loaded into physical memory at the location specified by those system service table entries overwritten by the Sony code. If another program is loaded there, it will be executed instead. And if it contains data or garbage, the results are liable to be even more bizarre when the APIs corresponding to those overwritten system service table entries are invoked.
Secondly, Microsoft enforces kernel security through a number of security measures. One of them is to checksum kernel routines when loaded at boot time, and check that those checksums match their expected values. This is missing for the Sony routines, since they don't reside in the kernel (and weren't written by Microsoft). They are thus significantly more vulnerable to being overwritten, linked to, etc. than the corresponding MSFT runctions. And note that any routines that utilize this security hole would execute in kernel mode, allowing almost unfettered access to the computer.
Thus, the Sony DRM root kit is likely to reduce both security and stability of Windows sytems.
Labels: Cyber/IP Law
9:09 AM Display: Full / Chopped / Footer
Display:
Full /
Chopped /
None
Display:
Chopped /
Footer /
None
Posted by
Bruce Hayden at 9:09 AM
2 Comments:
Large parts of the windows kernel can be paged.
B
Just wanted to say that large parts of this are very wrong.
Kernel drivers are not paged out by default. You have to call a specific routine to page a driver out or you have to use special section names in the image ("PAGE").
So a VM swap of the offending driver posses no threat. Marks analysis is right on the money though that you can not unload once you have hooked the SSDT.
Also the kernel does not checksum individual subroutines. It checksums whole device driver images as they are loaded. However once they are loaded in to virtual memory you can do what ever you want to them.
Post a Comment
<< Home >>