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

151–160 of 545 posts

Re: Copy Fail

#151

Post by marshray »

john_strinlai wrote: post #128
marshray wrote: post #125

Earlier quoted context omitted.

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

Thanks!

I'd do 'umask 133' in front of the echo out of paranoia.

Out of curiosity, was the asterisk after '2>/dev/null' intentional? I had not seen that idiom before.

Re: Copy Fail

#152

Post by tptacek »

0x0 wrote: post #127
tptacek wrote: post #44

Earlier quoted context omitted.

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?

There is no one accepted set of norms on disclosure. Any strategy you take, someone will criticize.

Re: Copy Fail

#154

Post by john_strinlai »

marshray wrote: post #151
john_strinlai wrote: post #128

Earlier quoted context omitted.

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

Thanks! I'd do 'umask 133' in front of the echo out of paranoia. Out of curiosity, was the asterisk after '2>/dev/null' intentional? I had not seen that idiom before.

the asterisk is my oops, trying to format the comment in italics to differentiate my comment from the text provided by the author. sorry for the confusion

Re: Copy Fail

#155

Post by Xirdus »

john_strinlai wrote: post #135
Xirdus wrote: post #132

Earlier quoted context omitted.

That doesn't make reviewing the POC any less valuable.

what value do you believe renaming the variable from "g" to something else provides the linux maintainers?

It makes the exploit code more readable. We all love to laugh at C folks but for real, even Linux kernel maintainers care about readability.

Re: Copy Fail

#157

Post by vitus »

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…

Hilariously, "os as g" adds one more byte than it saves, since os is only used 4 times but the alias takes 5 extra bytes to save 4. And "socket as s" comes out even.

If you wanted real savings, you'd use "d=bytes.fromhex" instead of defining a function -- 17 bytes!! And d('00') -> b'\0' for -2 bytes.

We could easily get the byte count down further by using base64.b85decode instead of bytes.fromhex (-70 or so), but ultimately we're optimizing a meaningless metric, as you mention.

Re: Copy Fail

#158

Post by ranger_danger »

corvad wrote: post #10

If this is verified, this is a very big deal. Root access on any shared computer. Additionally do we know what kernel versions and stable versions have the patch?

As far as mainline goes, only 7.0 and up have the patch already.

Re: Copy Fail

#159

Post by [deleted] »

MarleTangible wrote: post #89
xeeeeeeeeeeenu wrote: post #82

It seems there was some kind of confusion during the disclosure process, because the vendors aren't treating this vulnerability as serious and it remains unpatched in many distros. https://access.redhat.com/security/cve/cve-2026-31431 "Moderate severity", "Fix deferred" https://security-tracker.debian.org/tracker/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://www.suse.com/security/cve/CVE-2026-3143…

Seems like distros consider it a medium risk because it doesn't involve remote code execution and requires local access. Though it allows local root privilege escalation which is considered high priority. https://ubuntu.com/security/cves/about#priority > Medium: A significant problem, typically exploitable for many users. Includes network daemon denial of service, cross-site scripting, and gaining user privileges.

[deleted]

Re: Copy Fail

#160

Post by scratchyone »

charcircuit wrote: post #32
maxtaco wrote: post #27

Use extreme caution running arbitrary code on your machines, especially obfuscated code that tickles kernel bugs! (edited)

The page explicitly describes that it is stealthy as it does not make permanent changes, only corrupting the binary in memory.

unfortunately the page can also lie to you haha. it seems people have reviewed the code by now, but running suspicious shellcode you don't fully understand is never a great idea.
Post reply on HN