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>] [day] [month] [year] [list]

Date: Tue, 09 Oct 2007 22:34:13 +0200
From: kriz.Full-Disclosure@....net
To: full-disclosure@...ts.grok.org.uk
Subject: URI handling woes in Acrobat Reader, Netscape,
	Miranda, Skype

I've looked through KB and MSDN and that's what I came up so far regarding ShellExecute and URI handling:

>>From http://support.microsoft.com/kb/224816/en-us

--------------------

How ShellExecute Works

The following background is for informational purposes only. It is provided so that you can better understand how your application interacts with the operating system. Do not base your designs on assumptions that you draw from this information. Be aware that this functionality may change in future versions of Microsoft products.

How ShellExecute Interprets the URL Passed

ShellExecute parses the string that is passed to it so that ShellExecute can extract either a protocol specifier or an extension. Next, ShellExecute looks in the registry and then uses either the protocol specifier or the extension to determine which application to start. If you pass http://www.microsoft.com to ShellExecute, ShellExecute recognizes the http:// sub-string as a protocol, which causes ShellExecute to view HKEY_CLASSES_ROOT\http\shell\open for information about how to run. If you pass myfile.htm to ShellExecute, ShellExecute recognizes the ".htm" sub-string as an extension. This causes ShellExecute to view HKEY_CLASSES_ROOT\.htm, which leads to HKEY_CLASSES_ROOT\htmlfile\shell\open. 

Typically, it is best to fully specify your URL in the string that is passed to ShellExecute, for example: http://www.microsoft.com instead of www.microsoft.com. When you fully specify the URL, you make sure that ShellExecute knows exactly which protocol you want. By default, however, ShellExecute detects some patterns that include www.* and ftp.*, and then maps those patterns to the Hypertext Transfer Protocol (HTTP) protocol and the File Transfer Protocol (FTP), respectively. 

--------------------

>>From the above I infer that the following steps dURIng ShellExecute( "mailto:test%../../../../windows/system32/calc.exe".cmd" ) on a Windows XP system with IE7 installed:

1) ShellExecute will check whether the supplied string  is a valid URL according to the relevant rfc (it is not).
2) ShellExecute now assumes that the string is a file and will extract the file extension (in this case it is .cmd)
3) ShellExecute will read HKEY_CLASSES_ROOT\.cmd to get the file type (in this case cmdfile)
4) ShellExecute will read HKEY_CLASSES_ROOT\cmdfile\shell\open\command to get the handler (in this case "%1" %*)
5) ShellExecute will replace any variables in the handler command with the supplied string (in this case %1 with mailto:test%../../../../windows/system32/calc.exe".cmd)
6) This results in "mailto:test%../../../../windows/system32/calc.exe".cmd" %* which will be interpreted as "mailto:test%../../../../windows/system32/calc.exe" .cmd" and fed into CreateProcess()
7) CreateProcess() will fix/normalize the path and execute the resulting command (calc.exe)

That's all!

NB: I'm not sure about step 6) - ShellExecute() eventually removes the garbage ("mailto:test%") from the beginning of the string so that  ../../../../windows/system32/calc.exe".cmd will be used dURIng further processing instead of mailto:test%../../../../windows/system32/calc.exe".cmd .

Conclusions:

1) Applications must not call ShellExecute() with invalid URLs. Any application has to validate URLs against the appropriate rfc (to lazy to look which ones apply)
2) The "file name" has to have an extension with a "useful" handler (in this case cmdfile which will simply execute anything)
3) With IE6 insalled the shell erroneously thinks  mailto:test%../../../../windows/system32/calc.exe".cmd  is a valid mailto URL an launches the mailto handler.
4) IE7 ships with a rewritten URL parser (cURL) that fixes the aforementioned  bug - see  http://blogs.msdn.com/ie/archive/2005/08/15/452006.aspx

5) "Overloading considered harmful" - having a separate function "ShellExecuteURL()" which only accepts valid URLs and rejects invalid ones could have prevented the problem?

>>From my point of view the URI handling problem is in every instance an application problem not a Windows (shell) bug.

Kriz

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

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