locked
Develop script to fix unquote binary path or use tool such as WSUS or Group policy with script quote path

    Question

  • strings.   Beca

    This month we came accross a vulnerability which is cause by install patches with their environment path unquote and embedded space. (long path name).

    The vulnerability takes advantage of the way Windows parses directory paths to execute code.   Consider the following command line. C:\windows\system32\notepad \temp\file.txt This tells windows to launch notepad.exe from the c:\windows\system32\ directory and pass it the argument \temp\file.txt. 

    Now consider this command line.

    C:\program files\Microsoft Office\Winword.exe

    If space is used as a delimiter, wouldn’t Windows think you are trying to execute the program  C:\PROGRAM.EXE and pass it the argument “files\Microsoft Office\Winword.exe”?    Or maybe you are trying to execute “C:\Program files\Microsoft.exe” and pass it the argument “Office\Winword.exe”?  So how does it know what you are trying to do?    If the software developer places quotation marks around the path then Windows knows the spaces are spaces and not delimiters.   If the software developer fails to put the path in quotes then Windows just doesn’t know.  If Windows doesn’t know then it tries to execute all the possible programs in the path.  First it tries “C:\Program.exe”,   Then, it tries “C:\Program files\Microsoft.exe” and finally the path we intended for it to execute. 

    This programming error is very common because when a developer is addressing paths on the file system they are usually stored in use they are in strings the developer has used quotes once already and they often fail to consider that they need two sets of quotes.  For example, the following line would incorrectly assign the path variable.

    pathvariable = “C:\Program Files\Common Files\Java\Java Update\jusched.exe”

    Really, the developer needs to double quote it because they need the path to contain quotes.  So they should have assigned their variable by doing something like this:

    pathvariable = “\\”C:\Program Files\Common Files\Java\Java Update\jusched.exe\\””

    In the first case, an attacker can strategically place a program in the path and his program will be executed instead of the intended program.   If the process runs under administrative privileges or some account other than the attacker it can be used to cause code to execute under a different set of privileges.  

    So the question is..... since Windows 95, when creating a bin path both long and short path name are created if enable in the registry

    For example lets take this example...

    The OS will create enviroment variable for pointing to long path name  C:\Program Files\crapy.exe

    and also create a short path name for C:\Progra~1\crapy.exe

    So how can I tell WSUS to install the path and create a environment variable to point to the executable to use the short path name instead of the long path name? Is this possible?

    Or I will have to create a report of software which install the updates patches with vulnerability and request a revision of the update.

    Or should I go a head identify the services which are type auto (exclude disable, manual) and code a script program and modify the enviroment path... Consequences of this approach, will I need to re-run the script if there a new software update for the third party software and it does n't address the path problem. I will need to run the script again.

    Or should I create a policy and associate the script with it, until a revision comes along.

    How can I get around this vulnerability as a long term fix versus a short term fix?

    Can someone tell me the best approach (mitigate) to solve this issue?

    thanks


    michael john ocasio


    • Edited by mjocasio23 Saturday, January 26, 2013 9:43 PM
    • Moved by Bill_Stewart Thursday, April 4, 2013 8:22 PM Move to more appropriate forum
    Saturday, January 26, 2013 9:43 PM

Answers

  • And you are stating this could be a false positive by Nessus...... thanks again

    michael john ocasio

    If this is because of a report by Nessus then you should contact Nessus.  If they are just scanning the registry then they will report this even if the patch is in place.

    Very often AV software and security vulnerability analysis software detect things even though they are no longer an issue.

    I do not know Nessus.  I have run many scanners on hundreds of systems and have never seen this detection.  I would not expect to see it on WS2003 and later systems.

    If you are in doubt an feel that somehow this does present a vulnerability you should contact Microsoft Support.  Tell them you have an issue with security and need a clarification.  Show them the reports and let MS tell you what they think.

    With security it is always good to double check and cross check.  Just don't assume that every detection is correct if you systems are patched up-to-date and the reports are old - this one is ancient.

    In any case you could not fix it with WSUS or with GP.

    It is also not really possible to detect all instances of this with a scan.  The issue with McAfee was in how it used CreateProcess to launch sub-processes.  This can only be detected if you know about it in advance. McAfee fixed this back in W2000.

    The fundamental vulnerability was fixed by Microsoft as much as it can be and all later programs should use the API correctly to prevent this from happening.  The service launcher should not allow a split path as of now.

    Understanding the  vulnerability requires a good knowledge of the API call.  The blog post you referenced understands how to create the effect but misunderstands the reason for the vulnerability.  They use RunDLL which just passesthe string to CreateProcess.  If you don't quote t correctly it will pass wrong.  This not a problem other than the program you want to run will likely not run.  THe blog write may be just trying to show what can happen but it I  not what IS happening.

    Call Nessus support to see if they can fix their detection. It will make your boss happy.


    ¯\_(ツ)_/¯

    • Marked as answer by mjocasio23 Sunday, January 27, 2013 3:16 AM
    Sunday, January 27, 2013 2:37 AM
  • The registry issue has been fixed by Microsoft a long time ago.  You do not need to be concerned about this.  CAll Nessus and tell them it is a false detection.  They will tell you how to fix this and will update their tool.

    If you insist on this exercise then use Group Policy to alter the registry.

    This is not a scripting issue. 

    Someone should move this to the off-topic forum.


    ¯\_(ツ)_/¯

    • Marked as answer by mjocasio23 Monday, January 28, 2013 6:30 PM
    Monday, January 28, 2013 5:12 PM
  • What environment variables are you talking about?  Environment variables do not have spaces and have nothing to do with services or creating programs.

    Are you talking about registry settings for the service descriptor?

    Once again.  This vulnerability was fixed back in Windows 2000.  Are you running an unpatched version or Windows 2000?

    Please refer to the links I posted.

    I still have no idea what your question is.


    ¯\_(ツ)_/¯

    • Marked as answer by mjocasio23 Sunday, January 27, 2013 2:12 AM
    Sunday, January 27, 2013 2:09 AM
  • I found the problem while installing the NVIDIA drivers..... If you look at step 4 in the below link, the default extraction path (will define environment var to point to this location, path to the server component), We went in and change the default extraction path and added the PROGRAM FILES PATH which contains embedded space and was not quote.... This was causing the scanner tool to detect the vector path as vulnerable....

    http://nvidia.custhelp.com/app/answers/detail/a_id/2900/~/guide-on-how-to-install-the-nvidia-display-driver-under-windows-7%2Fwindows-vista


    michael john ocasio

    • Marked as answer by mjocasio23 Sunday, January 27, 2013 9:23 PM
    Sunday, January 27, 2013 9:23 PM

All replies

  • You have posted in a scripting forum.

    There are fundamental errors in your logic.  Windows does not work the way you seem to be indicating that it does.  Much of your argument is true at a command prompt under the classic shell but not when using automation.

    Your question seems to be something about using WSUS.  You need to post in the WSUS forum for issue with WSUS.

    Note that WSUS does not install anything. WSUS deploys patches, updates and utility software.  These are all done with installer or patch file technology.  None of your issues are valid for these installer systems.

    What you need to do is state clearly what you are trying to accomplish and then state what is not happening or what errors you are getting.  Your description will be easier to understand if you do this with basic English and avoid complex technical descriptions.


    ¯\_(ツ)_/¯

    Saturday, January 26, 2013 9:53 PM
  • Her is an example of where you misunderstand how this works:

    pathvariable = “C:\Program Files\Common Files\Java\Java Update\jusched.exe”

    As a developer I have no issue with this in C,C# or VB.Net because when I use it it will be with an API that knows about path names.  The only place where spaces are an issue is at the command line. This is where an input string gets parsed.  At the commandline the 'space' character is a delimiter so it breaks the line.  In the API there is NO parsing.  A string is a string.


    ¯\_(ツ)_/¯

    Saturday, January 26, 2013 9:57 PM
  • Let me see if I could rewrite this.... give me a second please..... lets leave the WSUS or Group policy out of the question........ I just trying to find out a way that until an update patch is available to remedy unquote path.... Is there a solution I could use that instead of scripting I can take advantage of tools already build and probably change a setting to use the short path instead of the long path. The best place is ask developer is their aware of any software build or should I need to script this task......

    thanks for your respond


    michael john ocasio

    Saturday, January 26, 2013 10:00 PM
  • What is "unquote path"? As far as I can tell there is no such thing.  Can you show us a KB or other document that explains what you mean by this?

    ¯\_(ツ)_/¯


    • Edited by jrv Saturday, January 26, 2013 10:45 PM
    Saturday, January 26, 2013 10:44 PM
  • Try to give an example of something you are trying to do that won't work because of this issue.

    ¯\_(ツ)_/¯

    Saturday, January 26, 2013 10:46 PM
  • Saturday, January 26, 2013 11:17 PM
  • see article

    https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/14464


    michael john ocasio

    I think you are over stating this.  It is no an issue for WSUS or any other MIcrosoft program.

    See:

    Unquoted Windows search path vulnerability in Musicmatch Jukebox 10.00.2047 and earlier allows local users to gain privileges via a malicious C:\program.exe file, which is run by MMFWLaunch.exe when it attempts to execute launch.exe.


    ¯\_(ツ)_/¯

    Saturday, January 26, 2013 11:30 PM
  • All my checks show that this was fixed in all products last year.

    If you still have concerns than you need to check with the security forums and not in a scripting forum.

    If you are not using those products then you need not be concerned.


    ¯\_(ツ)_/¯

    Saturday, January 26, 2013 11:33 PM
  • Rading the article it seems to me that the person who wrote it does jnot know what he is talking about.  This is not a WIndows issues and never has been.  There are plenty of issues over the years but this is not one.

    THis is such an odd case that you would have to bend over backwards to make it happen.  Apparently the reported software has a programming errro that allows the exploit to work.  If you are not an admin then not much can happen.


    ¯\_(ツ)_/¯

    Saturday, January 26, 2013 11:36 PM
  • I reread you posts one more time and I still cannot make any sense out of your question.

    The CSV is about  services that are installed using a path with spaces in it.  There is no way to tell the system to change this globally.  The paths are in the registry.

    All services - McAfee Viruscan 4.5 - that had this problem were fixed years ago.  We are currently at McAfee 9+ so 4.5 is ancient.

    The CSV are so old that they cannot even be found on the NIST site.  I think this blogger is just jerking everyone's chain to see how many gullible people will respond.

    Are you sure someone in your organization is not sending you on a snipe hunt?


    ¯\_(ツ)_/¯

    Saturday, January 26, 2013 11:58 PM
  • I'm not implying that.... What I'm asking if there a is feasible way that it could be adapt while WSUS install the package and probably throught group policy check if environment var reference created by the package could be change to a short path name giving the fact if machine has this setting enable in the registry. This will eliminate the need to create a clean-up routine to check for these paths on patches who are flag by scanner. First thing to do is to inform the vendor to provide with revision and in the meantime client needs to get rid off the risk. The long term fix vendor provides the fix....... second if vendor don;t provide with revision, can it be done after deployment and either after or before the installation of package in the target machine?..... I will assume after the package gets install.... because you will be able to access the attributes of the services by GetWMIOject Class Win32_xxxxx  you can retrieve the path of the package which gets written in the form of long path name. I could go and check if the path is unquote and replace it with the short path name.

    What would be the most efficient way to do this.... giving the fact software may have more revision down the road and it they do and if they haven't revised the unquote path problem. If I write a stand alone script, my changes will be overwritten. So the only solution or approach will be to do it while the package gets install.


    michael john ocasio

    Sunday, January 27, 2013 12:02 AM
  • Like I posted.  WSUS and Group Policy do not install anything. They just download packages to be installed.  You have to contact the vendor of the package and have them change it.

    Again - this vulnerability has been fixed.  It is not something you need to worry about.

    What you want to do cannot be done by WSUS or Group Policy.

    The issue of using RunDLL to execute a program to demonstrate the problem is just a trick to make you believe there is a problem.

    THERE IS NO UNQUOTED PATH PROBLEM IN WINDOWS FOR WSUS OR GROUP POLICY.

    If you do not like or agree with this explanation then please post in the Windows Security forum and have them answer your question.


    ¯\_(ツ)_/¯

    Sunday, January 27, 2013 12:30 AM
  • You know what..... If I knew the answer of what I'm trying to do..... I will not ask...... Do me a favor if you are not going to be a source for help and provide a constructive opinion. I will suggest keep your comments to yourself..... I'm prety sure there are plenty of peoole out there with the desire to help........ So you figure.....  

    michael john ocasio

    Sunday, January 27, 2013 12:33 AM
  • I am sorry but there is no way to script anythimg to fix this issue. I cannot make this up.

    Please read this bulletin carefull. It is pone of the old bulletins posteed in your link.  Note tht the date is from the year 2000.

    http://www.securityfocus.com/bid/1920

    The National database is the source for this link.

    Here is the National Database entry:  http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-1128

    The first link is from the federal  database.

    These bugs were fixed years ago.  The blogger is just out in space about this.

    Even so there is no way to do what you want with script.

    Sorry.  As before.  If you disagree then try posting in the Windows Security Forum.  They will likely tell you the same thing.


    ¯\_(ツ)_/¯

    Sunday, January 27, 2013 12:51 AM
  • I want to thank you for your time on this matter.... This vulnerability was recorded by Nessus tool used by the agency that I work for.... This was collected in the last report of the agency apply to all the machines in the agency... We have 433 workstations outstanding and a couple of servers..... One example points to NVIDIA software driver having a path of the services as unquote and with embedded space. I went in and look in the services component and check path recorded in the environment variable and its define as unquote with embedded space which is flag by Nessus. I be dam..... My supervisor got in my case implying I haven't spend enough time in researching or coming up with a solution..... And you are stating this could be a false positive by Nessus...... thanks again

    michael john ocasio

    Sunday, January 27, 2013 2:01 AM
  • What environment variables are you talking about?  Environment variables do not have spaces and have nothing to do with services or creating programs.

    Are you talking about registry settings for the service descriptor?

    Once again.  This vulnerability was fixed back in Windows 2000.  Are you running an unpatched version or Windows 2000?

    Please refer to the links I posted.

    I still have no idea what your question is.


    ¯\_(ツ)_/¯

    • Marked as answer by mjocasio23 Sunday, January 27, 2013 2:12 AM
    Sunday, January 27, 2013 2:09 AM
  • And you are stating this could be a false positive by Nessus...... thanks again

    michael john ocasio

    If this is because of a report by Nessus then you should contact Nessus.  If they are just scanning the registry then they will report this even if the patch is in place.

    Very often AV software and security vulnerability analysis software detect things even though they are no longer an issue.

    I do not know Nessus.  I have run many scanners on hundreds of systems and have never seen this detection.  I would not expect to see it on WS2003 and later systems.

    If you are in doubt an feel that somehow this does present a vulnerability you should contact Microsoft Support.  Tell them you have an issue with security and need a clarification.  Show them the reports and let MS tell you what they think.

    With security it is always good to double check and cross check.  Just don't assume that every detection is correct if you systems are patched up-to-date and the reports are old - this one is ancient.

    In any case you could not fix it with WSUS or with GP.

    It is also not really possible to detect all instances of this with a scan.  The issue with McAfee was in how it used CreateProcess to launch sub-processes.  This can only be detected if you know about it in advance. McAfee fixed this back in W2000.

    The fundamental vulnerability was fixed by Microsoft as much as it can be and all later programs should use the API correctly to prevent this from happening.  The service launcher should not allow a split path as of now.

    Understanding the  vulnerability requires a good knowledge of the API call.  The blog post you referenced understands how to create the effect but misunderstands the reason for the vulnerability.  They use RunDLL which just passesthe string to CreateProcess.  If you don't quote t correctly it will pass wrong.  This not a problem other than the program you want to run will likely not run.  THe blog write may be just trying to show what can happen but it I  not what IS happening.

    Call Nessus support to see if they can fix their detection. It will make your boss happy.


    ¯\_(ツ)_/¯

    • Marked as answer by mjocasio23 Sunday, January 27, 2013 3:16 AM
    Sunday, January 27, 2013 2:37 AM
  • I found the problem while installing the NVIDIA drivers..... If you look at step 4 in the below link, the default extraction path (will define environment var to point to this location, path to the server component), We went in and change the default extraction path and added the PROGRAM FILES PATH which contains embedded space and was not quote.... This was causing the scanner tool to detect the vector path as vulnerable....

    http://nvidia.custhelp.com/app/answers/detail/a_id/2900/~/guide-on-how-to-install-the-nvidia-display-driver-under-windows-7%2Fwindows-vista


    michael john ocasio

    • Marked as answer by mjocasio23 Sunday, January 27, 2013 9:23 PM
    Sunday, January 27, 2013 9:23 PM
  • I told you that the vendor was the best place to check.   I also noted that you can only make the changes by changing the installer.  No amount of scripting can help you with this.

    Glad you were able to find a olution although the scanner too is just wrong here.  Drivers are NOT susceptible the vulnerability.

    I do not understand where you are finding environment variables.  There are no environment variables in an installer package. It is also not possible to directly edit an installer package.  It is not a script or batch file.


    ¯\_(ツ)_/¯

    Sunday, January 27, 2013 9:40 PM
  • Here is a bit from the Nessus write-ups:

    3.0 Identifying false positives

    Once the results are in a format you are prepared to deal with,
    the real work begins: analyzing the results and proposing solutions. In a
    perfect world this would be simple but due to the myriad combinations of
    software and configurations, remote black box vulnerability scanning is
    difficult and an inexact science.

    One problem is that sometimes Nessus
    just gets it wrong. This is the case not very often but it does happen. If
    appropriate techniques are used (many of which are discussed in the second
    article
    of this series) the accuracy can be increased, but for the
    foreseeable future a human will still need to pass final judgment. Sometimes
    vulnerability reports can be confusing due to the many possible combinations of
    software and configurations involved. Although every possible way that Nessus
    may throw a false positive or confuse the reader can't be enumerated, many of
    the reasons why these things happen and the signs to look for can be discussed.
    Nessus typically gives you a false positive due to one of two reasons: either
    the plug-in is only testing for a software version number or the results are
    unexpected but still valid.


    ¯\_(ツ)_/¯

    Sunday, January 27, 2013 9:43 PM
  • What I was refering that once the package was installed, it creates a environment variable pointing to the location where the executable resides.

    I was lookng at the possibility to revise the pathName propeerty of the services component (executable) by changing environment variable value and that will take care the vulnerability.

    The other possibility I was looking was to use the short path name instaed of the long path name to revise the PathName property of the services and also the environment variable.....

    Neither way is possible due to the first scenario, the  enviroment variable is define by the installer and second option, in order to use the short path name it need to be configure in the setup program.

    Which brings me to this question.....In order to change these properties, it has to be done throught the registry. Short term fix until revision of software arrives.

    Thank you so much for your time......


    michael john ocasio

    Monday, January 28, 2013 4:29 PM
  • Sorry but the driver installation package does not create an environment variables.  The vulnerability detected detects information stored in the operating system.  It has  nothing to do with environment variables.  Display drivers do not use environment variables.

    ¯\_(ツ)_/¯

    Monday, January 28, 2013 5:08 PM
  • The registry issue has been fixed by Microsoft a long time ago.  You do not need to be concerned about this.  CAll Nessus and tell them it is a false detection.  They will tell you how to fix this and will update their tool.

    If you insist on this exercise then use Group Policy to alter the registry.

    This is not a scripting issue. 

    Someone should move this to the off-topic forum.


    ¯\_(ツ)_/¯

    • Marked as answer by mjocasio23 Monday, January 28, 2013 6:30 PM
    Monday, January 28, 2013 5:12 PM
  • thank you for the tutorial........


    michael john ocasio

    Monday, January 28, 2013 6:31 PM
  • I think the issue I am seeing is that most who have blogged about this recently have some idea that it is the registries run string for a service or driver that causes this vulnerability. That may have been partly true years ago (W2K) before Microsoft changed the way these programs are launched.  The system protects itself from this kind of exploit.  The newer issues have been because services and programs from third parties have used unsafe Windows 95 style calling to 'CreateProcess' AND have stored the strings they use in INI files or in the registry. These strings, like the McAfee issue, are used to run external utilities.  These strings can be designed in such a way as to force a service or driver running at an elevated level to execute a rogue program.

    Fortunately  this is still not that easy and would require an Admin to allow an older driver or service to be installed and then allow a rogue program to alter that service or drivers environment (registry or INI file).

    The scanner scan only the older issue which has been fixed and displays false positives on purpose.  What it is intended to so is to have you determine if the service or driver you are using is subject to this vulnerability.  If it is you should remove it until the vendor fixes the vulnerability.  Microsoft has support documents telling vendors how to prevent stored strings from being used this way.  It has nothing to do with quotes and adding quotes is only a temporary patch. The best patch is to only allow signed software to be run on critical servers and, if possible, on user workstations.  Use only updated software from vendors and be careful when running as an admin.

    I never run as an admin and haven't for years.  I always download on a workstation whenever possible and then RDP into a standard user account.  I then use ‘RunAs’ to install the package.  This prevents the IE connection or any malware from gaining easy access to an admin session because IE is not run on the server or by an admin.  Some critical servers have IE disabled completely.

    Adding quotes to the strings will not protect you if the software is vulnerable.  The issue is not the in=place string but it is the ability of the string stored in a file or registry to start a program.

    Creating a file call C:\programs.exe may sound dangerous.  Try it with a copy of notepad renamed and then attempt to get it to launch.  You will find that it cannot be done.  The run string will fail since service and driver run strings are checked.

    I do not believe that there is any normal program today that exhibits this problem on Windows.  It is stil an issue on Macs and some Nix systems although I would think that that is patched.  Unfortunately Unix is not that easy to guard since so much of it is in shell scripts and string or text based files.

    I really think the best thing for you to do is to ask the developer of Nessus to check with Microsoft and remove the false detections.

    Good Luck.

     


    ¯\_(ツ)_/¯

    • Proposed as answer by RyanAK Thursday, April 4, 2013 3:38 PM
    • Unproposed as answer by RyanAK Thursday, April 4, 2013 3:39 PM
    Monday, January 28, 2013 6:58 PM
  • Hello,

    Let me start with: THIS IS NOT A FALSE POSITIVE

    I just tripped across this thread while trying to search for a COTS (Commercial Over the Shelf) software solution to this issue and this thread seems to ahve been steered incorrectly.

    First off this is absolutely without a doubt scripting related, it is not a Windows problem, it is a problem with poor program design, it is a real and definite threat to all Windows based computers, server or workstations, this has become an active topic of late because Nessus created a plugin to indenitfy it.

    The problem starts when a program is installed. If the imagepath string contains spaces and is not quoted appropropriately then a mailicious attacker could take advantage of it. For Example:

    I install ReallyCool Software Version 2. The imagepath is set to C:\Program Files\Really Cool Software\V2\RunMe.exe

    A malicious attack could be placed into the folder C:\Program Files  and if it was named really.exe anything that pointed to the imagepath would trigger C:\Program Files\really.exe if this was done with a privileged account then I own your computer. There are several other ways this can be used.

    How do you resolve this?

    The fix is easy, the deployment might not be. You will need to appropriately quote the imagepath so it would look like this: "C:\Program Files\Really Cool Software\V2\runMe.exe" notice it is surrounded by quotes. To deploy this fix to several thousand computers across an enterprise can be accomplished with a PowerShell Script.

    The really short version of that is: Identify the problem, take the results, quote them appropriately, send the results back to the computer in the form of a registry modification.

    Lots of logic gets builtin to that, but this is exactly what we are doing to resolve it and it works great. 6 hours of scripting and beating you head against the logic until you can find something that accounts for possibilities and handles them correctly if far faster than remoting into several thousand computers to manually change registry keys.

    There are other options as well, SCCM, GPO, and so on. Which is best for you? Your environment and circumstances will determine it.

    Thanks!

    • Edited by RyanAK Thursday, April 4, 2013 5:48 PM Copy paste failure
    Thursday, April 4, 2013 5:29 PM
  • You miss the point.  This has been patched and cannot happen on modern system unless you already have been hacked in some unknown way.

    It is NOT necessary to do this.  Most scanners no longer report this vulnerability if the OS is post XP SP2 I believe.  Nessus may be patched since this thread was started.

    This thread is also closed.  If you still have concerns then can you start a new topic.


    ¯\_(ツ)_/¯

    Thursday, April 4, 2013 5:54 PM
  • You could not be more wrong.

    Are you intentionally attempting to create vulnerable systems?

    Don't believe me, look for yourself:

    NVidia Vulnerabilities March 21,2013

    Symantec Vulnerability updated March 4, 2013

    McAffee Vulnerability March 20, 2013

    Common Exploits September 15, 2012

    Tennable makers of Nessus March 4, 2013

    Common Weakness Enumeration

    And the list goes on.... and way back in time. This has been an issue for a very long time. 

    If you choose to bury your head in the sand that is fine, please do not try to bring others with you.

    Thursday, April 4, 2013 8:19 PM
  • I don't want to be that guy but (oh hell yes I do)... You can easily replicate this vulnerability exists.  You seem to be focused on the fact that Microsoft "fixed" this.  I think what you mean is Microsoft "fixed" its own services by quoting them all.  If a service (any service) is installed into a path that contains spaces, any space and appropriately named executable can exploit the handling of paths to escalate.  The way you fix this is to "quote" the paths.  Microsoft has notified developers of the importance of doing this, but will not release a "fix" that goes and modifies the service calls for third party services.  Its up to the third parties to not let their software introduce this vulnerability into Windows.  Spoiler Alert:  Insisting this vulnerability does not exist does not make it so.

    This vulnerability does not allow remote exploitation, but a local user could use this to escalate their "WINDOWS" permissions through poor coding on the part of "THIRD PARTY" developers.  Everyone is at fault here.  Microsoft for poor handling of the service path, and the developers for not heeding the warning.

    To replicate this for your self, do the following: (The following is done on an up to date to date copy of Windows 7 Enterprise)

    Copy the PowerShell executable to your desktop.  Create one copy called CPS1.exe and another called call.exe

    Create a folder structure under program files (or program files (x86)) that looks like this: C:\Program Files (x86)\Test Space Service\Call Program

    In the "call program" folder, copy CPS1.exe

    On an administrative command prompt, run SC Create "Test Space" binPath= "C:\Program Files (x86)\Test Space Service\Call Program\CPS1.exe"

    Now, open REGEDIT and navigate to HKLM\System\CurrentControlSet\services\Test Space - you'll find this value:

    ImagePath REG_EXPAND_SZ C:\Program Files (x86)\Test Space Service\Call Program\CPS1.exe

    There are no quotes.  Start the task manager and view processes for all users.  Open the services.msc console and START the Test Space service.  You will see CPS1 show up as a system service.

    Kill CPS1, copy the call.exe into the folder above it.  This path is C:\Program Files (x86)\Test Space Service\call.exe

    Now start the service again, you will see call.exe start with system privileges.  This demonstrates that this vulnerability DOES IN FACT ALLOW escalation if the developer does not quote their service call paths.  Kill call.exe

    Now, go back into the registry and change the data for the ImagePath value to "C:\Program Files (x86)\Test Space Service\Call Program\CPS1.exe" (with the quotes).

    Go back into the service console and start the service again.  You will now see CPS1.exe started with system privileges, because the WINDOWS API responsible for managing this service call treated the path as ONE value, instead of interpreting the space on the lack of an appropriately named executable.

    Thanks for playing.

    To the original poster's question.  YES you can script resolution of this, but it is something you will have to run again and again.  You can utilize the REG command to export a list of imagepaths and parse them in your favorite scripting language to find spaces without quotes and correct them.  

    I wrote a script that does this for 4000 computers in about 4 hours.  Nessus tells me when I need to re-run it and against who.

    psuedo-code (I write in powershell)

    $results = Reg Query "\\$computername\HKLM\SYSTEM\CurrentControlSet\Services\" /v Imagepath /s 2>$nul

    if $null - offline

    else

    for each $result

    if contains "ImagePath"

    Cut up result string to obtain just the path.  Look one element backwards to find the associated key ($pathname)

    if $string contains " "

    if $string !contains ' " '

    $badvalue = $string

    $goodvalue = Fix string w/ escape characters (i.e $badvalue.replace('"\"' + $badvalue + '"\"')

    $addstring = REG ADD '"\\' + $computername + "\" + $pathname + '" /v ImagePath /t REG_EXPAND_SX /d' + $addstring + '" /f

    break

    The escape character syntax can get a little complicated.  You also have to control for services with arguments.  It might be more productive for you, depending on your programming skill, to simply write one that finds and spits out all the vulnerable paths so you can manually create the fixed strings.  Then just script in a batch file with that REG ADD statement.  I automated it and I had to go back and fix 4 of 600 vulnerable paths, which I don't consider that bad of a margin of error.




    • Proposed as answer by RyanAK Thursday, April 4, 2013 8:31 PM
    Thursday, April 4, 2013 8:28 PM
  • I will sit down this weekend and write something to fix this.  I will update my post above with a link when complete.
    Thursday, April 4, 2013 8:44 PM
  • The problems you posted can only be fixed by patching the affected software.  It is stated very clearly in the notices.


    ¯\_(ツ)_/¯

    Thursday, April 4, 2013 9:50 PM
  • And the change the vendor makes to correct the problem is to "quote" the service path.  If I have software that prohibits me from upgrading, or compatibility issues with drivers, I can self-resolve this vulnerability by quoting the service path manually, as I demonstrated in my post.  I demonstrated how the vulnerable path is created, how it is exploited, and how it is no longer vulnerable after I manually correct it.  If really necessary, you can examine the service hive and find a legitimate vulnerable service, and exploit it yourself to prove it.  If you have Symantec installed SNAC is a good place to start.

    Also, anyone with Dell latitudes, all your wifi drivers are vulnerable to this, out of the box.  The vulnerability exists for people who already have local access and inappropriate access to installation directories.  This could also be exploited through mom and pop software that installs to non-program files directories that users are not abstracted from by UAC.  Or those legacy programs that get shimmed to run as administrator, giving the user access to filesystem areas they do not normally have.  Write your own service that spawns you an interactive powershell prompt and you now have admin access on that shell.  This is kindof a big deal.

    This vulnerability allows local malicious users to exploit vulnerabilities in Windows that are EXPOSED by third party vendors.  Microsoft's solution instead of changing the way the API is handled so that you are required to quote service paths, is to tell everyone to quote them and leave it alone (probably because it would have broken so many applications).

    Since this is a scripting forum, I also went ahead and answered the OP's question about scripting, since the idea would be that if I can manually correct it (And I proved that I could), it stands to reason I can automate that with the right logic sequence.


    Its pretty much the same as taking a car to a mechanic to change the oil, or changing it yourself.  The dealer will swear up and down the only way to fix it is to let them do it, but its still nonsense.  Take some ownership over your environment.  We're supposed to be administrators right?  I don't get paid to point the finger.  I get paid to understand the problem and fix it.  Clearly he is in a similar situation given his initial post.


    Thursday, April 4, 2013 10:52 PM
  • And the change the vendor makes to correct the problem is to "quote" the service path.  If I have software that prohibits me from upgrading, or compatibility issues with drivers, I can self-resolve this vulnerability by quoting the service path manually, as I demonstrated in my post.  I demonstrated how the vulnerable path is created, how it is exploited, and how it is no longer vulnerable after I manually correct it.  If really necessary, you can examine the service hive and find a legitimate vulnerable service, and exploit it yourself to prove it.  If you have Symantec installed SNAC is a good place to start.

    Also, anyone with Dell latitudes, all your wifi drivers are vulnerable to this, out of the box.  The vulnerability exists for people who already have local access and inappropriate access to installation directories.  This could also be exploited through mom and pop software that installs to non-program files directories that users are not abstracted from by UAC.  Or those legacy programs that get shimmed to run as administrator, giving the user access to filesystem areas they do not normally have.  Write your own service that spawns you an interactive powershell prompt and you now have admin access on that shell.  This is kindof a big deal.

    This vulnerability allows local malicious users to exploit vulnerabilities in Windows that are EXPOSED by third party vendors.  Microsoft's solution instead of changing the way the API is handled so that you are required to quote service paths, is to tell everyone to quote them and leave it alone (probably because it would have broken so many applications).

    Since this is a scripting forum, I also went ahead and answered the OP's question about scripting, since the idea would be that if I can manually correct it (And I proved that I could), it stands to reason I can automate that with the right logic sequence.


    Its pretty much the same as taking a car to a mechanic to change the oil, or changing it yourself.  The dealer will swear up and down the only way to fix it is to let them do it, but its still nonsense.  Take some ownership over your environment.  We're supposed to be administrators right?  I don't get paid to point the finger.  I get paid to understand the problem and fix it.  Clearly he is in a similar situation given his initial post.


    You are recovering the territory of this thread shich was closed a long tim ago.  PLease read the whole content.  It will save a lot of wasted time.

    If you actually track down what was done to fix this you will find that the WIndows OS has been altered to prevent this from happening.  The fact that some groups insist on posting it as a problem is not something that I can change.  If you actually understand what causes the vulnerability you will understand why it no longer exisits.


    ¯\_(ツ)_/¯

    Thursday, April 4, 2013 10:58 PM
  • You can resolve the vulnerability by adding the quotation to the imagepath string yourself. This is not a permanent fix of course and the correct action is for the software provider to patch or otherwise fix the problem with their software.

    But you are missing my point:

    "The registry issue has been fixed by Microsoft a long time ago. You do not need to be concerned about this. CAll Nessus and tell them it is a false detection. They will tell you how to fix this and will update their tool. If you insist on this exercise then use Group Policy to alter the registry. This is not a scripting issue. Someone should move this to the off-topic forum. "

    As stated this is completely false.

    • Microsoft fixed all of their applications and nothing else.
    • You should be concerned at a minimum contact your software vendors and find out if they are going to fix it.
    • Nessus does not need to be updated.
    • GPO can be used but is still a temporary fix
    • This can also be temporarily fixed/patched with a PowerShell script

    The original post and where it appears that the original poster tried to bring you back to was how could he change the registry to point to the shortened path that didn't contain the space to remediate the threat. Could he use a script to do it and could he use WSUS or some other method to deploy it.

    The absolute answer is stop using the software until the vendor fixes it. This is not always possible or the best answer for several different reasons. In the case of Symantec for example. Imagine you have SEP (Symantec Endpoint Protection) deployed to 10,000 computers, a patch comes out that you must apply otherwise the clients will fail to process updated virus definitions. You run it through an accellerated vetting process and deploy, only to find out afterwards that Symantec made a msitake and now the service path has an unquoted imagepath string in the registry that could be compromised.

    Better yet, you have a CEO who likes this program and it has an unquoted service path, you tell the CEO that he shouldn't use it becuase it isn't secure, he tells you make it secure, you contact the vendor, they tell you to pound sand, now what?

    You are left with a couple of choices, one of the answers is PowerShell and a script to rapidly remediate the problem until Symantec releases the patch/update. I would not create a script to try and use the abbreviated value, I would recommend adding the quotes, it is less work and cleaner. I also would not try to changed the environmental values this can have severe unintended consquences.

    "You miss the point. This has been patched and cannot happen on modern system unless you already have been hacked in some unknown way."

    jrv,

    Your responses to this thread are misleading and generally false. Respectfully, I am certain you have lots of knowledge about a great many things especially with scripting and windows in general but in this instance you clearly do not understand the issue, operating in an Enterprise environment or how this vulnerability affects the Windows operating system.  It is certainly not patched out and is just as valid today as it was 10 years ago. You are correct, that Microsoft no longer has the problem because they follow their own best practices and quote all of their imagepath strings but can you show me an office that only has Microsoft software installed?

    Thanks!

    Thursday, April 4, 2013 11:18 PM
  • And the change the vendor makes to correct the problem is to "quote" the service path.  If I have software that prohibits me from upgrading, or compatibility issues with drivers, I can self-resolve this vulnerability by quoting the service path manually, as I demonstrated in my post.  I demonstrated how the vulnerable path is created, how it is exploited, and how it is no longer vulnerable after I manually correct it.  If really necessary, you can examine the service hive and find a legitimate vulnerable service, and exploit it yourself to prove it.  If you have Symantec installed SNAC is a good place to start.

    Also, anyone with Dell latitudes, all your wifi drivers are vulnerable to this, out of the box.  The vulnerability exists for people who already have local access and inappropriate access to installation directories.  This could also be exploited through mom and pop software that installs to non-program files directories that users are not abstracted from by UAC.  Or those legacy programs that get shimmed to run as administrator, giving the user access to filesystem areas they do not normally have.  Write your own service that spawns you an interactive powershell prompt and you now have admin access on that shell.  This is kindof a big deal.

    This vulnerability allows local malicious users to exploit vulnerabilities in Windows that are EXPOSED by third party vendors.  Microsoft's solution instead of changing the way the API is handled so that you are required to quote service paths, is to tell everyone to quote them and leave it alone (probably because it would have broken so many applications).

    Since this is a scripting forum, I also went ahead and answered the OP's question about scripting, since the idea would be that if I can manually correct it (And I proved that I could), it stands to reason I can automate that with the right logic sequence.


    Its pretty much the same as taking a car to a mechanic to change the oil, or changing it yourself.  The dealer will swear up and down the only way to fix it is to let them do it, but its still nonsense.  Take some ownership over your environment.  We're supposed to be administrators right?  I don't get paid to point the finger.  I get paid to understand the problem and fix it.  Clearly he is in a similar situation given his initial post.


    You are recovering the territory of this thread shich was closed a long tim ago.  PLease read the whole content.  It will save a lot of wasted time.

    If you actually track down what was done to fix this you will find that the WIndows OS has been altered to prevent this from happening.  The fact that some groups insist on posting it as a problem is not something that I can change.  If you actually understand what causes the vulnerability you will understand why it no longer exisits.


    ¯\_(ツ)_/¯

    Really? Stop while you are behind... Speaking strcitly about Windows and Microsoft products, then OK maybe, oh wait I can take any of a half dozen microsoft products and turn them into a service and exploit this. Not exactly using it as intended, but not completely patched out and incapable of happening.

    IT Conversation Rules

    1. Never speak in absolutes
    2. See rule 1
    3. That is all

    Enjoy!

    Thursday, April 4, 2013 11:26 PM
  • JRV,

    1) This thread was opened less than 90 days ago.  That's considered "old"?  Windows fixed its own services (years ago), but continues to refuse to support third party applications on the grounds that they do not want to be responsible for breaking other applications (which they are accused of enough as it is).  It's only a big deal now because a tool in common use for security remediation can now report on it, which is attracting a lot of attention.

    2) It was marked answered but your answer was totally and completely incorrect, so the question is still valid, for the OP and for anyone else researching this problem.  For reference, I did read the whole content and found you provided factually incorrect information and no documentation to support your claims.

    3) Further, I demonstrated the problem still exists on an up to date system, and there are reports from some vendors who are now aware and are fixing this issue, (because Nessus exposed it for many a few months ago) but they are not the only vulnerable vendors.  So this issue will still exist for others as well.  Intel has drivers vulnerable to this, Symantec does, Dell does, and a whole host of other software applications.  The answer is absolutely NOT "wait until every vendor patches its software" and be vulnerable in the mean time.

    4) You have provided absolutely no documentation to back up your claim that this doesn't exist.  If Microsoft fixed it, post a KB that says this problem no longer exists.  Ancillary cut and paste from Tennable's website saying that sometimes false positives happen is NOT documentation.

    5) In the face of overwhelming supporting documentation and a real life example that you can try on your own, you continue to insist the problem doesn't exist.  If you followed my instructions, you would see that it in fact still does.  The ostrich defense does not protect your system or the systems you are responsible for.  The OP was looking for a way to secure his environment, and you managed to convince him the problem does not exist or that he was otherwise unqualified to make the correction.  

    Big help guy.  I would suggest that you read up on the topic and do some of your own testing before answering questions like this.  It will save a lot of wasted time and help a lot more people.


    Thursday, April 4, 2013 11:28 PM
  • Stop! I have been thought this nonsense before and have no intention of having another stupid argument over nothing.  Post you fix and be happy.


    ¯\_(ツ)_/¯

    Thursday, April 4, 2013 11:41 PM
  • Stop! I have been thought this nonsense before and have no intention of having another stupid argument over nothing.  Post you fix and be happy.


    ¯\_(ツ)_/¯

    I apologize if I went a little overboard, but understand that you should not put opinion out as fact. It would appear you "tech talked" the original poster into thinking that Nessus was giving false positives. The fact is Nessus can, does and will give good valid results for unquoted service paths. Nessus is of course not perfect but your reasoning for a false positive is severly flawed.


    Your assumptions in this case are invalid and inaccurate. Your comments to the effect of, this can not happen in a modern operating system Nessus must be wrong are slanderous and borderline libel. They certainly do not contribute to this post or Technet at large.

    Friday, April 5, 2013 12:13 AM
  • I am going to give JRC the benefit of the doubt and state that RyanAK and JRC are right - JVC may be interpeting this as a 'false positive' since it's how Windows is built and is thus 'by design' or 'as intended' however the RyanAK is correct in that this is a vulnerability. This vulnerability is created when developers/vendors do not properly encapsulate their service paths in quotes WHEN that path contains a space.

    Bottom line - If this shows up as a finding with your vulnerability scanner then it is NOT A FALSE POSITIVE and YOU ARE VULNERABLE. You should review your service paths to identify offenders and determine the appropriate action (accept or mitigate/fix).

    A quick example of a vulnerable and not vulnerable service entry..

    A vulnerable service entry: c:\program files\vendor\workstation client.exe

    Same entry but NOT vulnerable: "c:\program files\vendor\workstation client.exe"

    Notice the quotes... without the quotes as windows processes the path to the executable it doesn't know whether c:\program is an executable you're trying to pass variables to (meaning that Windows first looks to see if there is a c:\program.exe and if there is then it will run it in this way... "c:\program.exe" files\vendor\workstation client.exe   ... it takes the path after the first space as variable/arguments.

    Try it yourself in a LAB... find a vulnerable service on your machine, and put any exe where the first space is and rename it to match part of the path name - so if your vulnerable service path is like this c:\program files\vendor\workstation client.exe then you would put a *.exe file in the root of c:\ and name it 'program.exe' and then stop/restart that service.. it will run the executable and not the actual service.

    Anyway... typing this up quick but I hope that clarifies. This is a real vulnerability due to vendor/developer lack of attention to detail. Ultimate vendor's should fix this in their own applications to have correct paths but if not you can work around it manually by adding quotes to service paths yourself.


    • Edited by jgrose Friday, April 5, 2013 4:58 PM
    • Proposed as answer by jgrose Friday, April 5, 2013 4:59 PM
    • Unproposed as answer by jgrose Friday, April 5, 2013 5:03 PM
    Friday, April 5, 2013 4:55 PM
  • Joshua - not what I posted at all.

    The issue was fixed in the kernel API of Windows by changing how the strings are parsed.

    Think about it.  Leaving a hole like that up to the vendors and developers to patch does not make any sense.  Read the KBs I posted. Microsoft is clear about that issue as being fixed.


    ¯\_(ツ)_/¯

    Friday, April 5, 2013 5:07 PM
  • Try it yourself in a LAB... find a vulnerable service on your machine, and put any exe where the first space is and rename it to match part of the path name - so if your vulnerable service path is like this c:\program files\vendor\workstation client.exe then you would put a *.exe file in the root of c:\ and name it 'program.exe' and then stop/restart that service.. it will run the executable and not the actual service.



    That does not work on any of my servers.

    ¯\_(ツ)_/¯

    Friday, April 5, 2013 5:12 PM
  • The C:\program.exe is the only one that has been "patched" if you can call it that. Microsoft looks for program.exe at startup and warns you about it, and that can be turned off with a simple registry edit. If the change is made after startup and a service is started manually, C:\program.exe still works.

    I absolutely agree with you that its stupid that microsoft would leave a hole like this, but the fact of the matter is they did. You just have to find the right kind of key to exploit it.

    I am going to write a couple of scripts to find and fix these kinds of keys this weekend.

    I have validated the vulnerability exists and works as an escalation path on Windows 7, Server 2008R2, and Server 2003.

    After I found this discussion Thursday, I did a lab write up for it here on a new blog Ryan and I have recently started.

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

    I show how to replicate it on an up to date Windows 7 installation (procedure is the same for all longhorn kernals), and also link to a number of articles that talk about where this applies and where it doesn't, as well as why you can't user certain programs (i.e. notepad.exe) to show it exists.

    The problem is that the ImagePath value is read from the registry and parsed from there (dynamically at run time). Without the quotes, Windows absolutely looks for them in order. Services that are vulnerable and not being exploited are only that way because there's not an executable taking advantage of the path. And this isn't just a startup issue. This could also exploit on demand services that are kicked off by other services that run at startup (scan engines, etc) Microsoft published services have been fixed, by quoting the call. You can verify this at HKLM\SYSTEM\CurrentControlSet\Services and looking through the various keys there. This is the location Windows pulls the service path from.


    /Jeff

    • Edited by AKJeff Saturday, April 6, 2013 7:40 AM more format fail...
    Saturday, April 6, 2013 7:36 AM
  • Answer a simple question:  What account owns the root of the C drive on Windows 8?  Why is Windows 8 set up this way?


    ¯\_(ツ)_/¯

    Saturday, April 6, 2013 11:41 AM
  • I do not run Windows 8 or have a copy readily available at the moment.  But I'm going to guess the Trusted Installer or SYSTEM.  But you've peaked my interest so I'm going to deploy a Windows 8 VM and test this.  Even if there is a new owner for the root of C, I can exploit this in the root of Program File, as well as vendor folders beneath there.  Let's also consider the number of legacy programs still running out there that are under administrator context (and therefore can still move/edit/create files). 

    As an admin, I can say all day that running legacy programs as admin is a security breach, but if that program makes the company money I'm going to lose.  This is extraordinarily easy to exploit, and also extraordinarily easy to remediate.  So why not fix it?

    Frankly I hope it is fixed in Windows 8.  The fix is to STOP PARSING these paths and read them literally.

    Plus, what percentage of the market is Windows 8?  This vulnerability has been around since 2000.  Microsoft put in a check for C:\program.exe that only runs at startup.  Hardly a solution.  If Windows 8 fixes it, great.  But that doesn't change the fact that admins are responsible for a whole lot of vulnerable, non-windows 8 computers. 


    • Edited by AKJeff Saturday, April 6, 2013 7:54 PM formatting (again)
    Saturday, April 6, 2013 7:54 PM
  • I have posted a series of articles on my blog about this vulnerability, how it works (demonstrated/validated), as well as a series of scripts that will scan for it and fix it automatically if you want.

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

    The trackbacks show Finding/Fixing parts 1, 2, and 3.

    http://www.ryanandjeffshow.com/blog/2013/04/07/finding-and-fixing-unquoted-service-paths-pt1/

    http://www.ryanandjeffshow.com/blog/2013/04/07/finding-and-fixing-unquoted-service-paths-pt2/

    http://www.ryanandjeffshow.com/blog/2013/04/07/finding-and-fixing-unquoted-service-paths-pt3/

    One script gets the paths from a local machine, or collection of machines specified on the shell, in a text file, or from the pipeline.  The 2nd script examines all the objects that come out of the 1st script to determine which ones are vulnerable and recommend the fixed path.  The 3rd script takes the objects out of the 2nd script and applies them via REG ADD (which is nice because it works in non-PowerShell environments as well as environments where PSRemoting isn't enabled)

    The only outstanding problem I can find is handling paths with arguments that aren't flagged.  i.e "C:\program files\program.exe argument"  Check your results but in testing against hundreds of computers in the past few months, I've only found 4 total paths that exhibited this problem (on Database servers with SQL and Postgre)


    • Edited by AKJeff Sunday, April 7, 2013 6:14 AM fixed links
    • Proposed as answer by RyanAK Monday, April 8, 2013 5:49 AM
    Sunday, April 7, 2013 5:28 AM
  • As the Original Poster I hope you get a chance to come back and read this thread. If I am understanding your thought process you were thinking to try and force the imagepath values to use the truncated C:\PROGRA~1\ by modifying the environmental variable, and deploy it via WSUS or other means. Not 100% sure that is even possible, my opinion is; It is an interesting idea on how to resolve the issue, wrong place(s). See the rest of the thread, short version is

    • Yes, it is a vulnerability
    • Contact your vendors and request a patch
    • In the mean time, you should add the quotes
    • PowerShell is your friend, it can get the job done

    Thanks!

    Monday, April 8, 2013 5:27 AM
  • I am sorry I missed where Microsoft posted that? and how NIST, MacAffe, Symantec, NVIDIA and everyone else just has it wrong?
    Monday, April 8, 2013 5:31 AM
  • Try it yourself in a LAB... find a vulnerable service on your machine, and put any exe where the first space is and rename it to match part of the path name - so if your vulnerable service path is like this c:\program files\vendor\workstation client.exe then you would put a *.exe file in the root of c:\ and name it 'program.exe' and then stop/restart that service.. it will run the executable and not the actual service.



    That does not work on any of my servers.

    ¯\_(ツ)_/¯

    Did you try notepad.exe renamed again? Won't work, it can't run as a service unquoted service path or not. Try powershell.exe renamed it will at least launch long enough to see that the problem is there.
    Monday, April 8, 2013 5:33 AM
  • For those of you wondering, this also applied on Windows 8 Pro.

    So I just finished deploying a brand new Windows 8 VM.  I ran my Get-SVC/Find-SVC scripts and got one result...

    ComputerName : Win8VM1
    Status       : Retrieved
    Key          : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinDefend
    ImagePath    : %ProgramFiles%\Windows Defender\MsMpEng.exe
    BadKey       : Yes
    FixedKey     : "%ProgramFiles%\Windows Defender\MsMpEng.exe"

    I went and pulled a copy of the powershell executable and dropped it in the root of Program Files as Windows.exe to attempt to exploit this path.  I was not able to successfully launch powershell under the elevated context as I did in Windows 7 (bombed out with the didn't respond correctly error, which also happened in Windows 7 but took longer).

    However, this did prevent defender from coming back, so I could have at least disrupted anti-virus protection on reboot (Defender is auto start).  

    I suspect, but am unable to confirm at the moment, that if I had a legitimate program that could run as a background service, it would have elevated here.

    And of all the things that could have been deployed with Win8 and be out of the box vulnerable to this...it had to be Windows Defender...  My fix script was able to successfully remediate the vulnerability without issue.  This does however confirm that this vulnerability still exists in Windows 8, and it is on the developer to make sure their services are deployed correctly.

    Monday, April 8, 2013 5:34 AM
  • Answer a simple question:  What account owns the root of the C drive on Windows 8?  Why is Windows 8 set up this way?


    ¯\_(ツ)_/¯

    Ok I'll bite, I am not running Windows 8 yet, but I will see if it works there as well. If it does have the same issue, I might just make a video about it ;) Might do it either which way, IE here is Windows 7 note the problem, here is Windows 8 note it doesn't have a problem.

    On a side note: check this older article out:

    http://packetstormsecurity.com/files/58954/TISA-2007-09-Public.txt


    They state:

    Limitations:
    ============
    This conditions are difficult, if not impossible, to exploit on Windows XP/2003/Vista. By default these operating systems implement restrictive file permission policy. Exploitation is limited to Microsoft Windows 2000 and to misconfigured ACLs cases.

    I would say difficult for certain not so close to impossible. It is a vulnerability right? So we are talking about a compromised system or compromising a system. I would say you are pretty safe from most browser exploits, but a crafty installer could give you a bigger payload than you expect.

    Thanks!

    Monday, April 8, 2013 5:47 AM
  • Also Let's not forget the following cases...

    • Home users usually run under admin on their OEM computers
    • Many places have turned off UAC and shimmed/configured applications to run as admin for compatibility purposes (especially legacy XP stuff)
    • Having UAC off allows that exploit above to take place under XP/Vista/7

    And In windows 8, I was at least able to shut down defender via this approach.  I didn't have a legitimate service to run to verify escalation, but at that point it's still a problem either way.

    Tuesday, April 9, 2013 11:02 PM
  • We are getting bothered with this as well, and I agree, it is not fixed.  We have hundreds of servers and many more workstations reporting the vulnerability and the only fix 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 9:35 PM
  • You realize of course that this thread has been closed for a very log time.

    It you have an issue with security I highly recommend that you post in the security forum for the fixes you need.

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserversecurity


    ¯\_(ツ)_/¯

    Monday, September 16, 2013 9:46 PM
  • You realize of course that this thread has been closed for a very log time.

    It you have an issue with security I highly recommend that you post in the security forum for the fixes you need.


    ¯\_(ツ)_/¯

    Not sure what "closed" means to you...  probably more like "not my problem".  That may be true, but this is the best discussion of a still existing problem I have found.  Maybe you should invlove someone in the Security team in support of your customers?  Your tag is appropriate - ¯\_(ツ)_/¯

    Monday, September 16, 2013 10:13 PM
  • If you look very closely you will see that the thread is marked as answered.

    Please check the posting guidelines.  If you have issues with scripting that are related to an answered thread then please start a new question.  You can post a link back to this thread for reference if it is useful.

    I still suggest that a post in the security forum would get you a better answer.  The method posted here is all that can be done with a script.  Software installers frequently rewrite these keys and in many cases the fix may break the software.  The security people can tell you how they currently believe you should react to this issue.  Scripting people are not the experts in this area.


    ¯\_(ツ)_/¯

    Monday, September 16, 2013 10:18 PM