Home page logo

bugtraq logo Bugtraq mailing list archives

Re: Re[2]: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape,Miranda, Skype
From: Glynn Clements <glynn () gclements plus com>
Date: Sun, 7 Oct 2007 14:40:59 +0100

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

Glynn Clements <glynn () gclements plus com>

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]