[dead]
Claude wrote a full FreeBSD remote kernel RCE with root shell
91–100 of 128 posts
Re: Claude wrote a full FreeBSD remote kernel RCE with root shell
#92Earlier quoted context omitted.
> get it pumping out CVEs. Is that a good thing or bad? I see that as a very good thing. Because you can now inexpensively find those CVEs and fix them. Previously, finding CVEs was very expensive. That meant only bad actors had the incentive to look for them, since they were the ones who could profit from the effort. Now that CVEs can be found much more cheaply, people without a profit motive can discover them as we…
It's good and bad. Not all CVEs are the same, some aren't important. So it really depends on what gets founds as a CVE. The bad part is you risk a flood a CVEs that don't matter (or have already been reported). > That meant only bad actors had the incentive to look for them Nah. Lot's of people look for CVEs. It's good resume fodder. In fact, it's already somewhat of a problem that people will look for and report CVE…
It also depends on if the CVEs can be fixed by LLMs too. If they can find and fix them, then it's very good.
Re: Claude wrote a full FreeBSD remote kernel RCE with root shell
#93Earlier quoted context omitted.
It's good and bad. Not all CVEs are the same, some aren't important. So it really depends on what gets founds as a CVE. The bad part is you risk a flood a CVEs that don't matter (or have already been reported). > That meant only bad actors had the incentive to look for them Nah. Lot's of people look for CVEs. It's good resume fodder. In fact, it's already somewhat of a problem that people will look for and report CVE…
It also depends on if the CVEs can be fixed by LLMs too. If they can find and fix them, then it's very good.
Fixing isn't often a problem for CVEs. The hard part is almost always finding the CVE in the first place.
There are some extreme cases that might require extensive code changes, and those would benefit from LLMs. But a lot of the issues are things like off by one issues with pointers.
Re: Claude wrote a full FreeBSD remote kernel RCE with root shell
#94[dead]
Re: Claude wrote a full FreeBSD remote kernel RCE with root shell
#95I could see that being an incremental time save (perhaps not worth the token spend except for the dev team, not a high-value bug). But nbody finds this kind of bug "by hand" and hasn't for a long time now. Do people here really care about kernel security or testing automation? They're just talking about it because Claude? Everything on HN is people doing unpaid promotional work for Anthropic, just talking about all the promise Claude holds and all the various ways you could be spending more money on Claude. bored aimless vibes.
Re: Claude wrote a full FreeBSD remote kernel RCE with root shell
#96Key point is that Claude did not find the bug it exploits. It was given the CVE writeup[1] and was asked to write a program that could exploit the bug. That said, given how things are I wouldn't be surprised if you could let Claude or similar have a go at the source code of the kernel or core services, armed with some VMs for the try-fail iteration, and get it pumping out CVEs. If not now, then surely not in a too di…
> get it pumping out CVEs. Is that a good thing or bad? I see that as a very good thing. Because you can now inexpensively find those CVEs and fix them. Previously, finding CVEs was very expensive. That meant only bad actors had the incentive to look for them, since they were the ones who could profit from the effort. Now that CVEs can be found much more cheaply, people without a profit motive can discover them as we…
The biggest question is can you meaningfully use Claude on defense as well, eg can it be trusted to find and fix the source of the exploit while maintaining compatibility. Finding the CVEs helps directly with attacks while only helping defenders detect potential attacks without the second step where the patch can also be created. If not you've got a situation where you've got a potential tidal wave of CVEs that still have to be addressed by people. Attackers can use CVE-Claude too so it becomes a bit of an arms race where you have to find people able and willing to spend all the money to have those exploits found (and hopefully fixed).
Re: Claude wrote a full FreeBSD remote kernel RCE with root shell
#97Earlier quoted context omitted.
Claude is already able to find CVEs on expert level. Does it fix them as fast as it finds them? Bonus if it adds snarky code comments
I'm more interested if it fixes CVEs faster than it introduces them.
That too. Honestly I am expecting that if AI is such the wonder-miracle that people act like it is that it should be able to spot complex back-doors that require multiple services that look benign when red teamed but when used in conjunction provide the lowest CPU ring access along with all the obfuscated undocumented CPU instructions and of course all the JTAG debugging functions of all the firmware.
Re: Claude wrote a full FreeBSD remote kernel RCE with root shell
#98Key point is that Claude did not find the bug it exploits. It was given the CVE writeup[1] and was asked to write a program that could exploit the bug. That said, given how things are I wouldn't be surprised if you could let Claude or similar have a go at the source code of the kernel or core services, armed with some VMs for the try-fail iteration, and get it pumping out CVEs. If not now, then surely not in a too di…
They tried. It didn't work that well:
Re: Claude wrote a full FreeBSD remote kernel RCE with root shell
#99Key point is that Claude did not find the bug it exploits. It was given the CVE writeup[1] and was asked to write a program that could exploit the bug. That said, given how things are I wouldn't be surprised if you could let Claude or similar have a go at the source code of the kernel or core services, armed with some VMs for the try-fail iteration, and get it pumping out CVEs. If not now, then surely not in a too di…
They tried. It didn't work that well: https://red.anthropic.com/2026/zero-days/
How did you managed to get it to do that? When I gave it instructions to use Ghidra MCP to look for vulnerabilities in a windows driver on my local machine it refused saying it's not allowed to do pentest activities even if sandboxed to your own device.
Re: Claude wrote a full FreeBSD remote kernel RCE with root shell
#100Key point is that Claude did not find the bug it exploits. It was given the CVE writeup[1] and was asked to write a program that could exploit the bug. That said, given how things are I wouldn't be surprised if you could let Claude or similar have a go at the source code of the kernel or core services, armed with some VMs for the try-fail iteration, and get it pumping out CVEs. If not now, then surely not in a too di…
They tried. It didn't work that well: https://red.anthropic.com/2026/zero-days/
Sorry, can you clarify what you're saying here? What didn't work that well?