Linux Kernel Security Bug Allows Remote Code Execution for Authenticated Remote Users (zdnet.com) 51
The Zero Day Initiative, a zero-day security research firm, announced a new Linux kernel security bug that allows authenticated remote users to disclose sensitive information and run code on vulnerable Linux kernel versions. ZDNet reports:
Originally, the Zero Day Initiative ZDI rated it a perfect 10 on the 0 to 10 common Vulnerability Scoring System scale. Now, the hole's "only" a 9.6....
The problem lies in the Linux 5.15 in-kernel Server Message Block (SMB) server, ksmbd. The specific flaw exists within the processing of SMB2_TREE_DISCONNECT commands. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the kernel context. This new program, which was introduced to the kernel in 2021, was developed by Samsung. Its point was to deliver speedy SMB3 file-serving performance....
Any distro using the Linux kernel 5.15 or above is potentially vulnerable. This includes Ubuntu 22.04, and its descendants; Deepin Linux 20.3; and Slackware 15.
The problem lies in the Linux 5.15 in-kernel Server Message Block (SMB) server, ksmbd. The specific flaw exists within the processing of SMB2_TREE_DISCONNECT commands. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the kernel context. This new program, which was introduced to the kernel in 2021, was developed by Samsung. Its point was to deliver speedy SMB3 file-serving performance....
Any distro using the Linux kernel 5.15 or above is potentially vulnerable. This includes Ubuntu 22.04, and its descendants; Deepin Linux 20.3; and Slackware 15.
Not a problem for Samba users (Score:5, Insightful)
If you just run ordinary Samba instead of trying to cram all this stuff into the kernel, you don't have a problem. Lots of stuff just doesn't need to be in the kernel.
Re: (Score:2)
dont shove every possible server inside the kernel (Score:2)
If you just run ordinary Samba instead of trying to cram all this stuff into the kernel, you don't have a problem.
^^^^---: This! Times over 9000. Too bad mod only goes up to 5.
Also applies for kernel httpd servers, etc.
Re: (Score:2)
Or use a language which can guarantee isolation (stronger than Rust).
Re: (Score:2)
The technique which guarantees isolation is: don't put it in the kernel.
Microkernel vs monolithic (Score:5, Insightful)
Re:Microkernel vs monolithic (Score:5, Funny)
Don’t worry I’m sure it will get merged into systemd.
Re: (Score:2)
Good. Then it will not be on my Linux systems...
Re: (Score:2)
That was modded Funny? It's only been two days since this particular story hit this site [slashdot.org].
Re: (Score:3)
Obviously not. Also, in order to have a secure system, do not compile stuff in you are not using. Or at the very least delete the modules.
Re: (Score:3)
The microkernel people always just waved away performance concerns, promising that they'd be addressed later (but with no clear path to do so). Message passing between independent memory spaces will always have higher latency.
Network file sharing needs high performance (low latency is actually more important for most things than high throughput), and so it usually ends up in the kernel. The Linux NFS server started out as a user-mode program, but they just never could get good performance out of it, so it m
Re: (Score:2)
It is rare that the bottleneck for networked filesystems is in the kernel.
Re:Microkernel vs monolithic (Score:4, Interesting)
Re: (Score:1)
The microkernel people always just waved away performance concerns, promising that they'd be addressed later (but with no clear path to do so). Message passing between independent memory spaces will always have higher latency.
There is quite a bit you can do about it, even short of faster context switching hardware. Which isn't strange to ask for given all the other specialised hardware for specific tasks found in modern desktop CPUs.
One example is QNX' "canned messages", where one process prepares a message for later delivery, which gets done on a fast signal once it happens.
A network file system is user space has to deal with two user to kernel transitions. The backing file store is in the kernel, and the network is in the kernel.
You could stick the network FS in with the user space network stack process.
Let me also mention the other two rings x86 gives you, cribbed from multics wi
Re: (Score:2)
To the Great White North?
Re: (Score:2)
Note, another factor is that it's easier to integrate an in-kernel server with the exported filesystems.
File locking, NFSv4 file delegations, NFSv4 change attributes, and lookup of files by filehandle are all areas where we've traditionally depended on in-kernel interfaces between knfsd and filesystems.
Over time we've added APIs which expose that functionality to userspace (see for example open_by_handle_at(2)), and we may some day get to the point where userspace has access to all the same filesystem funct
Re: Microkernel vs monolithic (Score:2)
Samba becomes a problem for performance at 100Gbps. It's fine at 40Gbps. Now how many people are doing 100Gbps SMB servers is another question, but 99.999% of all Linux based servers doing SMB are better off with Samba. Frankly the kernel based NFS server is a disaster area as you have zero visibility of what the hell is going on when things go wrong and you invariably end up having to reboot the server.
Re: (Score:2)
100Gbps is fast hardware. Seems like you should have a faster CPU and RAM if you have that fast of storage.
Regardless, there should be solutions that don't involve putting the server in the kernel.
Re: (Score:2)
You don't need to run as root, you could implement a userland service that only provided access to files owned by one user.
You could also drop privileges once a user has authenticated, down to the level of the currently authenticated user. That way you don't need to implement permission checks in the service either, since the kernel will take care of that.
Re: (Score:2)
That's a very simplistic design that doesn't scale well to thousands of clients. And for SMB/CIFS to Windows clients, I'm not even sure how well it would work (since the Windows permission model doesn't map 100% onto the Unix permission model, so IIRC some things are stored in extended attributes interpreted by Samba, don't know about the kernel SMB).
And it still isn't a perfect security fix, since a compromise would allow access to things outside the exported segment of the filesystem (the base OS, possibl
Re: (Score:2)
It depends on what exactly you're running SMB for, and how many clients you actually have...
A lot of SMB on Linux deployments are in the form of small scale NAS appliances. Many of them only have one user, and no need for any permissions system.
Re: (Score:2)
An 8 bit entry on every cache and TLB entry and an 8 bit comparison before finalising an instruction (or load for RISC) would be enough for drivers and the odd kernel integrated server, it's not a big deal.
Re: (Score:2)
PS. I see SeL4 has PCID support, so it can run 4096 MMU isolated processes without TLB flushing right now. Though for AMD only Zen 3 and up has support.
Re: (Score:2)
There is always a performance/security tradeoff. If userland samba is fast enough, then do not use a kernel SMB module. I imagine there are use cases for which a kernel module was necessary (servers and performance).
Re: (Score:2)
It's a kernel module. You can put anything in a module.
Re: (Score:2, Informative)
I had the same question so did some research. Maybe I'm too generous, but I tend to assume there is a good reason and want to know what it is.
The main one seems to be performance. SMB can actually perform quite well if some of the high end stuff is implemented, like DMA that bypasses some of the handling overhead. To get that it needs to be in the kernel.
Re: (Score:3)
was it really necessary to implement SMB
Nope
Re: (Score:1)
Shouldn't authed users be able to run code? (Score:2)
Or is it something more complex? Or is it slashdots title editors fault...
Re: (Score:2)
Re: (Score:2)
I think it means auth'd users can run code as root (or even worse, within kernel context.)
Re: (Score:2)
This is probably for authenticated users that are blocked from logging in. Because otherwise it wouldn't make any sense at all.
Slackware not affected (Score:5, Informative)
Slackware has never enabled CONFIG_SMB_SERVER in any kernel.
Re: (Score:3, Funny)
Slackware has never enabled CONFIG_SMB_SERVER in any kernel.
And when you grow up, you'll never enable in your own kernel that you build yourself.
Re: (Score:1)
He was building custom kernels even before your mother had the accident of having you.
Are Slashdot's old timers already dead or they just don't read posts here anymore? Or maybe don't care to reply?
Re: (Score:2)
This is the first I saw this thread, I was elsewhere yesterday.
But the care Slackware uses in deciding what to enable in their kernel (among other reasons) is why Slackware is still my main system.
No Samba in my outfit (Score:2)
Re:No Samba in my outfit (Score:5, Interesting)
Re: (Score:1)
But I do agree that it should never have been baked into the Linux kernel. Maybe it caught Linus on a bad day.
It's not part of the core kernel, it's a kernel module. Anything can go into those.
Re: (Score:1)
But I do agree that it should never have been baked into the Linux kernel. Maybe it caught Linus on a bad day.
Or maybe Linus realised the benefits of having a filesystem level driver in the kernel where it shares the same space as network drivers and presents to the rest of the system in a unified sane way.
Re: (Score:2)
LOL modded down for agreeing with Linus Torvalds, Slashdot what have you become.
Slackware 15 is not a Debian descendent... (Score:4, Informative)
Slackware 15 is definitely not linked to Debian. It had its own package manager (used to use tarballs for everything at first), and has been around for longer than Debian, tracing back to the SLS days.
Re: (Score:2)
Well, if we're going to be nitpicking, then neither does Deepin Linux descend from Ubuntu.
Re: (Score:2)
Slackware 15 is definitely not linked to Debian. It had its own package manager (used to use tarballs for everything at first), and has been around for longer than Debian, tracing back to the SLS days.
SLS? Space Launch System ? https://en.wikipedia.org/wiki/... [wikipedia.org]
Thats only over a decade old. I think Slackware, Debian and many other distros have been around longer ;)
Re: (Score:2)
Joking right ? :)
Anyway here is a link
https://en.wikipedia.org/wiki/Softlanding_Linux_System
systemd approach? (Score:2)
Why would you integrate a file daemon functionality right into the kernel? The concept alone sounds like a completely terrible idea already.
Dear Santa (Score:3)
I would like for Christmas a fully security-audited mathematically verified Linux kernel.
Module blacklist? (Score:2)
Are distros autoloading this?
Do people using these distros need to push out a module blacklist conf?
I so rarely regret running Debian Stable with its "old-ass" LTS kernel.
New code and exploration is fantastic behind several firewalls. I am glad Samsung is working on kernel code.