-
Notifications
You must be signed in to change notification settings - Fork 69
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
Add detection for attempts to use CVE-2023-4911 #182
Add detection for attempts to use CVE-2023-4911 #182
Conversation
Signed-off-by: Richard Tweed <RichardoC@users.noreply.github.com>
Welcome @RichardoC! It looks like this is your first PR to falcosecurity/rules 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@RichardoC thank you very much, left some initial comments. Let's wait to hear from @loresuso and @darryk10.
Also thank you for following the new style guide and framework, this is the first new rules' contribution since then besides our own contributions 🙃 .
rules/falco-incubating_rules.yaml
Outdated
|
||
# Detection for possible use of CVE-2023-4911 | ||
# Based on https://www.qualys.com/2023/10/03/cve-2023-4911/looney-tunables-local-privilege-escalation-glibc-ld-so.txt | ||
- rule: Program possibly trying to use CVE-2023-4911 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- rule: Program possibly trying to use CVE-2023-4911 | |
- rule: Potential Local Privilege Escalation via Environment Variables Misuse |
Suggestion: Let's start a more generic rule that can span beyond just one CVE as we are limited in the number of rules we can maintain and this is the reason why we are looking to push for new rules that are more generic and behavior based.
@loresuso is looking into a rule around LD_PRELOAD
-> Lorenzo do you see potential to consolidate your work into this rule?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, though I can't think of other environment variables leading to attacks off the top of my head...
Are you wanting a list of environment variables that are known to be misused and this alert triggers if it detects one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@loresuso mind posting a preview of the idea of the rule you have in mind around LD_PRELOAD
?
Instead of a list of env variables it likely needs to be more granular and macros for each case, perhaps the sandbox rule Decoding Payload in Container
is a good example. Currently it's just one use case but it's designed in a way that allows for easy expansion like and (base64_decoding or other_decoding or other_macro)
. WDYT?
Again the reasoning is that we cannot for example go up to 500 or so rules, there is an upper bound and some consolidation may make sense. Also please note some older rules are on our radar for either replacement, deprecation or re-writing them as they don't align with what I just said.
rules/falco-incubating_rules.yaml
Outdated
Detect use of GLIBC_TUNABLES environment variable, which could be used for priviledge escalation to root on hosts running vulnerable glibc versions. | ||
condition: > | ||
spawned_process | ||
and proc.env icontains GLIBC_TUNABLES |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you have initial guidance around how noisy this could be? @darryk10 will help testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the official docs, I expect this env var isn't in common use so I wouldn't expect this to fire in most environments. If someone is actively using this functionality though, they should disable this detection
https://www.gnu.org/software/libc/manual/html_node/Tunables.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One problem I see using this approach is that the whole exploit is a bruteforce one. For this reason, I believe that this rule would be triggered for every attempt to redirect execution through the stack. I still need to double check this, but we can use https://github.com/RickdeJager/CVE-2023-4911#cve-2023-4911---looney-tunables to try it out. I am wondering if there is a way to overcome this, in case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it'd also detect attempts to do this exploit even if the host isn't vulnerable.
There's a simpler PoC here if it helps https://www.qualys.com/2023/10/03/cve-2023-4911/looney-tunables-local-privilege-escalation-glibc-ld-so.txt#:~:text=%24%20env%20%2Di%20%22GLIBC_TUNABLES%3Dglibc.malloc.mxfast%3Dglibc.malloc.mxfast%3DA%22%20%22Z%3D%60printf%20%27%2508192x%27%201%60%22%20/usr/bin/su%20%2D%2Dhelp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am just putting some reasoning here, because I think the rule couldn't be better than this with the tools we have right now, so for me it's a +1 to keep it, even if, as you said, it triggers also if the exploit failed 'cause the host has the patch. But it's ok because it's still a sign that there is someone misbehaving in our system.
What would be perfect here (i.e more behavioral-based rule), it's noticing that we have a high privilege process loading a shared library that is not a system one. Adding monitoring for this would cover this and many other CVEs, but we can't do it right now. It's also hard to achieve, because loading libraries is done in userspace through mmap
and mprotect
syscalls by the dynamic linker, but I believe it would be a solution for a category of exploits. Just putting this here to start a wider discussion on that
rules/falco-incubating_rules.yaml
Outdated
# Based on https://www.qualys.com/2023/10/03/cve-2023-4911/looney-tunables-local-privilege-escalation-glibc-ld-so.txt | ||
- rule: Program possibly trying to use CVE-2023-4911 | ||
desc: > | ||
Detect use of GLIBC_TUNABLES environment variable, which could be used for priviledge escalation to root on hosts running vulnerable glibc versions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you browse the existing rules desc you see that we try to also provide tuning advice https://falcosecurity.github.io/rules/, would you have ideas. Let's also wait until we know the final rules name and scope as that will dictate the final desc as well.
rules/falco-incubating_rules.yaml
Outdated
condition: > | ||
spawned_process | ||
and proc.env icontains GLIBC_TUNABLES | ||
output: Process run with GLIBC_TUNABLES environment variable which could be attempting priviledge escalation (env=%proc.env evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Text also to be adjusted after deciding on rules name and scope.
Co-authored-by: Melissa Kilby <melissa.kilby.oss@gmail.com> Signed-off-by: Richard Tweed <RichardoC@users.noreply.github.com>
Here is a final suggestion
Would be great to merge it soon if you have time. Thank you! |
Signed-off-by: Richard Tweed <RichardoC@users.noreply.github.com>
Sounds good to me, have updated with your changes |
LGTM! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it looks really good! Thanks
LGTM label has been added. Git tree hash: 1677f94329b438e2d7793c8f3611b1e420e55746
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
Thanks a bunch for your amazing contribution 🚀!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: darryk10, incertum, RichardoC The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind feature
Any specific area of the project related to this PR?
/area rules
Proposed rule maturity level
/area maturity-incubating
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Initial detection of attempts to use CVE-2023-4911
I'm not aware of away to detect GLIBC versions in these rules, so having to rely on this less common environment variable being set