Tech Support
Documentation
Login
Contact Us
New Linux Kernel Functionality Equals New Attack Surface
Joao Correia
December 29, 2022 - Technical Evangelist
The Linux Kernel has grown in scope and functionality over the years. New schedulers, new drivers, new filesystems, new communication protocols, new security holes… oh, wait. That last one is not like the others. Actually, new security holes are often the result of newly added functionality. Sure, not every single new feature adds new security vulnerabilities – but the ones that do speak to a massive codebase that is prone to unexpected, obscure, and obfuscated interactions that give rise to dangerous situations.
How Does Functionality Get Added In?
Every single Kernel subsystem has, at some point, been useful enough to someone that it was submitted for inclusion into the Kernel mainline codebase. Most, if not all, such subsystems could probably be implemented in Userspace rather than directly inside the Kernel, but the ultimate goal of a submitter of such code is to gain every possible ounce of performance. Being directly inside the Kernel execution space means that there are less context switches, direct access to memory regions otherwise out of reach, and generally easier and faster calls to other core functionality and hardware access.
Over the years, this led to a proliferation of, for example, filesystems support (there are now dozens of different filesystems supported straight from the Kernel), NTFS, exFAT, XFS, and many, many, others – and they all have a compelling reason for being part of the Kernel. The same can be said of packet filtering modules, network protocols – the whole nine yards. There are countless others making the rounds of code submission, review, and rewrites for future inclusion as well (ZFS, anyone?). Just how many filesystems do you really need on any given system?
The same could be said for debugging, as multiple functionalities exist to provide debugging inside the Kernel. Sometimes they even compete with each other and can’t be enabled at the same time.
It’s similar to this:
So, What’s the Catch?
When the Linux Kernel was started, the Internet was a speck of dust compared to what it is today. The number of networked systems and even total networks around the world could be tallied and listed relatively easily. You probably knew the operators working the systems you connected to regularly by name. Cybersecurity wasn’t a thing.
So, adding new features to the Kernel brought a broader scope into the project as well as a longer reach for a great piece of software, and also allowed for a great expansion of the user base – which calcified into the core group of Linux enthusiasts that led the project when it reached a significant-enough size.
There weren’t many reasons to not include something new and interesting for someone. The opposite was true – more features meant more interested users.
Things changed. Quite a lot, in fact.
Leave Your Baggage at the Door
As it turns out, adding many complex pieces of code into something that is growing by accretion sometimes introduces unexpected results.
Take the Berkley Packet Filter (BPF) subsystem as an example. Initially conceived and proposed as a way to add new, tailor-made firewall implementations, it lets users add what amounts to basically any code and execute it in the Linux Kernel execution context. It has also been the source of dozens of vulnerabilities, some pretty serious ones, over the past few years. Given its purpose, it’s not totally unexpected.
Others are not so clear cut in the risks they introduce.
Let’s consider another example. Last year, the ksmbd subsystem was proposed and accepted into the Kernel. It’s somewhat similar to Samba (i.e., it enables the use of SMB file sharing directly, rather than relying on a separate piece of software). Ultimately, it should provide faster SMB transfer speeds by relying on shorter call stack depths (calling Kernel functions directly rather than through the Kernel ABI, like Samba). Knowing SMB’s history of vulnerabilities, worms, exploits, and other nasty stories could give some reason for concern, but into the Kernel it went, sponsored by Samsung. Of course, cybersecurity being what it is, just a couple of days ago it was publicly disclosed that a 10 (out of 10) risk vulnerability existed in ksmbd, as it exists in the Kernel 5.15 code base (used by Ubuntu 22.04, for example).
We’re not simply adding new functionality. We’re adding all the bugs and unexpected interactions between new and old code that are, unfortunately, only obvious in production systems.
A(nother) Lump of Coal for Christmas
So, just like last year’s infamous Log4j, the holiday season is fertile ground for the very dangerous vulnerabilities to sprout. Just like sysadmins and security teams struggled to grapple Log4j and patch it on time, this new ksmbd vulnerability is another patch-now-or-you’ll-be-hacked vulnerability. It’s remotely exploitable, easy to trigger, and gives full system access. So far, apparently a user has to be authenticated to a share to be able to trigger it – so there’s that for some good news, but it’s still pretty serious. “Patch now” is an understatement.
Also, what is it with new vulnerabilities coming out when IT teams are running skeleton crews and are slower to react? Oh, wait…
Root Cause Considerations
This is not a hit piece on specific subsystems. It’s not even criticism of the Kernel itself or its development process – it’s undeniable success is obvious. But, and there’s always a “but,” maybe new subsystems should remain in testing for longer. Or, when similar functionality is already achievable in Userspace, maybe Kernel inclusion should not be accepted at all. Everyone always has a compelling story behind a request, and it’s always the “next best thing” since sliced bread. The proverbial devil is, in this case, in the (implementation) details.
Just like the security landscape is getting more and more dangerous, maybe it’s time to tighten the requirements for accepting new systems. After all, there are only so many eyeballs available to keep an eye on things.
There are hundreds of thousands of lines of code in the Kernel, and it’s not possible to account for all the weirdly beautiful interactions between the very new code and all the old cringe-worthy parts still remaining from the early days. Who can vouch that a new filesystem being added won’t blow a fuse when used in a system with a scheduler that is hardly ever used? Are the test suites that good to account for it? Or is that simply another surprise waiting to hit IT teams in coming holiday seasons?
I, for one, would like to be able to enjoy my eggnog instead of worrying about hackers in my systems during Christmas.
