Explore rules options around LD_PRELOAD env

[incertum]

See falcosecurity/libs#1546 (comment)

@Biagio-Dipalma @loresuso @darryk10 @RichardoC

[RichardoC]

It's also worth clarifying where these are appropriate, i.e. how severe does the CVE have to be for these to be included/how long since a patch was made?
I do think these have a place (hence raising #182 ) but I expect these to rot faster than other detections and thus get removed after some amount of time, or moved to a graveyard example file. This compares with others like a process unexpectedly opening a subshell is unlikely to be a rule that gets removed

[incertum]

@RichardoC 100% agree on trying to create a detection that is more behavioral rather than just addressing one specific CVE. Let's explore! LD_PRELOAD has been brought up multiple times by multiple folks, so I think some sort of rule is due 🙃, but just checking for the env variable being present is super noisy for sure ...

The referenced PR also introduced the capabilities to check env variables in the parent process lineage.

---

Side note: @RichardoC would you be willing to help with further cleaning up the rules in this regard? So that one day we have broader, but still well tuned detections. Also feel free to propose rules we should re-write or deprecate 🙏.

[RichardoC]

I'll certainly try to help, but can't guarantee time for the next few months

[loresuso]

Hello! I've been thinking a bit about writing this LD_PRELOAD rule and I couldn't figure out how to write it down properly.
The first thing about using proc.env is that LD_PRELOADing can be achieved also by using the file /etc/ld.so.preload, not using environment variables at all.
Then, let's think about the problem more in general. I see the whole use case of the rule as the following: we may want to trigger an alert whenever a library is loaded from a particular path, that is something owned by a potentially compromised user (e.g. his home directory) or a world-writable directory (e.g. /tmp). In fact, if the malicious library was loaded from /usr/lib, /lib or something else, it means that the attacker has already permission to write to a root folder, so he has at least a lot of capabilities or full root already. The other thing is that the env variable of LD_PRELOAD can be space-separated (LD_PRELOAD=/path/1 /path/2). So with the previous reasoning in mind, we would like to work with paths, so using startswith would be nice, but space-separated values prevent us to do that and use only contains, which by the way can't give us control about how the path starts.
Hope we can address somehow the problems I am seeing! Wdyt?

[Biagio-Dipalma]

@loresuso fair point!
Env variables can contain different values and using operators like startswith, pmatch or endswith on the single value is valuable to define precise detections.
A possible solution can be: split the string by space, column and semicolon, if a list is achieved the items will be added to an array and can be referred directly by doing something like proc.env[LD_PRELOAD][0] startswith "/tmp". In this scenario, I think that we also need to follow the logic of the proc.aname field: so if an operator is applied to the env variable it will be applied to each element of the related array to write conditions like proc.env[LD_PRELOAD] startswith "/tmp" and apply the startswith to each item extracted.

Regarding the detection part I think that we can define:

• a separate rule to detect the LD_PRELOAD trick via file (open_write on that file)
• a "suspicious LD_PRELOAD value" rule to detect suspicious paths in the LD_PRELOAD env variable. Something like:

- list: ld_suspicious_paths
   items: [/tmp, /usr, /var]

- rule: Suspicious paths detected in LD_PREALOD variable
  desc: [...]
  condition: spawned_process and proc.env[LD_PRELOAD] pmatch (ld_suspicious_paths)

• specific rules for particular use cases

[incertum]

• Would something like this work (proc.env[LD_PRELOAD] startswith "/tmp" or proc.env[LD_PRELOAD] contains " /tmp")? Perhaps we get away without further patching the proc.env logic which we also wouldn't have until the next release in May.
• Re the hard-coded /etc/ld.so.preload what other conditions should we look for when opening the file for reading? How common or noisy is using the file approach?
• I would keep it to one rule only. We can also consider first creating a more narrow Sandbox rule and then expanding it over time? Just to get us going.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[poiana]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh with /remove-lifecycle rotten.

Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle rotten

[incertum]

/remove-lifecycle rotten
/remove-lifecycle stale

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[poiana]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh with /remove-lifecycle rotten.

Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle rotten

[poiana]

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

Mark the issue as fresh with /remove-lifecycle rotten.

Provide feedback via https://github.com/falcosecurity/community.
/close

[poiana]

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

Mark the issue as fresh with /remove-lifecycle rotten.

Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.