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

61–70 of 406 posts

Re: SQLite Critical CVEs or LLM Slop?

#61

Post by worthless-trash »

inigyou wrote: post #51
insanitybit wrote: post #24

Earlier quoted context omitted.

This is what the Linux kernel is currently attempting since becoming a CNA. edit: "This" being to sabotage the CVE system via DoS, to be clear.

What do you mean? It isn't a DoS to assign every single bug fix a CVE! Every single bug is making someone vulnerable in some way.

> What do you mean?

No analysis is being done in the linux kernel to assess vulnerability.

> It isn't a DoS to assign every single bug fix a CVE!

On people who care about this, it is, not in the project itself though.

> Every single bug is making someone vulnerable in some way.

Not every bug is making someone vulnerable. (docs bugs, test bugs) behavioral changes, performance improvements, the list goes on.

Re: SQLite Critical CVEs or LLM Slop?

#62

Post by bluGill »

YeahThisIsMe wrote: post #23
anygivnthursday wrote: post #21

Earlier quoted context omitted.

If I remember correctly, we had to patch or provide justification for CVEs flagged by tools like AWS Inspector for SOC2 as well.

So you didn't have to patch all of them.

No, but if you don't patch them you need to convince an auditor that they are not a problem. Often patching is easier.

I'm working on such a problem now - we are using an old web browser (no longer supported) to show help on one system. That is web pages were generate internally, with no links elsewhere, and no provision for the user to enter a URL. It is still easier port to a newer supported browser than to convince the auditors that that we are not exploitable. Sure it is obvious that everything is internal and we won't write html that exploits bugs, but nobody wants to convince an auditor of that.

Re: SQLite Critical CVEs or LLM Slop?

#63

Post by pbronez »

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.

I once had a customer threaten to reject a delivery over a CVE. I dug into it. The CVE was that an Ocaml PostgreSQL client didn’t implement an authentication feature.

I convinced the customer to accept the delivery by pointing out that (1) our app had zero lines of ocaml and (2) the feature had been implemented in the ocaml driver since the CVE was issued.

Re: SQLite Critical CVEs or LLM Slop?

#64

Post by vrighter »

lucideer wrote: post #9
inigyou wrote: post #3

This is going to be fun for organizations that are mandated to patch all CVEs, isn't it?

I'm very curious what organisations would have such a policy. I can't imagine it being viable for any size of org without significant self-deception (or banning the use of all open source at which point CVEs are moot anyway).

I have been given a list by security. "We had an automated tool scan that machine. It reported these. Fix anything medium severity and above.

Never mind that some of them involved vulnerabilities in some part of the bluetooth stack (servers in our datacenter don't even have bluetooth). But they just didn't care

Re: SQLite Critical CVEs or LLM Slop?

#66

Post by michaelt »

lucideer wrote: post #9
inigyou wrote: post #3

This is going to be fun for organizations that are mandated to patch all CVEs, isn't it?

I'm very curious what organisations would have such a policy. I can't imagine it being viable for any size of org without significant self-deception (or banning the use of all open source at which point CVEs are moot anyway).

SOC2 CC7.1 [1] requires a vulnerability scanner, findings tracked with tickets, assigned severities according to a documented risk-based system, severity-based SLAs for remediation, and that the SLAs mostly be complied with or have tracked exceptions.

However it doesn't mandate any particular SLA, or the details of how risks are to be evaluated.

Organisations get to write their own policy, and they don't need to commit to patching every CVE within 24 hours or anything like that.

[1] https://www.compliancebase.org/controls/soc-2/cc7-1

Re: SQLite Critical CVEs or LLM Slop?

#67

Post by bluGill »

lucideer wrote: post #22
SirFatty wrote: post #10

Earlier quoted context omitted.

ITAR

ITAR has no such hard requirements. Might be some orgs that tell themselves they're attempting this under ITAR but they're not doing it in any comprehensive way. The only thing within ITAR that I'm aware of concerning itself with software supply chain is SP 800-218 requirements & that's just a load of open-to-interpretation weasel words about having CVE detection & automations in place & some defined plans for reduci…

Yes and no. ITAR (and other laws like it) are self assessment and don't specifically say thing thing.

However your interpretation / self-assessment is subject to various reviews/audits. These days the reviewers are not going to be kind to someone who just says "not an issue", they will demand strong justification. Most organizations take the view that is is easier to fix all CVEs than try to pass audits.

Thus by the letter of the law you are correct. However to meet the letter of the law without fixing CVEs is generally seen as harder than thus fixing CVEs. So the effect is ITAR (and similar laws) force you to fix CVEs.

Re: SQLite Critical CVEs or LLM Slop?

#69

Post by dgellow »

inigyou wrote: post #3

This is going to be fun for organizations that are mandated to patch all CVEs, isn't it?

One can hope that will put pressure on the industry to design a better system than CVEs. The signal noise ratio was already terrible before LLMs, I cannot imagine that will still be a meaningful system in 10y.

But I’m too cynical to not consider all the middlemen who benefit from the status quo

Re: SQLite Critical CVEs or LLM Slop?

#70

Post by post-it »

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…

But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.
Post reply on HN