OSSEC-HIDS Security Audit Findings

[cpu]

Hi folks,

I spent some free time recently auditing OSSEC. I was primarily focused on a threat model where an OSSEC agent is compromised (e.g. the agent key and assoc. counters are known) and used to attack the OSSEC server (primarily ossec-remoted and ossec-analysisd). Given the problem domain of OSSEC and HIDS generally I think this is fair game. Since these are post-auth bugs and there isn't guidance on vulnerability disclosure in the README I thought it was acceptable to post information full-disclosure to the repo.

I found a handful of bugs and have done my best to address the root cause, the affected versions, the impact and potential fixes in the issues I've filed. I will request CVEs for the security relevant bugs later on.

In terms of rough risk levels I'd categorize the findings as follows:

Informational:

• os_regex-empty-pcre2-off-by-one - os_regex: OSPcre2_Compile off-by-one heap overflow compiling empty regex. #1811 (Edit: now fixed by os_regex: refuse to compile empty PCRE2 pattern. #1826)
• rootcheck-check-rc-if-shell-injection-risk - rootcheck: risk of shell metachar injection in check-rc-if. #1812

Low:

• analysisd-syscheck-decoder-msg-location-path-injection (CVE-2020-8446) - CVE-2020-8446: analysisd: syscheck decoder location path injection. #1813
• analysisd-OS_CleanMSG-allows-control-chars-in-msg (CVE-2020-8445) - CVE-2020-8445: analysisd: OS_CleanMSG allows control characters in msg. #1814
• analysisd-OS_CleanMSG-bad-location-segfault (CVE-2020-8448) - CVE-2020-8448: analysisd: OS_CleanMSG segfault processing invalid msg location. #1815 (Edit: now fixed by analysisd: fix possible null ptr deref in OS_CleanMSG. #1823)
• analysisd-syscheck-decoder-off-by-one-read - syscheck decoder: off-by-one heap overflow in DB operations. #1819 (Edit: I made a mistake in my analysis here, it's not a bug).

Med:

• analysisd-OS_CleanMSG-off-by-one-syslog (CVE-2020-8443) - CVE-2020-8443: analysisd: OS_CleanMSG off-by-one heap overflow cleaning syslog msgs. #1816 (Edit: now fixed by analysisd: fix off-by-one in OS_CleanMSG. #1824)
• analysisd-OS_ReadMSG-use-after-free-ossecalert (CVE-2020-8444) - CVE-2020-8444: analysisd: OS_ReadMSG heap use-after-free with ossec-alert msgs. #1817
• analysisd-OS_ReadMSG-use-after-free-syscheck (CVE-2020-8447) - CVE-2020-8447: analysisd: OS_ReadMSG heap use-after-free decoding syscheck msgs. #1818

High:

• analysisd-rootcheck-decoder-heap-overflow (CVE-2020-8442) - CVE-2020-8442: analysisd rootcheck decoder: heap overflow in DB_File. #1820 (Edit: now fixed by analysisd: fix heap overflow in rootkit decoder. #1825)

Some caveats/context to add:

1. I'm not a professional C coder, w.r.t suggested fixes YMMV!
2. I don't write exploits for a living. My assessments of exploitability/risk should be considered lower bounds.
3. This wasn't an extensive audit. I followed my nose and used some fuzzing.
4. OSSEC 2.7 seems to be the earliest tag in the Github repo. I didn't dig deeper into history to see if any of these bugs affect older releases (some likely do).

If you would be interested in trying to adopt fuzzing as part of your CI (or as an integration with oss-fuzz, etc) I'd be happy to try and provide some notes but likely don't have the resources to implement it myself to a merge-able standard of work.

Thanks! You can close this top-level issue as you see appropriate.

[cpu]

Another note: I did not file bugs related to algorithmic complexity/DOS. There are a few places where ossec-analysisd is doing O(N) work for attacker controlled N and can be made to consume a lot of CPU/processing time. If you are interested in fixing this class of bug I can file an additional issue or two.

[cpu]

👋 Small update: I've opened pull requests to address the bugs I feel confident fixing myself.

• analysisd-rootcheck-decoder-heap-overflow -> analysisd: fix heap overflow in rootkit decoder. #1825
• analysisd-OS_CleanMSG-off-by-one-syslog -> analysisd: fix off-by-one in OS_CleanMSG. #1824
• analysisd-OS_CleanMSG-bad-location-segfault -> analysisd: fix possible null ptr deref in OS_CleanMSG. #1823
• os_regex-empty-pcre2-off-by-one -> os_regex: refuse to compile empty PCRE2 pattern. #1826

As a bonus I opened another small PR to fix a Makefile bug I encountered: #1822

The ones I haven't addressed:

• analysisd-OS_ReadMSG-use-after-free-ossecalert and analysisd-OS_ReadMSG-use-after-free-syscheck -> I left a comment about these two. My naive proposed fix would leak memory.
• rootcheck-check-rc-if-shell-injection-risk -> This will be fairly intricate and I'm skeptical the value of the check merits the time needed to redesign/re-implement it.
• analysisd-syscheck-decoder-msg-location-path-injection -> I'd like a second set of eyes on the bug before I assume my proposed fix is sensible.
• analysisd-OS_CleanMSG-allows-control-chars-in-msg -> This may be somewhat intricate as well and I'm probably not a strong enough C coder to do it with expedience.

[cpu]

I've updated the issue description to reflect which of the bugs are fixed in master.

I will request CVEs for the security relevant bugs later on.

I completed the CVE request forms today and will update relevant issues when CVEs are assigned.

[atomicturtle]

Looks like the CVE's are assigned now, I'd like to get the CVE's associated with the issue ID's here so I can align those up with the 3.6 changelog entries. Thanks for the hard work here!

[cpu]

I'd like to get the CVE's associated with the issue ID's here so I can align those up with the 3.6 changelog entries.

Done ☑️