lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ