-
Notifications
You must be signed in to change notification settings - Fork 905
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
Rule: PTRACE attached to process #2226
Conversation
Signed-off-by: Alessandro Brucato <alessandro.brucato@sysdig.com>
rules/falco_rules.yaml
Outdated
|
||
- rule: PTRACE attached to process | ||
desc: "This rule detects an attempt to inject code into a process using PTRACE." | ||
condition: evt.type=ptrace and evt.dir=> and evt.arg.request=11 and proc_name_exists |
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.
This is a really initiative!! Thanks!
Here are my two cents/questions:
- Should we include
PTRACE_SEIZE
as well? - Why do we care
proc_name_exists
? - Security tooling might use ptrace capability (e.g. Falco in certain scenario), maybe we should add macro to exclude the known processes?
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.
Hey @Kaizhe , thank you for your feedback!
- Sure, PTRACE_SEIZE makes sense to me, I added it in the condition
- We saw some false positives without that macro
- Sure, I added the macro (as an empty list)
/milestone 0.34.0 |
rules/falco_rules.yaml
Outdated
|
||
- rule: PTRACE attached to process | ||
desc: "This rule detects an attempt to inject code into a process using PTRACE." | ||
condition: evt.type=ptrace and evt.dir=> and evt.arg.request=11 and proc_name_exists |
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.
Nice idea @Brucedh!
Just wanted to add something to this. Code injection is usually performed by issuing the ptrace
syscall and using the following three requests in my opinion: PTRACE_ATTACH
, PTRACE_POKETEXT
and PTRACE_SETREGS
. The poke text requests usually copy a shell code to the memory of the victim process and the set regs request usually modifies the instruction pointer to execute from that shell code. As you were saying, the attach requests could possibly lead to false positives, so I think we can also use the two other requests to improve this rule.
WDYT?
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.
Hey, thanks for the feedback. Do you know why Falco thinks that "POKETEXT" is evt.arg.request=5 and not 4, same with SETREGS being 27 from Falco's point of view but 13 from a C programmer's perspective? https://elixir.bootlin.com/linux/v4.8/source/arch/arm/include/uapi/asm/ptrace.h#L16
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.
Hello @nicklangsysdig, the reason is that Falco maps those flags to its internal representations. This is done for portability so that regardless of the system Falco is running, the flags will all have a unique representation. This is useful if flags can change from one OS to another. If you want to dig deeper and know about how Falco redefines these flags, please check it here: https://github.com/falcosecurity/libs/blob/master/driver/ppm_events_public.h#L416-L454
https://github.com/falcosecurity/libs/blob/master/driver/ppm_flag_helpers.h#L1435
keep in mind that the same reasoning applies to all flags, so this is an advice you can re-use in the future 🙂
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.
Thank you for your feedback @loresuso !
I agree it’s a good idea to cover also PTRACE_POKETEXT and PTRACE_SETREGS. I added them along with PTRACE_POKEDATA, which is equivalent to PTRACE_POKETEXT
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 makes sense, thank you!
…and whitelist macro Signed-off-by: Alessandro Brucato <alessandro.brucato@sysdig.com>
Signed-off-by: Alessandro Brucato <alessandro.brucato@sysdig.com>
LGTM |
LGTM label has been added. Git tree hash: 608066d4bbdff5aae572605fa6d5186876f64f5e
|
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Brucedh, darryk10, jasondellaluce, leogr 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 |
Signed-off-by: Alessandro Brucato alessandro.brucato@sysdig.com
What type of PR is this?
/kind rule-create
Any specific area of the project related to this PR?
/area rules
What this PR does / why we need it:
The ptrace system call can be used to alter a target's memory and execution which make it popular for injecting code. It is often used by malware for this purpose in order to be more stealthy, or steal information from the process. Legitimate tools, such as GDB or security software, may also leverage this method.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: