Comment by rvz
11 hours 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.
> 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.
Yeah 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.)
The 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.
Why 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.
> 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.
8 replies →
Yes, 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 or https://mirage.io/
"C executables" are most of the frontier of exploit development, which is why this is a meaningful model problem.
Can we fight fire with fire, and use LLMs to rewrite all the C in Rust?
Usually 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.
Sure, 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.
1 reply →
Wouldn’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.