Perhaps, but if the exploit code is published folks can double-check that they implemented the mitigations properly.

If there's no PoC, how can you really be sure?

Why not? There has already been a working exploit floating around, at least now it comes from an authoritative source.

anyone who will use the exploit maliciously will immediately and trivially be able to create a working exploit.

An exploit was already published.

The third party posted an exploit.

"sudo" in "sudo echo 3 > /prox/sys/vm/drop_caches" does not do anything because only runs echo, not the write.

And if a machine is already exploited, it's too late to do just that. You need to rebuild the whole disk image because anything on it could be compromised.

>And if a machine is already exploited, it's too late to do just that. You need to rebuild the whole disk image because anything on it could be compromised.

this is more targeted at the people who run the PoC to see if their machine is vulnerable.

just transcribing some relevant stuff from https://github.com/V4bel/dirtyfrag/issues/1 so that people visiting this thread dont need to poke around a bunch of different places.

There is no evidence it is actually coming from Meta. The Reddit researcher the article cites generated their entire "analysis" in three days using Claude: https://news.ycombinator.com/item?id=47659552

Their website also added this page since I posted that comment: https://web.archive.org/web/20260411112604/https://tboteproj... where they claim their website is under "surveillance" because it got a few thousand requests from Google Cloud et al, most of them to a single page. This shows how low their standards are.

The way that Reddit "researcher" had Claude bang out a GitHub repo in a couple days and single-handedly established the narrative throughout the internet is scary.

When it was released I read a few of the reports in this repo and they didn't even support the claims made. Claude was admitting it couldn't find the evidence.

It's terrifying how easily this misinfo operation established itself as fact on websites where users view themselves as being more informed than average on these topics, like Hacker News.

> There is no evidence it is actually coming from Meta

My personal view that social media should be age gated is caused by Meta. But broadly, polling shows a commanding majority (60+ percent) of Americans believe in restrictions for under 14s.

Is there broad support for digital ID, age verification, etc? Or is it a broad sentiment that kids shouldn’t be on social media. Everyone I know agrees with latter but almost no one supports the former.

The parent commenter is conflating two things. Your right, there can be broad general sentiment that "kids probably shouldn't on social media, or better framed, social media in it's current iteration isn't healthy for people especially kids" but that doesn't imply people are asking for intrusive surveillance or to be monitored at all times when they are online.

> that doesn't imply people are asking for intrusive surveillance or to be monitored at all times when they are online

There is strong demand for regulation and low awareness of the surveillance consequences. We don’t have anyone advocating for a privacy-preserving solution, not effectively at least. Given the demand for something to be done, each jurisdiction is basically taking from the first available option.

Yes, i was asking which one the polling they were citing was about.

Two thirds of Americans believe in "setting limits on how much time minors can spend on social media" [1]. Where we have limited polling, a similar fraction support "banning social media use for all kids under 14" [2].

These are policy polls. The sentiment has moved beyond vague notions that kids should be entrusted to Meta less.

[1] https://www.pewresearch.org/short-reads/2023/10/31/81-of-us-...

[2] https://www.yahoo.com/news/articles/poll-most-mass-voters-su...

There seems to be a growing movement worldwide to restrict social media to under (some teenage range). I understand some of frustration. It comes from the increase in mental health issues with minors… but they are using that as cover to overreach and impose censorship for many. An alternate method is stop social media etc from abusing their users with algorithms favoring “engament”.

It is also convient for people to have a single outside source to blame their and their children's problems on. Rather than admit their poltical and economic policies and cultural expectations might all be a bigger problem.

And then most people just want a ban. So politicians, working as they often do in a technical vacuum, treat it like the other things we age gate.

Common enough that Mozilla has full-time engineers working on triaging compatibility issues, so they can either be fixed in Firefox or reported to webmasters. Here are the reports they get: https://webcompat.com/issues

Some of them will be paid by subscription and have ads

> pause OSS contribution and usage

What do you mean by that? They can't possibly stop using Linux/Kubernetes/Chrome (including Edge)/almost all programming languages/nginx/...

So this replaces a SUID binary, in order to run as PID 0. The website claims it can escape "Kubernetes / container clusters" and "CI runners & build farms" but I don't see anything supporting the claim it can escape a container (or specifically, a user namespace).

I ran the exploit in rootless Podman, and predictably it doesn't escape the container.

They also claim their script "roots every Linux distribution shipped since 2017.", but only tested four; and it doesn't work on Alpine

>The website claims it can escape "Kubernetes / container clusters" and "CI runners & build farms" but I don't see anything supporting the claim it can escape a container

they state that the write-up is forthcoming. presumably there is some additional steps or modifications that will be detailed in the 'part 2'.

"Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."

This is correct. The container escape exploit and writeup is not yet released.

Opus 4.7 it if you can't wait

> They also claim their script "roots every Linux distribution shipped since 2017.", but only tested four; and it doesn't work on Alpine

They've done themselves no favours at all with their write up.

It does seem legitimate (I was able to use the PoC on a 24.04 instance), and seems like it should be a big deal, but the actual number of affected distributions seems way lower, and not even remotely as per their claim every distribution since 2017.

For example with Ubuntu, if I'm reading it right there's some impact in 16.04 (EOL), but then at least as per their analysis, only the vendor specific 6.17 kernels they ship that have it (e.g. linux-gcp, linux-oracle-6.7 etc.). That's a relatively new kernel version they started shipping recently, after it was released upstream last September.

i mean, it doesn't work on any SELinux, but it's still quite severe anyhow

Have you got any info about this. 'seinfo -c' shows there is an alg_socket class. I presume this permission is required to be able to create an AF_ALG socket:

    $ sesearch -A -c alg_socket -p createallow bluetooth_t bluetooth_t:alg_socket { accept append bind connect create getattr getopt ioctl listen lock read setattr setopt shutdown write };
    allow container_device_plugin_init_t container_device_plugin_init_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_device_plugin_t container_device_plugin_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_device_t container_device_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_engine_t container_engine_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_init_t container_init_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_kvm_t container_kvm_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_logreader_t container_logreader_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_logwriter_t container_logwriter_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_t container_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_userns_t container_userns_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow openshift_app_t openshift_app_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
    allow openshift_t openshift_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
    allow spc_t unlabeled_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
    allow staff_t staff_t:alg_socket { append bind connect create getopt ioctl lock read setattr setopt shutdown write };
    allow sysadm_t sysadm_t:alg_socket { accept append bind connect create getopt ioctl listen lock read setattr setopt shutdown write };
    allow unconfined_domain_type domain:alg_socket { accept append bind connect create getattr getopt ioctl listen lock map name_bind read recv_msg recvfrom relabelfrom relabelto send_msg sendto setattr setopt shutdown write };
    allow user_t user_t:alg_socket { append bind connect create getopt ioctl lock read setattr setopt shutdown write };

... that's a lot of domains, including container_t and user_t; and obviously anything unconfined_t can't be expected to be restricted.

(Maybe you & others are specifically thinking of Android's policy?)

sorry yeah, I saw not exploitable on Android and thought most SELinux would be ok. Not super sure on this case what the surface is

The 2017 claim is based on the vulnerability having been introduced in this commit in the second half of 2017: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

The details will depend on whether the kernel is a newer release or a maintenance version of an older release.

It overwrites bytes in memory of any file you can read. It's not hard to imagine how it could escape a lot of things.

If you can get to real UID 0 from a rootless container, you can escape it, but you do need to take extra steps. Same with it working on Alpine: the underlying vulnerability probably still exists, but the script might need some adjusting. It's a PoC, not a full exploit for every situation.

It's worth pointing out that you cannot, definitionally, get "real UID 0" in a "rootless" container, because then it wouldn't be a rootless container. This is relevant because this exploit doesn't claim to be able to bypass user namespaces, and that getting "real UID 0" would be a different exploit.

The underlying exploit allows writing arbitrary values to the page cache, independent of any namespacing, so it should be assumed to allow container escapes even if the given PoC code doesn't do that.

That's fair (although it doesn't have anything to do with getting "real root" in a userns in that case). I guess one approach would be something like modifying the host's logrotate binary and waiting for it to trigger, or something like that. Would escape the container to root on the host directly. I imagine it wouldn't be a sure thing to pull off, either, but definitely straightforward enough that any APT should be asking Claude to develop it.

Their PoC does as you say, but is built upon arbitrary modification of the page cache, which could be abused for the other things

Ah indeed, it can be used to overwrite the page cache for files on read-only volumes.

Kubernetes 1.33 switches to user namespaces enabled by default, which I imagine is the same underlying mechanism that rootless Podman uses. `hostUsers: false` is the way to ensure that root in the pod is root on the host. It's trivial for a real (unmapped) root to escape a Kubernetes pod.

Did you try it on systems that don't have the patch already? Seems many distributions already shipped kernels with the patch ~a month ago.

It's patching the binary in memory, so the binary patch would be architecture dependent. The existing one is only x86_64, but with an updated payload, it would work on arm.

this is because the `su` binary is replaced with x86 shellcode, replace it with aarch64 and it will work just the same.

there is a PoC floating around for Alpine.

The binary "zip" isn't the exploit, it's the shellcode. The exploit is the rest, which changes the code of a SUID executable (su).

> make a WASM slave and thousands of developers can give their CPU/Memory/Disk for build slaves

WASM isn't a magic bullet for sandboxing. CI environments assume a full Linux. So you need to either ran a VM (with the attack surface that implies) or a write an x86 emulator in WASM (which would be very slow).

You also need anti-abuse to stop bitcoin miners from using your system. GitHub probably have full-time employees working on it.

> Like bitcoin mining, there could be some competition between 3 parallel builds to pick the winner if the output is the same.

It's a lot more complicated because many builds are not deterministic, you need to store artefacts, build secrets, etc.

Companies like golem.network or iex.ec have been working on this problem for a decade and they are still not easy to use.

Use a package repository that fast-tracks security updates, like Debian Stable.