I'm curious to know what people think about Anthropic's claim that Claude found 500 high-severity vulnerabilities in open-source packages.

[mhitza@third-party.cyou]

@dangoodin the OpenSC commit that contains the highlighted code on the post https://github.com/OpenSC/OpenSC/commit/9ab1daf21029dd18f8828d684ee6151d9238edab . No detail about the fix and no security disclosure on the GitHub repository.

[trode@hachyderm.io]

@dangoodin hearsay, but I heard the model used had reduced safeguards, which allowed it to be more aggressive

[spaceinvader@social.securitytheater.net]

@dangoodin How popular/big were these OSS projects? There’s a big difference between finding a vuln in something like curl or Apache and my janky crap I pushed up to GitHub.

CVSS of 10/10 in my thing will impact one person, but in curl it’ll impact a few million more people. Including, still, me.

[leberschnitzel@existiert.ch]

@rootwyrm according to their blog it didn't claim that it found the vulnerability in the commit, but checked the rest of the code base if the same vulnerability might be unpatched in other places, and it seems to have been.
My questions are more with some others here: how many false positives had the human experts need to wade through to get to the real vulnerabilities

@dangoodin

[raymaccarthy@mastodon.ie]

@dangoodin
Anthropic have a lot of resources for PR and issue a lot of dubious and misleading statements?

[david_chisnall@infosec.exchange]

@dangoodin

There's a long history of doing fuzzy matching on patterns of known bugs to find more of the same kind. Coccinelle is the most well-known example of this. It was not actually written for vulnerability discovery, but it turns out that you could write patterns to patch a vulnerability and then it would find a load of similar ones.

Few projects actually use it.

OpenBSD has a policy that people who find security bugs should search for similar things in the code and fix them all. It turns out that humans who write a bug in one places are very likely to write the same bug elsewhere and this is no less true for bugs that lead to security vulnerabilities.

It sounds like this is a pretty good use case for an LLM, because it is a tool for doing fuzzy matching on a token stream. Finding patches that fixed vulnerabilities and then looking for the 'before' shape in other places will find a load of things.

With a bit of automation (sorry, 'agentic' use), you can do the following flow:

• Find things that look like the 'before' state.
• Apply a patch to make it look like the 'after' state.
• Use guided fuzzing techniques to try to produce a test case that triggers the new checks introduced in the 'after' version.
• If you find an example, flag it to the user as a potential security issue.

It's probably very computationally expensive, but cheaper than having a human do the same thing (which is so expensive almost no one does it).

[dangoodin@infosec.exchange]

@leberschnitzel @rootwyrm

Ah thanks. I knew I was missing something.

[aburka@hachyderm.io]

@dangoodin it reads as a threat

[bertdriehuis@infosec.exchange]

@FritzAdalis @GossiTheDog @dangoodin that’s the problem with human code review: humans just aren't that good at repetitive work (even though it stuns me that anyone who fixes an issue resulting from strcat() usage would not simply do a grep -r for other occurrences).

I have read, and reread, all BER related code in netsnmp, and managed to miss a number of integer overruns - even though I was specifically looking for them. It's that experience that makes me such an advocate for languages such as Rust.

[reverseics@infosec.exchange]

@dangoodin I wrote up an analysis of the first 'vulnerability' they wrote about. it does not appear to be a vulnerability at all (sure the original code uses 'unsafe' functions, but you can't exploit anything as far as I can tell). https://infosec.exchange/@reverseics/116067178548980458 .

I can't speak to the second vulnerability they wrote about, it would take me too long to determine whether it is a real or a hallucinated bug.