Today we are releasing MS10-007 to address a URL validation issue generally applicable to the ShellExecute API.
How would a malicious user leverage this vulnerability?
This issue involves how ShellExecute handles strings that appear to be legitimate URLs, but are malformed such that they result in execution of arbitrary code. Various technologies use ShellExecute to initiate a browser navigation. It is assumed that the operation is safe if the parameter passed to ShellExecute “looks like a URL.” It seems reasonable to expect that if a string is a valid URL, it cannot possibly result in execution of arbitrary code when processed by ShellExecute.
But while it may be valid to assume that
will not execute a system command, it should be understood that the core purpose of the ShellExecute API is to execute files. This vulnerability involves the use of a valid-looking URL that ShellExecute will run as a system command. To get exploited, a user might click on a link appearing outside the context of the browser, for example as an address book contact. At that point, a remote executable could run without prompting.
Recommendations for Developers
We recommend that application developers wishing to use ShellExecute for URL-based navigation take a conservative approach to validation. First, developers should heed the specific guidance in KB943552 as it pertains to this scenario. Additionally, rather than simply validating that a URL is of the format [scheme]://[FQDN]/[path]?[querystring], it is advisable to also validate that the URL scheme is one of a specific set of allow-listed URL schemes, for example “http” or “https.” This is consistent with guidance provided in Chapter 4 of the Microsoft Design Guidelines for Secure Web Applications.
As it turns out, many commonly-used code paths actually do perform this level of URL scheme validation and thus do not present viable attack vectors, even in the presence of the ShellExecute bug. Defense-in-depth FTW!
Thanks to Chengyun Chu for insight and analysis on this issue.
- David Ross, MSRC Engineering
*Posting is provided "AS IS" with no warranties, and confers no rights.*