Sandbox AdobeReader/Chrome, Bypassing ASLR und DEP Einstellungen

[Schattenfang]

anbei ein wirklich interessanter artikel über mögliche probleme im sandboxing-prozess von chrome in verbindung mit adobe.

http://esec-lab.sogeti.com/post/Bypassing-...-Adobe-Reader-X

hier mal ein paar auszüge:

We will see here how a bug in the Chrome sandbox can lead to the full bypass of ASLR and DEP in the renderer process with a good reliability (although not breaking the sandbox protection itself). The target will be an up-to-date Adobe Reader 10.1.3 on Windows 7 x64.
[...]
So what's happening ? The answer is simple: Windows does not randomize addresses allocated with VirtualAllocEx. Dynamic memory randomization is actually performed in userland when calling functions like HeapAlloc, and does not happen with VirtualAlloc and VirtualAllocEx functions.
[...]
It is interesting to see how a mistake in the implementation of a security measure can impact the efficiency of another. ASLR particularly is a very fragile feature. It is only working under the assumption that every executable page in the process address space is randomized. How many products, supposedly protected by ASLR, have we seen still exploitable because one DLL wasn't compiled to be ASLR-compatible (oops...) ? This fragility speaks for itself here, where a single static page with a few instructions is enough to nullify the protection.

hier wird es besonders spannend:

We can easily access to NtReadFile by calling NtSetInformationThread with -2 (GetCurrentThread()) and a bad ThreadInformationClass as arguments. The resulting error code will be STATUS_INVALID_INFO_CLASS (0xC0000003). NtReadFile has syscall number 3 so that is fine for us.

The broker creates a lot of event handles (for IPC purpose) before the renderer is even started. As Windows handles are assigned incrementally (by multiples of 4), the broker's events have predictable handle values. Most of those events are unsignaled. You can observe this behavior in the capture of Process Explorer below.

was ist mit emet? das müsste man wirklich mal testen.

[Gast_Scrapie_*]

was ist mit emet? das müsste man wirklich mal testen.

Wenn eine Anwendung mit EMET geschützt ist, dann wird auch für jede, von dieser Anwendung geladene, DLL (unabhängig ob ASLR-compatible oder nicht) die Speicheradresse unvorhersehbar verändert. Klick

Scrapie

Der Beitrag wurde von Scrapie bearbeitet: 06.07.2012, 07:37

[Schattenfang]

Wenn eine Anwendung mit EMET geschützt ist, dann wird auch für jede, von dieser Anwendung geladene, DLL (unabhängig ob ASLR-compatible oder nicht) die Speicheradresse unvorhersehbar verändert. Klick

danke scrapie. in der theorie ja, aber funktioniert es in der praxis auch so? gibt es da nicht auch ähnliche mögliche lücken? vielleicht schaffe ich es nächste woche mal zu testen. das thema interessiert mich schon seit längerer zeit zunehmend, obwohl emet und co ja auch nicht wirklich neu sind.