full-disclosure - Re: 0-day PDF exploit

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <BAY129-F3167391A3FF8FC3C7F810ACB9E0@phx.gbl>
Date: Thu, 18 Oct 2007 02:18:32 +0000
From: "cocoruder ." <frankruder@...mail.com>
To: eric@...hner.us
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: 0-day PDF exploit

Yes, you are right, the adobe's fault is allowing to call "mailto" URI 
without user's validate(they checked other URIs such as "http" but not 
"mailto"), but the "remote code execute" is due to MS's fault, I am not 
prefer or hate any vendor and anyone, but the initial disclosure misleaded 
me to believe there is a PDF file format vul because "the vulnerability 
affecting both Adobe Reader and Foxit Reader". Thanks for your infos again.



welcome to my blog:
http://ruder.cdut.net





>From: eric@...hner.us
>To: "cocoruder ." <frankruder@...mail.com>
>CC: full-disclosure@...ts.grok.org.uk
>Subject: Re: [Full-disclosure] 0-day PDF exploit
>Date: Wed, 17 Oct 2007 03:07:16 -0700
>
>>Why everybody said it is a zero day about PDF? it's just a fault in
>>IE7, or just want to make a big media hit? real PDF zero day will
>>exists in the PDF's file format, or some Adobe's expanded 
>>functions.
>
>Actually, it's about PDF *and* IE7.  Both are at fault, and if 
>either  one of them was doing the right thing, the exploit would 
>fail.
>
>The first fault is Adobe's.  Because it's their code that first  
>acquires the input from the attacker, it's their job IMHO to 
>validate  it properly, but they don't.  Instead, they turn around 
>and tell  Windows to open the bogus URI.
>
>The second fault is IE7's.  The protocol handler used to fail  
>gracefully by rejecting this kind of malformed URI, but now it  
>doesn't.  The new behavior is to turn around and call ShellExecute() 
>  with data taken from the URI.
>
>I prefer to think of it this way: Adobe's code has been doing the  
>wrong thing for years, and they've gotten lucky.  But now, a new bug 
>  in IE7 has come along which makes the old bug in Adobe's code  
>exploitable.
>
>- Eric
>
>

_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger:  http://messenger.msn.com/cn  


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/