3 ms·
Tells you all you need to know around how extremely weak a C executable like QuickJS is for LLMs to exploit. (If you as an infosec researcher prompt them correc
by rvz 10mo ago
Tells you all you need to know around how extremely weak a C executable like QuickJS is for LLMs to exploit. (If you as an infosec researcher prompt them correctly to find and exploit vulnerabilities).
> Leak a libc Pointer via Use-After-Free. The exploit uses the vulnerability to leak a pointer to libc.
I doubt Rust would save you here unless the binary has very limited calls to libc, but would be much harder for a UaF to happen in Rust code.
- cookiengineer 10mo agoThe reason I value Go so much is because you have a fat dependency free binary that's just a bunch of syscalls when you use CGO_ENABLED=0. Combine that with a minimal docker container and you don't even need a shell or anything but the kernel in those images.
- akoboldfrying 10mo agoWhy would statically linking a library reduce the number of vulnerabilities in it? AFAICT, static linking just means the set of vulnerabilities you get landed with won't change over time.
- cookiengineer 10mo ago> Why would statically linking a library reduce the number of vulnerabilities in it? I use pure go implementations only, and that implies that there's no statically linked C ABI in my binaries. That's what disabling CGO means.
- akoboldfrying 10mo agoWhat I mean is: There will be bugs* in that pure Go implementation, and static linking means you're baking them in forever. Why is this preferable to dynamic linking? * It's likely that C implementations will have bugs related to dynamic memory allocation that are absent from the Go implementation, because Go is GCed while C is not. But it would be very surprising if there were no bugs at all in the Go implementation.
- tptacek 10mo agoThey're prioritizing memory corruption vulnerabilities, is the point of going to extremes to ensure there's no compiled C in their binaries.
- underdeserver 10mo agoYou can have memory corruption in pure Go code, too.
- tptacek 10mo agoUh huh. That's where all the Go memory corruption vulnerabilities come from!
- cookiengineer 10mo agoNobody claimed otherwise. You're interacting with a kernel that invented its own programming language based on macros, after all, instead of relying on a compiler for that. What could go wrong with this, right? /s
- staticassertion 10mo agoAnd in Rust (yes, safe Rust can have memory safety vulnerabilities). Who cares? They basically don't happen in practice.
- cookiengineer 10mo agoIt would be nice if there was something similar to the ebpf verifier, but for static C, so that loop mistakes, out of boundary mistakes and avoidable satisfiability problems are caught right in the compile step. The reason I'm so avoidant to using C libraries at all cost is that the ecosystem doesn't prioritize maintenance or other forms of code quality in its distribution. If you have to go to great lengths of having e.g. header only libraries, then what's the point of using C99/C++ at all? Back when conan came out I had hopes for it, but meanwhile I gave up on the ecosystem. Don't get me wrong, Rust is great for its use cases, too. I just chose the mutex hell as a personal preference over the wrapping hell.
- eru 10mo agoYes, you can have docker container images that only contain the actual binary you want to run. But if you are using a VM, you don't even need the Linux kernel: some systems let you compiler your program to run directly on the hypervisor. See eg https://github.com/hermit-os/hermit-rs https://github.com/hermit-os/hermit-rs or https://mirage.io/ https://mirage.io/
- tptacek 10mo ago"C executables" are most of the frontier of exploit development, which is why this is a meaningful model problem.
- 0xDEAFBEAD 10mo agoCan we fight fire with fire, and use LLMs to rewrite all the C in Rust?
- 0xbadcafebee 10mo agoSure, but the LLMs will just chain 14 functions instead of 7. If all C code is rewritten in Rust tomorrow that still leaves all the other bug classes. Eliminating a bug class might have made human attacks harder, but now with LLMs the "hardness" factor is purely how much token money you have.
- adrianN 10mo agoLlms are not magic. Fixing a large class of exploits makes exploitation harder.
- 0xbadcafebee 10mo agoThey kind of are magic, that's the point. You can just tell them to look at every other bug class, and keep them churning on it until they find something. You can fast-forward through years of exploit research in a week. The "difficulty" of different bug classes is almost gone. (I think people underestimate just how many exploits are out there in other classes because they've been hyperfocused on the low-hanging fruit)
- saagarjha 10mo agoUsually rewriting something in Rust requires nontrivial choices on the part of the translator that I’m not sure are currently within the reach of LLMs.
- 10mo ago
- vsgherzi 10mo agoWouldn’t the idea be to not have the uaf to begin with? I’d argue it saves you very much by making the uaf way harder to write. Forcing unsafe and such.
- pizlonator 10mo agoYeah Fil-C to the rescue (I’m not trying to be facetious or troll or whatever. Stuff like this is what motivated me to do it.)
- deleted 10mo ago[deleted]
- lelanthran 10mo ago> Tells you all you need to know around how extremely weak a C executable like QuickJS is for LLMs to exploit. (If you as an infosec researcher prompt them correctly to find and exploit vulnerabilities). Wouldn't GP's approach work with any other executable using libc? Python, Node, Rust, etc? I fail to see what is specific to either C or QuickJS in the GP's approach.