Hilfe - Suche - Mitglieder - Kalender
Vollansicht: Sandbox AdobeReader/Chrome
Rokop Security > Security > Trojaner, Viren und Würmer
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:
ZITAT
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:

ZITAT
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.
Scrapie
ZITAT(Schattenfang @ 05.07.2012, 21:11) *
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
Schattenfang
ZITAT(Scrapie @ 06.07.2012, 08:24) *
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.
Dieses ist eine vereinfachte Darstellung unseres Foreninhaltes. Um die detaillierte Vollansicht mit Formatierung und Bildern zu betrachten, bitte hier klicken.
Invision Power Board © 2001-2018 Invision Power Services, Inc.