Add detection for attempts to use CVE-2023-4911

[RichardoC]

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

[poiana]

Welcome @RichardoC! It looks like this is your first PR to falcosecurity/rules 🎉

[incertum]

@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 🙃 .

[incertum]

Suggested change

	- 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?

[RichardoC]

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?

[incertum]

@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.

[incertum]

Would you have initial guidance around how noisy this could be? @darryk10 will help testing.

[RichardoC]

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

[loresuso]

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

[RichardoC]

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

[loresuso]

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

[incertum]

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.

[incertum]

Text also to be adjusted after deciding on rules name and scope.

[incertum]

@RichardoC

Here is a final suggestion

# possible use of CVE-2023-4911
- macro: glibc_tunables_env
  condition: (proc.env icontains GLIBC_TUNABLES)

- rule: Potential Local Privilege Escalation via Environment Variables Misuse
  desc: >
    Process run with suspect environment variable that could be attempting privilege escalation. One use case is 
    detecting the use of the GLIBC_TUNABLES environment variable, which could be used for privilege escalation 
    on systems running vulnerable glibc versions. Only known and carefully profiled processes that legitimately 
    exhibit this behavior should be excluded from this rule. This rule is expected to trigger on every attempt, 
    even failed ones.
  condition: >
    spawned_process 
    and glibc_tunables_env
  enabled: true
  output: Process run with suspect environment variable which could be attempting privilege 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)
  priority: NOTICE
  tags: [maturity_incubating, host, container, users, mitre_privilege_escalation, TA0004]

• In one of my previous comments I somehow copied the wrong TA, it should be TA0004
• spell correction of privilege
• removed phrasing of privilege escalation to root as in the new world of containerized environments root has lost its meaning as capabilities define more the actual power for workloads not directly running on the host.
• We can postpone the discussion around possibly extending this with the LD_PRELOAD use case, I would still keep the rule name already generic for when (not if) the next use case comes around. This is also why I am suggesting adding a macro already.
• Re desc, please read it as suggestion, must not be my version, feel free to adjust it

Would be great to merge it soon if you have time. Thank you!

[RichardoC]

@RichardoC

Here is a final suggestion

# possible use of CVE-2023-4911
- macro: glibc_tunables_env
  condition: (proc.env icontains GLIBC_TUNABLES)

- rule: Potential Local Privilege Escalation via Environment Variables Misuse
  desc: >
    Process run with suspect environment variable that could be attempting privilege escalation. One use case is 
    detecting the use of the GLIBC_TUNABLES environment variable, which could be used for privilege escalation 
    on systems running vulnerable glibc versions. Only known and carefully profiled processes that legitimately 
    exhibit this behavior should be excluded from this rule. This rule is expected to trigger on every attempt, 
    even failed ones.
  condition: >
    spawned_process 
    and glibc_tunables_env
  enabled: true
  output: Process run with suspect environment variable which could be attempting privilege 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)
  priority: NOTICE
  tags: [maturity_incubating, host, container, users, mitre_privilege_escalation, TA0004]

• In one of my previous comments I somehow copied the wrong TA, it should be TA0004
• spell correction of privilege
• removed phrasing of privilege escalation to root as in the new world of containerized environments root has lost its meaning as capabilities define more the actual power for workloads not directly running on the host.
• We can postpone the discussion around possibly extending this with the LD_PRELOAD use case, I would still keep the rule name already generic for when (not if) the next use case comes around. This is also why I am suggesting adding a macro already.
• Re desc, please read it as suggestion, must not be my version, feel free to adjust it

Would be great to merge it soon if you have time. Thank you!

Sounds good to me, have updated with your changes

[loresuso]

LGTM!

[darryk10]

it looks really good! Thanks

[poiana]

LGTM label has been added.

Git tree hash: 1677f94329b438e2d7793c8f3611b1e420e55746

[incertum]

/approve

Thanks a bunch for your amazing contribution 🚀!

[poiana]

[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:

• OWNERS [incertum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment