[dead]
Claude Code Found a Linux Vulnerability Hidden for 23 Years
291–300 of 303 posts
Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years
#292Every time I read these titles, I wonder if people are for some reason pushing the narrative that Claude is way smarter than it really is, or if I'm using it wrong. They want me to code AI-first, and the amount of hallucinations and weird bugs and inconsistencies that Claude produces is massive. Lots of code that it pushes would NOT have passed a human/human code review 6 months ago.
What models are you using, on what type of codebases, with what tools?
I'm using Claude Code with the latest version of Sonnet, using the official VS Code extension.
At my company they set it up that way.
Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years
#293Earlier quoted context omitted.
> Checking if a real vulnerability can be triggered is a trivial task compared to finding one Have you ever tried to write PoC for any CVE? This statement is wrong. Sometimes bug may exist but be impossible to trigger/exploit. So it is not trivial at all.
Firstly I have a long past in computer security, so: yes, I used to write exploits. Second, the vulnerability verification does not need being able to exploit, but triggering an ASAN assert. With memory corruption that's very simple often times and enough to verify the bug is real.
Thank you for clarification. It actually helped: at first I was overcomplicating it in my head.
After thinking about it for an hour I came up with this:
LLM claims that there is a bug. We dont know whether it really exist. We run a second LLM that is capable to write unit-tests/reproducer (dont have to be E2E, shorter data flow -> bigger success rate for LLM), compile program and run the test for ASAN assert. ASAN error means proven bug. No error, as you said, does not prove anything, because it may simply mean LLM failed to write a correct test.
Still don't know how much $ it would cost for LLM reasoning, but this technically should work much better than manually investigating everything.
Sorry for "have-you-ever" thing :)
Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years
#294Earlier quoted context omitted.
But the service also tells criminals and adversaries about the bomb locations.
And? So do a variety of other services. Was it your impression that the criminals and adversaries were behind the 8 ball on this? AI is reviving debates about vulnerability research that we thought we killed off in the 1990s.
Perhaps the argument isn't about the ethics of security research, but rather the divide between those who can afford non-free software licenses and those who ethically or circumstancially can't.
Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years
#295Earlier quoted context omitted.
And? So do a variety of other services. Was it your impression that the criminals and adversaries were behind the 8 ball on this? AI is reviving debates about vulnerability research that we thought we killed off in the 1990s.
Perhaps the argument isn't about the ethics of security research, but rather the divide between those who can afford non-free software licenses and those who ethically or circumstancially can't.
You'd see the same thing in 1990s full-disclosure debates, where people trying to create a social/cultural argument against vulnerability research would throw this kind of stuff against the wall just to see what would stick. It's either good to know about vulnerabilities in the code you rely on or it isn't.
Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years
#296I replicated this experiment on several production codebases and got several crits. Lots of dupes, lots of false positives, lots of bugs that weren't actually exploitable, lots of accepted/ known risks. But also, crits!
I think this really needs to be party of the message. It's great that Claude found a vulnerability that apparently has been overlooked for a long time. It's even proper for Anthropic to tout the find. But we should all ask about the signal to nose ratio that would have been part of the process. If it only was successful... That would be worth touting, too. But I expect there was more noise than they'd care to admit.…
I have to agree with you. We don’t talk nearly enough about the real signal to nose ratio.
(Sorry. I couldn’t resist lol)
Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years
#297Earlier quoted context omitted.
It's always the inconsistencies which amaze me, from the article: > I have so many bugs in the Linux kernel that I can’t report because I haven’t validated them yet You have "so many?" Are they uncountable for some reason? You "haven't validated" them? How long does that take? > found a total of five Linux vulnerabilities And how much did it cost you in compute time to find those 5? These articles are always fantasti…
>And how much did it cost you in compute time to find those 5? This is the last thing I'd worry about if the bug is serious in any way. You have attackers like nation states that will have huge budgets to rip your software apart with AI and exploit your users. Also there have been a number of detailed articles about AI security findings recently.
Yeah, this was one of my first thoughts too. It’s impossible to know but I wonder how many of these “unknown exploits” have been in use by government agencies for years already. Or decades, apparently.
Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years
#298Earlier quoted context omitted.
I like biasing it towards the fact that there is a bug, so it can't just say "no bugs! all good!" without looking into it very hard. Usually I ask something like this: "This code has a bug. Can you find it?" Sometimes I also tell it that "the bug is non-obvious" Which I've anecdotally found to have a higher rate of success than just asking for a spot check
Do you not run into too many false positives around "ah, this thing you used here is known to be tricky, the issue is..." I've seen that when prompting it to look for concurrency issues vs saying something more like "please inspect this rigorously to look for potential issues..."
yes but i can identify those easily. i know that if it flags something that is obviously a non issue, i can discard it.
...because false positives are good errors. false negatives is what i'm worried about.
i feel massively more sure that something has no big oversights if multiple runs (or even multiple different models) cannot find anything but false positives
Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years
#299Earlier quoted context omitted.
I like biasing it towards the fact that there is a bug, so it can't just say "no bugs! all good!" without looking into it very hard. Usually I ask something like this: "This code has a bug. Can you find it?" Sometimes I also tell it that "the bug is non-obvious" Which I've anecdotally found to have a higher rate of success than just asking for a spot check
Just in case you didn't read the full article, this is how they describe finding the bugs in the Linux kernel as well. Since it's a large codebase, they go even more specific and hint that the bug is in file A, then try again with a hint that the bug is in file B, and so on.
very interesting. i think "verbal biasing" and "knowing how to speak" in general is a really important thing with LLMs. it seems to massively affect output. (interestingly, somewhat less with Opus than with GPT-5.4 and Composer 2. Opus seems to intuit a little better. but still important.)
it's like the idea behind the book _The Mom Test_ suddenly got very important for programming
Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years
#300Earlier quoted context omitted.
It is, but that's not a useful or insightful thing to say
It's not an insightful statement right now, but it was at the peak of cloud hype ca. 2010, when "the cloud" often used in a metaphorical sense. You'd hear things like "it's scalable because it's in the cloud" or "our clients want a cloud based solution." Replacing "the cloud" in those sorts of claims with "another person's computer" showed just how inane those claims were.
No, it doesn't at all. "it's scalable because it's in the cloud" may be reductive nonsense or it could be true. It's scalable because it's on someone elses computer and in a matter of minutes it can be on one of their computers with twice the ram and vCPUs. That is a meaningful thing to say when the alternative is CAPEX heavy investment in your own infrastructure. Same with "our clients want a cloud based solution" in contrast with on-prem installs. They don't want your shitty pizza box in their closet, they want someone else to be doing the hosting.