Live data from Hacker News

Claude wrote a full FreeBSD remote kernel RCE with root shell

github.com

61–70 of 128 posts

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

#61
post #28
post #25

Earlier quoted context omitted.

Freebsd doesn't have docker. It has jails which can serve a similar purpose but are not the same in important ways

Please at least read the context before attempting to correct me... Here's what I'm referring to: https://github.com/califio/publications/blob/7ed77d11b21db80...

I'm not correcting you, I'm adding context for people who don't know much about freebsd.

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

#63
post #12

> It's worth noting that FreeBSD made this easier than it would be on a modern Linux kernel: FreeBSD 14.x has no KASLR (kernel addresses are fixed and predictable) and no stack canaries for integer arrays (the overflowed buffer is int32_t[]). What about FreeBSD 15.x then? I didn't see anything in the release notes or the mitigations(7) man page about KASLR. Is it being worked on? NetBSD apparently has it: https://wik…

This is more of a Linux kernel criticism of KASLR, but perhaps it's related as to why it's not been a priority in FreeBSD (i.e. it gives a false sense of safety and rather focus on 'proper' security hardening): https://forums.freebsd.org/threads/truth-about-linux-4-6-sec...

Security is an onion, honestly you want both layers to be as hard as possible.

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

#64
post #50

Earlier quoted context omitted.

A talk given by an employee that stands to make millions from Anthropic going public, definitely not a conflict of interest by the individual.

I didn't say "watch this without critical thinking". The chance this is completly fabricated though is very low and its an highly interesting signal to many others. There was also a really good AI CTF Talk at 39c3 hacker conference just 4 month ago.

But you did say “Claude is already able to find CVEs on expert level.”

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

#65

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…

Look at Xbow which spawned a few "open source" competitors.

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

#66
The most difficult part is always to find the vulnerability, not to fix it. And most people who are spending their days finding them are heavily incentivized to not disclose.

Automatic discovery can be a huge benefit, even if the transition period is scary.

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

#68
post #64

Earlier quoted context omitted.

I didn't say "watch this without critical thinking". The chance this is completly fabricated though is very low and its an highly interesting signal to many others. There was also a really good AI CTF Talk at 39c3 hacker conference just 4 month ago.

But you did say “Claude is already able to find CVEs on expert level.”

Please also read my comments with critical thinking and add my comment and its content to your own list of signals you trust :P

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

#69

The most difficult part is always to find the vulnerability, not to fix it. And most people who are spending their days finding them are heavily incentivized to not disclose. Automatic discovery can be a huge benefit, even if the transition period is scary.

Hopefully such automation also covers fixing instead of giving open source devs headaches, like the one over some obscure codec from the 90's.

Nevertheless, attacking is a targeted endeavour, unlike defense. Fixing is, in _general_, more difficult in theory.

* reference to past google and ffmpeg incident

Post reply on HN