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: <18184.57835.923700.822600@cerise.gclements.plus.com>
Date: Sun, 7 Oct 2007 14:40:59 +0100
From: Glynn Clements <glynn@...ements.plus.com>
To: "Kurt Dillard" <kurtdillard@....com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	Thierry Zoller <Thierry@...ler.lu>
Subject: Re: URI handling woes in Acrobat Reader, Netscape,
	Miranda, Skype


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@...ements.plus.com>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ