ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
36% Positive
Analyzed from 1389 words in the discussion.
Trending Topics
#linux#kernel#security#cve#more#cves#bugs#those#https#number
Discussion (39 Comments)Read Original on HackerNews
A blog post about this, published at the time: https://sigma-star.at/blog/2024/03/linux-kernel-cna/
The title is editorialized (i.e. the OP made it up), the link simply goes to the kernel CVE mailing list archive.
> Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team.
(And because this happens during the stable release process, there are a lot of 24-hour periods where they issue a ton of CVEs for all the minor bugs fixed in the release.)
[1]: https://en.wikipedia.org/wiki/Failure_mode_and_effects_analy...
We patched for a CVE last week that a malicious usb sound card device could be use the gain root.
On a Vm? Is that something we really need to worry about??
They do not care if the issue is in a piece of code that is never executed and would require full access to the machine. It is there and tool X reports it.
Even security audits are terrible, when they don't find anything major they start reporting stuff that few percent of companies have implemented just to stuff their reports, it is ridiculous.
Then companies started hiring paper pushers into security roles and discretion no longer mattered, it just became a game of "Check the box" with no regard for what is actually running in prod, or whether you're actually vulnerable.
Same shit with auditors. I deal with PCI and it's a fight to explain why the "compensating controls" work to a non technical auditor. If it doesn't check the box exactly, good luck.
> Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team.
This is just Greg being a baby. Linux has to be removed as a CNA ASAP, it was a terrible idea to ever grant them that power.
This has nothing to do with AI or even security.
https://www.bleepingcomputer.com/news/microsoft/microsoft-ju...
https://blog.desdelinux.net/en/virus-in-gnulinux-reality-or-...
Considering no Linux distro come with an antivirus by default, Linux as a desktop was always extremely vulnerable to bad actors.
As a server, I would argue otherwise.
Most distros people use as a desktop are alarmingly insecure by default,the security model lags well behind macOS and even Windows (again, by default. You can of course do work to harden it).
You lose out on hardware verified boot with signed system volumes, virtualization backed security, granular runtime permissions (apps having full R/W on ~Home, screen recording, microphone access).
Immutable distros like Silverblue, flatpak are moving linux desktop security in the right direction but its far from the default, and there are still gaps that need to be closed.
We (Linux community) loves to criticize security through obscurity, but that's exactly what most desktop linux users are relying on to not get pwned, relying on marketshare being so low that there just hasn't been that many incidents.
Indeed, and those who actually understood software development always knew vulnerabilities can occur just as easily as bugs.
And in some cases more easily than bugs, because many of modern vulnerabilities are so subtle, especially where crypto is involved.
Also, if Microsoft hypothetically open sourced their code, do you think there would be more, less, or the same number of CVEs? I would guess more.
I don't want to go too far to defend Linux. I want to make the case that it has been the more secure OS this whole time.
Your phone is ringing, caller ID says its Theo de Raadt from OpenBSD. :)
Nothing to panic about.
We are going to see more of this with LLMs being able to uncover hundreds of bugs in projects just like Linux.
You are right, its over.
On a more serious note. Yes and no. The kernel is secure. It is probably the most scrutinized piece of software in existence. LLMs will find things but most probably they just will help contributors fix bugs.
Given that Linux allows the use of AI assistance [0] you'll be very disappointed to see that people will use LLMs to find even more CVEs and bugs much quicker. That also means they will be fixed much quicker which should be a good thing; as long as the core developer is in the loop checking.
Unless you are against or downplaying this, you may not know that you are actually coping.
[0] https://docs.kernel.org/process/coding-assistants.html
Go Greg!!
https://en.wikipedia.org/wiki/Greg_Kroah-Hartman
http://www.kroah.com/linux/
I don't consider this a tragedy, it's just unearthing the reality.
Linus is pro-AI as a tool ( and I mostly agree, there are consequences however that at least need to be talked about ). That's why I was talking about firing up those AI machines and fix those CVEs ( "make no mistakes" ).
But it seems every Linux topic related to security or languages is the ultimate mine field for knee-jerk reactions. :)