New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Active response tools allow arbitrary code execution #10858
Comments
|
Has a CVE been requested for this issue? It also seems like 4.2.5-rc1 was rewritten to be the 4.2.5 release, meaning that people watching the releases in the repository didn't get a notification for it. What happened here? |
|
@ajakk yes, that is CVE-2021-44079. Regarding your second question, we marked v4.2.5-rc1 as a pre-release, then we published v4.2.5 as a stable release. Is there anything wrong? Best regards. |
I requested that CVE and they seem to have used the suggested description that I wrote. Did you independently also request it? I think it's a bit strange to make a security release without a CVE, since CVEs are picked up by others who might not follow Wazuh releases closely. I only noticed this issue because I watch releases in this repository.
I don't pretend to be familiar with how Github package releases work, but I only ever got a release notification for v4.2.5-rc1 so I think there's something a bit off here? |
|
Hi. Thank you for your feedback, which will help us to define a procedure for vulnerabilities. If you didn't receive a notification for v4.2.5, maybe it was because we created the pre-release (v4.2.5-rc1) and then modified it. With this in mind, next time we will do a new release. Thank you. |
|
Thank you! |
|
Hi, does this issue exist in Wazuh versions before 4.2? It appears previous versions used shell-based AR scripts instead of C-based executables. At least for ossec-slack.sh it appears to sanitize the alert data by removing any double-quotes before passing it to wget or curl. It's a bit confusing since CVE-2021-44079 states all Wazuh versions before 4.2.5 are affected. On a related note, please consider explicitly mentioning security fixes in Wazuh's emails that announce new releases, and in the release notes --- 4.2.5's note just states it "includes new features or enhancements." Wazuh administrators shouldn't have to learn about security fixes via third-parties like CERT. Thanks! |
|
Good morning, tell me when the next system upgrade is expected, so that you know when to start the upgrade to fix the vulnerability |
|
Hi @vikman90 , in wazuh 4.1.5 those scripts .sh , not python. |
|
When is the update that patches this issue planned to roll out? |
The fix commit is in 4.2.5 and later: |
|
Hi all, To clarify your concerns, this bug appeared in 4.2.0, as stated in the table above. It was produced by PR #7317 (issue #6954), where we translated the shell scripts (such as ossec-slack.sh) into C programs (like wazuh-slack.c). We are not aware of the shell version is vulnerable. Thus, this vulnerability affects Wazuh versions from 4.2.0 to 4.2.4 (included). The patch for this bug (#10809) was released in v4.2.5, with a double fix:
That's why upgrading either the agent or the manager will mitigate the vulnerability. However, we recommend upgrading both. @torataks thank you for your comment, we will follow your suggestion to mention security fixes in upcoming releases. On the other hand, @ajakk I would kindly ask you to request a change in the CVE to more precisely indicate the affected versions, in order to prevent confusion. Should you have further questions or concerns, please let me know. Regards. |
|
Done, but if you want a change to a CVE it can be done by anyone, there's nothing special about me with respect to the CVE. |
|
Thank you @ajakk, I appreciate it. |
This issue was reported by @rk700.
We found a command injection bug in the active-response script wazuh-slack.
The alert JSON data is put in the shell command line as POST body for
curl:However, the raw log line which could be partially controlled by an attacker is also included in the JSON data. Single quote in JSON is not escaped and therefore could be used to truncate the command:
Remediation
system()function call withwpopenv(), which executes subprocesses without a shell.disable-accountfirewalld-dropnetshroute-nullwazuh-slack!)\x21$)\x24')\x27`)\x60The text was updated successfully, but these errors were encountered: