How effective is something like Deep Freeze against boot sector infections?

Question

I work for an embedded system manufacturer and on our older generation systems, which are powered by Windows Embedded, a number of customers have been experiencing virus infections. Due to the real time nature of these systems, anti-virus solutions are not particularly practical.

These are primarily caused by their employees being on the internet and downloading inappropriate material to the system. We require the browser for customer service reasons, so simply locking it out isn't an option.

We've been exploring Deep Freeze as a way of mitigating the issue, this tool is designed to restore the file system state.

I'm uncertain as to whether this will be effective against boot sector viruses, does anyone have any experience with this? Has anyone used Deep Freeze for this sort of purpose?

Where can I obtain reasonably relevant boot sector viruses for testing? (For anyone concerned about the legitimacy of this part of the question, I can be contacted at my work email for verification, it's the email associated with this account).

score 10 · Accepted Answer · answered Nov 15 '11 at 18:52

Forgive me, but the #1 solution for a real-time dependent system is to not let undesignated junk run on it. Users shouldn't be browsing the Internet with an RTOS setup. That needs to stop yesterday.

At least in good theory, Deep Freeze type systems will protect your computer from any permanent modification. They intercept all write activity and remap it. That means that any changes, including to the boot sector, would be dereferenced upon boot. Frozen data is never overwritten, just pointed away from until the system is reset.

I completely agree about restricting the system, however, this part of the product is really out of my hands and was put in the field long before I got on the scene. This is a mitigation attempt primarily. — Stephen, Nov 16 '11 at 00:16

score 9 · Answer 2 · answered Nov 15 '11 at 20:17

Firstly, I agree with Jeff. Connecting real time systems to the internet is not a good idea, especially if they're critical.

Secondly, on Deep Freeze - according to the wikipedia article:

Deep Freeze is a kernel-level driver that protects hard drive integrity by redirecting information being written to the hard drive or partition, leaving the original data intact.

In terms of the impact on your system this means that writes look like this:

 ----------------------                ---------------------
 | Userland program   |<-----Read--------|  Kernel         |          |-------------------|
 | e.g. explorer.exe  |                | |-|-------------|<---Read----|  File system      |
 | or something else  |<-----Write--|  |   | Deep Freeze | |          |  i.e. directly to |
 ---------------------- or read of  |------| Driver      | |          |  block device     |
                  modified contents    |   |-------------- |          |-------------------|
                                       |         /|\       |
                                       -----------|---------
                                                  | Write/read changed content
                                                 \|/
                                           ----------------
                                           | Some form of |
                                           | temporary    |
                                           | storage      |
                                           ----------------

So any modifications you make using standard IO routines will be redirected to a temporary storage. Reads, as I understand it, will also follow this if the content is modified, otherwise loading directly from the file system itself. When the system is reloaded, that section is forgotten.

How effective this is depends on the level of penetration. Inside the kernel, if you use the hooked routines to write files, your writes will be redirected too. However, kernels can write directly to the disk and will contain code to do that, so unless you patch all of that to remove it, it is feasible to write to disk. The intercept is likely to be higher up than that, mostly because that'll catch 99% of all calls and because it is reliable.

Where can I obtain reasonably relevant boot sector viruses for testing?

Now, the crux of the issue. Deep freeze's write protection only works once loaded. So you are correct in your assumption that if you load code before deep freeze standard routines will work for you just fine. You could even load a filter at a greater priority, intercept certain writes and persist them before deep freeze even sees them.

As to finding code that would get you started, vbootkit 2.0 was a proof of concept (aside from inserting itself it didn't do much) "bootkit" designed to compromise windows vista x64 pre boot. It has disappeared from the internet on looking for it this evening, but if you can find a copy, that will give you a starting point. It is, however, complicated. I'm writing a filter driver right now (blame AviD) and getting it right is hard. I don't know of any code that deliberately targets deep freeze specifically, though.

score 5 · Answer 3 · answered Nov 15 '11 at 21:33

The "right way" to protect boot code on an embedded device is to load from a ROM: it should be hard to modify the boot sector. Even without a true ROM, most flash devices I've seen have a lock sequence you can write from within the flash driver. This makes the device harder to overwrite (not impossible, say by a targeted attack) -- preventing garden variety viruses from infecting your boot. As far as finding viruses to test with, I'd consider writing something that has specific knowledge of your system to test how strong your protections are.

We are considering this as a viable option, but it won't work to retrofit existing systems in the field. — Stephen, Nov 16 '11 at 00:19

How effective is something like Deep Freeze against boot sector infections?

3 Answers3