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

21–30 of 116 posts

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

#21

Post by mnau »

Avamander wrote: post #19
viraptor wrote: post #15

Earlier quoted context omitted.

> If you can't reason about your codebase to a sufficient extent to actually determine that then something is very wrong. The environment where we write critical code the way we do now is very wrong. It's actually not that easy to figure out if something is exploitable or not. What if you add heap grooming? What if you enable another specific feature? What if an application fights for the same lock? What if measuring…

> The environment where we write critical code the way we do now is very wrong. It's actually not that easy to figure out if something is exploitable or not. Then the correct approach is not to cause "CVE fatigue" that can cause significant second-order effects. Not to mention the fact that who else is better suited to make that assessment? It's unavoidable that an assessment still has to be made because fundamentall…

CVE is just a identifier. CVSS should assign a score.

I would require all CVE to ha attached exploit demo code. Otherwise it's shouldn't be CVE

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

#22

Post by michaelt »

Retr0id wrote: post #10
bhaney wrote: post #2

> Known vulnerabilities are in practice defined as ‘something with a CVE’ Then change that definition and stop operating off of it. It has never been correct.

Most people don't get a choice of which legislation/regulations to comply with.

There's plenty of people in that position, but they're all working at huge corporations. Nobody ends up having to chase things like SOC2 and PCI-DSS without getting paid for it.

Why should unpaid volunteers working on the Linux kernel do compliance work for FAANG-sized companies without getting paid for it? If these companies want the reports carefully triaged, they can send some employees to carefully triage them.

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

#23

Post by kuschku »

Right now, the vast majority of CVEs reported are bullshit filed by wannabe security researchers for resumé padding. Look at all the useless CVSS 9.8's filed against curl. With LLMs, even more bogus reports get filed every single day.

CVEs assigned to every linux commit are more valid than each and every one of those bogus CVEs. Each and every one of them is associated with an actual change in a security-critical project.

If you want the flood of useless CVEs to stop, you have to clean your own house first.

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

#24

Post by throwaway11460 »

viraptor wrote: post #3

While I understand the problems raised in this post, I think they're going a bit too far. The CVEs assigned to the kernel were already specific to various parts of it. You're not running linux-x.y.z, but rather linux-x.y.z + specific config. That means vendors already needed to look at CVEs and decide what applies to them and what doesn't. It's up to NVD records to include how likely something is to be a problem and…

Perhaps people don't care about companies doing it and they don't want to be notified about it?

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

#25

Post by Retr0id »

michaelt wrote: post #22
Retr0id wrote: post #10

Earlier quoted context omitted.

Most people don't get a choice of which legislation/regulations to comply with.

There's plenty of people in that position, but they're all working at huge corporations. Nobody ends up having to chase things like SOC2 and PCI-DSS without getting paid for it. Why should unpaid volunteers working on the Linux kernel do compliance work for FAANG-sized companies without getting paid for it? If these companies want the reports carefully triaged, they can send some employees to carefully triage them.

Nobody (at least, not me) is calling for the Linux foundation to do additional work.

They've taken it upon themselves to assign a CVE to every bugfix, and it's being pointed out that that doesn't seem to be helping anyone.

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

#26

Post by denton-scratch »

Is it true that the Linux Kernel has traditionally deprecated the idea of "security bugs"? I thought the kernel crew took the view that a bug is a bug.

So perhaps this policy is a kind of spoiler response to efforts to require all security bugs to have a CVE allocated.

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

#27

Post by Avamander »

kuschku wrote: post #23

Right now, the vast majority of CVEs reported are bullshit filed by wannabe security researchers for resumé padding. Look at all the useless CVSS 9.8's filed against curl. With LLMs, even more bogus reports get filed every single day. CVEs assigned to every linux commit are more valid than each and every one of those bogus CVEs. Each and every one of them is associated with an actual change in a security-critical pro…

Bad CVEs elsewhere aren't an excuse.

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

#28

Post by eqvinox »

Avamander wrote: post #9
mnau wrote: post #7

CVE DOS - aka denial of service through legislative/regulatory requirements instead of technical attack is going to be fun. Edit: by that I mean filing bogus report or just non-security related CVEs. That is also reason why a lot of projects are trying to register themselves as CNA (see curl etc).

It's going to be fun when companies pick Windows instead of Linux because it doesn't cause an awful to handle patch cycle in contexts where things have to work within some regulatory bounds (that make pointless updates cost a lot of time, effort and money, maybe even cause risk to human life).

> It's going to be fun when companies pick Windows instead of Linux […] work within some regulatory bounds

You can get FuSa (functional safety) certified Linux; to my knowledge this just does not exist for Windows. There may be other situations where the choice does exist, but considering Windows and Linux widely equivalent in this context is not possible.

> maybe even cause risk to human life

Neither Windows nor Linux are, to my knowledge, certified for SoL (safety-of-life) applications. And to no surprise considering this is close to (but not quite) a mathematical proof your system can't hang/crash/starve, which is pretty much impossible for anything beyond an RTOS with current tooling.

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

#29

Post by eqvinox »

Good. Forcing downstream consumers of open source projects to spend resources on identifying and fixing security issues is not just entirely appropriate, but direly needed.

If you're already paying someone to maintain Linux for you, this shouldn't be causing that much trouble; it might need some contractual adjustments but you're already set up to get a stream of "good" updates. The patch frequency may be higher, but other people already do the majority of the work for you.

If you were just ingesting Linux "for free"… well, tough luck. You're profiting from the work of others already, you don't get to complain about not being spoon fed exactly what you need.

In practice, a small number of commercial entities (likely a mix of commercial distributions and designated security companies) will probably offer "Linux as a service". People could do the same work on their own, but that's not cost effective.

Either way, this shift in responsibilities has been long overdue.

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

#30

Post by eqvinox »

Avamander wrote: post #12
phh wrote: post #5

This article largely misses the point from the Linux kernel's point of view. They have always said "Every bug is a security bug". I don't know about more global content, but at Kernel Recipes (2019?) gregkh took a Pixel that was running latest Google security patches that contained all CVEs. Then looked at non-CVE patches he merged in his LTS. And it took him less than an hour to find a DoS vulnerability. I understan…

> They have always said "Every bug is a security bug". If you can't reason about your codebase to a sufficient extent to actually determine that then something is very wrong. If everything is a CVE, nothing is. That approach just wastes a lot of time and effort making people not so familiar with the codebase (as the maintainers) do triage. I hope they get burnt quick by this approach.

> If you can't reason about your codebase to a sufficient extent to actually determine that then something is very wrong.

Linux kernel developers are entirely capable of assessing this. They're just refusing to do it for someone else's definition of a "security bug".

"Every bug is a security bug" means "we fix things when they need fixing, categorizing the fixes is not our job and you'll need to do that yourself".

As such, the current new approach is in fact a concession, there's now a broad pre-categorizing of fixes you can work off.

> making people not so familiar with the codebase (as the maintainers) do triage

You seem to be under the impression that you hadn't needed to do that before. Which, to be fair, worked for a long time. From an engineering perspective this was always a case of "skipping inspections and verification", because the Linux community never agreed to do that work on top of providing the system.

> I hope they get burnt quick by this approach.

How would they get burnt by this? Social pressure from other kernel developers (or even outside) isn't going to have that effect. The only possible influence would be from employers paying for Linux work — in which case it's a perfectly reasonable discussion about spending paid time on security issues.

Post reply on HN