That Didn't Take Long: KSMBD In-Kernel File Server Already Needs Important Security Fix

[phoronix]

Phoronix: That Didn't Take Long: KSMBD In-Kernel File Server Already Needs Important Security Fix

It was just a few weeks back that KSMBD was merged into Linux 5.15 while now it's seeing its first important security fix...

https://www.phoronix.com/scan.php?page=news_item&px=SMB3-File-Server-Security-Fix

[treba]

Nothing that couldn't have happened in user space - but still quite embarrassing "beginners" bug :/

[Spacefish]

srsly something like that shouldn´t reside in kernel, as there is always a chance to have some buffer overflow / out of bound reads. Here we have the added bonus, that it is remote exploitable most of the time

[mangeek]

srsly something like that shouldn´t reside in kernel...

I'm not in a position to judge such things, but I tend to agree. I would be moving things like NFS out of the kernel and into userland, like a microkernel. My biggest concern is that I think the things that would benefit the most from having an in-kernel file server are the things least likely to get updates, embedded stuff.

[flower]

I still think smb belongs in userland (same with nfs). AND all reasons why it is better in kernel should be solved so that anyone can use them from userland.

its also much easier to update userspace than kernel

[mdedetrich]

I'm not in a position to judge such things, but I tend to agree. I would be moving things like NFS out of the kernel and into userland, like a microkernel. My biggest concern is that I think the things that would benefit the most from having an in-kernel file server are the things least likely to get updates, embedded stuff.

If you want performance you don't really have a choice (or alternately change parts of Linux to another language that can better detect a subset of these problems, but suggesting this is like talking about he host must not be named in Harry Potter).

[uid313]

Imagine if Microsoft would have put SMB/CIFS in the Windows kernel, we would all laugh and ridicule them!

[S.Pam]

I'm not in a position to judge such things, but I tend to agree. I would be moving things like NFS out of the kernel and into userland, like a microkernel. My biggest concern is that I think the things that would benefit the most from having an in-kernel file server are the things least likely to get updates, embedded stuff.

I agree. I work with quite a few industrial devices and very few receives updates...

As for NFS, there is Ganesha as a userland NFS server.

[pipe13]

If you want performance you don't really have a choice (or alternately change parts of Linux to another language that can better detect a subset of these problems, but suggesting this is like talking about he host must not be named in Harry Potter).

How would a different language have prevented or even caught this particular problem? I'm not familiar with Rust, but am with C, and routinely avail myself of realpath(), filesystem::canonical(), and their Qt equivalents, as a matter of principle and course.

This isn't rocket science. The error wasn't caught as early as it might have been, but it was caught early.

[ssokolow]

How would a different language have prevented or even caught this particular problem? I'm not familiar with Rust, but am with C, and routinely avail myself of realpath() and it's Qt equivalents, as a matter of principle and course.

This isn't rocket science. The error wasn't caught as early as it might have been, but it was caught early.

Rust would have helped with this part:

Additionally, the pull request has a missing buffer overflow check. There are also three more patches currently undergoing review/testing for additional buffer overflow cases in the KSMBD server.

The failing to normalize paths before enforcing .. is just an embarrassing beginner's mistake. (I knew to make sure I was doing that for the IRC fserve script I never finished back in my late high school and early university years!)

Of course, in my case, it was more or less because I'd realized early on that the best way to handle security is to make it someone else's fault if the relevant code proves to be broken.