Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude wrote a full FreeBSD remote kernel RCE with root shell

github.com

Post reply on HN
Print view View original

81–90 of 128 posts

Re: Claude wrote a full FreeBSD remote kernel RCE with root shell

#81

Post by wslh »

magicalhippo wrote: post #3

Key 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…

While it's great to clarify, LLMs are actually finding bugs and writing exploits [1][2]. There are more example though.

[1] https://news.ycombinator.com/item?id=47589227

[2] https://xbow.com/

Re: Claude wrote a full FreeBSD remote kernel RCE with root shell

#82

Post by giancarlostoro »

wslh wrote: post #81
magicalhippo wrote: post #3

Key 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…

While it's great to clarify, LLMs are actually finding bugs and writing exploits [1][2]. There are more example though. [1] https://news.ycombinator.com/item?id=47589227 [2] https://xbow.com/

Another great example is how Claude is helping Mozilla find zero day exploits in Firefox, by the hundreds, and ranging from minor to CVE level, for over a year:

https://blog.mozilla.org/en/firefox/hardening-firefox-anthro...

I think the Mozilla example is a good one because its a large codebase, lots of people keep asking "how does it do with a large codebase" well there you go.

Re: Claude wrote a full FreeBSD remote kernel RCE with root shell

#84

Post by zer00eyz »

ogig wrote: post #32
magicalhippo wrote: post #3

Key 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…

Setting up fuzzing used to be hard. I haven't tried yet, but my bet is having Claude Code, today, analyze a codebase and suggest where and how to fuzztest it and having it review the crashes and iterate, will produce CVEs.

It has access to more testing data than I will ever look at. Letting it pull from that knowledge graph is going to give you good results! I just built a chunk of this (type of thinking) into my (now evolving) test harness.

1. Unit testing is (somewhat) dead, long live simulation. Testing the parts only gets you so far. These tests are far more durable, independent artifacts (read, if you went from JS to rust, how much of your testing would carry over)

2. Testing has to be "stand alone". I want to be able to run it from the command line, I want the output to be wrapper so I can shove the output on a web page, or dump it into an API (for AI)

3. Messages (for failures) matter. These are not just simple what's broken, but must contain enough info for context.

4. Your "failed" tests should include logs. Do you have enough breadcrumbs for production? If not, this is a problem that will bite you later.

5. Any case should be an accumulation of state and behavior - this really matters in simulation.

If you have done all the above right and your tool can return all the data, dumping the output into the cheapest model you can find and having it "Write a prompt with recommendations on a fix (not actual code, just what should be done beyond "fix this") has been illuminating.

Ultimately I realized that how I thought about testing was wrong. Its output should be either dead simple, or have enough information that someone with zero knowledge could ramp up into a fix on their first day in the code base. My testing was never this good because the "cost of doing it that way" was always too high... this is no longer the case.

Re: Claude wrote a full FreeBSD remote kernel RCE with root shell

#85

Post by margalabargala »

mentalgear wrote: post #77
magicalhippo wrote: post #3

Key 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…

[flagged]

Brute force might be dismissed as "not elegant" but it's highly effective. Especially for bypassing security.

If you need to access someone's account or decrypt their hard drive, brute force is an effective way to do it.

Re: Claude wrote a full FreeBSD remote kernel RCE with root shell

#86

Post by lateforwork »

magicalhippo wrote: post #3

Key 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 well--allowing vulnerabilities to be fixed before bad actors find them.

Re: Claude wrote a full FreeBSD remote kernel RCE with root shell

#88

Post by astrange »

alcor-z wrote: post #38

The MADBugs work is solid, but what's sticking with me is the autonomy angle — not just finding a vuln but chaining multiple bugs into a working remote exploit without a human in the loop. FreeBSD kernel security research has always been thinner on the ground than Linux, which makes this feel both more impressive and harder to put in context. What's the actual blast radius here — is this realistically exploitable on…

This post is AI slop.

Re: Claude wrote a full FreeBSD remote kernel RCE with root shell

#89

Post by cogman10 »

lateforwork wrote: post #86
magicalhippo wrote: post #3

Key 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…

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 CVEs on things that don't matter just so they can get the "I found and reported CVE xyz" on their resume.

What this will do is expose some already present flaws in the CVE scoring system. Not all "9"s are created equal. Hopefully that leads to something better and not towards apathy.

Post reply on HN