none
Unquoted Service Path Vulnerability

    Question

  • This problem has been documented very clearly in several places, but folks seem to be getting the run around on an actual fix.  Before going any further, please read the following to understand the problem (sorry for the odd links, I am still waiting on account verification):

    H  T  T  P  :  :  /  /www.ryanandjeffshow.com/blog/2013/04/05/the-microsoft-windows-unquoted-service-path-vulnerability/

    This was discussed at length in this technet forum to no avail:

    H  T  T  P  :  :  /  /social.technet.microsoft.com/Forums/windows/en-US/402a8487-4612-4350-9777-9bbd32edf45b/develop-script-to-fix-unquote-binary-path-or-use-tool-such-as-wsus-or-group-policy-with-script-quote

    The long and short is as follows:

    We have hundreds of servers and many more workstations reporting the vulnerability and the only fix I am able to find (powershell scripts) is one I find risky.  Deploying a script to hundreds of machines potentially affecting thousands of services is just a bad idea, no matter how good your script is.  And, as previous folks have explained, you will have to continually do this as evidently NEW software still have the problem.

    On my Windows 7 machine, I ran the following command to grab the bad services:

    wmic service get name,displayname,pathname,startmode |findstr /i "auto" |findstr /i /v "c:\windows\\" |findstr /i /v """

    I got several hits, but here is one example:

    • Intel(R) Management and Security Application Local Management Service 
    • LMS
    • C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\LMS\LMS.exe

    If I run "net stop LMS"

    Then "echo "foo" > c:\program.exe"

    Then "net start LMS"

    I get the following:

    System error 216 has occurred.

    This version of *** is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

    Meaning the service tried to run c:\program.exe and failed.

    This is clearly a flaw in how MS is handling unquoted paths.  Three of the affected services are up to date software and security related.  Just preventing these from starting would be bad.  I will be contacting the vendors of some key software, but if I look at the entire list, I would spend the rest of my days just trying to find vendors and explain this to them.

    What is MS going to do to resolve this? 

    Monday, September 16, 2013 10:41 PM

Answers

  • User places program.exe that makes admin account in c:\

    This right here is the fundamental flaw in your whole argument. *IF* a user can place a file named program.exe in the root of drive C:, then that user also has the rights to EXECUTE that program directly -- whether it can be done by a malformed command line is irrelevant. Said user already IS an administrator, so there's no need to "wait for an admin to logon", either to cause the program to be executed, or to exploit another admin's privileges. The user placing the file can do both on their own!

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence R Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, October 16, 2013 8:11 PM

All replies

  • Some additional reference material:

    Here’s an article explaining the vulnerability: h t t p : / /www.commonexploits.com/?p=658

    Here’s the CVE: h t t p : / /web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1609

    Monday, September 16, 2013 10:58 PM
  • I guess this all depends on how you actually view this behavior.

    First, your scenario already requires two things:

    - Administrative access (in order to place an executable file in the root of the volume), and

    - A defective command string.

    Now, frankly, there's no real difference at all between forgetting to put quotes around a fully-qualified pathname to something in %ProgramFiles% and just calling the program directly. Either you have the ability to execute the program improperly placed, or you don't.

    I don't see it as a flaw... it's quite clearly been documented since the creation of long-path names that path names with embedded spaces required the use of quotation marks in order to properly operate. What you observe from the failure to use those quotation marks is exactly what the documentation has said would happen .. it will ignore everything after the first space and treat that as the Executable Program. This IS how Windows operates.

    The only issue here, is whether one considers this a security vulnerability, or just accepts it as a quirk of how the file system and command processor operate.

    In the end, the only way it CAN be a vulnerability is if there actually does exist a C:\PROGRAM.EXE and to create that file you have to have system administator privileges, in which case you can run anything anywhere on the system anyway, so what does it matter? A Standard User would not have any privileges to run C:\PROGRAM.EXE because it is in the root of the system volume.

    So, maybe the challenge here is presenting a more practical description of why this is a security issue. At best it's a low-priority annoyance only encountered by people who don't follow the rules for command line processing anyway. Frankly, given that nobody launches programs from the command line, it may even be less signficant than a minor annoyance.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Tuesday, September 17, 2013 5:54 PM
  • Lawrence,

    Thanks for the prompt and detailed reply.  I agree with the assessment and at the same time I have to comply with our security and compliance scans.  I am not sure why security companies have decided to bring this to the forefront once again, but they have and are classifying this as a "HIGH".  I am going to see if we can look to reclassify this as a lower risk and move forward.  I will see if I can get our security engineers to provide an assessment and opinion on the matter.

    Thanks,

    Chris

    Tuesday, September 17, 2013 7:17 PM
  • On XP SP3 the NT AUTHORITY\Authenticated Users has write access to the
    root of the system drive. So this can be exploited on XP.

    It can also be exploited on Windows 2003 R2 SP2 terminal server because
    the the NT authority\Terminal Server User has write access to c:\program
    files\.

    A unquoted service path vulnerability is a local privilege escalation vulnerability.

    User places program.exe that makes admin account in c:\
    User waits for admin to logon.
    Admin starts or auto starts vulnerable program that starts program.exe
    -Boem-

    Tuesday, October 15, 2013 9:04 PM
  • To add to that it's also a nice way for malware to stay persistent. A researcher running autoruns will never find this :)
    Tuesday, October 15, 2013 9:18 PM
  • User places program.exe that makes admin account in c:\

    This right here is the fundamental flaw in your whole argument. *IF* a user can place a file named program.exe in the root of drive C:, then that user also has the rights to EXECUTE that program directly -- whether it can be done by a malformed command line is irrelevant. Said user already IS an administrator, so there's no need to "wait for an admin to logon", either to cause the program to be executed, or to exploit another admin's privileges. The user placing the file can do both on their own!

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence R Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, October 16, 2013 8:11 PM
  • > Said user already IS an administrator

    No.
    A user with user privileges on a domain joined pc can write to c:\ because of the 'NT AUTHORITY\Authenticated Users' group.
    So you don't need admin rights to write to c:\ on a Windows XP machine

    > then that user also has the rights to EXECUTE that program directly

    A user with user privileges on a domain joined pc can indeed execute a executable. But Windows will not allow that exe/user to make an local admin account.

    Also:
    If a user has admin privileges he can obtain SYSTEM privileges if the vulnerable service is running as SYSTEM.

    Again: A unquoted 'service' path vulnerability is a local privilege escalation vulnerability.

    Tuesday, October 29, 2013 11:12 AM
  • > Said user already IS an administrator

    No.
    A user with user privileges on a domain joined pc can write to c:\ because of the 'NT AUTHORITY\Authenticated Users' group.

    On my domain joined XP SP3 system, NT AUTHORITY\Authenticated Users doesn't even exist in the ACL for the root of drive C:.

    On my domain joined Win7 SP1 system, NT AUTHORITY\Authenticated Users has *ZERO* rights to the root of drive C:, but is listed in the ACL.

    Repeating my previous premise, one MUST already be an Administrator in order to place a file in the root of drive C:. Non-Administrative users do not have WRITE permissions to the root of drive C:.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence R Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Saturday, November 02, 2013 4:16 PM