A crypto module loading vulnerability

Posted Jan 29, 2015 4:17 UTC (Thu) by josh (subscriber, #17465)
Parent article: A crypto module loading vulnerability

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).