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

231–240 of 545 posts

Re: Copy Fail

#231

Post by john_strinlai »

akdev1l wrote: post #215
john_strinlai wrote: post #144

Earlier quoted context omitted.

> Disagree because to run the PoC you really ought to understand what it’s doing. that is contained in the report, which will look similar to the blog. the maintainers will have an open line of contact with the reporters as well. the poc is a small part of the entire report. its not like the linux maintainers only received this poc and have to work out the vulnerability from it alone. > It is failing at letting peopl…

what the blog says and what the code does are two different things. For all I know the blog itself is a honey pot. I need to know what the code does before I run it.

>I need to know what the code does before I run it.

its literally code meant to exploit your system. you should be running it in an environment built for that already.

you dont test exploit pocs on your daily driver.

Re: Copy Fail

#232

Post by ebiggers »

As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. The kernel's cryptography code is just for in-kernel users (for example, dm-crypt).

The algorithm being used in this exploit, "authencesn", is even an IPsec implementation detail, which never should have been exposed to userspace as a general-purpose en/decryption API.

If you're in charge of the configuration for a Linux kernel, I strongly recommend disabling all CONFIG_CRYPTO_USER_API_* kconfig options. This would have made this bug, and also every past and future AF_ALG bug, unexploitable. In the unlikely event that you find that it breaks any userspace programs on your system, please help migrate them to userspace crypto code! For some it's already been done. But in general, AF_ALG has actually never been used much in the first place, other than in exploits.

I don't think there's much other option. This sort of userspace API might have been sort of okay many years ago. But it just doesn't stand up in a world with syzbot, LLM-assisted bug discovery, etc.

Re: Copy Fail

#233

Post by arcfour »

hackernudes wrote: post #149

LPE = local privilege escalation Too many darn acronyms. This one wasn't too hard to figure out from context but I wish people would define acronyms before using them!

LPE is a very well-known acronym within the security community, it's not purely academic or obscure or anything.

I agree that it would be a good idea to define it explicitly when writing for a broader audience, but I don't think it's particularly egregious that they didn't. It's certainly something I could see myself forgetting.

Then again, the whole writeup appears to be AI-generated, so...

Re: Copy Fail

#234

Post by alpn »

ebiggers wrote: post #232

As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. Th…

For anyone wondering: AF_ALG is a Linux socket interface that exposes the kernel’s crypto API via file descriptors, using normal read(2)/write(2) calls for hashing and encryption.

Re: Copy Fail

#235

Post by arcfour »

It's unfortunate that this does not include which versions of the kernel are vulnerable/patched, especially since this is a builtin module which cannot be easily removed with rmmod...

I was wondering if I was vulnerable running Fedora 44, kernel 6.19.14, and after a few minutes of digging I was able to find the linux-cve-announce mailing list post: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20... which says:

  ...fixed in 6.18.22 with commit fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8

  ...fixed in 6.19.12 with commit ce42ee423e58dffa5ec03524054c9d8bfd4f6237

  ...fixed in 7.0 with commit a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
Hope that helps.

Re: Copy Fail

#236

Post by x4132 »

Twirrim wrote: post #170
progval wrote: post #51

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…

> 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 e…

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

Re: Copy Fail

#237

Post by x4132 »

angry_octet wrote: post #205
phreack wrote: post #40

The page itself seems vibecoded and a bit of an advertisement, but it does look like the vulnerability is real and high risk. It does explain the big security update I just got, guess I'll prioritize updating today.

These guys don't need to advertise, they are already 100% busy with work. But who wastes their time manually creating web pages? Especially kernel devs.

it's advertising their AI, not the talents of their humans :D

Re: Copy Fail

#238

Post by [deleted] »

barbegal wrote: post #22
skilled wrote: post #9

This looks like an extraordinary find at first glance. Does this mean you can go from a basic web shell from a shared hosting account to root? I can see how that could wreak havoc really quickly.

Yes I would imagine lots of those type of services would be vulnerable if they hadn't updated to the latest kernel versions.

[deleted]

Re: Copy Fail

#239

Post by cozzyd »

tylerni7 wrote: post #114
jzb wrote: post #24

This is amazing. Page says it works on RHEL 14.3, which doesn’t exist. Current RHEL is 10.x, this must’ve been done in a TARDIS.

ugh sorry should be fixed. There was some scrambling to get more info together to explain the issue (and yes, obviously marketing), so there are some minor mistakes. Thanks for pointing it out!

yeah, I assumed the whole thing was AI slop when I saw EL14...

Re: Copy Fail

#240

Post by ryandrake »

jesse_dot_id wrote: post #190

Good thing nobody is silly enough to let fully autonomous AI agents run as regular users on these affected operating systems. That could be disastrous given a zero day prompt injection technique.

Good thing we haven't normalized installing things with curl | sh
Post reply on HN