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

Copy Fail

copy.fail

Post reply on HN
Print view View original

121–130 of 545 posts

Re: Copy Fail

#121

Post by layer8 »

debo_ wrote: post #90
smlacy wrote: post #75

The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality. Looking at their source code [1] it starts with this simple line: import os as g,zlib,socket as s And already I'm perplexed. "os as g"? but we're not aliasing "zlib as z"? Clearly this is auto-generated by some kind of minimizer? Likely bec…

I don't see it as fetishizing byte count. I think of it as a proxy measure for how complicated or uncomplicated the exploit might be. They could just as well have said "we can do it in 3 lines of python" or "the Shannon entropy of the script implementing the exploit is really small" and I would have interpreted it similarly. Where do you see this "fetishizing" happening most often? It's a strange thing to counter-fet…

> I think of it as a proxy measure for how complicated or uncomplicated the exploit might be.

From a Busy Beaver, 256-bytes compo, or Dwitter perspective, 732 bytes isn’t really that meaningful.

And the sample exploit is even optimizing the byte size by using zlib compression, which doesn’t make much sense for the purpose. It just emphasizes the byte count fetishization.

Re: Copy Fail

#122

Post by akdev1l »

chasil wrote: post #46

On the downside, I need to push new kernels to all my servers. On this bright side, does this mean Magisk is coming to all unpatched Android phones?

No, Android doesn’t have suid binaries to exploit like in the PoC

Re: Copy Fail

#123

Post by tylerni7 »

tptacek wrote: post #94
smlacy wrote: post #75

The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality. Looking at their source code [1] it starts with this simple line: import os as g,zlib,socket as s And already I'm perplexed. "os as g"? but we're not aliasing "zlib as z"? Clearly this is auto-generated by some kind of minimizer? Likely bec…

I don't get the 732-byte thing either and while I think it's a relatively punchy and unusually informative landing page for named vulnerability there are little snags like this all over it. But the fact that it's not a kernel-exec LPE and it's reliable across kernels and distributions is important; it's close to the maximum "exploitability" you're going to see with an LPE. Which the page does communicate effectively;…

yeah... definitely a bit of a rush to get the landing page out after a long time in the disclosure process. The folks putting this all together have been working like mad (finding the bug, disclosing, working a lot on patching, writing up POCs and verifying exploitability in different scenarios) and stayed up really late to finish up the landing page, which led to a lot of minor issues.

But the bug is real and people should patch :)

For the size: sometimes people will shove in kilobytes of offset tables or something into an exploit, so it'll fingerprint and then look up details to work. This is much smaller because it doesn't need any of that, which is important for severity. (I agree the "golf" nature is a bit of an aside, kind of like pwn2own exploits taking "10 seconds")

Re: Copy Fail

#124

Post by akdev1l »

krunck wrote: post #96

Wow. I tried it on an old testing VM of Ubuntu 24.04 that had not been touched for a few months. Instant root with the bonus that any user that runs "su" gets root too. I updated the VM thinking it would be fixed afterward. Nope.

You’d have to reinstall the su binary itself I guess

Re: Copy Fail

#125

Post by marshray »

john_strinlai wrote: post #65
marshray wrote: post #61

Earlier quoted context omitted.

No it hasn't. Ubuntu before 26.04 LTS (released a week ago) are currently listed as vulnerable. Debian other than forky and sid are currently listed as vulnerable. This is a disgrace.

Disclosure timeline 2026-03-23Reported to Linux kernel security team 2026-03-24Initial acknowledgment 2026-03-25Patches proposed and reviewed 2026-04-01Patch committed to mainline 2026-04-22CVE-2026-31431 assigned 2026-04-29Public disclosure (https://copy.fail/) kernel 6.19.14-arch1-1, the kernel in question from the parent comment, has been patched.

The lesson here being... compile your own kernel from git sources every few days?

Give up entirely on non-virtualized container security?

This is not sarcasm. I'd finally given in and started learning about docker/podman-style OCI containerization last week.

Re: Copy Fail

#126

Post by StableAlkyne »

john_strinlai wrote: post #80
smlacy wrote: post #75

The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality. Looking at their source code [1] it starts with this simple line: import os as g,zlib,socket as s And already I'm perplexed. "os as g"? but we're not aliasing "zlib as z"? Clearly this is auto-generated by some kind of minimizer? Likely bec…

> As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this. lucky for them, its an exploit script, not enterprise code. all that needs to be "reviewed" is whether or not it exploits the thing its supposed to. edit: yall really think a 10-line proof of concept script needs to undergo a code review? wild. i shouldnt be surprised that the top comment…

It's just sloppy. Readers are human, and little mistakes like this take away from the article. Then you add a nonexistent RHEL version, and it just isn't a good look. Which is a shame, because it's otherwise a very interesting vuln.

Maybe you didn't care, but the length of this comment chain clearly shows that it matters. Effective communication is just as important as the engineering.

Re: Copy Fail

#127

Post by 0x0 »

tptacek wrote: post #44
rdtsc wrote: post #39

Earlier quoted context omitted.

[flagged]

I have no idea about this page, but Theori/Xint has a staff of veterans, they are a serious thing.

Dropping a public exploit on github before distros have patches available isn't very cool, or is that just how veterans roll these days?

Re: Copy Fail

#128

Post by john_strinlai »

marshray wrote: post #125
john_strinlai wrote: post #65

Earlier quoted context omitted.

Disclosure timeline 2026-03-23Reported to Linux kernel security team 2026-03-24Initial acknowledgment 2026-03-25Patches proposed and reviewed 2026-04-01Patch committed to mainline 2026-04-22CVE-2026-31431 assigned 2026-04-29Public disclosure (https://copy.fail/) kernel 6.19.14-arch1-1, the kernel in question from the parent comment, has been patched.

The lesson here being... compile your own kernel from git sources every few days? Give up entirely on non-virtualized container security? This is not sarcasm. I'd finally given in and started learning about docker/podman-style OCI containerization last week.

in this specific case, they offer an alternative mitigation if your chosen distro has not updated yet:

For immediate mitigation, block AF_ALG socket creation via seccomp or blacklist the algif_aead module:

    echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
    rmmod algif_aead 2>/dev/null

Re: Copy Fail

#129

Post by alufers »

rany_ wrote: post #21

Could this be used to root Android devices? Does Android ship with algif_aead?

I rewrote it quickly to C [1] (and changed the embedded binary to be aarch64).

Unfortunately it fails on calling bind() on my device, so probalby Android doesn't ship with that kenrel module by default :(. So no freedom for my $40 phone.

Putting it out here, maybe somebody else will have better luck.

[1] https://gist.github.com/alufers/921cd6c4b606c5014d6cc61eefb0...

Re: Copy Fail

#130

Post by Banditoz »

fragmede wrote: post #109
smlacy wrote: post #75

The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality. Looking at their source code [1] it starts with this simple line: import os as g,zlib,socket as s And already I'm perplexed. "os as g"? but we're not aliasing "zlib as z"? Clearly this is auto-generated by some kind of minimizer? Likely bec…

> Anyway, I could go on. Then go on. zlib is only used once, so "zlib as z" in exchange for using z once doesn't get you anything. Using os directly and not renaming it g saves you 2 bytes though. But in this age where AI outputs reams of code at the drop of a hat, why shouldn't we enjoy how small you can get it to pop a root shell? https://gist.github.com/fragmede/4fb38fb822359b8f5914127c2fe... edit: If we drop offs…

>...why shouldn't we enjoy how small you can get it to pop a root shell?

Because I want to know what the exploit is doing and how it works, and if it's even safe to run.

A privesc PoC is NOT the place for this kind of fun.

Post reply on HN