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

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!

[poiana]

LGTM label has been added.

Git tree hash: 1677f94329b438e2d7793c8f3611b1e420e55746

[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](https://github.com/falcosecurity/rules/blob/main/OWNERS)~~ [incertum] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment