from Hacker News

Using Large Language Models to Catch Vulnerabilities

by sigmar on 11/1/24, 3:19 PM with 29 comments

  • by cjbprime on 11/1/24, 6:18 PM

    The work is impressive, but I wish Google wouldn't try so hard to claim to be the world first at everything. This claim feels extremely unprincipled:

    > We believe this is the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software. Earlier this year at the DARPA AIxCC event, Team Atlanta discovered a null-pointer dereference in SQLite, which inspired us to use it for our testing to see if we could find a more serious vulnerability.

    Every word in "public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software" applies to the Team Atlanta finding that they are citing too, and the Team Atlanta finding was against an actual release version of SQLite instead of a prerelease. If either team has provided the first example of this convoluted sentence, it is Team Atlanta, not Google.

    It is possible that they're arguing that the Team Atlanta finding wasn't "exploitable", but this is very debatable. We use CVSS to rate vulnerability impact, and CVSS defines Availability (crashing) as an equal member of the [Confidentiality, Integrity, Availability] triad. Being able to crash a system constitutes an exploitable vulnerability in that system. This is surely especially true for SQLite, which is one of the most mission-critical production software systems in the entire world.

    But if we're going to act like we're being very precise about what "exploitable" means, we should conclude that neither of these are exploitable vulnerabilities. To exploit them, you have to provide malicious SQL queries to SQLite. Who does that? Attackers don't provide SQL queries to SQLite systems -- the developers do. If an attacker could provide arbitrary SQL queries, they can probably already exploit that SQLite system, through something like an arbitrary file content write to an arbitrary local filename into RCE. I don't think either group found an exploitable vulnerability.

  • by jumploops on 11/2/24, 12:33 AM

    We have a “poor man’s” version of this running as a GitHub Action on our PRs[0].

    It basically just takes the diff from the PR and sends it to GPT-4o for analysis, returning a severity (low/medium/high) and a description.

    PRs are auto-blocked for high severity, but can be merged with medium or low.

    In practice it’s mostly right, but definitely errs on the side of medium too often (which is reasonable without the additional context of the rest of the codebase).

    With that said, it’s been pretty useful at uncovering simple mistakes before another dev has had a chance to review.

    [0] https://magicloops.dev/loop/3f3781f3-f987-4672-8500-bacbeefc...

  • by simonw on 11/1/24, 8:18 PM

    I think the key insight from this is:

    > We also feel that this variant-analysis task is a better fit for current LLMs than the more general open-ended vulnerability research problem. By providing a starting point – such as the details of a previously fixed vulnerability – we remove a lot of ambiguity from vulnerability research, and start from a concrete, well-founded theory: "This was a previous bug; there is probably another similar one somewhere".

    LLMs are great at pattern matching, so it turns out feeding in a pattern describing a prior vulnerability is a great way to identify potential new ones.

  • by ngneer on 11/2/24, 1:16 PM

    Sounds like they had some fun, but what is missing from the analysis is the effort spent, or even a rough indication of said effort. The epilog lists about sixteen non-security contributors that were needed to achieve the feat, and probably many more security personnel were needed from GPZ. Yet the outcome is one bug that could have been found with manual code review or a custom fuzzer. I am not sold on the premise that LLMs can increase code security or lower costs. At the moment, LLMs are producing and introducing more insecure code than they are finding.
  • by maxtoulouse31 on 11/1/24, 10:21 PM

    Shameless self-plug here, however two years ago I attempted a self study project following a similar intuition:

    https://maxdunhill.medium.com/how-effective-are-transformers...

    And created a Hugging Face repo of known vulnerabilities if anyone else wants to work on a similar project (link in blog post).

    My project was a lay person’s not especially successful attempt to fine-tune a BERT-based classifier to detect vulnerable code.

    Having said this, a main takeaway echoes simonw’s comment:

    “LLMs are great at pattern matching, so it turns out feeding in a pattern describing a prior vulnerability is a great way to identify potential new ones.”

    Given majority of vulnerabilities stem from memory misallocation, it seems that an LLM would most consistently find misallocated memory. Useful, though not the most complex vulnerabilities to weaponise.

    It seems the next frontier would be for an LLM to not only identify previously unidentified vulnerabilities, but also describe how to successfully daisy chain them into an effective vulnerability exploitation.

    Said differently, giving an LLM a goal like jail breaking the iOS sandbox and seeing how it might approach solving the task.

  • by sigmar on 11/1/24, 4:03 PM

    TL;DR P0 collaborated with DeepMind to make "Big Sleep," which is an AI agent (using gemini 1.5 pro) that can look through commits, spot potential issues, and then run testcases to find bugs. The agent found one in SQLite that was recent enough that it hadn't made it into an official release yet. They then tried to see if it could have been found with AFL, the fuzzer didn't find the issue after 150 cpu-hours.
  • by princearthur on 11/2/24, 7:17 AM

    I'm excited at the prospect of LLMs being deployed here. An attacker only needs to find one weak link in the chain. Eliminating weak links is hard, and might be NP-complete.

    However, throw resources at it and you might just make weak links much rarer. Throw a variety of heterogenous LLMs at it, and you might be looking at a large force multiplier.

  • by westurner on 11/2/24, 8:48 PM

    awesome-code-llm > Vulnerability Detection, Program Proof,: https://github.com/codefuse-ai/Awesome-Code-LLM#vulnerabilit...
  • by guerrilla on 11/2/24, 2:59 PM

    So the the eternal arm's race escalates.
  • by coding123 on 11/1/24, 9:08 PM

    Most code ought to be replaced with llm generated and then reviewed by a number of additional llms