A crypto module loading vulnerability [LWN.net]

By Jake Edge
January 28, 2015

Loading a module into a running kernel is rather invasive, which is part of why the operation is restricted in various ways. For the most part, it requires root privileges (or the CAP_SYS_MODULE capability) to load a module, but there are exceptions. Some modules get automatically loaded when a new piece of hardware is plugged in, a new filesystem type is mounted, or a new kernel cryptographic algorithm is needed. In the latter case, however, unprivileged users could cause any module in the official module directory to get loaded by exploiting a hole in the crypto subsystem—at least until recently.

The problem was actually discovered almost two years ago when Mathias Krause pointed it out in a thread about a similar bug with mount and user namespaces. In that case, the root user in a user namespace (who might be a regular user in the top-level namespace) could mount a filesystem using the -t (type) option and pass any module name as the parameter. That would cause the kernel's module-loading logic to load the module, even if it wasn't a filesystem. Krause noted that the same was true for the crypto subsystem.

The mount problem was fixed shortly after it was reported, but a fix for the crypto bug evidently slipped through the cracks. Neither of these bugs allowed unprivileged users to load arbitrary (i.e. attacker-controlled) modules, which would be a much more severe problem, but even being able to load unexpected modules from the standard location (normally under /lib/modules) can lead to various vulnerabilities including privilege escalation—full system compromise, essentially.

Since kernel modules have intimate access to the kernel, vulnerabilities in modules have been exploited in the past. But if an administrator believes that regular users cannot load certain modules, they may be less inclined to update their kernel to fix a problem in an "irrelevant" module. There is also the risk of unknown or zero-day module vulnerabilities. The risk of any of that may be fairly low, but there are reasons that module loading is restricted to certain users.

The usual fix (and the one that was applied for filesystems) is to prefix the user-supplied module name with a subsystem-specific string; for filesystems, "fs-" was used. All filesystems that can be built as modules got a MODULE_ALIAS() using the prefix. The request_module() call for filesystems was modified to prepend the prefix, which means that the kernel would no longer load just any module as a filesystem type, it would need to actually be a filesystem module.

Obviously, the same scheme can be applied to the crypto subsystem, but there were a few wrinkles, as Krause outlined in a G+ post. First off, the vulnerability is a bit more easily accessed than the mount and user-namespace flaw. Any user-space program that binds to an AF_ALG socket (which provides a netlink-based user-space interface to the crypto subsystem) can specify the type of cipher that it wishes to use. If that cipher is not present, the kernel will try to load a module of that name. Since there are no restrictions on the name, any module name can be passed and it will be loaded.

Modifying all of the cryptographic algorithms that can be built as modules to add a "crypto-" prefix, while changing the crypto module–loading code to do the same, is the obvious path forward. Kees Cook made that change, but there was a problem with the fix. Crypto ciphers can also specify a mode, so the AES cipher in electronic codebook (ECB) mode would be specified as "ecb(aes)". Cook's original fix would allow any module to be specified for the mode (e.g. "vfat(aes)") and it would get loaded.

That led to a second patch from Cook, but that was missing some needed crypto module aliases. A patch from Krause added the necessary aliases.

But there was still one more (non-kernel) bug that was found in this process. The kernel turns the module-loading job over to the modprobe user-space utility, which finds the module file, reads it in, and uses the init_module() system call to add it to the kernel. As it turns out, Krause was using a BusyBox-based system to test the patches. He discovered that BusyBox's modprobe effectively uses the basename of the module name passed to it. That means everything up through the final "/" is ignored. A request for "/vfat" gets turned into a request for "crypto-/vfat", but the BusyBox modprobe ignores the first part and happily loads the vfat module—which takes us back to square one.

That problem affected more than just crypto (in fact, Krause doesn't mention crypto in the bug report, presumably because Cook's patches had not yet been merged). He noted two other commands that would load modules when they shouldn't:

    # ifconfig /usbserial up
    # mount -t /snd_pcm none /

In both cases a prefix is used ("netdev-" and "fs-", respectively) to avoid this kind of problem, but BusyBox effectively ignored them. BusyBox maintainer Denys Vlasenko fixed the bug one day after Krause reported it. There were some fits and starts along the way, but those bugs are fixed now, as Krause noted:

So, all in all, this initial remark on an otherwise unrelated LKML thread [led] to an incomplete fix that, while being tested, uncovered its incompleteness and yet another bug in a completely different code base. Nice bug smashing, I would say ;)

The kernel bug has been around since 2011, when the AF_ALG interface to the crypto subsystem was introduced in 2.6.38. The bugs were assigned three separate CVE numbers: CVE-2013-7421 for the original bug Krause pointed out in 2013, CVE-2014-9644 for the "vfat(aes)" variation, and CVE-2014-9645 for the BusyBox modprobe bug. The kernel fixes are included in the mainline and will be released with 3.19; backports to the stable kernels may be coming as well.

While it is not a particularly critical bug, letting unprivileged users mess with kernel internals is certainly something to be avoided. But it has languished for nearly two years since its discovery, which is kind of surprising. Disabling module loading (either at boot or in the kernel config) is one fairly easy mitigation technique, though it may not be an option for some types of systems (especially desktops and laptops).

Index entries for this article
Kernel	Cryptography
Kernel	Modules
Kernel	Security/Vulnerabilities
Security	Linux kernel/Modules

to post comments

A crypto module loading vulnerability

Posted Jan 29, 2015 2:07 UTC (Thu) by spender (guest, #23067) [Link] (21 responses)

Grsecurity was unaffected by this repeated problem of missing module alias prefixes, as we (prior to the introduction of the NIH-inspired module alias prefix method) had a different solution to the problem of arbitrary module loads by unprivileged users.

-Brad

A crypto module loading vulnerability

Posted Jan 29, 2015 4:14 UTC (Thu) by josh (subscriber, #17465) [Link] (20 responses)

And as with the last hundred instances of grsecurity having solved a problem out of tree, it stayed out of tree until someone else actually got it upstream into the kernel. It's not NIH when the prior implementation didn't actually get upstreamed.

These comments are getting old. Yes, we know that the last time grsecurity tried to patch-bomb LKML it didn't go well. If at first you don't succeed...

A crypto module loading vulnerability

Posted Jan 29, 2015 7:45 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link] (18 responses)

It's also getting old that mainline still doesn't care about implementing years-old, time-proven protections against well-known holes such as, but not limited to, blissfully dereferencing ops structures and executing target code from userspace, or bounds-checking refcounts.
Those are among the protections which make a sanely configured grsecurity / PaX -patched kernel immune to the vast majority of Linux kernel privesc exploits.
It's getting old that mainline still has weak UASLR, and spends time on making, then repeatedly attempting (but still failing, according to spender's comments) to fix an easily defeatable KASLR.
Et caetera.

Of course, those security features reduce performance. But they make the Linux kernel so much more secure.

A crypto module loading vulnerability

Posted Jan 29, 2015 8:03 UTC (Thu) by josh (subscriber, #17465) [Link] (17 responses)

There's a difference between "doesn't care" and "doesn't have a patch in front of it for". If you want something fixed in mainline, submit patches to mainline, in reasonable, self-contained chunks, with explanations.

(Also, the kernel does have at least one protection mechanism against executing userspace code in kernel mode now.)

A crypto module loading vulnerability

Posted Jan 29, 2015 11:28 UTC (Thu) by spender (guest, #23067) [Link] (16 responses)

Yes, "Linux" has a feature for that now. Of course all it took was for Intel to add an explicit feature to its processors, and then yes, for a subset of the processors we support, Linux does now 9 years later (2003->2012) have a similar (but still not quite as good) feature.

I was simply mentioning grsec in response to the article since it didn't mention it at all. If you're jealous of actual innovation and want to make excuses for upstream security, expect factual responses ;)

BTW "grsecurity" never submitted anything mainline. I myself have only ever to my knowledge sent two mails to LKML, one to report a DoS in execve, one to report a boot failure on a rare Itanium system. Both of those no more recent than four years ago. So if you think our goal is to upstream grsecurity, or feel that it is somehow our fault for not upstreaming it and therefore upstream Linux can be absolved of fault for its lack of security, I don't think you understand anything at all really ;)

-Brad

A crypto module loading vulnerability

Posted Jan 29, 2015 12:11 UTC (Thu) by BlueLightning (subscriber, #38978) [Link] (14 responses)

The point is, you have two basic choices:

1) Keep on pointing out how useless you think the Linux kernel is at handling these issues

2) Get stuck in and fix it in the kernel upstream.

Obviously, #2 is harder, but if you actually want things to improve for the benefit of everyone, it's the most effective way to ensure that.

A crypto module loading vulnerability

Posted Jan 29, 2015 14:10 UTC (Thu) by spender (guest, #23067) [Link] (12 responses)

That's a cute false dichotomy you've constructed there, but no, sorry, neither you nor anyone else gets to dictate what I do in my free time. If we want to talk of responsibilities, my responsibility is to my own users -- that is, users of grsecurity.

So, since I don't need the permission of you or anyone else to do what I feel like in my free time, I will continue pointing out how upstream Linux fails to be motivated at all really to create and properly maintain useful security features, as well as how their perspective of security being the fixing of individual bugs is detrimental to their users.

Does not upstream or Red Hat or any other distro selling a product have a responsibility to provide a secure kernel? Even Microsoft has understood that for some years now. It's not my fault that you and others get defensive when faced with the embarrassing fact that neither a huge team of upstream developers and the entire sum of *paid* distro security teams have been able to create anything to match that of three people working on security in their free time over the past 13 years.

So keep doing what you're doing, which doesn't seem to include directing your angst at the people creating the problem, and I'll keep doing what I've been doing: creating useful security for free that anyone who wishes to can use.

-Brad

A crypto module loading vulnerability

Posted Jan 29, 2015 16:23 UTC (Thu) by cesarb (subscriber, #6266) [Link] (6 responses)

> It's not my fault that you and others get defensive when faced with the embarrassing fact

People get defensive when something is rubbed in their face all the time. So yeah, at least in part the defensiveness is your fault.

> that neither a huge team of upstream developers and the entire sum of *paid* distro security teams have been able to create anything to match that of three people working on security in their free time over the past 13 years.

You are standing in the shoulder of giants; the huge team of upstream developers has been working all this time to make the rest of the kernel. Hardening is just one of the many considerations they have; there's a cost-value tradeoff on everything added to the kernel, and hardening often has a large cost (the comment just below yours mentions one kind of hardening breaking many applications) for dubious value (hardening is a "backstop" against other bugs, which shouldn't exist in the first place).

They *could* have matched your output in these years, if they had put security above all other considerations. This seems to be a "blind spot" of many security professionals; they believe security to be the most important characteristic. But a highly secure system that nobody uses is worthless. The Linux kernel has grown in capability, while at the same time matching the hardware evolution; don't forget that the original system Linux ran in had a slow 32-bit single-core processor, no hotplug, no power management... Contrast with a recent LWN article mentioning optimizations so the kernel can deal with 100 Gb/s of network packets (https://lwn.net/Articles/629155/).

A crypto module loading vulnerability

Posted Feb 1, 2015 21:04 UTC (Sun) by imitev (guest, #60045) [Link] (5 responses)

>> People get defensive when something is rubbed in their face all the time

People shouldn't get defensive when better security practices thrown at their face could result in systems making it harder for government agencies to spy so easily, for home routers, IoT stuff, you-name-it to become part of botnets, or for whatever-latest-fancy-bug-in-the-news to be exploited.

>> ... for dubious value (hardening is a "backstop" against other bugs, which shouldn't exist in the first place).

Do you really mean that no security protections are needed at all since no bug should exist in the first place ? That's utopic at best.

>> But a highly secure system that nobody uses is worthless.

FWIW, I'm using a custom grsecurity kernel on my centos 7 servers for a few months now, and I had *0* problem, without any tweak needed for the kernel nor user-space. And for whatever reason (leaner or more recent kernel ?) I didn't witness any performance drop compared to the stock kernel. And that's with CONFIG_GRSECURITY_* stuff set to max security, not performance tradeoff.

Spender made it clear a few times that he doesn't consider pushing those patches to mainline, but I'm still wondering why no maintstream distro boasting security in their PR ads ever picked the patches, either as an alternate kernel, or with a way to enable some of the patches as opt-in.

Performance vs. security will always be a tradeoff, and it's a good thing that linux can deal with 100gb/s traffic, but the problem is that performance in linux is over-represented at the cost of security being a second class citizen.

A crypto module loading vulnerability

Posted Feb 1, 2015 22:29 UTC (Sun) by cesarb (subscriber, #6266) [Link] (4 responses)

> People shouldn't get defensive when better security practices thrown at their face could result in systems making it harder for government agencies to spy so easily, for home routers, IoT stuff, you-name-it to become part of botnets, or for whatever-latest-fancy-bug-in-the-news to be exploited.

People aren't emotionless robots. While cold logic would dictate that one should ignore the "thrown at their face" part, normal people feel annoyed by it. Presentation matters.

> Do you really mean that no security protections are needed at all since no bug should exist in the first place ? That's utopic at best.

No, I mean that the value of hardening protections is reduced by the fact that they only have any value in the presence of other bugs. The more these other bugs are fixed or avoided, the smaller the value of hardening becomes, while its cost remains the same. And the cost is not only performance; things like breaking programs (remember that "don't break userspace" is an important rule in kernel development), or making programs harder to develop or debug, or even extra complexity in the kernel, are also a real cost.

> Spender made it clear a few times that he doesn't consider pushing those patches to mainline, but I'm still wondering why no mainstream distro boasting security in their PR ads ever picked the patches, either as an alternate kernel, or with a way to enable some of the patches as opt-in.

Maintaining out-of-tree patches has a cost. Alternate kernel or opt-in is even worse, since it blows up the testing matrix: every new independent option doubles the number of possible test scenarios. And I believe these mainstream distributions all learned the hard way to avoid diverging from mainline too much.

So the best way to get these patches into mainstream distributions would be to push them into mainline. Since their creator doesn't want to do it himself, they would need an advocate to do that process. I have no insight on why such an advocate is lacking, but it's possible that abrasive behavior has pushed potential advocates away (as I said above, presentation matters).

> Performance vs. security will always be a tradeoff, and it's a good thing that linux can deal with 100gb/s traffic, but the problem is that performance in linux is over-represented at the cost of security being a second class citizen.

It's not just performance, it's also features. Things like being able to use new hardware, for instance. So the tradeoff is not "performance vs security"; it's "performance vs power usage vs required memory vs new hardware vs security vs ..."

Performance is the most talked about because it's easily quantifiable; one can easily point that "this proposed security patch makes a CPU-bound program 2% slower", for instance, while quantifying "this proposed security patch makes the memory management code even more complicated" is harder. But performance is not the only consideration.

The most important consideration would be, I believe, developer and reviewer time. And that's where the tradeoff has the most influence; most developers don't have a "security mindset" (https://www.schneier.com/blog/archives/2008/03/the_securi...), which could be described as "looking at the world through the eyes of an attacker". Most developers are not interested in "making the most secure system ever"; they want to make it run in their hardware, or make it run faster in their hardware, or make it do more interesting and useful things in their hardware.

Which, in the end, is what really matters. "Being secure", by itself, is useless; when people talk about a secure system, they mean "do X but securely", with the "do X" part being what the system actually does, and the "but securely" being an addition. If the system doesn't do X, it will be replaced by a system which does X, even if it's "less secure". If a system's developers focus too much on being secure, to the exclusion of everything else, not many people will use it, and a highly secure system that nobody uses is worthless.

A crypto module loading vulnerability

Posted Feb 2, 2015 0:38 UTC (Mon) by spender (guest, #23067) [Link] (3 responses)

This is really such a sorry excuse of an argument. I keep seeing this idea repeated by you and others that somehow security is only possible if done to the exclusion of everything else. It's amazing how anything can be done at all if people have to work the way you suggest, not even at the individual developer level but project-wide.

You keep mentioning how hardening only has value in the existence of bugs -- let me know in what century that eradication becomes possible. It's funny that you make mention of bugs being avoided, as that itself (e.g seccomp) is an example of security hardening. Not to mention the cost of finding and fixing bugs of the same classes over and over again (while at the same time introducing more of the same type) versus implementing generic defenses against these bug classes. You advocate a strategy that is immensely inefficient as far as security goes.

You also make mention of "breaking programs" but I don't think you really know what you're talking about. In the majority of cases, this is a simple problem for distros to fix -- it's not the job of the kernel. For the same reason PT_GNU_STACK (an upstream "feature") can break apps or reduce security unnecessarily if configured improperly, some features of grsecurity and PaX need proper userland configuration. We even provide a daemon to fix these issues automatically without any specific distro support -- that's by no means "breaking programs".

The fact that grsecurity exists, that it operates on top of the Linux kernel and provides all the same features, supports all the same hardware, and benefits from the same performance improvements you claim can't possibly exist in conjunction with security -- it's a trivial proof by construction that renders your argument nonsensical.

Why bother defending something that's clearly lacking? You'd at least have some shred of credibility if you could admit simple truths.

-Brad

A crypto module loading vulnerability

Posted Feb 2, 2015 12:47 UTC (Mon) by cesarb (subscriber, #6266) [Link] (2 responses)

> I keep seeing this idea repeated by you and others that somehow security is only possible if done to the exclusion of everything else.

I didn't say that; I said that security to the exclusion of everything else, or even an excessive focus on security, would get nothing useful done.

> You keep mentioning how hardening only has value in the existence of bugs -- let me know in what century that eradication becomes possible. It's funny that you make mention of bugs being avoided, as that itself (e.g seccomp) is an example of security hardening.

Seccomp is not a bug being avoided, it's merely security hardening. Avoiding bugs is using compiler features, static checkers, or even design patterns to prevent the bug from happening in the first place. A simple example is the "must check the return value" function attribute, which makes it harder to forget to check the return value of a function. Another example is the "printf format" function attribute, which warns the developer when the arguments don't match the format.

Yes, erradication is not possible, even with formal proofs (since the formal specification might be wrong). But it doesn't change the fact that fixing or avoiding bugs reduce the value of hardening, without reducing its cost.

> You also make mention of "breaking programs" but I don't think you really know what you're talking about.

Since I've never used grsecurity or PaX, I'm going by second-hand information; I had just read a comment on a nearby thread mentioning that one feature of one of them breaks several programs.

> In the majority of cases, this is a simple problem for distros to fix -- it's not the job of the kernel. For the same reason PT_GNU_STACK (an upstream "feature") can break apps or reduce security unnecessarily if configured improperly, some features of grsecurity and PaX need proper userland configuration.

So it's a case of "breaks programs unless configured not to", and doing that configuration has a cost. That's what I'm talking about - these hardening features have a cost and a value, and there's a tradeoff between them. And the cost and value functions are different for different people; you value security so highly that the cost becomes trivial, but for people with different value functions, the comparative cost is higher.

> The fact that grsecurity exists, that it operates on top of the Linux kernel and provides all the same features, supports all the same hardware, and benefits from the same performance improvements you claim can't possibly exist in conjunction with security -- it's a trivial proof by construction that renders your argument nonsensical.

But who wrote all these features, hardware support, and performance enhancements? As I mentioned in my initial comment, you are standing in the shoulder of giants. The developers who wrote all those things weren't focused on security; they were focused on writing the features, hardware support, and performance enhancements. Had they focused on security instead, would we have all these things? Or would we have a highly secure system that nobody would use?

A crypto module loading vulnerability

Posted Feb 3, 2015 10:24 UTC (Tue) by imitev (guest, #60045) [Link] (1 responses)

>> I said that security to the exclusion of everything else, or even an excessive focus on security, would get nothing useful done.

Something like selinux in strict/mls mode would be a good example of getting nothing useful done for casual computer use. But grsecurity patches proved to be unintrusive and they are useful in protecting a system from a vast range of exploits.

>> But it doesn't change the fact that fixing or avoiding bugs reduce the value of hardening, without reducing its cost.

We may agree to disagree then. LWN articles and some maintainers often lament the lack of proper review of kernel patches, and with the current kernel development pace it's not like we're fixing more bugs that we're creating. And even if that trend was reversed, providing global safeguards (hardening) that would protect against a single but devastating exploit still has a huge value.
The cost for users is ~0, and for kernel devs they'll have to adapt the work / PoC Spender has done. IMO the value/cost ratio is huge.

>> [...] you are standing in the shoulder of giants. The developers who wrote all those things weren't focused on security; they were focused on writing the features, hardware support, and performance enhancements

True. Hence the problem that you have to add security as an after-thought, and then people complain that it breaks stuff or hurts performance (which as stated before, wasn't even the case with grsecurity for my particular use cases). Compared for instance to managing a selinux system, fixing a few grsecurity flags for user space programs requiring lower security is dead easy. Mainstream distributions have much more invasive customizations so it's not like they couldn't fix this if they decided to ship grsecurity.

In a pre-Snowden world you could have said that paying more attention to security would slow kernel/linux development, but today people are finding out the hard way that there's indeed a need for better security. I have a feeling that the majority of kernel devs still focuses more on coding style issues than security, which is a pitty. The perceived abrasiveness of security people is not a reason to ignore their work altogether and throw out the baby with the water bath. In comparison Linus is pretty abrasive too, but nobody seems to have anything to say about it.

I'd recommend you give grsecurity a try, there's no need to be a security expert. For me the "cost" you often mention has been to figure out what the bazillion config options a vanilla kernel has nowadays were for, and setting a build environment. Save for reading the documentation of the various grsec config options, the cost of running grsecurity kernels has been 0 so far.

A crypto module loading vulnerability

Posted Feb 4, 2015 1:21 UTC (Wed) by flussence (guest, #85566) [Link]

>The perceived abrasiveness of security people is not a reason to ignore their work altogether and throw out the baby with the water bath. In comparison Linus is pretty abrasive too, but nobody seems to have anything to say about it.

True, though on the other hand Linus doesn't make a habit out of gloating at other people's mistakes in the comments of articles here.

*Your* post is doing a much better job of promoting grsec, FWIW. I can read it without feeling attacked for using a mainline kernel...

A crypto module loading vulnerability

Posted Jan 29, 2015 17:35 UTC (Thu) by flussence (guest, #85566) [Link] (4 responses)

Perhaps the fact so few people wish to use your code is a hint that its presentation needs improving.

A crypto module loading vulnerability

Posted Jan 29, 2015 17:52 UTC (Thu) by Limdi (guest, #100500) [Link] (3 responses)

Or it hints that custom kernel installation is not one click away. Nor two, nore three.

A crypto module loading vulnerability

Posted Feb 5, 2015 15:09 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

Actually, custom kernel installation is pretty easy.

It's just because most people expect to switch their computer on and get a login prompt. They don't know anything about how it gets there, and are afraid to try, because they think any cock-up will need a complete re-install.

(And yes, when things go wrong, recovering can be a right pain - been there, done that!)

That's basically it - fear of the unknown. I don't like messing about REPLACING known-good stuff (which is why I don't like grub2-mkconfig that much!) but I build new kernels, I *add* them to my boot scenario, and it's pretty easy.

It's like driving a car - many of us oldies are much better at looking after our cars not because we can do any of the maintenance, but because we understand how cars work we look after them better such that maintenance is less necessary.

Too many people remember the old days of tvs when "if it doesn't work, hit it" was good advice. So, in good old cargo-cult science mode, when an lcd tv doesn't work they hit it and wonder why it breaks :-)

If you actually learn what goes on under the covers, custom kernels shouldn't be scary at all ... :-)

Cheers,
Wol

A crypto module loading vulnerability

Posted Feb 5, 2015 16:17 UTC (Thu) by cesarb (subscriber, #6266) [Link] (1 responses)

There's another aspect to the use of a custom kernel.

When you use a distribution-provided kernel, it's updated through the package manager. You don't have to do anything other than keeping the distribution updated; it'll be kept up-to-date together with the rest of the system.

When you use a custom kernel, you're responsible for updating it. You have to follow the announcements for new kernel releases, download the patches and recompile every time a new version is released.

A crypto module loading vulnerability

Posted Feb 5, 2015 16:23 UTC (Thu) by dlang (guest, #313) [Link]

more to the point, people are afraid of custom kernels because they think it completely invalidates their support (and to be fair, some support organizations encourage this belief)

A crypto module loading vulnerability

Posted Jan 29, 2015 14:14 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link]

Doing PaX / grsecurity and upstreaming PaX / grsecurity are two very different tasks requiring different skills.

The former consists mostly in analysis, development, coding and debugging work. It requires higher technical skills, and it is performed (mainly on their spare time) by persons who'd rather focus on good defensive measures (as opposed to half-measures of the "better than nothing, but still far short of good" variety, ala KASLR), coding, and some argumented finger pointing at ongoing insecurity policies.
I'm told that rebasing PaX / grsec changes onto mainline for each kernel version, every ~60-70 days nowadays, is not an insurmountable task.

The latter is a matter of security-minded programmers integrating existing code in working shape, dealing with politics (getting changes accepted in the first place, staying firm on not reducing the value of PaX / grsec protections as part of mainlining), following up on core and subsystem maintainers, etc.
IMO, the latter is a job for RedHat, Google and/or other large organizations with large Linux interests, who can afford the expense of men-months of skilled developers performing some kind of interface between the PaX / grsec code and top kernel devs.
Bystanders can help filtering the useful bits by taking care of the easier bits of the huge PaX and grsecurity patches, some of which are drive-by changes not too directly security-related.

Gentoo hardened, Arch and openSUSE, among others, have done some work in the area of integrating PaX / grsec at the kernel package and the packaging system levels. This is a double-edged sword, which raises the weight of PaX / grsec (historically, mainline has already shown some receptiveness to originally out-of-tree, but time-proven patches carried by distros), but also makes it easier to sidestep mainline integration.
Though it can be done outside the packaging system, with e.g. paxd, packaging system integration is probably more likable to distros for setting the appropriate xattrs on hundreds of insecure applications which die horribly in PaX enforcing mode.
Distro grsec packages nullify the protective value of struct layout randomization, but machines running distro grsec kernel remain far less convenient for attackers to exploit than machines running distro mainline kernel packages.

A crypto module loading vulnerability

Posted Feb 2, 2015 9:57 UTC (Mon) by edeloget (subscriber, #88392) [Link]

> BTW "grsecurity" never submitted anything mainline.

With all the genuine respect I have for you and for your work, if you don't do it, who will? I don't have your knowledge on these issues, and I suspect many other are in the same case, so placing this burden onto our shoulders is a recipe for disaster.

A crypto module loading vulnerability

Posted Jan 29, 2015 10:52 UTC (Thu) by PaXTeam (guest, #24616) [Link]

> [...] the last time grsecurity tried to patch-bomb LKML [...]

when did that happen?

A crypto module loading vulnerability

Posted Jan 29, 2015 4:17 UTC (Thu) by josh (subscriber, #17465) [Link] (4 responses)

These types of issues seem like they play off of an underlying problem: distributions ship something akin to "allmodconfig", including all the obscure modules with all their obscure vulnerabilities. The kernel has closed various issues that allowed users to trigger loading of arbitrary modules (that they could subsequently attempt to exploit), but could we do anything to fix the underlying problem?

A crypto module loading vulnerability

Posted Jan 29, 2015 10:57 UTC (Thu) by PaXTeam (guest, #24616) [Link]

perhaps some of the kernel attack surface reduction work reported here: http://researcher.ibm.com/researcher/view_person_pubs.php...

A crypto module loading vulnerability

Posted Jan 29, 2015 13:54 UTC (Thu) by SLi (subscriber, #53131) [Link] (2 responses)

Well, what do you think they should do? Distribute only the modules that everybody uses, and force 95% of people to compile their own kernel? How should someone decide what's important to include?

Perhaps the kernel config help should tell which modules are probably important and which are not?

And when I'm compiling a kernel for myself, if I want to prepare for the case that I purchase some new hardware (without knowing in advance what), which modules should I build if I want to avoid recompiling the kernel again?

A crypto module loading vulnerability

Posted Jan 29, 2015 16:45 UTC (Thu) by josh (subscriber, #17465) [Link] (1 responses)

For one thing, perhaps move some of the modules that only a tiny fraction of a percent of people will use, and that commonly lead to exploits (such as obscure in-kernel filesystems or obscure network protocols) into separate packages, where people who know they need them can install them.

For another, I'd love to see many of the in-kernel filesystem implementations for obscure filesystems (the kind typically only used for data forensics and recovery) turned into FUSE filesystems and moved into sandboxes in userspace, where an exploit does much less harm. A bit of work on compatibility could allow "mount -t obscurefs" to automatically become "mount -t fuse.obscurefs". Ditto for any other such functionality that could be moved to userspace without affecting its users.

A crypto module loading vulnerability

Posted Feb 7, 2015 9:10 UTC (Sat) by farnz (subscriber, #17727) [Link]

For the first suggestion, do you mean something like Fedora's kernel-modules-extra package? It moves a selection of lesser used modules into a separate package, so that they're still available if you need them, but not installed if you don't (and most people don't need them).

Another solution

Posted Jan 29, 2015 10:43 UTC (Thu) by Seegras (guest, #20463) [Link] (2 responses)

I actually did have a solution in place for a long time:

root@laurin:~# lsmod
libkmod: ERROR ../libkmod/libkmod-module.c:1638 kmod_module_new_from_loaded: could not open /proc/modules: No such file or directory
Error: could not get list of modules: No such file or directory

Yes, that's
# CONFIG_MODULES is not set
in the kernel .config

The trouble is, some people actually have add-ons for firewalls that must be compiled as modules. http://xtables-addons.sourceforge.net/geoip.php

Another solution

Posted Jan 29, 2015 11:02 UTC (Thu) by PaXTeam (guest, #24616) [Link]

this works for custom kernels, but no so much for generic distro kernels. what may help them is a mechanism that would let modules link into vmlinux at installation time (and later every time a new not-yet-used module gets loaded) so that over time a sort-of monolithic vmlinux would emerge on the user's machine (of course bugs like the one in the article wouldn't help this process).

Another solution

Posted Jan 30, 2015 17:13 UTC (Fri) by jhhaller (guest, #56103) [Link]

And, there are some devices which must have firmware installed before their modules can be installed. I have a TV tuner with that issue. I'm not actually using that card but haven't pulled it. After a disk crash and a kernel reinstall, I didn't reinstall the firmware, and the module won't load.

Can you mount fs images in userns?

Posted Jan 29, 2015 14:01 UTC (Thu) by SLi (subscriber, #53131) [Link] (1 responses)

It's never been quite clear to me, even after googling, what's possible in a userns and what it's intended to do securely. Perhaps someone could enlighten me?

Apparently the idea is that you can do contained root-like operations as non-root. Does root still need to enable this case-by-case? Obviously it wouldn't make much sense to let a user run shutdown() in a userns?

Would a default configuration, or a configuration intended to be reasonably secure, let unprivileged users mount filesystem images in a user namespace? If that is the case, from personal experience I know that it's easy to at least crash the system with a corrupted filesystem (read: every time I've tried I've accomplished it in a few hours), and I'd be willing to bet that it could with some effort also be used to elevate privileges. Even if you don't allow modifying a mounted image, which I believe the filesystems don't even try to survive.

Can you mount fs images in userns?

Posted Jan 30, 2015 6:23 UTC (Fri) by dlang (guest, #313) [Link]

In a user namespace you are supposed to be able to do just about anything that only affects that namespace, including creating a 'root' account that gets used within that namespace

The kernel has been modified (hopefully completely) so that userids in a userns are always converted to their real userid before the kernel does permission checks for things that need root permission.

But the crypto module problem is actually unrelated to namespaces.

What's happening here is that the kernel defaults to trying to be helpful. In many cases, if you try to access some capability that could be a module, and that capability isn't part of the kernel already, it will try to be helpful and automatically load the needed module rather than returning an error.

In some cases, which module gets loaded can be specified by whatever is triggering the load. In the case of mount, it's the filesystem type that is used as the module name. In crypto it's the encryption type that's used as the module name.

When the mount problem was hit, it was something that could only be done by root, and mostly dismissed (because root could already load an arbitrary module, even arbitrary code). Then when it was found that it could be triggered by normal users inside a user namespace, a fix was put in place.

The crypto module loading can be triggered by any normal user just trying to use crypto the way it's supposed to be used. and then shortcuts in the busybox modprobe code made it even harder to patch around.

This sort of thing is why I like to avoid modular kernels on my servers and disable loading modules entirely (even though some top kernel developers have told me that my concerns are silly, and disabling module loading is meaningless because root can work around it)

A crypto module loading vulnerability

Posted Feb 8, 2015 3:58 UTC (Sun) by scientes (guest, #83068) [Link] (1 responses)

AF_ALG also doesn't work with spice () and friends. I got in a patch fixing a regression in this area but on dither testing it is still broken, and always was.

A crypto module loading vulnerability

Posted Feb 8, 2015 4:44 UTC (Sun) by viro (subscriber, #7872) [Link]

Yes, its ->sendmsg() wants to play with get_user_pages_fast() (or iov_iter_get_pages() these days) and that just doesn't work for kernel pages. FWIW, we probably could teach iov_iter_get_pages() to work with ITER_BVEC - pages in these guys _are_ refcounted in normal fashion, so splice() could be doable. kernel_sendmsg(), OTOH, is probably hopeless...