image

Microsoft tool beschermt tegen Adobe Reader-lek

maandag 13 september 2010, 09:57 door Redactie, 8 reacties

De honderden miljoenen gebruikers van Adobe Reader die hun systeem tegen drive-by downloads willen beschermen, kunnen Microsoft's Enhanced Mitigation Evaluation Toolkit (EMET) gebruiken. Dat laten beide leveranciers weten. Vorige week werd bekend dat hackers weer een zero-day beveiligingslek in de PDF-lezer misbruikten voor het infecteren van systemen en stelen van gegevens.

In tegenstelling tot eerdere berichten omzeilt de exploitcode niet de Address Space Layout Randomization (ASLR) die Windows als beveiliging tegen exploits toepast. ASLR had de exploit kunnen voorkomen, maar de beveiligingsmaatregel was niet door Adobe toegepast, aldus Microsoft.

Oplossing
In afwachting van een patch, waar nog altijd geen datum voor is, heeft Microsoft een oplossing in de vorm van EMET. Die verplicht de applicatie namelijk om wel ASLR te gebruiken. Adobe heeft de gevolgen van EMET nog niet voldoende kunnen testen en waarschuwt bedrijven om de maatregel eerst zelf te testen voordat die massaal wordt ingezet. Microsoft laat in deze blogposting zien hoe gebruikers EMET moeten configureren.

Reacties (8)
13-09-2010, 11:01 door Didier Stevens
Door Redactie: In tegenstelling tot eerdere berichten omzeilt de exploitcode niet de Address Space Layout Randomization (ASLR) die Windows als beveiliging tegen exploits toepast. ASLR had de exploit kunnen voorkomen, maar de beveiligingsmaatregel was niet door Adobe toegepast, aldus Microsoft.

Klopt. Elke executable (EXE, DLL, ...) heeft een vlag (cfr PE fileformaat) dat aangeeft
of ASLR mag toegepast worden of niet. De loader die .EXE en .DLL files in het geheugen laadt ter uitvoering,
kijkt naar deze vlag en beslist dan op welk adres de executable in het geheugen geladen wordt.
Als de vlag aanstaat, dan wordt het adres pseudo-willekeurig gekozen (ASLR). Als de vlag niet aanstaat,
dan wordt er een vast, voorspelbaar adres gebruikt.

Adobe Reader 9 heeft deze vlag aanstaan voor zijn EXE en de meeste van zijn DLLs.
In deze zero-day gebruikt de exploitcode code uit een DLL waar de ASLR vlag af staat.

Overigens is het niet moeilijk (zeker in het geval van Adobe Reader) om shellcode te schrijven die dynamisch
adressen opzoekt en zo ASLR omzeilt. Zulke shellcode is veel groter dan statische shellcode, maar bij de meeste
Adobe vulnerabilites is dit geen probleem omdat je in de praktijk niet beperkt wordt in de grote van je shellcode.

ASLR is vooral nuttig bij vulnerabilities van netwerk services. Bij netwerk service vulnerabilities is het vaak zo dat
de grote van de shellcode beperkt wordt door het netwerk protocol, en heb je gewoon geen plaats om dynamische shellcode te gebruiken.
13-09-2010, 11:32 door Anoniem
Ik heb mijn C: schijf doorzocht op 'icucnv36.dll' (ook hidden/system/non-indexed) en kon deze niet vinden. Ik gebruik Adobe Reader 8.2.4 onder Vista 32-bits.

In Process Explorer stond deze .dll ook niet na het laden van Adobe Reader.
Misschien is downgraden naar de 8 versie van Adobe Reader dus ook een optie (maar misschien ook niet).
13-09-2010, 11:33 door Bitwiper
Als ik http://blog.metasploit.com/2010/09/return-of-unpublished-adobe.html goed begrijp is icucnv36.dll de oorzaak van deze specifieke Adobe Reader kwetsbaarheid.

Uit de eigenschappen van icucnv36.dll haal ik "IBM ICU Common DLL" en http://ibm.com/software/globalization/icu/. Die webpage verwijst verder naar http://www.icu-project.org/.

Als ik op die laatste site naar de sources kijk van deze DLL dan zie ik veel mogelijke buffer overflows, van het type char buf[256], verderop gevolgd door strcat() en strcpy() calls. N.b. of er bij het gebruik van dit soort code daadwerkelijk sprake is van BOF's hangt ervan af of er in de betreffende code voor de calls naar strcpy en strcat checks worden gedaan en/of je om andere reden kunt uitsluiten dat "user-provided-strings with unknown length" worden verwerkt, maar over het algemeen betekenen dit soort constructies niet veel goeds.

Of je Adobe de schuld kunt geven van deze kwetsbaarheid is dus discutabel. Verder ben ik benieuwd welke ander softwarefabrikanten van deze DLL's gebruik maken...
13-09-2010, 12:12 door Didier Stevens
Door Bitwiper: Als ik http://blog.metasploit.com/2010/09/return-of-unpublished-adobe.html goed begrijp is icucnv36.dll de oorzaak van deze specifieke Adobe Reader kwetsbaarheid.

Nee, de kwetsbaarheid is in cooltype.dll van Adobe.
http://osvdb.org/show/osvdb/67849

icucnv36.dll is de DLL waarvan de ASLR vlag afstaat.
13-09-2010, 12:34 door Bitwiper
Door Didier Stevens: Nee, de kwetsbaarheid is in cooltype.dll van Adobe.
Je hebt gelijk, in http://www.vupen.com/blog/ wordt dit ook duidelijk uitgelegd. Thanks Didier!
13-09-2010, 13:04 door [Account Verwijderd]
[Verwijderd]
13-09-2010, 14:17 door Didier Stevens
Door Peter V: ... ben ik overgetapt op het Open Source programma Sumatra PDF ...

Sumatra PDF ondersteunt ook ASLR en DEP (ter info: Foxt Reader doet dit niet).
Het is echter niet geconfigureerd om te draaien met een Low Integrity Level.
Maar je kan dit zelf gemakkelijk afdwingen met het de icacls utility.
Voor meer uitleg: http://blog.didierstevens.com/2010/09/07/integrity-levels-and-dll-injection/
15-09-2010, 11:27 door Anoniem
kan via ADOBE READER ontvangen berichten wel lezen maar niet uitprinten
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.