CSED 431 Week 2

Virtual Machines

Windows SteadyState / DeepFreeze
 


The schedule says:
    5:15-6:45 in LT 605, 7:00-8:15 in the Emerging Technologies Lab
More like 5:15-6:30, 6:30-7:45

Virtual Machines -- How they work

Modern computers all have at least two internal privilege levels: user and kernel (sometimes also called supervisor). (Intel processors typically have up to four privilege levels.) Any instruction dealing with either physical I/O (ie disk read/writes) or with changing the internal memory allocations and restrictions can only be executed in kernel mode; changing the mode can also only be done from kernel mode. User programs always run in user mode. When the OS loads, it runs initially as supervisor.

If my user-mode program wants to do something privileged, it has to ask nicely, since it cannot execute it directly. It does this by issuing a trap instruction, which ends up referring to a special trap table in low memory (that cannot be altered by user-mode programs). Suppose, for example, that a program wants to read block 1083 of a file (or for that matter of a disk). It sets up parameters for the operation:
  1. The operation description is READ_BLOCK
  2. The block desired is 1083; a handle to the appropriate file or disk is also provided
  3. The address of a suitably sized chunk of memory to hold the new data is provided
The TRAP instruction shifts to kernel mode, but it also jumps to a pre-determined library; that is, the user-mode program cannot run its own code in kernel mode. The predetermined library is in charge of carrying out user-mode requests, but is also in charge of maintaining system integrity. In the case above, the library will invoke its read_block() procedure, with the appropriate parameters. That procedure will check that the file block (and file handle) is valid, and it will check that the buffer address is valid and appropriate, before doing anything else. File permissions would also be checked if necessary (though most OSs, including windows, check file permissions only when files are first opened). If everything checks out, the read_block() procedure will then fetch the appropriate data, and finally return control to the user program with the cpu level back in user mode.

That trap-instruction library can be large and complex; it represents (along with "interrupt handlers") the whole extent of machine code that runs at kernel level, and to a great extent determines the character of the operating system.

What a virtual machine does is twofold:
For example, the above READ_BLOCK for the windows guest is now executed by the windows trap library running in userland, up until the point of the actual I/O instruction. That instruction is "trapped" and at that point the host OS takes over, directing the read not to be from a hardware hard-disk controller but from a virtual-disk file instead.

Calling a conventional library (in windows, a .dll) is like the trap library, except that no privilege escalation occurs. A user program could, in principle, always supply its own libraries. Standard libraries are used, however, as they are a great convenience for the programmer.

In the real world, the trap-instruction library can be extended or modified by kernel drivers. In windows, these are *.sys files, usually in c:\windows\system32\drivers.




Windows SteadyState

This is a Microsoft-developed package for securing standalone (that is, not on a domain) windows hosts. As of this writing, it is not yet available for Windows 7, though it has recently been ported to Vista. The main component of interest, for us, is Windows Disk Protection (WDP), a Microsoft alternative to DeepFreeze (DF) by Faronics, Inc.

One big difference between WDP and DF is that the former can always be disabled by any administrator while the latter is intended to be "hardened" against administrator activity. In fact, a common setting for DF is in computer labs (such as Loyola) where every user is given local administrative access.

Both WDP and DF install special "drivers" that intercept disk reads and writes and store all new changes in a special place. WDP stores all drive changes in a special file \Cache.WDP, which is created in size equal to half the drive free space (and thus big enough to handle any changes to the remaining half). I do not know where DF keeps its cache file. All new writes go to the cache file and not to the actual disk file hierarchy (thus the existing file hierarchy on the disk is never changed). All reads check first in the cache file; an entry there means that the relevant disk block was changed while no entry there means that the data is then read from the original filesystem. When the system is rebooted, the WDP/DF software clears the cache entries and so the disk filesystem begins again from scratch.

The drivers are loaded at boot time (or by program control), basically from registry entries, eg
    HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\System\Wdf01000
for WDP.

For WDP, I compared the list of *.sys files in the directory C:\windows\system32\drivers before and after installation, and found that WDP created two new files: wdfldr.sys and wdf01000.sys. "Wdf" likely stands for "windows driver foundation", a Microsoft framework for writing drivers.

For both WDP and DF, if you access the drive in question other than through the instance of Windows that has the disk protection installed, changes can be made and are persistent. That is, both WDP and DF only protect against changes while they are running; they do not restore the disk from some preset "backup" location.

Here is how we can write to frozen drives:
Writing to frozen machines is only part of what might need to be done; one may also need to modify the frozen machine's registry. This is done by using regedit under another windows instance to load the appropriate "hive" file. The main system hive files are in C:\windows\system32\config, and are SAM, SECURITY, SYSTEM, and SOFTWARE.  Note that, on a "non-live" windows filesystem, these are ordinary files that can be copied at will; on boot systems these registry files are "protected" by being in use and cannot be copied. Editing hive files of another instance of Windows will be discussed below.

For both WDP and DF, note that removing the relevant driver files will have no effect: the change is made only to the cache, and when the system reboots the file will still be there. The file itself was loaded into the kernel at boot time and is no longer consulted. Similarly, deleting the registry entry that invokes the driver will have no effect, because the registry hive file will be restored on reboot -- like any other file -- and the old entry will then reappear. Both WDP and DF also appear to use process threads that lock some crucial registry entries by "holding them open".

Both WDP and DF provide a software interface for unfreezing the disk. For WDP, that interface is available to anyone running the SteadyState console application as an Administrator. For DF, even the administrator has to provide a special password to disable the software.

The "standard" approach to hacking DeepFreeze, that can be found by googling for "hacking deepfreeze", is to attach a debugger to the DeepFreeze password program and modify it so that it accepts any password and then disables DeepFreeze. (While this will work under XP, provided one has figured out all the executable-modification details, it is unlikely to work under Vista and later, because those operating systems provide for "protected processes" to which a debugger cannot be attached.

If we go in from the outside and simply delete the driver files (eg wdfldr.sys/wdf01000.sys), the resulting system will simply not boot.

Our approach here will be to delete the registry entry that invokes the driver. This involves the following:
Demo: using minXP to delete the wdf01000.sys file from medxp. It fails! If we were doing this from medXP, the deletion would only affect the "shadow copy" of the disk, and the original wdf01000.sys would be right back on the next reboot, loaded into the kernel.

Note that when installing SteadyState (the Microsoft package that contains WDP), the software attempts to contact Microsoft during the process. I did not notice until attempting to do install this offline that if the software cannot reach Microsoft then it still does go ahead with the installation, but it takes a lot longer. Also, note that the act of installing SteadyState disables Fast User Switching. This probably relates to the "basic six" security features that SteadyState enables by default. It may have more to do with the fact that the software enables the "Welcome screen".

Disabling Windows Disk Protection

Warning: almost all the steps here will break future removal or reinstallation of WDP.

We know we can disable WDP from the Steady State application. We will investigate disabling WDP by tweaking the filesystem and registry directly. In this sense, we are using WDP as an example of a potential virus, that we also might need to disable manually.

First, note that if we do the following to a clean copy of windows
then WDP will be disabled. (The desktop icon will still be there, but it will not run.) The disk cache file will have to be deleted manually. (Note that we will be unable to reinstall SteadyState successfully.)

Second, note that if we instead attempt to delete the drivers, wdfldr.sys and wdf01000.sys, the system will be unbootable.

A third attempt might be to remove the cache file. Attempting this is part of today's lab.

A fourth attempt is to edit the registry remotely, from another instance of windows (remember that editing the registry on a system with WDP enabled is useless).

To edit the registry remotely, first open regedit as usual. Then select HKEY_USERS, and choose File => Load Hive. Select the registry hive file you wish to edit, eg E:\windows\system32\config\system, or E:\Docs&Settings\owner\ntuser.dat. You will then have to provide a "mount point" name that represents the "link-in" point to the existing registry; a nonsense name is fine or, if you are editing a user profile, you can use the username. Now you can browse or search the registry hive, and make changes as appropriate. When searching, remember that the search will continue on into the rest of the registry.

If you are accessing a frozen machine via a linux boot CD, you will have to copy the registry hive file onto, say, a USB drive, and use that to carry the file to a real windows installation for editing. Reverse the steps to get the modified registry hive file back to its original location. And always leave a copy of the original, perhaps with the suffix ".backup", in its original directory.



Lab

1. Disable the user zack's ability to write to the Desktop. See how that affects saving files. Is windows at all "friendly" about its notification here?

2. Enable Windows Disk Protection on medXP ("medium-sized XP")

3. Verify that it works, eg by creating some folders on the owner desktop

4. Shut down medXP2, and boot minXP to access the medXP disk (as drive e:). Remove the cache file e:/Cache.WDP. Shut down minXP and reboot medXP. What happens? What does Windows Disk Protection do? Does it recover?

5. Remove windows disk protection (by using the option in SteadyState to disable it). Through what hoops must you jump?

6. Can you now re-enable it successfully?

7. Use remote-registry editing to change the wallpaper of owner, on medXP. Set the following registry value. which you can find more quickly by searching for "wallpaper":
    [owner]\Control Panel\Desktop\Wallpaper = C:\WINDOWS\web\wallpaper\Autumn.bmp
Verify that this survives reboot. (Note that Windows comes with Autumn.jpg, but that jpeg files can not be used for wallpaper directly, so I have made the conversion to .bmp format.)

To edit the registry remotely, first open regedit as usual. Then select HKEY_USERS, and choose File => Load Hive. Select the registry hive file you wish to edit, in this case E:\Docs&Settings\owner\ntuser.dat. You will then have to provide a "mount point" name that represents the "link-in" point to the existing registry; the simplest is to use "owner" or "ownerreg". Now you can browse or search the registry hive, and make changes as appropriate. Note that the [owner] in the previous paragraph represents the "mount point" you just selected. When searching, remember that the search will continue on into the rest of the registry.