141–150 of 545 posts
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 would absolutely never approve review of any code that used this. How often do you review, and subsequently block the release, of PoCs in this sort of context? Sounds like you've faced this a lot. I always thought code quality mattered less in those, as long as you communicate the intent.
How does "import os as g" communicate the intent? How does hiding the payload behind zlib communicate the intent? This is the opposite: obfuscating the intent, so they can brag about 732 bytes instead of 846 bytes (or whatever it might have been).
It would have been less work for everyone involved to just release the unminified source.
Earlier quoted context omitted.
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…
And this code is not readable at all. It is failing at letting people confirm the exploit easily.
Earlier quoted context omitted.
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…
Disagree because to run the PoC you really ought to understand what it’s doing. And this code is not readable at all. It is failing at letting people confirm the exploit easily.
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 people confirm the exploit easily.
it confirms the exploit incredibly easy. just run it, and you get confirmation.
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.
Anybody has the same feeling?
Interestingly it fails for me because my `su` isn't world-readable: $ stat /bin/su File: /bin/su Size: 59552 Blocks: 118 IO Block: 59904 regular file Device: 0,52 Inode: 796854 Links: 1 Access: (4711/-rws--x--x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2023-09-18 13:23:03.117105665 -0500 Modify: 2021-02-13 05:15:56.000000000 -0600 Change: 2023-09-18 13:23:03.119105665 -0500 Birth: 2023-09-18 13:23:03.117105665 -0500 I…
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
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…
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!
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?