How to solve the problem of the CVE system being broken. 1: Become a CNA. 2: Implement a system for issuing CVEs that is designed for the sole purpose of making sure you never have to interact with the CVE system. 3: ??? 4: Profit (AKA: People are trained to accept that CVEs are useless to you, and learn to stop caring about your project having them.)
CVE-s have become one of those useless metrics, that companies like to obsess with, like compiling with zero warnings. And I'm sure that _many_ companies just soiled themselves in fear, because they have signed some stupid "Zero CVE" commitment, and now the Kernel alone makes this impossible to keep.
@@EvanOfTheDarkness If you make it impossible, companies will be forced to give up on stupid zero CVE commitments whether they want to or not. Corporate will have only two options, stop caring or go insane. In the end, IT will be freed from a stupid, corporate mandate made by suits who don't know anything.
Unfortunately there is a very, very common reason to stick with old kernels that's unavoidable, you mentioned it, but drivers are the main part of that, especially nvidia. I have a machine that can't be moved past 6.8, and there are embedded systems that have zero driver support above 2.4, yes that's kernel version 2.4, not a distro or something. There are millions of tablets, routers and set top boxes shipping today in this condition.
To be fair to the other side, all products have a number of years of official software support. After that, that's (one of the) reason(s) nouveau exists. It's abtrade off, the user has to make, at the end of the day.
When I first started dabbling, I was impressed by the difference in threat model between desktop Linux and Windows. Here (at least when it comes to non-desktop-specific components like the kernel), ANYTHING that could lead to a crash or system resource exhaustion forced by a non-root user is considered a 'critical security vulnerability' and addressed as such, generally with specific change-logs attached to the update (as is appropriate for a multi-user/server OS, where a limited user of your system attempting to disable it is part of your threat model), whereas from the (generally very limited) documentation on patches issued in Windows 7 (the last version I had), it seemed that most of the security issues were fixing totally unprivileged RCE routes. (a copy-pasted "something something fixes a problem allowing an unauthenticated remote attacker to gain control of your system" was often the entirety of the 'technical details' on a Windows patch, if you expanded it. It's possible it was being misused for more minor fixes, but I remember it came up for what seemed like the majority of security updates with relatively little variation other than sometimes the word 'remote' being deleted.). While in theory this is fine for a single-user personal-computer OS, Windows is seriously overused for what it is, and I'm far more comfortable with overly-paranoid multi-user OS components being 'creatively used' in a desktop operating system than the other way around. Always better to plan for a more hostile environment than you actually face in practice.
Best description i can think of is. Developers have mentioned before that they treat any bug in the network stack as a security issue - so now that they're a CNA, it makes sense that there would be a percieved bump in bugs getting assigned a CVE #.
@@kreuner11 Then why didn’t you say that in regards to someone just having a ‘curious question’ and you instead responded with a smarmy question? You literally could have just said that, but instead, you thought it was something to be a smartass about. Just saying. Not saying you didn’t have a point, but you could have…just said it.
2:33 fair enough, there is a huge corpus of examples of people exploiting things no one thought were exploitable. Usually one person discovers a while new attack vector (speculative execution stage) and then all sorts of new research finds new vulns
No, the Kernel do get these out there, they do get flagged on peoples radar (there are services for it), Its good. Because one system might be exploitable given the complex hopps to get there.But people won't upgrade, unless something flags it. Noone (should) care about the amount, just the "does this affect me bit".
@@joseoncrack While true, that's simple not the case for most. This is why you need to read security bulletins by distros and agencies that do that second or third pass of assessment on actual application outside of the kernel dev space. Really Linux kernel CVEs aren't for you, unless you are literally the security implementation lead in a government or business.
Ar 12:40, you mention a bug with "negative impact to integrity" is called a vulnerability, so I think you are wrong at 14:15 saying "data corruption [is] not a vulnerability according to the CVE", as data corruption surely has "negative impact to integrity" (of the data being corrupted).
I actually really love the duality of the Linux kernel philosophy: - We have absolutely no way of controlling for all the insane user configurations - *We do not break userspace*
@@rizkyadiyanto7922 I guess overall all this confusion happen because it is pretty iffy to treat the CVE system as a bug tracking system and it requires ignoring the consumers of such CVE - primitive automatic scanners that match version to list CVE and security auditors which read them and either care or don't care enough to investigate or outright deny/allow In this regard you wouldn't hit sparc related DoS if you use x86 and as an auditor you would need to manually plow through it(I also doubt with the tagging as CVE in general if there is no clear exploitation path and way to test against it). monolithic or microkernel is also not that interesting in this regard, if there is buffer overrun in some network card for sgi o2 or G5 Power machine it probably not interesting for the security analyst to audit it, and would be more noise he need to clear out when a server stops to update on top of the existing endless noise he have in this regard not counting actual job meetings. On top of it, it is counter productive for the effort involved with CVE note above and will likely cause the opposite of security - once a package have enough CVE you can't effectively audit and is big/core/trusted enough it would just be whitelisted or outright denied as there are no tools or intentional capabilities to audit that much
It sounds like it doesn't matter what I think. The EU has decided that if you don't do it this way, you could face legal nastiness. And really, it's not the worst way to handle it. Many or most of the bugs aren't going to affect many or most of the users, and confidentiality is a little hard to maintain, so they just plow through the bugs and mark the ones that need it as CVEs and just fix them like any other bug. Seems fair to me.
Those static sounds almost freaked me out. I was thinking "what's wrong with my audio setup?" checking every connection until I realized it was from the video 🤣
I 100% agree with the your critical CVE isn't mine and vv. Most of the generic Linux (as the total OS) CVE's do not apply to my systems, and some *bugs* make my systems crash. I even had a discussion with a client that required me to upgrade my base system due to it being based on an EOL user space (which is unreachable). And then they show me network appliances in their network that were based on systems that EOL'd 20 years ago, and they never question that because of the name. There are a number of airgapped systems that just run code of 25 years ago. As long as they are airgapped there is no vulnerability. Security and exploitability is very very environment dependent. Personally I think the CVE'ing of bugs is good. But it means more work for me :-(. At least it gives me an area to focus on to see if a CVE can be relevant or not.
I’d love a tool that generates some hash of my kernel, including every driver I have installed, the boot process etc. And then another tool that can filter out anything I don’t even have compiled, and highlight anything concerning modules and drivers that I definitely am using all the time. I don’t have an issue with endless stream of CVEs. My only issue is with the inflated scores we nowdays see. There has never been a 9.9 in my eyes because not once has a nationstate declared a full on emergency to deal with a CVE.
I've been saying it for years, the CVE process is broken and we need better *programatic* tooling that can evaluate if your use can even trigger the relevant code path, let alone the bug contained in that path
Maybe absolutely require a proof of concept. You shouldn't call something a vulnerability if you didn't make code that targets that stuff directly and can actually be malicious.
@@BrodieRobertson Perhaps try different lighting, probably because of the quantization parameter (how flat your video is, so if it's flatter then youtube would try to compress it more)
@@fghsgh btw the number that you guys see on the video page and one I see aren't the same for usually the first day or so of a video. RUclips makes use of eventual consistency and it doesn't really matter if the viewer sees the wrong number. From my side the video is performing perfectly fine
Imagine if somebody who was assigning CVE's to Wayland bugs realised that Gnome's client side decorations could be abused by malicious actor in phishing manner i.e. by showing „close button” which i.e. runs rm -rf.
That makes zero sense. If you could make a "fake" button do something it shouldn't, then you could also just ... do that. If a program has the permissions to create a button that rm -rf 's your home directory they also have permission to just do it silently with no input the moment you execute it.
If malicious code runs on a system it is not a bug when the malicious code abuses an API or Framework, unless it causes privilege escalation, escapes a sandbox or does denial of service. Malicious code running a shell command or deleting files is not a bug. Any non sandboxed code can use the unlink syscall to delete files the current users has permission to delete or use execv to run commands.
Excellent breakdown of a complex topic. Everything I heard sounds accurate to reality. It sounds like Linus is running shop like most companies should be (and often don't). Eventually Rust will be a boon here, but now I've heard more about where Rust vs existing C tooling and where many kernel needs can't be done with Rust even on unstable. I'm now in camp of start with Zig 1st IF that will help and work more smoothly with tooling, but keep an eye to Rust for down the road.
I would not recommend zig for a production environment (or even a serious hobby project you plan to stick with for the long haul) even slightly given how drastically it changes between versions. i have faith it'll be great once it hits 1.0 but that is a long ways away.
@@meaty-bunny You seem to be experiencing the Dunning-Kruger effect. Only those at the peak of Mt. Stupid would have such overconfidence in their skill that they'd purposely neglect to use the better tool. It's never wise to be irresponsible.
using an LLM to find vulnerabilities is an interesting approach, im sure algorithms are super great at analysing all code that has caused CVE´s and then it could look for patterns in non CVE code to see if it finds CVE patterns and a LLM is a convenient way of interfacing with an algorithm but im not entirely sure if thats the algorithm that should be doing the work. Unless of course its a custom LLM specifically trained for it but for example ChatGPT would be a nightmare with it constantly making something up and most other LLM´s would have the same problem.
Im sorry, the takes here are just nonsensical to me. "Oh no, nearly any Kernel bug is a vulnerability because of DOS potential." - Well yes. Yes it is. You have just discovered you're building a product of criticality and not just some random app. "Data corruption is not a vulnerability" - Data corruption IS a vulnerability because the availability criteria of the data are violated. These criteria do not only apply to the running system but also at rest and it's nonsensical to think of them in this narrow manner to anyone actually using the kernel.
5:58 Not to mention ChromeOS, which is based on (ironically enough) Gentoo
Ewe .... Gentoo. Should just learn arch....
redhat engineers doing that is kinda based
How to solve the problem of the CVE system being broken.
1: Become a CNA.
2: Implement a system for issuing CVEs that is designed for the sole purpose of making sure you never have to interact with the CVE system.
3: ???
4: Profit (AKA: People are trained to accept that CVEs are useless to you, and learn to stop caring about your project having them.)
CVE-s have become one of those useless metrics, that companies like to obsess with, like compiling with zero warnings.
And I'm sure that _many_ companies just soiled themselves in fear, because they have signed some stupid "Zero CVE" commitment, and now the Kernel alone makes this impossible to keep.
@@EvanOfTheDarkness If you make it impossible, companies will be forced to give up on stupid zero CVE commitments whether they want to or not. Corporate will have only two options, stop caring or go insane. In the end, IT will be freed from a stupid, corporate mandate made by suits who don't know anything.
Unfortunately there is a very, very common reason to stick with old kernels that's unavoidable, you mentioned it, but drivers are the main part of that, especially nvidia. I have a machine that can't be moved past 6.8, and there are embedded systems that have zero driver support above 2.4, yes that's kernel version 2.4, not a distro or something. There are millions of tablets, routers and set top boxes shipping today in this condition.
Tldr; run the latest kernel, if you can't? File a complaint with the vendor (they probably don't comply with GPL either) and try to keep it sandboxed.
Didn't nvidia go open source?
To be fair to the other side, all products have a number of years of official software support. After that, that's (one of the) reason(s) nouveau exists. It's abtrade off, the user has to make, at the end of the day.
Set top boxes, what's someone going to do if they hack into my set top box? run up my cable bill with on demand and pay per view purchases?
@@fuseteamthe closed source binary blob in the kernel was replaced by an open source interface to closed source binary blobs outside of the kernel.
When I first started dabbling, I was impressed by the difference in threat model between desktop Linux and Windows. Here (at least when it comes to non-desktop-specific components like the kernel), ANYTHING that could lead to a crash or system resource exhaustion forced by a non-root user is considered a 'critical security vulnerability' and addressed as such, generally with specific change-logs attached to the update (as is appropriate for a multi-user/server OS, where a limited user of your system attempting to disable it is part of your threat model), whereas from the (generally very limited) documentation on patches issued in Windows 7 (the last version I had), it seemed that most of the security issues were fixing totally unprivileged RCE routes. (a copy-pasted "something something fixes a problem allowing an unauthenticated remote attacker to gain control of your system" was often the entirety of the 'technical details' on a Windows patch, if you expanded it. It's possible it was being misused for more minor fixes, but I remember it came up for what seemed like the majority of security updates with relatively little variation other than sometimes the word 'remote' being deleted.). While in theory this is fine for a single-user personal-computer OS, Windows is seriously overused for what it is, and I'm far more comfortable with overly-paranoid multi-user OS components being 'creatively used' in a desktop operating system than the other way around. Always better to plan for a more hostile environment than you actually face in practice.
Best description i can think of is. Developers have mentioned before that they treat any bug in the network stack as a security issue - so now that they're a CNA, it makes sense that there would be a percieved bump in bugs getting assigned a CVE #.
If theres so many cve in an open source kernel, imagine how many are hiding in windows
did you watch the video?
@@kreuner11No, So cite a timestamp for how many they are hiding in windows rather then asking a pressumptive question.
@@twenty-fifth420 the point is that not ever CVE is an actual vulnerability, and even then it heavily depends on your computers setup
@@kreuner11 Then why didn’t you say that in regards to someone just having a ‘curious question’ and you instead responded with a smarmy question?
You literally could have just said that, but instead, you thought it was something to be a smartass about. Just saying. Not saying you didn’t have a point, but you could have…just said it.
@@twenty-fifth420 this ain't Twitter
2:33 fair enough, there is a huge corpus of examples of people exploiting things no one thought were exploitable. Usually one person discovers a while new attack vector (speculative execution stage) and then all sorts of new research finds new vulns
No, the Kernel do get these out there, they do get flagged on peoples radar (there are services for it), Its good. Because one system might be exploitable given the complex hopps to get there.But people won't upgrade, unless something flags it. Noone (should) care about the amount, just the "does this affect me bit".
Sure, but the more there are and the harder it gets to determine which ones could affect you.
@@joseoncrack While true, that's simple not the case for most. This is why you need to read security bulletins by distros and agencies that do that second or third pass of assessment on actual application outside of the kernel dev space. Really Linux kernel CVEs aren't for you, unless you are literally the security implementation lead in a government or business.
9:55 damn I got hit with the imaginary exploit
Haha, same.
Well, time to use windows i guess!
No, please don't
Btw, i watched the entire video. TRUST ME
@@no_name4796 i don't trust you
I already was so confused a Linux user promoting windows hahahaha
Ar 12:40, you mention a bug with "negative impact to integrity" is called a vulnerability, so I think you are wrong at 14:15 saying "data corruption [is] not a vulnerability according to the CVE", as data corruption surely has "negative impact to integrity" (of the data being corrupted).
If they clearly state the sub-system and have a good scoring attached to it... totally fine, seems appropriate.
I actually really love the duality of the Linux kernel philosophy:
- We have absolutely no way of controlling for all the insane user configurations
- *We do not break userspace*
Greg: if you aren't running the latest (LTS) kernel your system is insecure
Android: aight bet
Android 4.19 gang here XD
Latest does not mean newest LTS branch, it means the newest version of that branch
@@braapybobby let's gooooo
@@BrodieRobertson right because multiple LTSes can exist
@@fuseteam 4.19 is the next to be dropped but it's still getting patches
i dont get why the cve is per the kernel and nnot per device driver or architecture
to make it big and spooky so people are scared and use apple / microsoft products instead even though they're less secure.
Because most bugs in the kernel are a denial of service security issue due to crashes.
because its monolithic kernel.
Because those are part of the kernel. It would be so much messier to have it split up like that.
@@rizkyadiyanto7922
I guess overall all this confusion happen because it is pretty iffy to treat the CVE system as a bug tracking system and it requires ignoring the consumers of such CVE - primitive automatic scanners that match version to list CVE and security auditors which read them and either care or don't care enough to investigate or outright deny/allow
In this regard you wouldn't hit sparc related DoS if you use x86 and as an auditor you would need to manually plow through it(I also doubt with the tagging as CVE in general if there is no clear exploitation path and way to test against it).
monolithic or microkernel is also not that interesting in this regard, if there is buffer overrun in some network card for sgi o2 or G5 Power machine it probably not interesting for the security analyst to audit it, and would be more noise he need to clear out when a server stops to update on top of the existing endless noise he have in this regard not counting actual job meetings.
On top of it, it is counter productive for the effort involved with CVE note above and will likely cause the opposite of security - once a package have enough CVE you can't effectively audit and is big/core/trusted enough it would just be whitelisted or outright denied as there are no tools or intentional capabilities to audit that much
It sounds like it doesn't matter what I think. The EU has decided that if you don't do it this way, you could face legal nastiness. And really, it's not the worst way to handle it. Many or most of the bugs aren't going to affect many or most of the users, and confidentiality is a little hard to maintain, so they just plow through the bugs and mark the ones that need it as CVEs and just fix them like any other bug. Seems fair to me.
Those static sounds almost freaked me out. I was thinking "what's wrong with my audio setup?" checking every connection until I realized it was from the video 🤣
I think I've worked out the issue, I blame KDE
@@BrodieRobertson Always blame KDE.
I 100% agree with the your critical CVE isn't mine and vv. Most of the generic Linux (as the total OS) CVE's do not apply to my systems, and some *bugs* make my systems crash.
I even had a discussion with a client that required me to upgrade my base system due to it being based on an EOL user space (which is unreachable). And then they show me network appliances in their network that were based on systems that EOL'd 20 years ago, and they never question that because of the name.
There are a number of airgapped systems that just run code of 25 years ago. As long as they are airgapped there is no vulnerability.
Security and exploitability is very very environment dependent.
Personally I think the CVE'ing of bugs is good. But it means more work for me :-(. At least it gives me an area to focus on to see if a CVE can be relevant or not.
I’d love a tool that generates some hash of my kernel, including every driver I have installed, the boot process etc. And then another tool that can filter out anything I don’t even have compiled, and highlight anything concerning modules and drivers that I definitely am using all the time.
I don’t have an issue with endless stream of CVEs. My only issue is with the inflated scores we nowdays see. There has never been a 9.9 in my eyes because not once has a nationstate declared a full on emergency to deal with a CVE.
honestly, so long as they are marked as "no biggie", there can be 1000 a week for all I care.
Ideally I would've liked to see a chart with the distribution of severity. I assume these are mostly low severity scoring 1.0-3.0?
I find the concept of nested abbreviations troubling: it isn't CNA , it is a CVENA
What do you do if it's recursive
@@BrodieRobertson I think the best way to resolve a halting problem is to let it run and see if it ever halts...
😂
gnunununununununu
I don't see what's the problem here. I will rewatch it later.
There isn't one, just explaining the methodology behind why there are so many
@@BrodieRobertson ok, tanks
I've been saying it for years, the CVE process is broken and we need better *programatic* tooling that can evaluate if your use can even trigger the relevant code path, let alone the bug contained in that path
Maybe absolutely require a proof of concept. You shouldn't call something a vulnerability if you didn't make code that targets that stuff directly and can actually be malicious.
if riemann_hyphothesis_is_true() {hack();}
Go ahead, prove it is or isn't dangerous.
Don't even try to fix it until then.
So are the CVE's scored and prioritized in any way, or is it just FIFO no matter how long it takes or how important a fix is?
This was not covered in the talk sadly
i've either got powerelectronics ingrained on my mind or there's some mic problems around 10:00
yea no this is on brodie's end
@8:33 a very audible under run, maybe you need to enable real time audio on your system or increase the quantum size ;)
05:24 kernel did break userspace: pwntools issue 1871
i love your outro
How dare you say I have a vulnerability 😭
This is hardcore level im just a mouse driver...
Why does your camera look like 480p even though I am watching at 1080p
I have tried to work out why things get so compressed for a long time
@@BrodieRobertson Perhaps try different lighting, probably because of the quantization parameter (how flat your video is, so if it's flatter then youtube would try to compress it more)
Doesn't this mean its even easier to locate Linux Kernel CVEs and therefore make it easier to patch them?
Are you people sure it's the Kernel and not the SystemD?
So weird to only see one comment
And barely 1K views
Lol, apparently either youtube is on drugs, or nobody gives a f about the kernel
huh, yeah, this seems bad
hope this video ends up performing well after all, this is exactly the kind of content i want
@@fghsgh btw the number that you guys see on the video page and one I see aren't the same for usually the first day or so of a video. RUclips makes use of eventual consistency and it doesn't really matter if the viewer sees the wrong number. From my side the video is performing perfectly fine
Imagine if somebody who was assigning CVE's to Wayland bugs realised that Gnome's client side decorations could be abused by malicious actor in phishing manner i.e. by showing „close button” which i.e. runs rm -rf.
Brainrot take. If you can draw to the screen, you can delete data.
Every desktop allows for client side decorations, GNOME just forces them
That makes zero sense. If you could make a "fake" button do something it shouldn't, then you could also just ... do that. If a program has the permissions to create a button that rm -rf 's your home directory they also have permission to just do it silently with no input the moment you execute it.
If malicious code runs on a system it is not a bug when the malicious code abuses an API or Framework, unless it causes privilege escalation, escapes a sandbox or does denial of service. Malicious code running a shell command or deleting files is not a bug. Any non sandboxed code can use the unlink syscall to delete files the current users has permission to delete or use execv to run commands.
Excellent breakdown of a complex topic. Everything I heard sounds accurate to reality. It sounds like Linus is running shop like most companies should be (and often don't). Eventually Rust will be a boon here, but now I've heard more about where Rust vs existing C tooling and where many kernel needs can't be done with Rust even on unstable. I'm now in camp of start with Zig 1st IF that will help and work more smoothly with tooling, but keep an eye to Rust for down the road.
Zig is neither memory safe nor released (0.13 Alpha). So I'm not sure why you'd recommend Zig at all here.
I would not recommend zig for a production environment (or even a serious hobby project you plan to stick with for the long haul) even slightly given how drastically it changes between versions. i have faith it'll be great once it hits 1.0 but that is a long ways away.
@@mmstickSoydev: “I need the tool to do the thinking for me”
@@meaty-bunny You seem to be experiencing the Dunning-Kruger effect. Only those at the peak of Mt. Stupid would have such overconfidence in their skill that they'd purposely neglect to use the better tool. It's never wise to be irresponsible.
@@mmstick You’re the spitting image of a soydev. X)
using an LLM to find vulnerabilities is an interesting approach, im sure algorithms are super great at analysing all code that has caused CVE´s and then it could look for patterns in non CVE code to see if it finds CVE patterns and a LLM is a convenient way of interfacing with an algorithm but im not entirely sure if thats the algorithm that should be doing the work.
Unless of course its a custom LLM specifically trained for it but for example ChatGPT would be a nightmare with it constantly making something up and most other LLM´s would have the same problem.
Panic on Oops!
I am scared once they documented the cve, it is much easier for certain groups to hunt unpatched or patched cves to attack linux users.
noo noo noo
Im sorry, the takes here are just nonsensical to me.
"Oh no, nearly any Kernel bug is a vulnerability because of DOS potential."
- Well yes. Yes it is. You have just discovered you're building a product of criticality and not just some random app.
"Data corruption is not a vulnerability"
- Data corruption IS a vulnerability because the availability criteria of the data are violated. These criteria do not only apply to the running system but also at rest and it's nonsensical to think of them in this narrow manner to anyone actually using the kernel.
The latest Pop!_OS 24.04 Alpha still ships Linux 6.9.3 from May (and there's no update in the repos).
Do love the latest Linux Content! (not that before was not stricly linux, but eh =)
Edit: Wooo, Debian mentioned!
The kernel does the publishing? And it can't be disabled with a build flag?! Sounds like bloat to me.
CVEs have no relation to build flags.
Beurocracy at its finest.
All that really changes is now there are 4 people who are doing useless job.