The number of reported security vulnerabilities has gone up drastically. And so has the frequency, number, and volume of security patches. Which also makes the gap between fully supported distributions and ones with only partial security support larger. (Not every distribution provides full security upddates for the full announced life time of a release.)
How are you folks reacting to this?
You must log in or register to comment.
All I do at work lately is patch servers. It’s not very fun.
I think its a good sign, because it means the Kernel gets more secure. And it also means there is not just slop produced with Ai, if people know what they are doing off course. Any of these CVEs not found could have been abused by anyone else.
Edit: I was thinking and speaking of the Linux Kernel itself, but this applies to any other important code or service too.
The number of reported security vulnerabilities has gone up drastically.
I think of the number of FOUND security vulnerabilities has gone up drastically.
Its important to remember that the vulnerabilities always existed, we just know about them now. We have no idea how many of them were being quietly exploited before now.
There is no point being mad at AI for the avalanche of CVEs, if anything we should be mad ourselves for not prioritising security review of the code. Many of these issues probably could have been found before AI if we as an industry were willing to spend the resources doing the audits. But we werent willing, and now we have to pay for our sins.
you should listen to GKH’s review of the recent dumps of “CVEs” because you clearly don’t know what you’re talking about
Care to summarise?
https://m.youtube.com/watch?v=_MwMLPmMccs
I’m halfway through this, I assume that its what you mean? Nothing there so far invalidates what I said. 25% bad reports means 75% good reports.
Edit: I finished it, and nothing he says invalidates what I wrote.
I think it’s great. Amount of bugs is finite. It will stop and we will be better off for it.
Even if we assume every patch to an existing bug is perfect and doesn’t cause other issues somewhere else.
This still only applies if the kernel stays static/not adding features or support for new hardware.
Amount of bugs is finite.
Resources are also finite. You can’t proof the absence of bugs, you can only proof the existence of it.
Did you know, there are more ways to arrange a deck of cards than there are atoms on Earth. A standard deck has only 52 cards. Now imagine how many possibilities are there to have bugs in a code like the Linux Kernel. Just because something is finite does not mean we will ever reach that point.
You can absolutely prove the absence of bugs via formal verification.
The card example does not really make sense because the kernel is not a random set of syntax and bugs do not happen randomly. They usually happen because a dev overlooked a use after free or buffer overflow. Well we now have software really good at finding these things, as well as system languages that cannot have these bugs.
If bugs are closed faster than they are opened, the total amount goes down. For orientation: around 25% of all CVEs ever published were published this year. That means around 6x more bugs were fixed this year than in the other years. I don’t think the kennel gained that amount of additional bugs.
You can absolutely prove the absence of bugs via formal verification.
You can’t have a formal verification for an open ended system like the Linux Kernel. You can only have that with extremely narrow defined functions that only operate mathematical and the input and output are 100% deterministic. Someone has to make the test cases, and to my knowledge its not possible to do this with complex systems like the Linux Kernel.
The card example does not really make sense because the kernel is not a random set of syntax and bugs do not happen randomly.
It makes sense, because it proofs my point that a finite number is irrelevant if its that big. The randomness of it is absolutely not the point, its the sheer amount of possibilities.
Well we now have software really good at finding these things, as well as system languages that cannot have these bugs.
No software can test a complex system like this in its entirety to make sure there are no bugs. Those software itself need to be perfect themselves too. Therefore you introduce enormous complexity in solving bugs, which itself can have bugs.
If bugs are closed faster than they are opened, the total amount goes down.
I wasn’t arguing against that. I am arguing that a finite number of bugs is not a good argument to have none in the future. Because of the sheer amount of possibilities, and also because we cannot proof that Linux Kernel is perfect without any bugs. It is impossible.
Amount of bugs is finite
Not really, no.
🎵 99 little bugs in the code, 99 little bugs, you take one down, patch it around, 102 little bugs in the code 🎵
This is pretty much where I am with it. I see this as our transition phase towards more memory safe languages and tighter code
This is a good thing for Open Source Software. Yes, there’s a lot of vulnerabilities discovered, but in time, most, if not all of them will be patched. Closed Source Software on the other hand will always have the sword of Damocles hanging over their head, as it will be uncertain if they’re fully patched…
Greg Kroah-Hartman (the 2nd person in command in Linux) recently had a public talk where he discussed the whole situation with vulnerabilities. There he predicted that this would calmn down for Linux eventually, since, due to it being open source, there was always attempts to uphold a certain level of code quality, so the number of issues are quickly reducing as they are being addressed. However, having spoken to some developers working on closed source projects, he revealed how terrified they all are with the current situation, since they never had this kind of pressure to keep good code, so the technical debt is crazy for them.
Put everything behind VPNs and migrate services from Docker to VMs
Even the VPN hosts and OS full of CVEs
Yeah but you need to draw the line somewhere. With a VPN the attacker needs to compromise 2 different layers, which is far harder and less likely, especially if you put the VPN in a dedicated VM on a separate VLAN. If you are especially paranoid, you’d use a simpler VPN, like WireGuard, that has less chances of having unnoticed issues (code is small and well vetted), and use a different OS to run the VPN from the one running your services, so a critical flaw in one of the OSs is not enough for a full compromise.
Personally, I run all my services in Debian/Ubuntu systems, but they are behind WireGuard running in Alpine Linux VMs, which use musl instead of glibc, though I’ve considered using BSD there.
In your example the Linux TCP vulnerability would let an attacker into all your systems, and likely your network firewall too
Musl also exposed you to unauthenticated SSH access this month
I do recommend freebsd or openbsd
That’s why mixing OSs is a good way to spread the eggs in more baskets, so do consider using BSD. However, you are wrong on both claims, WireGuard is UDP only, it doesn’t use TCP, and my Alpine guest has had SSH disabled since the beginning, it can only be managed through the virtual serial port from the host OS, so locally only (unless someone manages to escape the VM), plus the SSH vulnerability was only possible when using OpenSSH, but one of the reasons for going with Alpine with musl was to avoid using the same packages as on my service hosts and use those that are smaller with less moving parts, so I’d have used Dropbear instead anyway.
Yeah but then like those VPNs should put their hosts also behind a VPN
VPNs all the way down
Fantastic! When we knew this was coming, the company finally prioritized several of my initiatives about getting up to date. More recent CVEs helped me prioritize a smoother path to updates
😂 I am somewhat envious! My company still uses flourescent lamps… and part the stack is from the same time.
Patch.
Cutting down external services to 0. SQL, Wiki, SVN, CalDAV, etc. All shut down.
I’ve certainly been remembering to update everytime I’m on my PC now.
It made me automate the process of updating that junk heap I call a homelab: the OS, the flatpaks, the docker images.
But then you don’t get the satisfaction of feeling like an admin.
I’ve also been keeping my unplugged most the time now even though I haven’t opened up any ports or made an attempt to set up a way to communicate with my servers services outside of lan.
I was just getting it finished for all the stuff I need locally and everything else involves talking to the scary outside world and I think I’ll wait on that for a little. I just finished my esphome display too which now can only tell me the temp, without the server.
I figure maybe in a few months to six months a lot of the security flaws in most things should of been addressed and I can probably bring my shit box to its full potential. I have a real GPU in mine I haven’t even got to really use besides testing llms and image gen, or trying out frigate ai features with my cat.
I already had automatic updates, so now it’s just a lot of rebooting.
It’ll be an annoying couple of years, and most bugs are nowhere near as serious as they are hyped up to be. Plan for more data breaches than usual though, not everyone is going to have sufficient layers of protection.
I just keep updating and patching, same as before. For big ones, like php2shell (before it was determined that it required a very specific setup), I check for signs of intrusion. But that’s still relatively rare. Just update.
It’s good that they’re finding these bugs and fixing them. The only thing I feel that I personally can do is to update as much as possible, and to reduce attack surface if possible.
