Impact
What kind of vulnerability is it? Who is impacted?
Rules are the items that Falco asserts against. Falco distributions ship several ruleset files, which are used by default.
It was discovered that attackers could circumvent some of those rules with various techniques.
For example, rules that solely check if a file is opened for writing can be evaded by writing the file into a temporary location and then moving it afterward to the targetted location (see #762 and see #766).
In another case, some rules were found to be overly specific in their conditions. For example, checking only if chmod is called 4777 allows passing 0477 or 6777 unnoticed (see #765).
Users who are using rulesets from a Falco version before 0.18.0 are impacted by the above cases.
Furthermore, various rules and macros use proc.cmdline to determine if certain strings are present or not. These checks are usually implemented to avoid false positives. In some cases, an attacker could maliciously make a command line that bypasses some of these checks (with a shell subcommand, for example). This problem is particularly relevant when proc.cmdline is used with contains and startswidth operators and the whole condition is not tightening by other means. As an example of this problem, condition piece and not proc.cmdline contains /usr/bin/mandb present in the Read sensitive file untrusted allowed the following command line to get unnoticed (see #1620):
cat /usr/bin/mandb /etc/shadow
Finally, some rules implement checks based on file paths (e.g., using the startswith with fd.name or fd.directory ) and assume paths are absolute. However, this assumption is not always met since one can also access files via system-level symlinks (such as /proc/self/root) exist or via other existing symlinks. Attackers could exploit this issue to be not detected by some rules.
Patches
Has the problem been patched? What versions should users upgrade to?
Some of these problems have been solved by:
Others have been mitigated over the time, for example:
Users should upgrade to version 0.28.1 or later.
More generally speaking, since rulesets evolve continuously to improve detection mechanisms and to address new cases, it's recommended to upgrade to the latest available version whenever possible.
Additionally, users must be aware that the predefined rule sets are not intended cover all possible cases anyways. The default rule sets provided with Falco are designed to cover the main attack vectors. For these reasons, users are advised to customize or extend the rules according to their specific needs.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Although users could upgrade ruleset files to a more recent version, that's not always possible since the required_engine_version of the ruleset file might be incompatible.
Thus, a version upgrade to 0.28.1 or later is strongly recommended.
References
Are there any links users can visit to find out more?
These vulnerabilities were initially reported in this security audit and are sub-parts of the identifier FAL-01-002.
For more information
If you have any questions or comments about this advisory:
Impact
What kind of vulnerability is it? Who is impacted?
Rules are the items that Falco asserts against. Falco distributions ship several ruleset files, which are used by default.
It was discovered that attackers could circumvent some of those rules with various techniques.
For example, rules that solely check if a file is opened for writing can be evaded by writing the file into a temporary location and then moving it afterward to the targetted location (see #762 and see #766).
In another case, some rules were found to be overly specific in their conditions. For example, checking only if
chmodis called4777allows passing0477or6777unnoticed (see #765).Users who are using rulesets from a Falco version before 0.18.0 are impacted by the above cases.
Furthermore, various rules and macros use
proc.cmdlineto determine if certain strings are present or not. These checks are usually implemented to avoid false positives. In some cases, an attacker could maliciously make a command line that bypasses some of these checks (with a shell subcommand, for example). This problem is particularly relevant whenproc.cmdlineis used withcontainsandstartswidthoperators and the whole condition is not tightening by other means. As an example of this problem, condition pieceand not proc.cmdline contains /usr/bin/mandbpresent in theRead sensitive file untrustedallowed the following command line to get unnoticed (see #1620):Finally, some rules implement checks based on file paths (e.g., using the
startswithwithfd.nameorfd.directory) and assume paths are absolute. However, this assumption is not always met since one can also access files via system-level symlinks (such as/proc/self/root) exist or via other existing symlinks. Attackers could exploit this issue to be not detected by some rules.Patches
Has the problem been patched? What versions should users upgrade to?
Some of these problems have been solved by:
Others have been mitigated over the time, for example:
Users should upgrade to version 0.28.1 or later.
More generally speaking, since rulesets evolve continuously to improve detection mechanisms and to address new cases, it's recommended to upgrade to the latest available version whenever possible.
Additionally, users must be aware that the predefined rule sets are not intended cover all possible cases anyways. The default rule sets provided with Falco are designed to cover the main attack vectors. For these reasons, users are advised to customize or extend the rules according to their specific needs.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Although users could upgrade ruleset files to a more recent version, that's not always possible since the
required_engine_versionof the ruleset file might be incompatible.Thus, a version upgrade to 0.28.1 or later is strongly recommended.
References
Are there any links users can visit to find out more?
These vulnerabilities were initially reported in this security audit and are sub-parts of the identifier
FAL-01-002.For more information
If you have any questions or comments about this advisory: