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

131–140 of 545 posts

Re: Copy Fail

#131

Post by tensegrist »

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…

llms love that though

"The honest solution: a clean 50-line cut" and so on, ad nauseam

Re: Copy Fail

#132

Post by Xirdus »

john_strinlai wrote: post #103
Xirdus wrote: post #102

Earlier quoted context omitted.

I'd imagine that at minimum, the team in charge of patching the vulnerability would need to review how the exploit works.

id imagine that they received more than just the poc in the report they received

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

Re: Copy Fail

#133

Post by wang_li »

stackghost wrote: post #45
maxtaco wrote: post #27

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

Analysis of the POC concurs with my tests that confirm that the portion of `su` that gets overwritten does not survive a reboot.

it's living in your page cache, not on your disk. flush the caches and it'll disappear.

Re: Copy Fail

#134

Post by john_strinlai »

StableAlkyne wrote: post #126
john_strinlai wrote: post #80

Earlier quoted context omitted.

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

agreed regarding the RHEL version!

i just dont understand huffing and puffing over "os as g" in a 10-line poc script, and saying "well i would never approve this". its not enterprise code. its not code that will ever be used anywhere else, for anything. its sole purpose is to prove that the exploit is real, which it does!

the rest of the information is in the actual vulnerability report. the poc is a courtesy to the reportee, so that they can confirm that the report itself isnt bullshit.

evidently, given the downvotes i am getting, people think exploit scripts should be enterprise quality code. ¯\_(ツ)_/¯ half of the reports i see flowing through mailing lists dont even have a poc.

amazingly HN-like to be upset about a variable name

Re: Copy Fail

#135

Post by john_strinlai »

Xirdus wrote: post #132
john_strinlai wrote: post #103

Earlier quoted context omitted.

id imagine that they received more than just the poc in the report they received

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?

Re: Copy Fail

#136

Post by collinmcnulty »

pixel_popping wrote: post #120

Yet, some people will still continue to say that "AI" isn't ready to replace (or strongly assist) our workflows, sure, some of the best humans devs left a vulnerability that serious (It's extremely serious, so many container as a service are vulnerable) for 9 years and an agent found it in 1 hour, maybe it's time to wake up and accept that it's UNSAFE to not use AI for security review as well?

A human security researcher found the core issue and an agent searched for where to apply it. I don’t think “an agent found it in one hour” is a fair summary of what happened.

Re: Copy Fail

#137

Post by JeremyNT »

tptacek wrote: post #52
rdtsc wrote: post #48

Earlier quoted context omitted.

The fact that they have no idea RHEL 14, probably the most well known enterprise distro, is not a thing, and yet they "directly verified on it" casts some doubt on seriousness.

I don't know what to tell you. I'm sure you have them dead to rights on Linux distro knowledge reliability, but the exploit here is real, and the vulnerability researchers they have on staff are also real. Xint is not generally a slop factory. It's ironic that the one thing LLMs can't do reliably in this space is "write copy for humans" (I don't trust them for that either).

Honestly I feel like a coding agent review would have caught this issue. I guess if you want to vibe-code your branded CVE web site it's not a bad idea to at least mash /review at the end.

Kind of funny to do something impressive and then ignore the details on the presentation, but perhaps that's not uncommon for security researchers?

Re: Copy Fail

#138

Post by akdev1l »

Banditoz wrote: post #130
fragmede wrote: post #109

Earlier quoted context omitted.

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

Agreed lmao the PoC itself looks like you’re getting attacked

Which I guess is true but I would like to verify the attack is the intended one

Re: Copy Fail

#139

Post by infogulch »

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…

While I agree that it doesn't make much sense to use a minimizer on code the reader could understand, the code-golfed byte count of a CVE repro communicates its complexity in a certain visceral way.

Re: Copy Fail

#140

Post by erans »

For agents, if you are concerned about that, block access to "su" as it is interactive anyway. Not loading it into the memory will block the attack. If you are using AgentSH (https://www.agentsh.org) you can add a rule to block "su" and soon be able to block AF_ALG sockets if you want to further protect things.
Post reply on HN