Three Flaws in the Linux Kernel Since 2006 Could Grant Root Privileges (scmagazine.com) 94
"Three recently unearthed vulnerabilities in the Linux kernel, located in the iSCSI module used for accessing shared data storage facilities, could allow root privileges to anyone with a user account," reports SC Media:
"If you already had execution on a box, either because you have a user account on the machine, or you've compromised some service that doesn't have repaired permissions, you can do whatever you want basically," said Adam Nichols, principal of the Software Security practice at GRIMM. While the vulnerabilities "are in code that is not remotely accessible, so this isn't like a remote exploit," said Nichols, they are still troublesome. They take "any existing threat that might be there. It just makes it that much worse," he explained. "And if you have users on the system that you don't really trust with root access it, it breaks them as well."
Referring to the theory that 'many eyes make all bugs shallow,' Linux code "is not getting many eyes or the eyes are looking at it and saying that seems fine," said Nichols. "But, [the bugs] have been in there since the code was first written, and they haven't really changed over the last 15 years...." That the flaws slipped detection for so long has a lot to do with the sprawl of the the Linux kernel. It "has gotten so big" and "there's so much code there," said Nichols. "The real strategy is make sure you're loading as little code as possible."
The bugs are in all Linux distributions, Nichols said, although the kernel driver is not loaded by default. Whether a normal user can load the vulnerable kernel module varies. They can, for instance, on all Red Hat based distros that GRIMM tested, he said. "Even though it's not loaded by default, you can get it loaded and then of course you can exploit it without any trouble...."
The bugs have been patched in the following kernel releases: 5.11.4, 5.10.21, 5.4.103, 4.19.179, 4.14.224, 4.9.260, and 4.4.260. All older kernels are end-of- life and will not receive patches.
Referring to the theory that 'many eyes make all bugs shallow,' Linux code "is not getting many eyes or the eyes are looking at it and saying that seems fine," said Nichols. "But, [the bugs] have been in there since the code was first written, and they haven't really changed over the last 15 years...." That the flaws slipped detection for so long has a lot to do with the sprawl of the the Linux kernel. It "has gotten so big" and "there's so much code there," said Nichols. "The real strategy is make sure you're loading as little code as possible."
The bugs are in all Linux distributions, Nichols said, although the kernel driver is not loaded by default. Whether a normal user can load the vulnerable kernel module varies. They can, for instance, on all Red Hat based distros that GRIMM tested, he said. "Even though it's not loaded by default, you can get it loaded and then of course you can exploit it without any trouble...."
The bugs have been patched in the following kernel releases: 5.11.4, 5.10.21, 5.4.103, 4.19.179, 4.14.224, 4.9.260, and 4.4.260. All older kernels are end-of- life and will not receive patches.
Local root exploit ... who cares (Score:2)
One down, infinite to go.
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
So, if you have root privileges, you can load the module and then use the exploit to get root privileges ....
Re: (Score:2)
Only if you are stupid enough to leave unneeded modules on your server.
Re: (Score:2)
Agree that a kernel stripped down to its minimum reduces the attack surface. If you are going that route it's not enough just to remove the modules, you should compile all needed modules as builtin and disable module loading entirely. This ought to be standard practice in any big installation, but guess what, sysadmins are by nature lazy and slovenly beasts. Much easier to just take everything the way it lands from the distro.
Most of us aren't going to go spelunking down there on a regular basis, life's too
Re: (Score:3)
So, if you have root privileges, you can load the module and then use the exploit to get root privileges ....
Reminds me of the line in House, "Frozen" (S4, E11):
House: Yes, if only she wasn't in a coma, we could get her to run a test to find out why she's in a coma. The results would likely be paradoxical.
Re: (Score:2)
So, if you have root privileges, you can load the module....
Read more closely. On Redhat systems an unprivileged user can cause the module to be loaded, presumably by way of udev or such. Didn't dig into exactly how but feel free. Redhat is shit. iScsi maintainer is shit. IScsi is pretty much shit for that matter, use NBD if you have the choice.
Re: Local root exploit ... who cares (Score:1)
Re: (Score:2)
Re: Local root exploit ... who cares (Score:2)
Re: (Score:2)
"Even though it's not loaded by default, you can get it loaded and then of course you can exploit it without any trouble...."
On Redhat. Friends don't let friends use Redhat.
Re: (Score:1)
Linux has had terrible security for 10+ years now (Score:5, Interesting)
It comes from Greg K-H and Linux both being super dismissive of security vulnerabilities, considering them "just another bug nothing special" and not prioritization them. There has never even been an effort to audit and clean up the code for issues like OpenBSD did.
A lot of anti-proprietary folks will say Linux is more secure than Windows/Mac, but it's not true. I work as a a pen tester and taking over most linux machines is generally much easier than you would think, because of issues like these that just don't get fixed or prioritized.
People will disagree with me out of principle, but I'm not wrong. When you have developers that don't take security seriously as they should, you won't have a secure product.
Re: (Score:3, Informative)
So first you have to get a user account. The code is unusable as a remote exploit. It is in a kernel driver that is not loaded by default and can't be loaded in all Linux versions without the relevant hardware being installed. Debian versions for example check if the relevant hardware (iSCSI) is present and won't load if it isn't (not likely IMO). So in other words more of a theoretical "bug" set.
So you can't use it unless you are already a user. Then it takes multiple hacks to enable the root acces
Re:Linux has had terrible security for 10+ years n (Score:5, Interesting)
Chained exploits exist. And these types of exploits are generally not aimed at home users, but instead at companies with servers that handle thousands to millions of users content, much MUCH more valuable targets. Chain this with an exploit in a web server or some other service running on the server, and its a total pwn. And That's the point. YOU may not care AS AN END USER, but as someone who manages globally distributed infrastructure to support end users such as yourself, you're damn sure I do care to know about these things and their implications.
Re: (Score:3)
Firstly, the module won't be loaded if the hardware isn't present and you need root privileges to load the module. The article claims that the module is always loaded on Red Hat, but I can clearly see that it isn't present on my CentOS systems.
Secondly, you should be running SELinux on your web server, which will prevent this exploit.
Re:Linux has had terrible security for 10+ years n (Score:4, Informative)
What hardware are you talking about? iSCSI is a way to expose a block device for network-based access. The only hardware required is a CPU, RAM and NIC. You can export a ramdisk over iSCSI if you want.
Also, the article doesn't say the relevant kennel module is loaded on RH-based distros: "Whether a normal user can load the vulnerable kernel module varies. They can, for instance, on all Red Hat based distros that GRIMM tested, he said."
If something like SystemD lets you use iSCSI to access a remote disk, your system is vulnerable.
Re: (Score:2)
I read the article again.
It claims that there is a known way to get kernel modules installed, but for this specific case, it requires the rdma-core package to be installed.
On CentOS, if you have a no-GUI webserver, then the rdma-core package isn't installed.
So this exploit has another dependency: installation of the rdma-core package and almost certainly, SELinux would need to be disabled.
Re: (Score:1)
Re: (Score:2)
I would hope that the use of SELinux is improving.
When I recently migrated some servers from CentOS 6 to CentOS 7, I put in the effort to make then run with SELinux in enforcing mode. I would hope that other administrators are doing this too.
Re: (Score:3)
iSCSI is not a hardware feature. It's a network block storage protocol, which I happen to use at my home.
But sure, 99.999% of Linux users surely don't use it.
Re: (Score:2)
iSCSI is an abomination. Wrapping up blocks in TCP/IP packets so you can send them on the same layer two network segment (which is what happens in 99.999% of use case scenarios) is obscene.
I could also wax lyrical terrible it is without per channel pause when you have anything other than a one to one host to storage ratio. That was several weeks of my life I am not getting back working that shit out. Fun fact it's why per channel pause was added to Data Center Ethernet when the whole FCoE was a thing. Becau
Re: (Score:3)
The relevant hardware is an external network attached subsystem...
Yes, there CAN be offload adapters, BUT those are somewhat uncommon outside of fairly high end systems. AND the iSCSI subsystem is still separate from the kernel modules for the adapter.
I think the "debian" feature you're referring to is udev... It's not unique to debian or "debian like" systems.
Re: (Score:2)
So first you have to get a user account. The code is unusable as a remote exploit. It is in a kernel driver that is not loaded by default and can't be loaded in all Linux versions without the relevant hardware being installed.
The only hardware iSCSI needs is a network card, similar to SMB or NFS.
I guess most machines (including yours) have that hardware installed and enabled.
Re: (Score:2)
apple.com /s
Re: (Score:1)
I work as a a pen tester and taking over most linux machines is generally much easier than you would think
doesn't provide a lot of credibility, no information about the function of the respective Windows/Mac or Linux machines that were pen tested. If the Windows/Mac were servers managed by a competent admin and the Linux machines were not managed at all, (just desktops with users that were supposed to hit the update button but postponed it indefinitely) that would mak
Re: (Score:2)
Re: (Score:2)
I accept that Linux could have a bigger focus on security, but find me a significant OS that doesn't have privilege escalation exploits. No one has figured out how to stop those.
Your security model needs to assume that a hacker who has access to your system also has access to root, otherwise your security model is broken.
Re: Apples to pears. (Score:2)
Re: (Score:2)
You are wrong. The claim was never "Linux is more secure". The claim was always "with competent system administration, Linux is more secure". And that is where you fail. For example, removing kernel modules not needed falls under "basics".
Re: Linux has had terrible security for 10+ years (Score:1)
Re: (Score:3, Insightful)
It comes from Greg K-H and Linux both being super dismissive of security vulnerabilities, considering them "just another bug nothing special" and not prioritization them. There has never even been an effort to audit and clean up the code for issues like OpenBSD did.
Multiple organizations have conducted security related code reviews and contributed patches for the Linux kernel.
I work as a a pen tester and taking over most linux machines is generally much easier than you would think, because of issues like these that just don't get fixed or prioritized.
You are full of shit. Remote exploits are rarely enabled by kernel vulnerabilities. Local privilege escalation is a dime a dozen on any non-niche OS.
People will disagree with me out of principle, but I'm not wrong. When you have developers that don't take security seriously as they should, you won't have a secure product.
If you find yourself in a position where developers a required to take security seriously in order to create a secure product you've already failed.
Re: (Score:2)
You are full of shit.
Agree. Maybe respondent watched Mr Robot, that's as far as they got with pen testing.
Remote exploits are rarely enabled by kernel vulnerabilities.
Right. When it does happen every few years then it's instant, industry wide news
Local privilege escalation is a dime a dozen on any non-niche OS.
If you think that then you should try it yourself. See if you can manage it with a CVE that's older than your last system update.
If you find yourself in a position where developers a required to take security seriously in order to create a secure product you've already failed.
Ah no, that's just not true, security is a culture that goes all the way up and down the stack. For example, A PHP hack who doesn't sanitize their SQL strings is a clear and present danger.
Re: (Score:1)
Greg K-H and Linux
Not a good start.
People will disagree with me out of principle, but I'm not wrong.
Well, actually, you are wrong. I mean, you got the name of Linus wrong in the very first sentence.
If you can't even bother getting that detail right... The rest of your post is basically an appeal to yourself.
Not impressed.
I work as a a pen tester ? (Score:1)
I totally believe you are a a pen tester
Microikernel anyone? (Score:3, Interesting)
Re:Microikernel anyone? (Score:5, Insightful)
Why waste 5% of your performance on marshaling messages when you can have a faster kernel, which you turn around and run pulseaudio on to slow it back down.
Re: (Score:1)
AMD is only introducing PCID with Zen3 ... using process space isolation for isolating parts of the kernel was never a 5% performance trade off until relatively recently even on Intel.
It would have made more sense to write the majority of the kernel and userland in safe languages instead, if an usable "safe" by default system programming language had actually been available before now. Even if that would have been solved sooner, user land would still be a wasteland of never-ending exploits due to shell scri
Re: (Score:2)
Process space isolation is different than message passing serialization overhead that you find on old microkernels like Mach and QNX.
There have been a lot of options for safe languages over the years. But it doesn't really ever seem to catch on in the kernel world. I often press my employer to look into formal verification systems like Spin. And there have been a few demonstrations of kernels in Rust that can't have overflow bugs.
Part of the push for containers everywhere, even your browser, is not to elimi
Re: (Score:2)
Process space isolation is different, but a buffer overflow in a single kernel space microkernel won't care that it's supposed to use messages. If a microkernel is presented as a solution to unsafe memory access related bugs then process space isolation for the microkernel components can be assumed.
For decades C defenders and their illusion of control dominated with nary any real opposition. I feel the acceptance of the fundamental stupidity of using plain text interfaces with the necessity of escaping is d
Re: Microikernel anyone? (Score:1)
Ditto for bounds checks, null pointer checks, memory management / garbage collection, safe branch prediction, and so on.
Lazy hacks for bad coder that think they are superior and can do it, thanks to the Dunning-Kruger effect.
(Some can do it. Definitely. But most probably not.)
Re: (Score:2)
Why waste 5% of your performance on marshaling messages when you can have a faster kernel, which you turn around and run pulseaudio on to slow it back down.
Then write your server backend in PHP or Javascript for good measure.
Re:Microikernel anyone? (Score:5, Informative)
The biggest problem with microkernel in today's CPUs is IPC.
Consider opening a file in a microkernel-based OS. The user process needs to send a message to the file system server, the file system server then needs to send one or more messages to the block device driver. Due to the way CPUs are designed, processes cannot just call each other, to send a message a process must issue a system call to the kernel and then the kernel must dispatch the message to the other process.
The typical flow would be like this
* Process issues a system call to the kernel to send a message (1st context switch)
* The kernel passes the message to the file system server (2nd context switch)
* the file system server issues a system call to the kernel to send a message (3rd context switch)
* the kernel sends a message to the block device driver (4th context switch)
* the block device driver reads and writes from the hard drive, and eventually issues a system call to return the result (5th context switch)
* the kernel sends a message to the file system with the results (6th context switch)
* the file system server issues a system call to return the result (7th context switch)
* the kernel gives the result to the user process (8th context switch)
all these context switches mean thrashing the TLB and cache.
Now consider a monolith kernel like Linux:
* Process issues a system call to the kernel to send a message (1st context switch)
* kernel passes message to file system (no context switch, just a function call)
* file system passes messages to the block device driver (no context switch, just a function call)
* block device driver returns result
* file system driver return result
* kernel returns result to user process (2nd context switch).
This is easily an order of magnitude faster.
It is entirely possible to design a CPU that allows processes to talk to each other securely at a cost equivalent to a function call. RISC-V should have addressed this, I think it was a missed opportunity, It is still possible to make extensions for this. See this talk:
https://www.youtube.com/watch?... [youtube.com]
The Mill is an example of a CPU architecture specifically designed for microkernels, IPC can be made extremely cheap with performance equivalent to function calls, see this talk https://millcomputing.com/docs... [millcomputing.com] . In this kind of architecture, the flow would be:
* Process issues a "portal" call to file system server (very cheap)
* file system server issues a portal call to block device driver
* block device driver talks to device
* block device driver returns the result
* file system server returns the result.
* process continues.
This can all happen securely, efficiently, and without needing the kernel to be an intermediary.
Realistically, until we see hardware support for microkernels, they are not going to become popular.
Re: (Score:3)
IA-32 aka x-86 32 had something similar to this, in the form of call gates. And a faster but less flexible one in the form of SYSENTER/SYSEXIT.
https://en.wikipedia.org/wiki/... [wikipedia.org]
In AMD 64, AMD (sadly) got rid of call gates, along with the 4 rings of protection (0 to 3), leaving only two (kernel (0) and user (3))
Nonetheless, some microkernel systems, like QNX, use various tricks to speed up performance of message passing.
One popular one is to transfer execution rights to the message receiving process along wit
Re: (Score:3)
It's actually about 3 million lines of code for the kernel and 25 million lines for drivers. Each machine only uses a handful of drivers meaning it's the 3 million lines that matter most.
Many Flaws (Score:1)
There are always flaws in any big project. And there are smart people whose job it is to sift through source and discover them. And report them to their organisation to make use of. It's the flipside of the 'security through obscurity is not secure' bromide.
Open Source is not a panacea.
Re: Many Flaws (Score:1)
Smart people will not sift through other people's things, let alone to find thrash. Nobody does. Nobody likes it.
People want to have fun.
If you want somebody to do that tiresome and tedious job, you will have to pay them. (And keep the source open, otherwise you will have to take his word for it, and that is really no better.)
Re: (Score:1)
You might not have noticed that I said that the smart people have jobs doing it.
And if you do not run iSCSI, no problem. (Score:3, Insightful)
iSCSI is really a rather rare thing to use. Somebody here is trying to make themselves look important...
Re:And if you do not run iSCSI, no problem. (Score:4, Informative)
Not true, you can cause the module to be loaded even with a regular user account on RedHat-based systems. On Debian-based systems, the loading won't work if you don't have iSCSI hardware, but that's a narrow escape and there might be other ways around it. This is a serious privilege escalation vulnerability, affecting most Linux installs out there.
Re: (Score:2)
Oh, you are talking about people stupid enough to have kernel modules they do not need on their systems? Sure, if you cannot even get basic system administration right, all bets are off.
Re:And if you do not run iSCSI, no problem. (Score:4, Insightful)
... i.e. 99% of systems out there, even in cloud and corporate. Yes, I've worked extensively on million-plus machine compute farms and there are a lot of drivers left in the golden builds that are not necessarily used.
When you installed your linux desktop, did you build your own kernel? Did you go through menuconfig for a few hours and unselect every hardware driver you didn't have on your machine at the time?
And when you plug in new hardware, do you first rebuild your kernel to include the driver so you can plug it in the following day?
Then congratulations, you are one of maybe 20 linux users on the planet who are not vulnerable. Enjoy your superiority. The rest of us normal humans are still worried.
Re: (Score:2)
What's annoying is that an obvious workaround for 99.999% of users is to delete the offending module.
I think the following is a workaround
find /lib/modules -name libiscsi.* -delete
Re: (Score:2)
Installations being expensive does not mean they are competently administrated. Deleting non-needed software, including kernel modules, is what you find in the _basic_ hardening guide that should be applied to any system that goes into production.
Also, why do you think removing modules needs a kernel compile? You can simply start the system, check what modules got loaded and then remove all others. A bit of scripting may help. And why do you think that adding a driver to the kernel will defer hardware insta
Re: (Score:2)
I dunno what to tell you man, that's not how system administration is done at any place with more than a few hundred machines - and wasn't even the way it was done at any of the smaller shops I worked at.
You make one golden build that covers all the various hardware generations and configurations that your system might have to interface with and then you distribute that to every machine in your fleet. You definitely don't make post facto changes like rm'ing unneeded kernel modules.
I think our disconnect is
Re: (Score:2)
Actually, I am talking virtualized or otherwise uniform hardware. Then removing not needed kernel modules is part of the base-hardening done in the install image. But sure, if you have non-uniform hardware, and are incapable of removing the modules (e.g. by a delayed installation process or as part of an Ansible installation routine), then you end up with the mess you describe.
My point is that this is a sign of incompetence. Linux (like anything in the Unix-sphere) is designed for competent system administr
Re: (Score:2)
Neither Facebook, where I used to work at, nor Google, where I currently work, use traditional virtual images with their own kernel, we use containers (borg/k8s at G and tupperware/twine at F). If you want to criticize our competence and say that we subscribe to a "prevalent defective mind-set"... ok. There is certainly no lack of investment in infrastruture at either of these companies. If you still feel like criticizing our competence, I invite you to instead apply and bring your energy to make things bet
Re: (Score:2)
So are you doing base-hardening for the systems that these containers get put on, which includes removing not needed kernel modules or not? If the modules are left in there, maybe a competent _external_ security and hardening review would be something to invest some money in?
Re: (Score:2)
When you installed your linux desktop, did you build your own kernel? Did you go through menuconfig for a few hours and unselect every hardware driver you didn't have on your machine at the time?
Yep.
And when you plug in new hardware, do you first rebuild your kernel to include the driver so you can plug it in the following day?
Yep.
congratulations, you are one of maybe 20 linux users on the planet who are not vulnerable. Enjoy your superiority.
Thanks! It is rather awesome.
Unfortunately there are only so many hours in a day. Little time is left for non-kernel-related things like social interaction, personal hygiene, etc.
Re: (Score:2)
How?
Re:And if you do not run iSCSI, no problem. (Score:4, Informative)
Reading the article again, it claims that there is a known way to do this, but it requires the rdma-core package to be installed.
If you have a Red Hat/CentOS webserver without an installed GUI, the package will not be installed, thus reducing the number of vulnerable machines dramatically.
Re: (Score:2)
You'll have that package installed if you have Infiniband or anything that uses the Infiniband API. That includes pretty much any high-performance network card (Juniper, Chelsio, etc.), and various compute cluster, supercomputing and other high-performance computing systems. You'll also have it installed for anything using storage clusters. It might not affect smalltime web servers, but this is going to affect a lot of high-performance computing setups.
Re: (Score:2)
If you are running a webserver on bare metal, you are doing it wrong.
Most of those webservers are running in a container or VM. The container or VM host should not be easily accessible from the Internet.
Re: (Score:2)
Not true, you can cause the module to be loaded even with a regular user account on RedHat-based systems. On Debian-based systems, the loading won't work if you don't have iSCSI hardware, but that's a narrow escape and there might be other ways around it. This is a serious privilege escalation vulnerability, affecting most Linux installs out there.
There is no such thing as iSCSI hardware. There is SCSI hardware, but for iSCSI, the only hardware you need is a network card, similar to NFS or SMB...
Re: (Score:2)
Bazinga, we have found the Dunning-Kruger afflicted.
May I point you to the Qlogic QLE4060C-E, and a whole host of similar iSCSI HBA's..
I am also wondering why if you are correct a bunch of my servers at work have a boot over iSCSI option requiring firmware support in the NIC, which not all NIC's support because not all my servers have it.
As such there *IS* such a thing as iSCSI hardware. Next time before you post trivially verifiable nonsense do a Google search.
rdma-core? (Score:2, Informative)
Reading https://blog.grimm-co.com/2021... [grimm-co.com] it looks partly tied to rdma-core. Not such common on debian for instance: https://qa.debian.org/popcon.p... [debian.org]
Shallow bugs (Score:2)
many eyes make all bugs shallow
First, not a lot of people run storage area networks. I don't, so my motivation to review this particular module is low. Second, the sorts of people who do run SANs are also the kind that would be likely to purchase support contracts from the likes of Red Hat. Where the hell is their fee supported software support on this? And finally, while cloud service providers might have some untrustworthy users on their systems, many corporate users do not. There is a certain amount of trust one places in the people w
So tired of people misinterpreting that quote (Score:4, Informative)
Eric didn't say "all bugs are don't exist". Anyone who takes "bugs are shallow" or mean "there are no bugs" is misunderstanding what he was saying.
He was writing about how bugs are handled.
Around the time he wrote that, Internet Explorer had a known issue that Microsoft had listed on MSDN for two years, with no fix. Two years after publication of CATB, four years after the issue was known, Microsoft released a partial fix - because they couldn't figure out how to actually fix it. It was another three years before the responsible team at Microsoft finally fixed the bug. Seven years from finding the bug to a proper fix.
The "many eyes" quote is:
--
Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Or, less formally, "Given enough eyeballs, all bugs are shallow.'' I dub this: "Linus's Law''.
My original formulation was that every problem "will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. "Somebody finds the problem,'' he says, "and ***somebody else understands it.***"
--
When Shellshock came out, just on one mailing list alone there were about 150 of us looking at it and trying to find the best solution. People were proposing different patches and adjustments to the functionality. We were digging deep into the problem. A few hours after Shellshock came out, Florian Weimer said on the list that the issue could not be "fixed", the feature couldn't be patched to make it safe. He said the feature needed to just be disabled, removed, because it could not be made safe. Over the next two days several people submitted patches to make it safe. For every suggested patch, someone found a way around it. None of the patches made it secure.
About 2 1/2 days in, it became apparent to everyone that every patch was bound to fail; we started to see why you simply couldn't have that function and be secure. We started to see what Florian had seen immediately. We had been digging deep, trying to understand the implications of every possible change. For Florian it was shallow, the fix was obvious to someone, and that time someone was Florian. "Given enough eyeballs, all bugs are shallow; the fix will be obvious to someone". Not "all bugs are not exist".
Contrast the 2 1/2 days to come to a thorough understanding and proper fix for the bug in the open source vs the seven years the issue languished in IE, with a broken half-fix for three years.
For the current issue, it was fixed last week and revealed yesterday. "Problem will be characterized quickly" - I'd call a week ahead of time quickly.
Re:So tired of people misinterpreting that quote (Score:4, Informative)
Here's an example from my personal experience of what Linus was talking about, when he said "the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. Somebody finds the problem, and somebody else understands it."
In 2012 I found a problem in the Linux storage stack, in LVM.
I didn't understand the problem. I presented it to the LVM team.
One of the LVM maintainers understood it well enough to realize it was really a raid problem, with symptoms at the LVM level. So he referred me to the raid team.
Neil Brown, the raid maintainer, understood and and store a fix *without even being a computer to test whether his fix would even compile*.
https://marc.info/?l=linux-rai... [marc.info]
I found it, Mike Snitzer or someone understood where we should REALLY be looking for a *proper* solution, Neil Brown immediately knew exactly what the real source of the problem was and exactly how to fix it properly. Note the three of us worked for three different companies. No one team at any one company had right people to find the problem (lvm volumes hang in specific situations), recognize that the LVM symptom was actually due to a raid problem, and understand exactly how raid should be fixed. It took three different sets of eyeballs to get the right solution.
Long past time for multi-level modules (Score:5, Interesting)
Perhaps breaking up a module as;
* Initialization & tear down, which is un-mapped when not in use. Thus needing extra work to exploit.
* Interrupt service routine, always mapped to kernel space when driver / module is in use. This level is designed to have only access to it's companion Data transfer routines, and kernel routines related to interrupts.
* Data transfer routines, run and mapped onto it's own user, separate from kernel & normal users. This level is designed to have only access to relatable kernel functions. For example, iSCSI does not need access to network drivers, only the TCP/IP stack.
* User libraries call the Data transfer routines, which are at user level, not kernel level.
* Checksum all R/O code & R/O data for verification that nothing has changed. Both Interrupt level & user level. Allow for cron initiated scan.
Will this slow things down?
Almost certainly.
Could this introduce bugs, and possibly more security flaws, in the short term?
Of course, all new things do.
Will this ever happen?
Not unless I do it. (And I don't have the skill to implement it well. Or know what details would work well, or not at all, until I try.)
I don't pretend to known what would be best, but this particular issue will bite us again, and again, (ad nauseam).
My own thoughts are that bugs should be squashed at a higher priority that new features. (Unless that new feature helps squash future bugs.) We don't need new features as much as rock stable code, which Linux is not. Linux kernel might be rock stable in certain use cases, but over all, it's not.
Re: Long past time for multi-level modules (Score:1)
We answered that, literally decades ago.
The solution would be a microkernel with a RBAC API firewall between the modules and between everything else too.
And the reason we haven't done it yet, is the same as for Spectre/Meltdown or all those buffer overflow / pointer / stack / bounds bugs of C-likes: A little performance hit.
Despite QNX showing that the his really doesn't have to be big.
I guess it's time to stop cutting corners and stop letting hack jobs re-invent the wheels (like memory management) each tim
Re: (Score:1)
Pedantry Question (Score:2)
"Three recently unearthed vulnerabilities in the Linux kernel, located in the iSCSI module used for accessing shared data storage facilities, could allow root privileges to anyone with a user account."
I'd just like to ask what the prevailing view is with regards to whether or not it is acceptable to use the term "Linux Kernel" when referencing "Linux Kernel Module".
I hope that my question isn't quite as silly as it seems. Given that K
Re: (Score:2)
I'd just like to ask what the prevailing view is with regards to whether or not it is acceptable to use the term "Linux Kernel" when referencing "Linux Kernel Module".
Simple:
Is the source code of said module in the linux kernel git repository?
Does linus compiles said code when he his preparing a new kernel?
If the answer to any is yes, then sure, the module is part of the linux kernel.
And this particular iSCSI module complies with both.
Re: (Score:2)
It is correct to describe kernel modules as "kernel" because when loaded/linked they are indistinguishable from any other part of the kernel, in particular having exactly the same privileges.
For regular PCs, this changes nothing. (Score:1)
If you got access to the user account, what more would you need?
(It's a problem on servers, of course.)
If this was a Windows or macos vulnerability... (Score:2)
If this was about a Windows or macos vulnerability, this thread would be filled with posts blasting Microsoft or Apple.
But this is about linux vulnerabilities. Therefore, and predictably, this thread is instead filled with post after post of apologists and downplaying the severity of such vulnerabilities.
Yeah, you can mod this flamebait if you want. But is it really flamebating to point out to people their bias, irrationality and tribalism ?
Re: If this was a Windows or macos vulnerability.. (Score:2)
Re: (Score:2)
The reason comments like yours are tiresome is that we know without any doubt that there have been long-running known critical security bugs in proprietary software, which in some cases persisted for years.
With any closed source software, you will often not even know that the company knows of serious security failures until they fix them, if they fix them. With open source, you find out about the bugs, so it might look like there are more of them.
The vulnerability is severe enough to be worthy of discussion
Re: (Score:2)
More like 0.01% of systems if you ask me.
Re: (Score:2)
More like 0.01% of systems if you ask me.
Yeah, servers at scale, where you want a cheaper and more flexible alternative to fibrechannel.
People like facebook, google, microsoft are among the 0.01% of users of this technology.
In punny desktops like yours, not so much.
In my pounny desktop, I have a iSCSI connection to my NAS, because, aside from NFS4 and SMB3, I need a block device for "things".
iSCSI hardware (Score:2)
In many a post I've seen references to "iSCSI" hardware. So, I think a clarification is in order:
There is no such thing as iSCSI hardware
There is SCSI hardware of course, but notice the absence of the lowercase 'i'.
For i SCSI, the only hardware needed is a network card, similar to NFS or SMB.
Re: (Score:2)
Most iSCSI deployments probably use software initiators, but hardware iSCSI HBAs are a thing.
Granted, this vulnerability probably only affects the Linux iSCSI software initiator.
Re: (Score:2)
I was presuming the same thing, but the modules in question are also a dependencies for some qlogic, chelsio, broadcom, emulex, and generically is in the rdma stack. So a number of network devices will force those to load.
Re: (Score:2)
There is no such thing as iSCSI hardware
There actually is, the iscsi target is hardware. Plus the iscsi module in question is a driver. I know, I found that a bit awkward too but it's not wrong.
The "many eyes" argument is an interesting one... (Score:1)
It's always been an overly-clever argument by the open source community to claim that the code being open to all eyes made it so everyone could look at the code and people would therefore catch bugs and security issues - this was often simply accepted at face value, without anybody asking the obvious question: IS everybody looking at the code? The simple ability of people to look does not by any means mean that ANYBODY, and particularly people properly skilled and interested, IS looking.
This article, howeve
Re: (Score:2)
For the open source community, we probably need a formal system for code investigation - something most programmers are probably not interested in doing.
Sure, this is what corporations can offer other corporations in the Linux world. The only real value add on top of what you can get for free is security. Support, from what I hear, is extremely uneven anyway. That doesn't surprise me. Take Redhat (please) for example. I worked for Tivoli just post-acquisition by IBM and got to see IBM ruin the place. They hired in a level 1 support team to take phone calls and they were dumb as stumps. It took those of us in level 2, who were all former sysadmins, longer to
Re: (Score:1)