Recent Features
| |||||||||||||
A story of three kernel vulnerabilitiesA story of three kernel vulnerabilitiesPosted Feb 19, 2013 21:47 UTC (Tue) by Trou.fr (subscriber, #26289)In reply to: A story of three kernel vulnerabilities by spender Parent article: A story of three kernel vulnerabilities
I concur with spender's remark, the vulnerabilities could have been selected to underline a real problem with security and not just metrics with a DoS nobody will ever trigger (the ext4 one is a joke).
However, the handling of the ptrace vuln is very representative of the state of security in the Linux world.
Nobody cares about real security. The only progress that has been made in actual security in a _mainline_ distro was in Ubuntu with the work of Kees Cook. Distros don't care about security, Linus doesn't care either so we're stuck with a platform with very little progresss in 10 years.
The support for signed kernel module is quite representative too : it's been implemented because of UEFI, 10 years too late (in Linus' words).
Seeing the awesome work in grsecurity and PaX being ignored is depressing. The discussion about the inclusion of grsecurity in Debian is quite revealing : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090 :( It leads to fragmentation : people with security needs manage and maintain their own grsecurity kernel and just don't even try to push it upstream because of the refusals they will get...
Microsoft, which was despised for its horrible security 10 years ago has made such progress that Linux is considerably behind now. I just hope we'll be able to catch up.
(Log in to post comments)
A story of three kernel vulnerabilities Posted Feb 19, 2013 22:05 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
support for signed kernel modules has existed for a long time and wasn't created because of UEFI. It has been in the distro kernels for years before it got upstream. Specifically, RHEL kernels have been using it. It just got recently upstream however.
A story of three kernel vulnerabilities Posted Feb 19, 2013 22:59 UTC (Tue) by spender (subscriber, #23067) [Link]
Signed module support is still completely useless unless the /dev/cpu/*/msr vulnerability is fixed properly. Checking for CAP_SYS_RAWIO doesn't cut it.
-Brad
A story of three kernel vulnerabilities Posted Feb 19, 2013 23:37 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
If you're root you've also got access to the MMIO regions of a bunch of devices with DMA engines, so just locking down MSR access isn't going to be a huge win. The Secure Boot work covers most of this, but it's based on the assumption that unless you've got some mechanism for verifying the integrity of your bootloader and on-disk kernel, the security improvement isn't huge - modify the embedded sectors of the bootloader (so tripwire won't pick things up), and just wait for the system to be rebooted for a kernel security update.
Signed module support in RHEL was never about security, it was about supportability. If customers are willing to use MSR hacks to load unsigned modules they're also going to be willing to just modify their bug reports to remove the tainted flags, so making it foolproof was never a great concern.
A story of three kernel vulnerabilities Posted Feb 20, 2013 10:30 UTC (Wed) by renox (subscriber, #23785) [Link]
> I concur with spender's remark, the vulnerabilities could have been selected to underline a real problem with security and not just metrics with a DoS nobody will ever trigger (the ext4 one is a joke).
"could have been"? What about the HFS+ exploit?
A story of three kernel vulnerabilities Posted Feb 20, 2013 13:52 UTC (Wed) by Trou.fr (subscriber, #26289) [Link]
well it's a "real" issue but it's nothing compared to others that have a wide security impact as in every script kiddie can pwn a webserver :
1) outdated CMS with remote code execution (mostly PHP) 2) easy execution of any executable 3) ready to use exploit that works reliably as unprivileged user
The HFS+ vuln is not exploitable in that case. While it can be used for "physical" attacks like the USB key, it is not usable remotely.
_Thousands_ of servers have been compromised with that scenario :
A story of three kernel vulnerabilities Posted Feb 20, 2013 16:24 UTC (Wed) by bfields (subscriber, #19510) [Link]
In the late eighties/early nineties I seem to recall infected floppy disks were the main (or at least a very common) vector for virus transmission.
If people don't exchange data on usb keys as much as they used to on floppies, perhaps that wouldn't be as effective these days.
A story of three kernel vulnerabilities Posted Feb 20, 2013 23:59 UTC (Wed) by andrel (subscriber, #5166) [Link]
Supposedly Stuxnet was transmitted using a USB key.
A story of three kernel vulnerabilities Posted Feb 21, 2013 11:55 UTC (Thu) by Trou.fr (subscriber, #26289) [Link]
Stuxnet used a vulnerability in the Windows shell (the so-called LNK vulnerability), not in the filesystem code.
As for floppies, viruses spread mostly by running infected executables, not using vulns.
A story of three kernel vulnerabilities Posted Feb 20, 2013 20:44 UTC (Wed) by corsac (subscriber, #49696) [Link]
And about support for signed modules: I'm sure everyone loves having an X509/ASN1 parser running in ring0.
A story of three kernel vulnerabilities Posted Feb 20, 2013 21:23 UTC (Wed) by raven667 (subscriber, #5198) [Link]
There is far far far more than that when it comes to complex interfaces. Aside from the arbitrariness of ioctl there is bpf and GPU command validation as well as iptables and who knows what else that is passing complex data structures into the kernel.
A story of three kernel vulnerabilities Posted Feb 21, 2013 3:16 UTC (Thu) by draco (guest, #1792) [Link]
There's nothing about signing stuff that requires ASN.1 or X.509. Also, it's entirely possible that userspace uses ASN.1/X.509 to get at the keys to sign with, but something else to carry the signature itself.
If the kernel must parse ASN.1/X.509 to parse the signature for authentication...yikes, but that's not a requirement. (And even if they are, I hope it's a really limited implementation.)
A story of three kernel vulnerabilities Posted Feb 21, 2013 6:16 UTC (Thu) by corsac (subscriber, #49696) [Link]
A story of three kernel vulnerabilities Posted Feb 21, 2013 19:13 UTC (Thu) by zlynx (subscriber, #2285) [Link]
I'd rather have an ASN1 parser in there than yet another custom format. At least ASN1 is well defined and doesn't shift its meaning on different machine architectures.
A story of three kernel vulnerabilities Posted Mar 1, 2013 17:56 UTC (Fri) by lopgok (guest, #43164) [Link]
I think the SELinux is real security 'progress in a _mainline_ distro'.
It is in the mainline kernel.
|
|||||||||||||