8 comments

  • magicalhippo 1 hour ago
    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 distant future.

    [1]: https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08...

    • fragmede 1 hour ago
      > Credits: Nicholas Carlini using Claude, Anthropic

      Claude was used to find the bug in the first place though. That CVE write-up happened because of Claude, so while there are some very talented humans in the loop, Claude is quite involved with the whole process.

      • magicalhippo 1 hour ago
        > Claude was used to find the bug in the first place though. That CVE write-up happened because of Claude

        Do you have a link to that? A rather important piece of context.

        Wasn't trying to downplay this submission the way, the main point still stands:

        But finding a bug and exploiting it are very different things. Exploit development requires understanding OS internals, crafting ROP chains, managing memory layouts, debugging crashes, and adapting when things go wrong. This has long been considered the frontier that only humans can cross.

        Each new AI capability is usually met with “AI can do Y, but only humans can do X.” Well, for X = exploit development, that line just moved.

      • bayindirh 15 minutes ago
        Yes, that claim needs a source.
    • petcat 1 hour ago
      > 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.

      FreeBSD kernel is written in C right?

      AI bots will trivially find CVEs.

      • pjmlp 1 hour ago
        The Morris worm lesson is yet to be taken seriously.
        • pitched 50 minutes ago
          We’re here right now looking at a CVE. That has to count as progress?
  • ptx 1 hour ago
    > 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://wiki.netbsd.org/security/kaslr/

  • panstromek 1 hour ago
    The talk "Black-Hat LLMs" just came out a few days ago:

    https://www.youtube.com/watch?v=1sd26pWhfmg

    Looks like LLMs are getting good at finding and exploiting these.

  • m132 1 hour ago
    Appreciate the full prompt history
    • ptx 1 hour ago
      Well, it ends with "can you give me back all the prompts i entered in this session", so it may be partially the actual prompt history and partially hallucination.
    • dark-star 47 minutes ago
      they read like they were done by a 10 year old
      • m132 12 minutes ago
        It does, the whole tone and the lack of understanding of Docker, kernel threads, and everything else involved make it sound hilarious at first. But then you realize that this is what led to a working exploit in the end...
      • addandsubtract 12 minutes ago
        [dead]
  • PunchyHamster 1 hour ago
    I'm just gonna assume it was asked to fix some bug and it wrote exploit instead
  • fragmede 1 hour ago
  • Adam_cipher 9 minutes ago
    [dead]
  • rithdmc 1 hour ago
    Running into a meeting, so won't be able to review this for a while, but exciting. I wonder how much it cost in tokens, and what the prompt/validator/iteration loop looked like.