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

[Glynn Clements <glynn () gclements plus com>]

Kurt Dillard wrote:

> 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.

URIs are open-ended. There are dozens of existing schemes, and new
schemes are being added all of the time. It is unreasonable to expect
every program which handles URIs to validate them against such a
complex and unstable specification, particularly when it's merely
passing them through, and not actually *processing* them.

A web browser should be expected to validate URIs which it is
processing itself (e.g. http: and https: URIs), as well as validating
against generic URI syntax (to which the example URI conforms). For
URIs which it passes to an external handler (e.g. mailto:), it only
needs to identify the scheme (to select the correct handler); it is
the handler's responsibility to validate its own URIs (i.e. mail
programs need to validate mailto: URIs).

The fundamental flaw here is that Windows' built-in URI handler
doesn't invoke external programs correctly, resulting in a
shell-injection attack. This is no different to the hundreds or even
thousands of other shell-injection attacks which have been reported on
BugTraq and FD over the years.

Modifying individual programs to protect against a shell-injection bug
in Windows' URI handler is a workaround (mitigation strategy), not a
fix.

-- 
Glynn Clements <glynn () gclements plus com>