It rather involved being on the other side of this airtight hatchway: Unquoted service paths

Or, Why most "Unquoted Service Paths" findings are unnecessarily alarmist

In late 2012, the issue of improper quoting in the configuration of paths to service executables seemed to begin getting attention again, possibly due to this article. Or perhaps this one. Or maybe this one, which links to articles describing similar issues going back to 2000. For whatever reason, scanning tools are now reporting "security vulnerabilities" with "Risk Factor: High", and taking up IT professionals' time chasing down issues that most of the time are not real security threats.

The issue that the scanners are identifying is that sometimes vendors install and configure Windows services in a file system path that contains a space (typically under "Program Files"), and fail to quote the path correctly when they configure the BinaryPathName value that tells Windows what to run. For example, say you install a service program in "C:\Program Files\My Super Service\SuperService.exe", and specify the service’s BinaryPathName like this, without any quotes:

C:\Program Files\My Super Service\SuperService.exe -p Network

When the Service Control Manager (SCM) starts the service, it treats the BinaryPathName value as a command line and tries to execute it. Quotes would tell Windows which part of the text represented the executable's path and which parts were command line arguments, if any. In the absence of quotes, Windows assumes that space characters are delimiters. So first, it parses out C:\Program and looks for C:\, C:\Program.exe, C:\Program.Bat, etc. When it finds none of those, it assumes that the first space is not in fact a delimiter, treats the characters up to the next space character as part of the file path, and repeats the process. In the second pass it will look for C:\Program Files\My.comC:\Program Files\My.exe, etc. After it fails to find those (as well as C:\Program Files\My Super.exe, etc.), it finally finds and executes SuperService.exe, passing it -p Network as command line parameters.

The ambiguity due to the lack of quotes means that if there were a C:\Program.exe, Windows would execute that program instead of the intended target program.

The "security vulnerability" assertion is that all an attacker has to do on a computer that has a LocalSystem service misconfigured in this way is to create a "C:\Program.exe" or a "C:\Program Files\My.exe" and Windows would start that program as the all-powerful LocalSystem, giving the attacker an easy elevation of privilege.

Yes, it is true that such services are not configured correctly. It is true that a few extra CPU cycles and disk I/O are being consumed needlessly when the programs are started. It is true that the wrong program could even be executed. But it has not been a true security vulnerability in any of the cases I have seen.

The reason it’s not usually a security vulnerability is because by defaulta non-admin attacker cannot create those files. Only administrators can, and if the attacker already has admin rights, there is no further elevation of privilege to be had -- the attacker already has all the privilege needed to do anything on the computer.

This configuration error becomes a security issue only if additional misconfiguration of file system permissions allows non-admins to create files in locations that should be protected. In Windows XP and newer, non-admins can create subdirectories in the root directory of the system drive (typically "C:\") but they cannot create files there. Permissions are set that way specifically to prevent this type of attack. Additionally, non-admins cannot make any changes in Program Files directories. An administrator (or a program with administrative rights) that changes the default permissions can defeat this protection. These misconfigurations -- especially relaxing permissions under Program Files -- tend to be more serious problems than the unquoted service path issue.

The purpose of this post is not to argue against fixing misconfigured service paths. It is about prioritization of effort. If the file system permissions are misconfigured, those should be fixed. If the default permissions are intact, unquoted service paths are not high risk and correcting them does not have to take priority over other (real) high risk issues.

One additional note: Every now and again a customer will send us their security scanner's report showing misconfigured third party services and ask, "When will Microsoft publish a hotfix for the unquoted service paths vulnerability?" The answer is that the bug belongs to the service installer, not to Windows. We cannot prevent administrators or their programs from misconfiguring Windows.

Many thanks to Raymond Chen for reviewing this and for letting me appropriate his Hitchhiker's Guide "airtight hatchway" meme.