VMware ThinApp suffered from a dll hijacking vulnerability.
advisories | CVE-2021-22000
A few months ago I disclosed IBM(R) Db2(R) Windows client DLL
Hijacking Vulnerability(0day) I found:
https://seclists.org/fulldisclosure/2021/Feb/73
In that post I mentioned the vulnerability did not get fully patched.
After I told IBM on hackerone that I disclosed it, hackerone asked me
to delete the post, IBM apologized and fully patched the
vulnerability.
But this is not the point today. I found a similar problem in
VMware-ThinApp-Enterprise-5.2.9-17340778.exe.
After install the software create C:DummyTLS and rename a dll you
want to load to dummyTLS.dll and put it to C:DummyTLSdummyTLS.dll.
Run "C:Program Files (x86)VMwareVMware ThinAppSetup Capture.exe"
and C:DummyTLSdummyTLS.dll will be loaded.
(other exe like log_monitor.exe/snapshot.exe vulnerable too).
This is also because they use code like:
LoadLibraryExW(L"DummyTLSdummyTLS.dll", 0, 0);
In short, Windows will treat relative path in LoadLibrary(and many
other functions) as the path rooted relative to the current disk
designator.
Let us look into code in ntdll.dll. The logic here is:
KernelBase!LoadLibraryExW->ntdll!LdrpLoadDll->ntdll!LdrpPreprocessDllName.
In LdrpPreprocessDllName after calling
RtlDetermineDosPathNameType_Ustr it will return 4(RtlPathTypeRooted).
And after calling LdrpGetFullPath we get "C:DummyTLSdummyTLS.dll"!
You should not call LoadLibrary with the relative path. In fact, using
relative path is dangerous in many cases.
This was fixed in 2021-07-13 as CVE-2021-22000 and the advisory is
here : https://www.vmware.com/security/advisories/VMSA-2021-0015.html.
For these vulnerabilities I will post a summary at https://houjingyi233.com.
