Custom url protocol is a common feature in Windows and macOS. On Windows, these protocols are registered in registry: Registering an Application to a URI Scheme (MSDN).

For example, to associate alert: protocol to alert.exe , create following registry keys:

HKEY_CLASSES_ROOT

alert

(Default) = "URL:Alert Protocol"

URL Protocol = ""

DefaultIcon

(Default) = "alert.exe,1"

shell

open

command

(Default) = "C:\Program Files\Alert\alert.exe" "%1"

The %1 will be replaced with arguments from url. It is quoted incase there’s a space or something that confuses CommandLineToArgvW , mistakenly split the filename or something else into multiple parts.

But there’s a serious problem, even MSDN has warned clearly: Security Issues

When ShellExecute executes the pluggable protocol handler with a stringon the command line, any non-encoded spaces, quotes, and backslashes in the URI will be interpreted as part of the command line. This means that if you use C/C++’s argc and argv to determine the arguments passed to your application, the string may be broken across multiple parameters. To mitigate this issue: Avoid spaces, quotes, or backslashes in your URI Quote the %1 in the registration (“%1” as written in the ‘alert’ example registration)

ShellExecute is an api for opening both URI and local paths.

So here’s the root cause for CVE-2018-1000006. The exploit breaks command line with one single quote, then insert a new switch that electron main executable recognizes. Electron project is powered by Chromium, and the vulnerable version supports Chromium Command Line Switches as well. Seems like these following switches will launch arbitrary command:

--renderer-cmd-prefix

--gpu-launcher

--utility-cmd-prefix

--ppapi-plugin-launcher

--nacl-gdb

--ppapi-flash-path & --ppapi-flash-args

Let’s see how Chromium itself mitigate the issue: add a double dash switch before user supplied arguments, treat all switch after it as invalid.