Hell osquery team,
As per facebook security team, they (Teddy) recommended to create issue here.
Title
Privilege Escalation Bug in Osquery 4.2.0 (windows) via Dll Hijacking
Vuln Type
Code Execution
Product Area
Open Source (e.g. HHVM)
Description/Impact
Complete Details
[
Vulnerability Type: Privilege Escalation via DLL Preloading
DLL: zlib1.dll
Affected process: osqueryd.exe
Attack Vector: local
Description:
When osquery service is start, osqueryd.exe process is tries to load the zlib1.dll from user writeable directories and then drop or create malicious dll to writeable folder (C:python27).
Reboot (because of osquery service is auto start after rebooting) or restart the service. Malicious dll "zlib1.dll" will be loaded by that osqueryd.exe .
]
Impact
[Privilege escalation: User can executed as NT AUTHORITYSYSTEM
This occurs when an application fails to resolve a DLL because the DLL does not exist in the specified path or search directories. If this happens, a malicious Dll with the same name can be placed in the specified path directory leading to remote code execution as system user.
]
Repro Steps
OS: [Tested on Windows x64 1909]
Description: [When osquery service is start, osqueryd.exe process is tries to load the zlib1.dll from user writeable directories and then drop or create malicious dll to writeable folder (C:python27). Reboot (because of osquery service is auto start after rebooting) or restart the service. Malicious dll "zlib1.dll" will be loaded by that osqueryd.exe]
Steps
[Each step should be 1-2 sentences. Having many steps is fine.]
Filter the processes of osqueryd.exe with procmon (image: osquery1.jpg)

Create custom payload dll (image: osquery2.jpg)

Create batch file to execute which include in payload dll (image: osquery3.jpg)

Then,create or drop payload dll to writable folder C:python27 (image: osquery4.jpg)

Check the file that doesn't exist by default (image: osquery5.jpg)

Then reboot pc ( It's mean user haven't permission to start service. Reboot since osqueryd service is auto). or restart the service (for testing with admin). After reboot or restart the service, Malicious dll "zlib1.dll" has been loaded and payload will execute. (image: osquery6.jpg)

payload dll executed as a command "cmd.exe /c C:tempexec.bat" and batch file executed "whoami" and print out to C:osquery_EOP.txt (image: osquery7.jpg)
 are allowed if the name is a KnownDLLs entry
Interested in everyone's opinion on how this looks like!
About 4.: I've found that it's openssl that tries to load zlib1.dll, specifically because we ask it to here: https://github.com/osquery/osquery/blob/f54d904b21158fc89e0e5de3cc25337468b71c61/libraries/cmake/formula/openssl/CMakeLists.txt#L20
This has been carried over from the old brew formula scripts; as far as I can understand zlib in openssl is only used to enable SSL/TLS compression, which is also subject to information leak attacks.
Given that browsers around 2012 started disabling compression for that reason, I suggest we do the same and remove that and possibly other problems altogether.
I'll check other libraries too.
What do you think?
let me know you guys recognize as is this security issue or not? Can i get CVE id for this bug ?
My recommendation is to statically link openssl (and/or zlib) into osquery vs using them as DLLs.
So is this resolved now? We can close?
Let me know How can I request CVE id for this bug?
I think the specific issue is resolved but I think we can do more to prevent these bugs in the future. For example I read LOAD_LIBRARY_SEARCH_SYSTEM32 might be a restriction we can apply to LoadLibrary usage.
Let me know How can I request CVE id for this bug?
Yea, @theopolis mentioned that Facebook used to be the CVE Numbering Authority (CNA) that could allocate a CVE ID for osquery security bugs. But, now that the project is transitioned to Linux Foundation, which is not a CNA, I think the way to apply for a CVE is to apply through Mitre here: https://cveform.mitre.org/
If anyone else knows differently, please correct me but I think that is the process.
If anyone else knows differently, please correct me but I think that is the process.
I think we want to use GitHub's Security Advisory feature, https://help.github.com/en/github/managing-security-vulnerabilities/about-github-security-advisories#cve-identification-numbers which I can fill out later tonight or tomorrow.
I requested the CVE in a GitHub advisory, will let you know how it goes.
Their docs say
Assigning a CVE identification number generally takes 72 hours or less.
Did they respond, or no
This area of our repo, is it manually updated, or automatically via this submission process? https://github.com/osquery/osquery/security/advisories
Yeap, sorry for the delay, this was assigned CVE-2020-11081.
I'll close this issue out since we've fixed the issue. The PR and advisory will be published and referenced in the 4.4.0 release.
Hello @theopolis ,
any PR and advisory for 4.4.0 ? I didn't see that CVE ID.
This should be visible at https://github.com/osquery/osquery/security/advisories/GHSA-2xwp-8fv7-c5pm
Most helpful comment
About 4.: I've found that it's openssl that tries to load zlib1.dll, specifically because we ask it to here: https://github.com/osquery/osquery/blob/f54d904b21158fc89e0e5de3cc25337468b71c61/libraries/cmake/formula/openssl/CMakeLists.txt#L20
This has been carried over from the old brew formula scripts; as far as I can understand zlib in openssl is only used to enable SSL/TLS compression, which is also subject to information leak attacks.
Given that browsers around 2012 started disabling compression for that reason, I suggest we do the same and remove that and possibly other problems altogether.
I'll check other libraries too.
What do you think?