[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re[2]: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape,Miranda, Skype

In my opinion, every application should handle incoming data as bad data. Its poor programming to assume that incoming data is properly formatted and safe to process as is, even if the data is supposed to come from a process you own. Why so extreme? Because the bad guys are going to figure out how to get bad data to your code using pathways you didn't consider. In other words, I agree with Geo that each of the applications should inspect the URI before processing it. The OS components that are involved should too, but the 3rd party apps should never assume that IE or whatever has done so.

From: "Thierry Zoller" <Thierry@xxxxxxxxx>
Sent: Saturday, October 06, 2007 1:06 PM
To: <bugtraq@xxxxxxxxxxxxxxxxx>; <full-disclosure@xxxxxxxxxxxxxxxxx>
Subject: Re[2]: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape,Miranda, Skype

Dear Geo.,

G> If the application is what exposes the URI handling routine to untrusted
G> code from the internet,
Sorry, Untrusted code from the internet ?

The user clicks on a mailto link, is that untrusted code?
Or the mailto link is clicked for him.

Anyways, the mailto link
POST IE7 has a flaw/threat/vulnerablity it hasn't had PRE IE7.

G>  then it's the application's job to make sure that
G> code is trusted before exposing system components to it's commands, no?
Yes to a certain degree it is, like I said mitigation is fine, though
it shouldn't be the final word here, _if_ my assumptions I derive from
the things I know and just tested are correct. I might be wrong, but I
dont' think so =)

The problem here is the root cause, the root cause is that IE7
introduced a problem, you can call it "vulnerability" or "Threat" or
whatever floats your boat, I don't care, my point is, in my opinion
the handler itself is broken.

Thierry Zoller
Fingerprint : 5D84 BFDC CD36 A951 2C45  2E57 28B3 75DD 0AC6 F1C7