Live data from Hacker News

How Cloudflare responded to the “Copy Fail” Linux vulnerability

blog.cloudflare.com

11–20 of 86 posts

Re: How Cloudflare responded to the “Copy Fail” Linux vulnerability

#11
post #6

Earlier quoted context omitted.

Based on what? Proc title?

Proc title is very easily forged (without root even). Obviously a real privileged process could modify the kernel and do whatever it wants, but if I were trying to detect this I would start with /proc/$id/exe.

Maybe, but there's a prctl to change that reference which a root process can use.

Re: How Cloudflare responded to the “Copy Fail” Linux vulnerability

#13
post #6

Earlier quoted context omitted.

Would certainly be interesting to learn more about. A simple check: allowlist of known "processes that run as root". Any new process shows up, something happened.

Based on what? Proc title?

They might just compute a hash over the binary, or the code space in memory.

Re: How Cloudflare responded to the “Copy Fail” Linux vulnerability

#14
post #6

Earlier quoted context omitted.

Based on what? Proc title?

Proc title is very easily forged (without root even). Obviously a real privileged process could modify the kernel and do whatever it wants, but if I were trying to detect this I would start with /proc/$id/exe.

/proc/pid/exe is also easily forged, without root. For example you can do LD_PRELOAD=evil.so /bin/foo on any dynamic executable, or spawn /bin/foo unmodified and inject code via ptrace or /proc/pid/mem.

I have a fileless, execless copyfail exploit that works by injecting shellcode directly into systemd's pid 1. (I should probably publish it at some point...)

Re: How Cloudflare responded to the “Copy Fail” Linux vulnerability

#15

this is a techincal dive into how cloudflare responded, not a confirmation that they responded for whatever reason, unknown to me, hn automatically strips "how" from the start of titles. i cant remember ever seeing a title where this was an improvement.

I'm yet to see a good example of the title stripping, at least for "how" and "how to" (although perhaps this is survivorship bias).

Re: How Cloudflare responded to the “Copy Fail” Linux vulnerability

#17
Any Cloudflare employees reading this, your network map has a few PoPs missing from it https://www.cloudflare.com/network/ notably, Perth (PER) Australia. Hobart (HBA) Australia. Wellington (WLG), New Zealand. Christchurch (CHC), New Zealand. Nausori (SUV), Fiji.

Re: How Cloudflare responded to the “Copy Fail” Linux vulnerability

#19
post #3

Would love to learn more about their internal behavioural detection program. > One of the first things our security team did was confirm that our existing endpoint detection would catch this exploit. Our servers run behavioral detection that continuously monitors process execution patterns. It doesn't rely on knowing about specific vulnerabilities; it watches for anomalous behavior across the fleet.

I'd very much like to learn more about this too, deserves its own blog post.

Re: How Cloudflare responded to the “Copy Fail” Linux vulnerability

#20

The "Hunting for Exploitation" section is unclear to me: "The exploit leaves a distinctive trace in kernel logs when it runs." Hmm. Wouldn't a system with a compromised kernel also log exactly what the attacker wanted logged?

I guess the hope is the kernel has been able to successfully transmit that log message to the immutable central logging infra before it gets compromised.

Although given the tendency for end point logging agents to run on buffers to reduce their network chattiness I do wonder if a fast acting exploit could dump that buffer before it manages to be transmitted.

I don't think any of the agents are complex enough to immediately transmit permission elevation log messages over the regular background noise.

Post reply on HN