New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users
Status: WontFix
Owner:
Email to this user bounced
Closed: Oct 2015
Cc:



Sign in to add a comment
.NET Partial-Trust bypass via browser command-line injection in System.Windows.Forms.Help
Reported by matttait@google.com, Jul 13 2015 Back to list
A command-line injection vulnerability exists in the core .NET class System.Windows.Forms.Help::ShowHelp function allowing an attacker without "UnmanagedCode" permission to nevertheless directly control arguments passed to a "ShellExecute" invocation of the users' default browser.

This vulnerability allows an attacker who is able to run arbitrary .NET code within a .NET PartialTrust sandbox including the "WebPermission" permission for any URL to inject arbitrary parameters after the first parameter into the command line of the users' default browser.

Attached is a proof-of-concept, which is run from a PartialTrust application with the "WebPermssion" .NET permission asserted for the URL "http://www.google.com/x-noredirect". This causes the users' default browser to be launched with the command line:

<path-to-browser> "http://www.google.com/x-noredirect/#" injected-param ""

Also attached is a screenshot of Windows Task Manager for the case where the default browser is Google Chrome. In this case, Windows Task Manager reports that Chrome.exe was started with the following command line:

"chrome.exe" -- "http://www.google.com/x-noredirect#" injected-param ""

In practice, many major browsers do not allow for direct modification of the browser or execution (such as downloading and installing new extensions) via the command-line when launched via the Windows shell function "ShellExecute"; however this vulnerability could be combined with a command-line processing vulnerability to elevate out of a PartialTrust sandbox.

In particular, this vulnerability could be triggered via a "XAML Browser Application" launched from Internet Explorer's "Intranet Zone". XBAP containers automatically elevate from the "Low-Integrity AppContainer" sandbox used by Internet Explorer, and rely on the .NET permission sandbox to secure the .NET code downloaded from the remote website. XBAP containers automatically have the .NET "WebPermission" permission granted for the domain from which they are launched, and consequently this vulnerability can be launched from inside an XBAP container to perform command-line injection into the users' default browser launched directly at Medium Integrity, rather than launched within the "Low Integrity AppContainer" sandbox.
 
example.cs
435 bytes Download
screenshot.png
67.1 KB View Download
Project Member Comment 1 by hawkes@google.com, Oct 7 2015
Labels: MSRC-30648
Project Member Comment 2 by hawkes@google.com, Oct 12 2015
Labels: -Restrict-View-Commit
Status: WontFix
We received word that this is not considered a supported security boundary, and documentation improvements will be made to reflect that .NET Framework Code Access Security does not guarantee this type of code isolation.
Sign in to add a comment