No, it does not. Just saying it again and again doesn't make it so.
Let me guide you through the exploit you were using and explain why. 馃У
1/n
2
4
2
28
The privilege escalation happens when one of the below close() syscalls exploits the previously crafted memory corruption and starts a ROP chain to raise privileges through the classic 'commit_creds(prepare_kernel_cred(NULL)).'
2/n
1
7
In particular, one of these close() syscalls will enter the kernel unprivileged and leave it with raised privileges.
This destroys the claim "detects [鈥 while invoking a system call", as it clearly does not.
3/n
1
5
Afterwards the exploit makes use of the newly gained privileges to (1) access /etc/shadow and (2) escape possible namespaces.
Again, this destroys the claim of "detects when a process [鈥 changes namespace association", as these syscalls are doing just that.
4/n
1
4
Tetragon seems to detect the exploit only later at execve() time, when it finally notices the unexpected CAP_SYS_ADMIN capability (which was effectively used already).
5/n
1
5
That's quite some syscalls after the initial privilege escalation until Tetragon reacts to it. So either it's not syscall-synchronous or too coarse grained to be effective in preventing privilege escalation.
6/6
2
5
Maybe I misunderstood how Tetragon works, but it should be able to detect earlier when the close() syscall returns. They probably just used a policy that lets the demo play out a bit
2
2
that privilege escalating syscall doesn't need to return to userland for the exploitation process to be successful.
1
21
APTs do whatever they need to, including disabling eBPF programs.
May 19, 2022 路 8:52 AM UTC
2
1
3
