Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQLite Critical CVEs or LLM Slop?

research.jfrog.com

Post reply on HN
Print view View original

131–140 of 407 posts

Re: SQLite Critical CVEs or LLM Slop?

#131

Post by _flux »

inigyou wrote: post #120
trashb wrote: post #36

Could be just me but I would be quite careful running these PoC's, especially since the CVE's mostly seem nonsensical. I suppose these CVE's could be targeting some kind of PoC execution instead of actual bug reporting? (I didn't look at the code in depth). Why is the repo even mixing CVE's for "schreibfaul1 ESP32-audioI2S" and "SQLite"? Is mixing CVE's for different products in one repo common practice?

There is no specific practice for a repo full of bug reports. Having a repo full of bug reports is already unusual. Normally you report a bug against the software that has a bug, not by creating a file in your own repo.

I've created bug reports to open source projects that have related files in my repo. Then I can just list the reproduction instructions like:

1) arrange xxx, such that yyy.. or git clone this repo where this is set up. 2) ..

I thought that might have been quite helpful not just to the person I'm sending the bug report to, but also to myself when I need to evaluate if the bug has been fixed.

Re: SQLite Critical CVEs or LLM Slop?

#132

Post by ymir_e »

CodesInChaos wrote: post #99
ymir_e wrote: post #84

Earlier quoted context omitted.

Absolutely. I'm not sure how universal this is, but I saw George Hotz tweeted something about Mythos not being such a big deal since he's able to find security issues without a claimed $20,000 in token spend per vulnerability. The reality is that humans aren't perfect, so we do not make "perfect programs". It is also possible to test it yourself to see how good LLMs are at finding software issues: Find any open sourc…

I'm sure if somebody hired him for a pentest it'd cost more per vulnerability found.

I think his point was more that he didn't believe it was difficult to find these issues.

Could be Dunning-Kruger, but if AI models continue to get better this trend will surely continue.

Re: SQLite Critical CVEs or LLM Slop?

#133

Post by zuzululu »

ChrisMarshallNY wrote: post #4

The problem with this kind of thing, is that it reduces the S/N (Signal-to-Noise) ratio, so weeding out the legit CVEs becomes a lot more difficult. But, on the other hand, I do know that LLMs have been discovering a lot of legit CVEs, and I will lay odds that the blackhats are leveraging them to the max.

This is an issue with CVEs not LLMs

Re: SQLite Critical CVEs or LLM Slop?

#134

Post by insanitybit »

inigyou wrote: post #116
insanitybit wrote: post #96

Earlier quoted context omitted.

That's nonsense. The goal is and always has been to undermine the CVE system because Greg does not believe in the system. The kernel is the only project that marks CVEs to fixes, it's the only project that considers every bug to be a "Security" bug, and it has a multi-decades long history of telling the security world to fuck off - all consistent with what I've said. No one else has the process that the kernel has, d…

Or maybe it's ideologically motivated that other groups only identify certain bugs as security bugs?

Make a case then. My case is that Greg has, for decades, said that he hates the CVE system and rejected it and that the kernel objectively labels CVEs based on fixes (not the standard at all, CVEs are for vulns), etc. I can point to so many objective pieces of evidence to support my claim.

You seem to have a vague, leading question. If you want to say something about "other groups" or ideologies, go ahead.

Re: SQLite Critical CVEs or LLM Slop?

#136

Post by insanitybit »

oxydite wrote: post #135

Damn, dunno why I've always assumed that if something gets a CVE, then some authority has reproduced and verified it. Shouldn't it be CNA's job? Why would anything get a number if it hadn't been verified?

The current system is radically overwhelmed and has been seeing cuts over the last few years.

> then some authority has reproduced and verified it.

No, the system puts a lot of trust into the submitter.

Re: SQLite Critical CVEs or LLM Slop?

#137

Post by renezander030 »

jodacola wrote: post #85
ChrisMarshallNY wrote: post #4

The problem with this kind of thing, is that it reduces the S/N (Signal-to-Noise) ratio, so weeding out the legit CVEs becomes a lot more difficult. But, on the other hand, I do know that LLMs have been discovering a lot of legit CVEs, and I will lay odds that the blackhats are leveraging them to the max.

I'm sending all my condolences out to everyone who is in a corporate environment using tools like Veracode or Snyk to automatically assess for CVEs and block merges or deployments based on "findings". My experience in such environments leads me to believe this is going to be a rough ride for those heavily locked-down enterprises, because depending on the environment, an exception of "this CVE was hallucinated by AI"…

[dead]

Re: SQLite Critical CVEs or LLM Slop?

#138

Post by heresie-dabord »

flerchin wrote: post #39
ChrisMarshallNY wrote: post #4

The problem with this kind of thing, is that it reduces the S/N (Signal-to-Noise) ratio, so weeding out the legit CVEs becomes a lot more difficult. But, on the other hand, I do know that LLMs have been discovering a lot of legit CVEs, and I will lay odds that the blackhats are leveraging them to the max.

The vast majority of CVEs are not exploitable, basically noise. I suspect that the overwhelming majority of the CVEs being generated by LLMs are either noise of the sort in the linked article or noise of the sort that is not exploitable.

CVE-2026-4I5109 - Your kitchen drawer contains forks, which can maim and/or kill. An attacker with kitchen access could access the drawer. See...

CVE-1972-404: The code is written in C. ^_^

Re: SQLite Critical CVEs or LLM Slop?

#139

Post by red75prime »

gortok wrote: post #52

We can chalk this up as another example of over-exhuberance by what folks believe LLMs can accomplish vs. what they actually are. LLM-based “AI” is able to use its vast corpus of inputs and calculate the most statistically likely output in a given situation. It is probabilistic, and when you are dealing with probabilities in a situation where certainties, not probabilities, matter, you’re going to get dinged on credi…

Apophatic intelligence? "We don't know what intelligence is, but LLMs with CoT are certainly not it despite being Turing-complete."

Watching for unexpected failure modes is surely worth it.

Re: SQLite Critical CVEs or LLM Slop?

#140

Post by vorticalbox »

cogman10 wrote: post #56
flerchin wrote: post #39

Earlier quoted context omitted.

The vast majority of CVEs are not exploitable, basically noise. I suspect that the overwhelming majority of the CVEs being generated by LLMs are either noise of the sort in the linked article or noise of the sort that is not exploitable.

This is what I truly don't like about the CVE system. One such example is CVE-2023-45853 [1]. Zlib included in it's source an extra set of utilities and add-ons. One such utility, MiniZip, had a buffer overflow vulnerability. BAM, 8.8 CVE (was a 9, looks like they pulled it back a bit). But not one that the 99% of applications using zlib would ever be vulnerable to because almost nobody used the MiniZip utility. It w…

same things happens with npm and CVEs, most of the ones that bubble up aren't even called in my application so are no applicable.

go lang has a scanner [0] which only shows issues when the code actually calls the effected functions.

[0] https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck

Post reply on HN