Wednesday, January 03, 2007

Towards Verifiable Operating Systems

Last week I gave a presentation at the 23rd Chaos Communication Congress in Berlin. Originally the presentation was supposed to be titled "Stealth malware - can good guys win?", but in the very last moment I decided to redesign it completely and gave it a new title: "Fighting Stealth Malware – Towards Verifiable OSes". You can download it from here.

The presentation first debunks The 4 Myths About Stealth Malware Fighting that surprisingly many people believe in. Then my stealth malware classification is briefly described, presenting the malware of type 0, I and II and challenges with their detection (mainly with type II). Finally I talk about what changes into the OS design are needed to make our systems verifiable. If the OS were designed in such a way, then detection of type I and type II malware would be a trivial task...

There are only four requirements that an OS must satisfy to become easily verifiable, these are:
  1. The underlying processors must support non-executable attribute on a per-page level,

  2. OS design must maintain strong code and data separation on a per-page level (this could be first only in kernel and later might be extended to include sensitive applications),

  3. All code sections should be verifiable on a per-page level (usually this means some signing or hashing scheme implemented),

  4. OS must allow to safely read physical memory by a 3rd party application (kernel driver/module) and for each page allow for reliable determination whether it is executable or not.

The first three requirements are becoming more and more popular these days in various operating systems, as a side effect of introducing anti-exploitation/anti-malware technologies (which is a good thing, BTW). However, the 4th requirement presents a big challenge and it is not clear now whether it would be feasible on some architectures.

Still, I think that it's possible to redesign our systems in order to make them verifiable. If we don't do that, then we will always have to rely on a bunch of "hacks" to check for some known rootktis and we will be taking part in endless arm race with the bad guys. On the other hand, such situation is very convenient for the security vendors, as they can always improve their "Advanced Rootkit Detection Technology" and sell some updates... ;)

Happy New Year!


AS said...
This comment has been removed by the author.
Unknown said...

Having read your presentation, I came across the hardware red pill idea:

"How about creating a new instruction – SVMCHECK:
mov rax, [password]
cmp rax, 0
jnz inside_vm"

I see two possible problems with implementation of this:

1) the SVMCHECK instruction must be non-trappable even by the hypervisor (blue pill), or it could negate it directly.

2) Even if the instruction can't be trapped directly, the OS's scheduler could be trapped? If you alter code containing the SVMCHECK by means of dynamic translation by the Blue Pill, the instruction would never take place (always returning a 0 for 'no VM running'. Any reads of that particular page of code would also be intercepted, ostensibly showing the SVMCHECK instruction still in place. said...

I really enjoy reading your articles, essays and posts.

A quick comment: While reading the list of requirements, I was expecting this to be includedt "The operating system should install itself as an hypervisor (ring -1) in order to stop Type III malware (or other hypervisors) from installing into the system and taking control of it".

Joanna Rutkowska said...

To oddscurity:
Sure that SVMCHECK should be non-trappable. Even more, it should be a non-privileged instruction, so that it would be possible to execute it from usermode. Of course, it is theoretically possible to do a full code emulation (or binary translation), but then you end up having an emulator instead of a virtual machine. Even today's software based hypervisors, like e.g. VMWare, do the binary translation of only the kernel mode code, while executing the usermode code natively. So, I don't see any problems with implementing such an instruction.

To felipe:
Please distinguish between prevention and detection (in this case verification). OS’s hypervisor is needed for prevention, not detection of type III malware.

Admin said...

A very good, interesting and, of course, funny presentation. I like it very much. :)

ANELKAOS said...

Hi Johanna. The final title is better ;)

A very interesting presentation but I miss you in :(

I continue playing in user mode but I have a question (possibly basic for you) about yours VMs. If only one IDTR is True I don't understand why I don't know when execute in RM. "If no more IDTRs are in memory I know thath I execute in the RM" <- False, OK

But (in VM1) if I find anothers IDTs in memory (IDT of VM2) I know thath another VM be able execute <- I detect your "pill"?

void lidt(void *base, unsigned int limit) {
unsigned int i[2];

i[0] = limit << 16;
i[1] = (unsigned int) base;
asm ("lidt (%0)": :"p" (((char *) i)+2));

void *sidt(void) {
unsigned int ptr[2];
asm ("sidt (%0)": :"p" (((char *) ptr)+2));
return (void *) ptr[1];

It is not certain?

PD: I will see you in BH Europe :)

Joanna Rutkowska said...

To anelkaos: please do not confuse IDTR and IDT and also please do not confuse software based virtualization, where tricks like redpill are possible, with hardware based virtualization which is exploited by Blue Pill.

Regarding your last sentence: how you gonna find those other IDTs?

Anonymous said...

I listened to your presentation at CCC and it seems to me it is like a race to reach as low as possible into the depths of the machine. Which will eventually reach a limit and both virus and detector will be at the same level. Although you clearly pointed out that it is not possible to accurately establish if the system has been compromised by observing it. (Hope to have something like Nushu someday, if the throughput isn't too low)

Would you not agree that there will be some side effects if an attacker is using the machine? Surely he will not be able to fix all traces.

For example, FU was possible to detected through PID bruteforcing, although they corrected that in FUTo. But you can still use something similar to detect it. :)

Just a final side note: Microsoft has classified stuff like JS.Feebs in its Security Intelligence Report as a rootkit. (When the first virtualizing virus appears the threat level will be off the charts, even Futo wasn't in the Report)

Joanna Rutkowska said...

Krugger, it seems like you got all my points backwards. The purpose of the presentation I gave at CCC was to show that we (i.e. the good guys) can win this battle, provided some changes will be introduced into OS design (and I even discussed what changes are needed). And also I made it clear many times during this talk, that using side effects for malware detection is just not the proper way for doing that – we need a systematic way and not a bunch of hack…

war59312 said...

Sadly I don't ever seeing the spyware, virus, rootkit, etc. problem every being fixed.

There is way too much money to be made in making darn sure they never are. In fact I bet Microsoft would be sued like crazy (copyright, anti-trust, etc.) if they did try to "really" fix the problems.

At least thats how I see it... Sadly!

RixiM said...

Sounds to me like you're suggesting that PCs use a Harvard architecture, no?

Anonymous said...

Very interesting and COOL presentation! Thanks for sharing...

Anonymous said...

@war59...: no, since there is no physical distinction between code and data memory, so that the same physical page of memory can be used as a code page by one application and as a data page by another (just not simultaneously). Esp. the requirement that all pages can be read by a kernel driver pretty much disqualifies a harward architecture.