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@xxxxxxxxxxxxxxxxxx>
