Partager via

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

  • Article

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:\Program.com, 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.com, C:\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.

Comments

  • Anonymous
    November 17, 2014
    Hi Aaron.  As an admin who has his time wasted with these exact security "vulnerability" scanner results, I enjoyed your post.  On the other hand, it's such an easy thing to fix, even if it isn't usually that dangerous. And by brushing it off as not really that serious, we're assuming that this misconfiguration is not also coupled with an ACL misconfiguration of the file system... a combustible mixture on which I'd rather not take my chances. [Aaron Margosis]  You're right, it's important to verify file system ACLs before brushing it off - but again, those ACLs must be fixed, particularly under Program Files.  The quoted-path fix is relatively easy when you do them manually, one at a time, but writing script or other code that always gets it right is harder than one might expect.  E.g., the service executable's file extension is almost always .exe, but it doesn't have to be -- it's even possible for an executable image not to have a file extension.  Directory names can have dots in them, too, which a lot of script writers fail to recognize.  You can end up pushing out changes that cause services not to start at all.  It's probably better if you figure out which installers are doing it incorrectly and writing something specific to that installer that's packaged and executed with the installer, rather than making broad changes long after the systems have been deployed.  And again, make sure no one's messing with the ACLs (simpler) and there's no issue.

    • Anonymous
      June 27, 2016
      Every developer (and of course his dog too) could or better should have used Microsoft's application verifier to detect this bug: see https://msdn.microsoft.com/en-us/library/aa480483.aspx and its section "Checking for Proper Use of CreateProcess"Now check whether this MSDN article tells the truth about application verifier's tests!

  • Anonymous
    January 18, 2015
    The comment has been removed

  • Anonymous
    January 18, 2015
    The effort to add the missing quotes around 'long' pathnames with spaces is but VERY low! It's a shame that developers and their QA dont detect those silly errors and ship software with this bug. AND: are you REALLY sure that the hatchway is airtight? Unprivileged users can create a directory C:Program.exe (CreateProcess() ignores directories, junctions/mountpoints and symlinks to directories when it plays try&error), can open this directory and turn it into a reparse point. Look what happens after CMD.EXE /K MkLink C:Program.exe "%PUBLIC%" (yes, THIS needs a privilege not granted to "Users" per default). Now play with the other types of reparse points! [Aaron Margosis] If you come up with anything that actually allows a non-admin user to cause other users or the OS to run code of the non-admin's choosing, please email secure@microsoft.com.  Thanks.

  • Anonymous
    January 18, 2015
    JFTR: CreateProcess() only appends .exe, NOT .com, NOT .cmd, NOT .bat or any other member of the PATHEXT environment variable.

  • Anonymous
    March 24, 2015
    I appreciate your take on this and agree that it's primarily an issue of prioritization. The problem is that IF in the process of installing a third party program the permissions are changed for C: or C:Program Files then this becomes something that CAN be attacked. What's interesting to me though is that I just discovered that Microsoft Exchange 2013 contains multiple unquoted paths for Exchange services in Service Control Manager. Does this mean that Microsoft doesn't consider this a true problem and that permissions management is an enterprise problem and that MS doesn't have to prevent unquoted paths even in their core enterprise products? It's a lot easier to PREVENT this at the source then it is to monitor for changes to file system permissions across the enterprise. So now I'm off to develop a PowerShell script that detects non-standard permissions for C:, C:Program Files, and anywhere else services are configured to run from for every single system we have.

  • Anonymous
    December 04, 2015
    seclists.org/.../70 [Aaron Margosis] Totally misses the point. All his examples assume the user/attacker has admin rights.

  • Anonymous
    December 04, 2015
    [Aaron Margosis] Totally misses the point. All his examples assume the user/attacker has admin rights. Correct: Aaron TOTALLY misses the point. The user account created during Windows NT setup is an administrator account. According to Microsoft's own SIR reports about 2/3 of all Windows installations only have a single active user account. According to numerous Microsoft sources/statements UAC is NOT a security boundary (but a useless security theatre). [Aaron Margosis] <sigh>  IF YOU HAVE ADMINISTRATIVE RIGHTS (which the author of that post and now you are assuming), not only can you create a subdirectory under Program Files, you can change the configuration of the service to point to anything you want, you can replace the service executable file with anything you want, you can do anything you want. Tricking the service control manager into running the wrong program because of a path-quoting issue is the least of it. UAC same-desktop elevation is not a security boundary, but that only comes into play if you have an administrative account to work with. There is a security boundary between standard-user and administrator.

  • Anonymous
    December 05, 2015
    Just in case that you STILL don't get it: THE USER ACCOUNT CREATED DURING WINDOWS SETUP IS AN ADMINISTRATOR ACCOUNT! About 2/3 of your customers are on the WRONG SIDE of the (thanks to the security theatre UAC not) "airtight hatchway". Unfortunately most of these 2/3 of your customers but have NOT been warned and have no clue that UAC is NO security boundary. It's your company's duty to create a standard user account during Windows setup, like "real" OS do just a little bit longer than your company exists now. WHEN WILL MICROSOFT START TO FOLLOW BEST PRACTICE AND ABONDON THEIR BAD HABITS? [Aaron Margosis] I'm sorry, I get it now. I thought you were trying to make a point that was somehow relevant to unquoted service paths, but you're just trolling. Account and privilege management for managed enterprises and for independent individuals are entirely separate issues and completely out of scope for a post about unquoted service paths.

  • Anonymous
    December 05, 2015
    The point you TOTALLY missed starts with "Despite this, unprivileged users can ..." on FD. [Aaron Margosis] I didn't miss it. In fact, I specifically mentioned in the post that standard users can create subdirectories in %SystemDrive%. That doesn't give standard users the ability to get unquoted service paths to resolve to files that they place on the hard drive. If they could create files in %SystemDrive% or subdirectories in %ProgramFiles%, they could. But they're not allowed to do that.

  • Anonymous
    December 09, 2015
    "That doesn't give standard users the ability to get unquoted service paths to resolve to files that they place on the hard drive."

  1. Did anybody say they can?
  2. Fortunately about 2/3 of all Windows installations but DON'T have a standard user account (see your own companies SIR): There is NO AIRTIGHT HATCHWAY on these installations! [Aaron Margosis] Re 1 -- then why raise the point at all? How is it relevant? Re 2 -- Irrelevant to this discussion. This is about preventing elevation from standard user to System. If you're already admin then it's a moot point.

  • Anonymous
    December 09, 2015
    Ad 1. see the very first comment by Ryan Ries: "by brushing it off as not really that serious, we're assuming that this misconfiguration is not also coupled with an ACL misconfiguration of the file system... a combustible mixture on which I'd rather not take my chances." Ad 2. your marketing sells UAC with "user's dont have administrative privileges any more".to the unsuspecting Jane and Joe Average. On about 2/3 of all Windows installations there is NO airtight hatchway, a file C:program[.exe] or "%ProgramFiles%common[.exe]" can easily be used as APT there. An attacker can use both misconfigurations! [Aaron Margosis] I have already addressed both of these points. Your next troll post gets deleted.

  • Anonymous
    December 29, 2017
    "Only administrators can create these files." Wait what? On my newly installed Windows 10 I discovered I have write permission to C:\ without UAC elevation. I directly tested this from an unprivileged command prompt so it's not explorer elevating behind my back.[Aaron Margosis] I checked on a freshly-installed v1709 and the default permissions do not allow non-admin file creation in C:. Something must have altered the security descriptor on the root of the C: drive on your system.