[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 03 Mar 2007 08:39:36 +0100
From: Arne Vidstrom <arne.vidstrom@...ecurity.nu>
To: John Smith <genericjohnsmith@...il.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: Evading the Norman SandBox Analyzer
Hi,
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.
/Arne
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
>
>
Powered by blists - more mailing lists