Evading the Norman SandBox Analyzer Feb 28 2007 11:36AM
Arne Vidstrom (arne vidstrom ntsecurity nu) (1 replies)
Re: Evading the Norman SandBox Analyzer Mar 02 2007 08:49PM
John Smith (genericjohnsmith gmail com) (1 replies)
Re: Evading the Norman SandBox Analyzer Mar 03 2007 07:39AM
Arne Vidstrom (arne vidstrom ntsecurity nu)

Yes, the same instruction is used, but no, this is not the same thing at
all. In the SandBox Analyzer case the problem is that the limit is set
to a value which is not according to the Intel specification, which in
turn singles out the SandBox Analyzer.

The RedPill technique works because in the virtualization the SIDT
instruction is emulated in ring 0 but run straight on the processor in
ring 3. Therefore SIDT in ring 3 reveals the address of another IDT than
the one the OS thinks is in use. In a true emulator there is no reason
why the SIDT instruction should give different results in ring 0 and
ring 3, because everything is emulated both in ring 0 and ring 3. And
especially there is no reason why the limit should be for example 800h
instead of 7ffh. That is not a problem with the emulator in itself, but
a problem with the "OS" running inside the emulator. Which, again, is
not the same problem as the one RedPill uses. So no, this has not
already been published > 2 years ago.


John Smith skrev:
> This is the same as the results found > 2 years ago as published by
> Joanna Rutkowska as RedPill
> (http://invisiblethings.org/papers/redpill.html) (and before that in a
> Usenix paper) and therefore everyone who is interested in
> emulated/virtualized security already knows that SIDT is a problem
> instruction.
> John
> On Feb 28, 2007, at 11:36 AM, Arne Vidstrom wrote:
>> Hi all,
>> Summary:
>> The Norman SandBox Analyzer (http://sandbox.norman.no/live.html) runs
>> malicious code samples in an emulated environment while logging their
>> actions. In practice it is more or less impossible to make an
>> emulated environment perfectly similar to the real thing. It is
>> therefore possible to write malicious code that does not behave
>> maliciously when run in the Sandbox Analyzer. Here I will give one
>> example of such a technique.
>> Full text at:
>> http://www.ntsecurity.nu/onmymind/2007/2007-02-27.html
>> I have notified Norman about the problem but have chosen not to wait
>> for them to patch it. The reason being that this is not a regular
>> vulnerability, but rather an example of an inherent weakness in
>> emulated sandboxes in general. I assume they will patch this
>> particular case shortly though since it should be very easy to do.
>> Regards /Arne
>> http://ntsecurity.nu
>> http://vidstrom.net

[ reply ]


Privacy Statement
Copyright 2010, SecurityFocus