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

Dear Linux Kernel CNA, what have you done?

amanitasecurity.com

Post reply on HN
Print view View original

111–116 of 116 posts

Re: Dear Linux Kernel CNA, what have you done?

#111

Post by _tk_ »

tsujamin wrote: post #102
tptacek wrote: post #100

Earlier quoted context omitted.

The fact that every competent organization has slightly different brackets for those levels is only one of the many reasons why CVSS is a joke.

CVSS has consistent rules, but yeah then incentives that make people ignore particular rules (vulnerability chaining being the one that I’ve seen before) makes the public scores questionable sometimes. Still it’s a useful, if imperfect, tool in our industry I think.

Take a look at FIRST‘s FAQ wrt Supplemental Metrics.

It’s so complicated you have to have a degree in CVSS to properly rate a vuln and it’s also highly subjective - which they want it to be.

[1]: https://www.first.org/cvss/v4.0/faq

Re: Dear Linux Kernel CNA, what have you done?

#112

Post by amluto »

tptacek wrote: post #47

The purpose of CVEs is to ensure that people discussing vulnerabilities are talking about the same thing. CVEs aren't a checklist, they aren't a perfect enumeration, and it shouldn't matter if a CVE is issued for a nonissue. People who are burdened by requirements to ship (or produce rolling updates) to address every Linux kernel CVE are living in a state of sin. It doesn't make sense for the kernel CNA to alter its…

I think I agree. Erring in the direction of too many CVEs means that people trying to get bug fixes rolled out won’t need to deal with the dreaded “ok, we understand the problem, but we can’t actually fix it in our systems until it has a CVE” that comes all too often from distributors.

Re: Dear Linux Kernel CNA, what have you done?

#113

Post by mmc »

guardiangod wrote: post #84

Has any one in this thread actually evaluated all ~320 CVEs since Feb 20? Because I have. And I literally just finished writing a filter script for MITRE's cve.org API output. 1. Most of the new CVEs have potential security concerns. At the very least, they would have been assigned a CVE if they were reported by an external researcher. 2. Many of them don't affect the older LTS branches. 3. I found 1 (1!) CVE that ha…

> There are other ways to lessen the CVE workload.

> 1. Disable unused components with defconf or make menuconfig.

+1 for avoiding vulnerabilities, but were you saying this lessens the CVE evaluation workload? I'd love to hear about automation for evaluating CVEs based on a kernel config. I've done a fair amount of that manually and I'm not aware of any metadata in the CVE records (or in the CVE json in gregkh's new vulns repo) that includes config metadata.

Re: Dear Linux Kernel CNA, what have you done?

#114

Post by tptacek »

lokar wrote: post #83
tsujamin wrote: post #59

Earlier quoted context omitted.

you’re missing the CVSS aspect which is intrinsically tied to CVE issuance (atleast when issued through the CNA-LR). It’s not _just_ an identifier, it’s a entirely valid and useful tool of triage and classification

For me, CVSS and the people who use it lost all credibility when they asked my team for a urgent update to patch… a pcmcia bug in the kernel of our EC2 instances.

It's so easy to come up with stories about this that you don't really even need examples. I think everybody just sort of understands that if you put CVSS to the test, it would be ludicrously easy to stack two 8.0+ vulnerabilities next to each other with wildly different severity.

Re: Dear Linux Kernel CNA, what have you done?

#115

Post by alasarmas »

I hate to get all meta (no I don’t sorry not sorry), but there is 100% a thing where every word that means (a) some important thing and (b) some less important thing ends up being a word that, for the vast majority of people, carries something like the emotional impact of definition (a) and the actual meaning of definition (b). For example, “literally” now means “figuratively”, “scan” now means “skim”, “authentic” means “expensive”, and so on. It’s basically Gresham’s Law [0] where less-consequential definitions of words drive more-consequential definitions of the same out of the marketplace.

0. https://en.wikipedia.org/wiki/Gresham%27s_law

Re: Dear Linux Kernel CNA, what have you done?

#116

Post by fargle »

sour-taste wrote: post #53

This article does a good job explaining the Linux kernel position on cves: https://lwn.net/Articles/961978/ The relevant part: > Kroah-Hartman put up a slide showing possible "fixes" for CVE numbers. The first, "ignore them", is more-or-less what is happening today. The next, option, "burn them down", could be brought about by requesting a CVE number for every patch applied to the kernel. They intend to burn down the…

"burn them down" is kind of a brilliant political move.

on one hand, it's true to the "all bugs are security bugs (and the converse is obviously true)" position.

on the other hand, it will demonstrably cause hassles for what i term the "checklist security" people. "oh noes we only have the budget for N CVEs per release and we must have NONE > $arbitrary-number". and so that's a very good thing because checklist-security like that is far worse than nothing at all.

on the the other-other hand, in more legitimate, well engineered downstream user, a CVE for every bug may conversely actually help real security. "all" you have to do is evaluate every single potential security flaw's real actual applicability and impact for your use case. and if you can't afford that - faking it with a check-the-box mentality is no substitute. but maybe you can afford that? if so better data will probably help, not hurt.

finally, the other concrete improvement is that the people closest to the product will be able to more accurately judge the CVE score and more quickly correct outliers. a local privilege escalation that requires enhanced privileges to execute is not an 8. i'd much rather have 1000 CVEs with appropriate scores than 10 that are massively overrated and stupid. of course, a simple one-dimensional metric is hogwash anyway, but - baby steps.

Post reply on HN