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

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: <BAY134-DS1CBF070066D53CCEC8872A7AA0@phx.gbl>
Date: Sat, 6 Oct 2007 14:52:28 -0400
From: "Kurt Dillard" <kurtdillard@....com>
To: "Thierry Zoller" <Thierry@...ler.lu>,
	<bugtraq@...urityfocus.com>, <full-disclosure@...ts.grok.org.uk>
Subject: 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@...ler.lu>
Sent: Saturday, October 06, 2007 1:06 PM
To: <bugtraq@...urityfocus.com>; <full-disclosure@...ts.grok.org.uk>
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.
>
>
> -- 
> http://secdev.zoller.lu
> Thierry Zoller
> Fingerprint : 5D84 BFDC CD36 A951 2C45  2E57 28B3 75DD 0AC6 F1C7
>
>