Weet iemand of Adobe Reader by default op verlopen certificaten (simpel) en revocation (lastiger) checkt?

@Bitwiper: Ik ga er niet vanuit dat Adobe Reader de certificaten checkt waarmee de malware is gesigneerd die geïnstalleerd wordt dankzij een lek in Adobe Reader :-)

Een belangrijk punt dat niet belicht werd: de digitale handtekening (AuthentiCode) is ongeldig omdat het een copy/paste betreft vanuit een Foxit bestand. Is vrij eenvoudig te doen, kijk maar naar mijn disitool http://blog.didierstevens.com/programs/disitool/

In welke context?

Ter info: zelfs Windows laat het uitvoeren van executables met een ongeldige digitale handtekening toe.
Uitzondering: Patch Guard voor kernel drivers, en een nieuwe vlag FORCE_INTEGRITY (sinds Vista) die niemand aan zet in zijn executable.

Gewoon, als ik in een standaard geconfigureerde Adobe Reader een digitaal ondertekend PDF bestand open, krijg ik dan een waarschuwing als het certificaat verlopen is, of de hash niet meer klopt?

En, als gebruikmakend van boordmiddelen, alles in orde lijkt, checkt Adobe Reader vervolgens op certificate revocation (internet access nodig), en als dat niet lukt (timeout), krijg ik daar dan in elk geval een melding van?

Als het bovenstaande (deels) niet plaatsvindt is het nauwelijks zinvol om PDF's digitaal te ondertekenen (overigens heb ik geen idee of Adobe Reader ook root certificates van third parties "vertrouwt", en zo ja welke; ook dat is natuurlijk interessant om te weten).

Vergelijkbaar: ik heb m'n Firefox zo ingesteld dat een check op certificate revocation moet worden doorgevoerd, en ik een foutmelding krijg als dat niet lukt - de m.i. enige verstandige instelling. Maar, toegegeven, dit leidt helaas soms wel tot false positives.

Weet ik (zie m'n bijdrage van 23:40 onder http://www.security.nl/artikel/32980/1/Adobe_geeft_oplossing_voor_PDF-aanval.html). Maar dat Microsoft iets niet doet (waarschijnlijk om performance redenen), wil toch niet zeggen dat Adobe het daarom ook maar niet zou moeten doen bij PDF bestanden?

Bovendien vind ik de aanname onjuist dat je binaries hetzelfde zou moeten behandelen als documenten. Ik neem aan dat bijv. Outlook wel grondig op digitale MIME handtekeningen onder e-mails checkt. Voor de lezer is het in de meeste gevallen essentieel om te weten wie iets geschreven heeft, terwijl dit mechanisme bij programmatuur (onterecht) wordt gebruikt om "aan te tonen" dat die programmatuur "veilig" zou zijn (maar dat is een andere discussie). Als dit soort checks niet plaatsvinden (of zijn te omzeilen) bij e-mail en PDF bestanden, ontgaat het nut van digitale handtekeningen onder dergelijke bestanden me volledig (ik had er al geen hoge pet van op)...

Mogelijk kun je het checken op digitale handtekeningen (vanaf XP) in binaries (EXE, DLL, OCX, ...) ook afdwingen door het gebruik van SRP (Software Restriction Policies, voor een snel overzicht zie http://www.mechbgon.com/srp/), maar dat moet ik nog eens goed uitzoeken.

N.b. (off-topic) Als iemand goede/slechte ervaringen heeft met SRP lees ik dat graag (svp niet onder deze thread maar hier: http://www.security.nl/artikel/34426/1/Windows_DLL-lek_raakt_ook_EXE-bestanden.html)

OK, de context is PDF documenten, niet EXEs. Dacht dat het om EXEs ging.

Adobe Reader checkt digitale handtekeningen van PDF document. Kijk maar in Edit / Preferences / Security / Advanced Preferences

Waarschuwing bij mislukken revocation check krijg je niet.


Is onrechtstreeks mogelijk door certificate rules te gebruiken, maar dan moet je alle certificaten via een rule toevoegen. En het is ook zo dat niet alle EXEs AuthentiCode hebben.

Didier, 2x excuus: 1x voor de late reactie, en voor mijn -onterechte- conclusie dat het om een gesigneerd PDF bestand ging (de exploit bestaat kennelijk o.a. uit een gesigneerd exe bestand). Dank voor je reactie!