I would not be shocked to learn that intelligence agencies are using AI tools to hack back into AI companies that make those tools to figure out how to create their own copycat AI.
The coming industrialisation of exploit generation with LLMs
41–50 of 174 posts
Re: The coming industrialisation of exploit generation with LLMs
#42I genuinely dont know who to believe. The people who claim LLMs are writing excellent exploits. Or the people who claim that LLMs are sending useless bug reports. I dont feel like both can really be true.
Re: The coming industrialisation of exploit generation with LLMs
#43> In the hardest task I challenged GPT-5.2 it to figure out how to write a specified string to a specified path on disk, while the following protections were enabled: address space layout randomisation, non-executable memory, full RELRO, fine-grained CFI on the QuickJS binary, hardware-enforced shadow-stack, a seccomp sandbox to prevent shell execution, and a build of QuickJS where I had stripped all functionality in…
> Yikes.
Yep.
Re: The coming industrialisation of exploit generation with LLMs
#44> In the hardest task I challenged GPT-5.2 it to figure out how to write a specified string to a specified path on disk, while the following protections were enabled: address space layout randomisation, non-executable memory, full RELRO, fine-grained CFI on the QuickJS binary, hardware-enforced shadow-stack, a seccomp sandbox to prevent shell execution, and a build of QuickJS where I had stripped all functionality in…
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…
Combine that with a minimal docker container and you don't even need a shell or anything but the kernel in those images.
Re: The coming industrialisation of exploit generation with LLMs
#45I would not be shocked to learn that intelligence agencies are using AI tools to hack back into AI companies that make those tools to figure out how to create their own copycat AI.
Re: The coming industrialisation of exploit generation with LLMs
#46Earlier quoted context omitted.
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…
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.
AFAICT, static linking just means the set of vulnerabilities you get landed with won't change over time.
Re: The coming industrialisation of exploit generation with LLMs
#47> In the hardest task I challenged GPT-5.2 it to figure out how to write a specified string to a specified path on disk, while the following protections were enabled: address space layout randomisation, non-executable memory, full RELRO, fine-grained CFI on the QuickJS binary, hardware-enforced shadow-stack, a seccomp sandbox to prevent shell execution, and a build of QuickJS where I had stripped all functionality in…
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…
Re: The coming industrialisation of exploit generation with LLMs
#48I genuinely dont know who to believe. The people who claim LLMs are writing excellent exploits. Or the people who claim that LLMs are sending useless bug reports. I dont feel like both can really be true.
These exploits were costing $50 of API credit each. If you receive 5001 issues from $100 in API spend on bug hunting and one of the issues cost $50 and the other 5000 cost one cent each, and they’re all visually indistinguishable using perfect grammar and familiar cyber security lingo; hard to find the dianond.
Re: The coming industrialisation of exploit generation with LLMs
#49> In the hardest task I challenged GPT-5.2 it to figure out how to write a specified string to a specified path on disk, while the following protections were enabled: address space layout randomisation, non-executable memory, full RELRO, fine-grained CFI on the QuickJS binary, hardware-enforced shadow-stack, a seccomp sandbox to prevent shell execution, and a build of QuickJS where I had stripped all functionality in…
> glibc's exit handler > Yikes. Yep.
Re: The coming industrialisation of exploit generation with LLMs
#50Earlier quoted context omitted.
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.
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.