Unsafe at any clock speed: Linux kernel security needs a rethink

[Maxnix]

Just read on ArsTechnica: http://arstechnica.com/security/2016/09/linux-kernel-security-needs-fixing/

 

[kpa]

I didn't spot anything in that article that wouldn't apply to the FreeBSD kernel as stated. Things are equally bad for FreeBSD if you look at it with an unbiased critical eye.

 

[Maxnix]

Yeah, I agree about the implementation of proactively defensive technologies and all the problems caused by third parts softwares, but what hit me was this Cook's consideration:

"I hear a lot of blame-shifting of where this problem needs to be solved," he told the audience. "Even if upstream says 'oh sure we found that bug, we fixed it,' what kernel version was it fixed in? Did it end up in a stable release?"

Personally I've never heard of something similar in FreeBSD.

 

[kpa]

Yeah, I agree about the implementation of proactively defensive technologies and all the problems caused by third parts softwares, but what hit me was this Cook's consideration:

Personally I've never heard of something similar in FreeBSD.

We are in an happy (unhappy?) situation where almost none of the major vendors have a real interest in supporting FreeBSD directly in form of their own drivers. Intel is the major exception and is of course an example how it should be done, we have many competent developers working on the Intel drivers with direct support from Intel's engineers. We still have another problem with some of the kernel drivers. For example, the bluetooth support in FreeBSD was done by a single person (as I understand it) and it's quite honestly a disaster, nobody seems to want to touch the code because it's so broken. We also have problems with testing device drivers, just look at how long it has taken to produce the DRM/KMS drivers only because the devs working on it have had access only to a small percentage of the huge variety of the hardware targeted by the drivers.

Looking at the big picture we shouldn't treat our favorite OS with silk gloves, it's still a result of the exact same thinking and design that produced all of UNIX and UNIX-like operating systems including Linux. The design is still a monolithic kernel with nothing separating device drivers from the main kernel code at runtime, a single mistake in any of the device drive code can potentially take down the whole system and that's not something I would call a feature of a modern operating system. Don't get me started on the security implications of this design.

 

[Aaron45]

We are in an happy (unhappy?) situation where almost none of the major vendors have a real interest in supporting FreeBSD directly in form of their own drivers. Intel is the major exception and is of course an example how it should be done, we have many competent developers working on the Intel drivers with direct support from Intel's engineers. We still have another problem with some of the kernel drivers. For example, the bluetooth support in FreeBSD was done by a single person (as I understand it) and it's quite honestly a disaster, nobody seems to want to touch the code because it's so broken. We also have problems with testing device drivers, just look at how long it has taken to produce the DRM/KMS drivers only because the devs working on it have had access only to a small percentage of the huge variety of the hardware targeted by the drivers.

Looking at the big picture we shouldn't treat our favorite OS with silk gloves, it's still a result of the exact same thinking and design that produced all of UNIX and UNIX-like operating systems including Linux. The design is still a monolithic kernel with nothing separating device drivers from the main kernel code at runtime, a single mistake in any of the device drive code can potentially take down the whole system and that's not something I would call a feature of a modern operating system. Don't get me started on the security implications of this design.

For most of my professional career, the hardest hitting malware that I've seen on Windows based platforms utilized malicious drivers that were installed with administrator privileges. This is one of the reasons why driver signing has come around in the Windows world.

According to my own understanding, the same type of attack is possible on a Unix/Linux platform (though many a Linux geek has argued, even yelled at me for this statement). But the way the Linux crowd has defended against this attack is by preventing access to the root account, and thus blocking the installation of the malicious driver altogether. Of course, there's two problem with this, one of which has been pointed out already: vendor provided drivers with security holes and social engineering. We can't control what the vendors do and a root password can be disclosed through a well designed social engineering attempt.

So with that being said, I've always adopted two strategies. One: adopt defense in depth and assume for a moment that your security measure fails and two: always underrate and under advertise your product; humble and safe is always better than being proud and hacked. Basically what I'm saying is that maybe it's time to take a look at the kernel to see if it can't be secured against this?