Several people asked me recently what I
though about DeepSafe.
So, below I present my opinion...
First, for any AV system (or Host IPS,
or Personal Firewall, etc) to work effectively, there are three problems that must be addressed:
- How to protect the AV agent (code and data) from tampering (from the rest of the OS)?
- How can the AV agent get reliable access to (sensitive pieces of) the system memory and registers, and/or provide reliable memory protection for the (sensitive pieces of) the OS.
- What are those "sensitive pieces of” memory that should be monitored or protected?
From reading various PR materials, it
seems like the #1 above is the primary differentiation factor for
DeepSafe (DS). So, let's consider this problem in the context of e.g.
a Windows OS. In order to protect its code and data, DS uses, as it
is heavily advertised, Intel VT-x virtualization technology. Now,
that sounds really secure -- after all what can be more secure than a
hardware virtualization, right? ;)
But VT-x (including EPT) is only about
CPU virtualization, which in our case translates to protecting the DS
memory and registers from CPU-originating accesses. But, as every
regular to this blog knows, there is also another method of accessing
memory on any PC system, and this is through DMA transactions from
devices. The OS (so also the kernel malware) is free to program one
of the many devices in the system to issue DMA reads or writes to any
physical memory it
wants...
Now, in order to protect some portion
of the system memory (DRAM, cache) against DMA accesses, we have the
Intel VT-d technology... So, one would think that DS must be also
using VT-d in order to protect itself.
Very well, let's assume then that the
DeepSafe is not a total ripoff,
and that it implements also VT-d protection for its agent, although I
haven't found this mentioned in any of the public papers or press
materials I found on the web...
This, however, would be a bit complex
to do correctly, because the OS (so, also the kernel malware) still
has a full control over the chipset (MCH), which is the entity...
that controls the VT-d.
Now, in order to
prevent the OS (or the kernel malware) from playing with the chipset
for fun and profit, and e.g. disabling VT-d protection, DS would have
to virtualize the chipset.
If you look at some consumer VMMs, such
as VMware or Xen/Qemu, you would see that they all virtualize the
chipset for their guests (of course), but that the chipset they
provide this way is some kind of an ancient Pentium MCH. I don't
think any of the consumers would be especially happy if they found
out that after installing DS on their brand new 2012 laptop, Windows
suddenly see a Pentium-era chipset... And this is not without a
reason – chipsets, specifically MCHs, are one of the most complex
devices, perhaps only beaten by GPUs in this category. There are
virtually hundreds of configuration registers exposed by the chipset,
some of them control the VT-d, some other control system memory maps
and permissions, PCIe configuration, and many other things that I
even have no idea about, and this all makes virtualizing the chipset
a very challenging task.
So, it's either that McAfee and Intel
found some interesting way of how to securely virtualize the chipset
while preserving all of its (very rich) functionality, or that
they... don't bother with VT-d protection and chipset virtualization
at all, assuming that even without VT-d, DeepSafe is good enough and
“rises the bar” anyway (sarcasm intended).
(Can somebody from McAfee or Intel
confirm in the comments below what does DP really do?)
Anyway, let's assume they do
have VT-d protection and they do virtualize the chipset
somehow...
Now, we're moving on to the #2 point
from the list of tasks above -- about the reliable
memory access or reliable protection.
So, let say that the DS agent decided
that some part of the system memory, e.g. the IDT table, is sensitive
and should be monitored/protected. So it sets up EPT traps to trigger
an VT-x/EPT intercept on any access to that memory (or IDT base
register), in order to find kernel malware that tried to modify IDT.
That sounds really nice, but what if the malware uses DMA to modify
IDT? DS would not be able to catch such access! (So far we considered
the, hypothetical, use of VT-d only to protect the DS agent code).
One might think that DS is programming
VT-d to sandbox each and every device in the system (so including
GPU, USB controllers, NICs, SATA, etc) so they never be
allowed to touch any of those sensitive parts of the system, such as
IDT. Let's assume they do it this way...
And here we've arrived to the last
point from the list at the beginning: which of the system memory
constitutes those "sensitive pieces" that should be
protected/monitored? IDT? Sure. What about all the code sections of
the all the kernel modules? Yes. Are we fine now? Well, no, because
the malware can hook some pointers other than the well known IDT.
Some public NDIS data structure? Ok, we can add those to the
protected areas. But, what about some undocumented NDIS structures?
And this is just NDIS subsystem, one of the many subsystems in the
Windows kernel... When we think about it, it should be intuitively
obvious that in a general purpose Operating System like Windows, it
is not possible (at least for 3rd party) to make a
satisfactory list of all the sensitive pieces of memory that should
be monitored/protected, in order to detect all the system
compromises.
Greg Hoglund, Jamie Butler, Alex
Tereshkin, and myself, have been researching this area actively in
the early years of this millennium. In addition to the Alex's paper
linked above, you might also check out one of my last slides from
this
period.
I don't think anything has changed
since that time. It was also the reason why I gave up on writing
Windows compromise detectors, or forensic tools, and moved on to
researching other ways to secure OSes, which finally gave birth to
Qubes OS, many years later.
So, back to DS -- in order to provide a
somehow satisfactory protection level for your general purpose OS,
such as Windows, it would need to:
- Use VT-d to protect its own memory,
- Virtualize the chipset, at least some (sensitive) parts of it,
- Program VT-d permissions for each device to exclude all the sensitive areas in the system that should be protected, and also protect one device from DMAing into/from another device memory (e.g. NIC stealing GPU framebuffer, or inserting instructions to the GPU instruction buffer, or keystrokes to USB controller buffer). Ideally, this could be done by programming VT-d to grant each device only access to its own DMA buffer, but as far as I know, this would be very hard to implement, if not impossible for a 3rd party, on a Windows OS (in contrast to Linux, which mostly support this model). Please correct me, if the recent Windows version allows for such use of VT-d.
- Finally, and the most hard thing to solve, how to define all the "sensitive pieces of memory" in the system that should be protected and/or monitored? Although this is a somehow more generic problem, not specific to DS, but applying to any A/V, HIPS, or forensic tool.
So, is DeepSafe another piece of crap not worth any special attention, or has McAfee
and Intel came up with some novel methods, e.g. for chipset
virtualization, and other problems? Unless I see some technical info to backup the latter, I would have to assume,
unfortunately, the former. But I would like to be mistaken – after
all DeepSafe seems to be just a new incarnation of my Bluepill ;)