Section 10.4 The Virtual Machine Trojan

   


10.4 The Virtual Machine Trojan

Doug Merritt and I recognized that if we added Trojan horses to the UNIX source, they would be discovered within a few months. Also, we recognized that if we modified copies of the source to have Trojans, installed the resulting binaries, and removed the altered copy of the source, eventually the system would be recompiled and these Trojans, too, would be lost. After much analysis, we came up with the idea of the Virtual Machine Trojan. We were inspired by IBM's pioneering this technique on the 370 series. We would write our own PDP 11/70 emulator that would run the UNIX kernel as a user process.

The idea behind a Virtual Machine (VM) is that, at the lowest level, the computer's hardware would be emulated. The "guest operating system" would think that it is running on the actual hardware but some operations would be emulated. A VM can run almost as fast as the native hardware because the vast majority of instructions that are unprivileged would be run directly on the native hardware. When a privileged instruction was encountered running the VM, a hardware interrupt would trap into the "real" OS and would trigger an emulation.


Out came the hardware manuals and the design started. Then there was the thunk of our jaws hitting the ground. Our exploit was destroyed by a cruel twist of fate. Some engineer at Digital had to decide what to do when a privileged instruction was encountered when the hardware was running in unprivileged (user) mode. For our plan to work, this situation would need to be treated as an error, causing a trap into system space.

Alas, on the PDP 11/70, this situation causes the instruction simply to be ignored. To implement our plan, we would have to emulate each instruction. This would slow down the system by a factor of five or so. Because the system already was running at capacity, this new slowness would be investigated and the cause discovered.

This exploit certainly is available on some of the hardware that Linux now runs on. Additionally, because Linux is so efficient, most Linux systems have lots of spare CPU cycles that could be used to emulate every instruction without a substantial slowdown.

It did not occur to us then that there is a simple solution to this problem, used by most debuggers. When our VM was preparing to run the UNIX kernel, after the kernel was loaded into memory, it simply needed to scan the kernel's image for privileged instructions and replace these with instructions to generate a trap into our "real" OS. Then we could emulate these few privileged instructions while allowing the unprivileged instructions to run on the native hardware for speed.

Even a comparison of your files against what they should be will not detect this exploit as the VM would alter the Linux file system behavior to hide itself and make it appear that the Linux kernel started at the boot sector. A periodic complete reinstall from scratch will eliminate this Trojan. Another less time-consuming solution would be to boot from trusted floppies or CD-RW media periodically, compare the installed kernel to a known good version, and then compare all privileged programs and configuration files to a known good version. It is important to verify that the programs and configuration files have not been altered to contain Trojans, because even if the installed kernel is legitimate, any program running as root could install Trojans after startup.


       
    Top


    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    ISBN: N/A
    EAN: N/A
    Year: 2002
    Pages: 260

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net