Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Cloudflare responded to the “Copy Fail” Linux vulnerability

blog.cloudflare.com

Post reply on HN
Print view View original

21–30 of 86 posts

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

#21

Post by jeffbee »

Retr0id wrote: post #14
CGamesPlay wrote: post #8

Earlier quoted context omitted.

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...)

Yeah the whole system is based on the ability of one task to apparently become another task, that's how Unix works. So the indicators in /proc are just that: indicative at best.

There's no reason the task should even be assumed to be executing code in a file. A process can map code into anonymous memory and continue executing there without even branching. Again this is considered a feature of the system rather than a flaw.

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

#22

Post by rithdmc »

dboreham wrote: post #12

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?

The attack itself creates the logs, which - reading between the lines - are shipped to a central log server. A compromised server might not send any new indicators to the logs, but existing logs moved off device would still be available.

I'd like to know what those distinctive traces are, which is also missing :(

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

#23

Post by jmclnx »

> Linux kernel build based on the community's Long-Term Support (LTS)

CopyFail only highlights why Companies want LTS. If there was a supported kernel built prior to 2017, most large companies would still be on that version, avoiding this issue all-together.

The corporate mindset is usually "never upgrade unless there is new hardware needed or critical software failure". All CopyFail did was reinforce that mindset.

I wonder if CopyFail will cause enterprises put pressure on the Linux Foundation to maintain a "ultra LTS" were it is supported for 20 years ?

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

#24

Post by gilrain »

trollbridge wrote: post #7
john_strinlai wrote: post #5

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.

Starting a title with “How” is standard clickbait.

Starting a sentence with “How” is standard English, too.

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

#25

Post by staticassertion »

parliament32 wrote: post #9
jeffbee wrote: post #6

Earlier quoted context omitted.

Based on what? Proc title?

It's curious they're just "monitoring" rather than preventing. In a serious environment you'd run IPE with dm-verity/fs-verity to ensure binaries are whitelisted and integrity-checked at every execution.

lol no one does that (edit: or, rather, that is extremely uncommon, even in "serious" environments, for a ton of reasons).

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

#26

Post by gamegoblin »

john_strinlai wrote: post #5

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 learned a few years ago that HN also editorializes by dropping "world's" from titles

Before: Teens break record for world's longest kickball game

After: Teens break record for longest kickball game

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

#28

Post by staticassertion »

skinfaxi wrote: 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.

Syscalls and kernel module loading can both be logged, I assume that's sufficient here.

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

#29

Post by PunchyHamster »

for us it was

* Get list of modules from Puppet's facts, confirm module isn't used anywhere (it wasn't) * `install algif_aead /bin/false` in /etc/modprobe.d/disable-algif.conf * Run a check using exploit code to check it is no longer working

I imagine CF runs more stuff that could use it I guess but apparently it's not often used API

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

#30

Post by PunchyHamster »

jmclnx wrote: post #23

> Linux kernel build based on the community's Long-Term Support (LTS) CopyFail only highlights why Companies want LTS. If there was a supported kernel built prior to 2017, most large companies would still be on that version, avoiding this issue all-together. The corporate mindset is usually "never upgrade unless there is new hardware needed or critical software failure". All CopyFail did was reinforce that mindset. I…

> CopyFail only highlights why Companies want LTS. If there was a supported kernel built prior to 2017, most large companies would still be on that version, avoiding this issue all-together.

Sadly not really how it works for say Red Hat. They routinely backport features while keeping whatever "stable" number on kernel. We even had displeasure of them backporting a bug... same bug to 2 different RHEL versions

Post reply on HN