The State of Linux Security | Hacker News Reader

The State of Linux Security

linux-audit.com

141 pointskungfudoi55 comments

> Backdoor in Linux Mint (February 2016)

> Stop using MD5. If you still use SHA1, then add also the SHA256 or SHA512 hashes.

How did hash strength have anything to do with this? Unless my sources are completely out of whack, the MD5 of the backdoored ISO didn't match the official ISO. My understanding is that there is a vulnerability along these lines, but it requires the official build process to be compromised, whereas this was an edit on the Mint website to point to a malicious file on an attacker-controlled server.

The edit to the site was due to the whole thing being Wordpress. I know that Wordpress is decently flexible, "good enough" or even comfortable for many users, even technical ones, my thought is why not have the site be statically hosted instead? Or at least the primary informational pages.

Interesting that the site uses TLS, but most of the servers containing the download use plain old HTTP, which as we know, can be easily subjected to a MITM attack.

https://linuxmint.com/edition.php?id=225

Only a few of the ISOs are delivered with TLS/HTTPS, like this one:

https://mirrors.c0urier.net/linux/linuxmint/iso/stable/18.1/...

Properly signed images shouldn't need to be delivered over a secure connection. As long as you can receive a signed hash, and the signing key itself over a secure connection, you can obtain the image itself from anywhere.

and the signed hash is actually checked against the image. Of course, this is the step that is missing because it's a non-mandatory manual process.

Serving the images directly over HTTPS would provide more security for every end user that is not manually checking signing hashes.

True, although sometimes it's good to deliver signed updates over a secure connection for defense-in-depth - for example, to mitigate vulnerabilities like the recent CVE-2016-1252.

+1 "but some software has it's own crypto"¹ is kinda bad excuse for actively avoiding additional security - like Debian has on their mirrors (I think there even is (was?) an FAQ entry why there are no HTTPS mirrors, stating that APT packages are securely signed and that's all you'd need).

¹ I'm aware that APT actually uses GPG, but it does (did) so fishy manipulations both before and after invoking GPG on the signed files, that, if this would've happened in a corporate setting, I'd have rather peculiar questions for the employee who wrote that code.

That recent CVE, and also issues in software that I co-maintain, plus all the other CVEs that are delivered to my inbox changed my mind on open source quite a lot. Open source is completely worthless if no one actually bothers to read the code; I doubt anyone actually read those portions of the APT code, because anyone with a secure coding or crypto coding background should be alerted already by the function names (look them up). Instead we all always assume "ah well people use it and someone probably checked that anyway... should be good to go!". NO. It's not good to go. Read [the] code.

> ¹ I'm aware that APT actually uses GPG, but it does (did) so fishy manipulations both before and after invoking GPG on the signed files, that, if this would've happened in a corporate setting, I'd have rather peculiar questions for the employee who wrote that code.

From the openSUSE, I brought up my concerns about us not using HTTPS and it boils down to the fact that few mirrors want to host stuff over SSL. And if not many mirrors will do it, the benefit to users is diminished (you can't force the usage of SSL on the client).

On the plus side, openSUSE does serve a copy of the GPG signing key for the ISO over HTTPS (from the main site). I just wish that there were less steps required to be sure that the ISO is official.

Hashing strength has nothing to do with it. The real lesson is that they should have signed the hash they put on their website and actively encourage users to check it.

I would also argue that it's important not to conflate issues with the Linux kernel with any particular Linux distribution specific issue. The incident with Linux Mint is not reflective of the broader security of Linux in general, although it is good to point out that how one distributes anything can have security ramifications.

I feel the same way about the discussion of Mirai - the only thing broken embedded/IoT systems have in common with any given Linux distro, is the kernel, and maybe a few basic userspace bits (sometimes).

The site does have some interesting discussion about Core Infrastructure (again technically separate from Linux, although fundamental) and other Kernel issues and hardening though.

Wait, Linux did not have stack guard pages and r-x code pages until 4.9?

Pax/Grsecurity fork probably has it for some time, but not mainline tree (i.e "torvalds" linux).

Linux doesn't power the smallest devices in the world. It's about two orders of magnitude too large out at the low end.

Out of interest, what does?

Just random RT OS's? It's been awhile since I've worked on tiny 8 bit mcus, but all the stuff was really small and seemingly hand rolled, nothing as monolithic as Linux.

I would not be surprised to learn that it varies from company to company and chip to chip, with various bits being shared for common logic.

I remember VxWorks. Bigger than a while loop, but used in space missions back in the 90s: http://www.windriver.com/inspace/

Edit: looks like VxWorks wants a 32-bit CPU, 128KB of ROM, and 1-2MB of RAM. But you get threads, networking, filesystem, etc.

On the really low end, hardware is often single-purpose and you don't really need an operating system. When there is an operating system (maybe you have to listen to messages from something while performing a previously requested activity), a small hard real-time scheduling library gets used as an "operating system".

There are all kinds of micro-everything circulating out there, from timing and IO drivers to entire network stacks.

The almost-smallest devices are powered by LoopOS(tm):

  while(1){ }

So slow and bloated! Get with 2.0:

    for(;;){ }

As foofoo said, they often don't use OS's so much as libraries and loops. There are OS's that have been out there for a while for tiniest devices. Contiki is probably a nice intro to different tradeoffs they make in design and features:

http://www.contiki-os.org/

On more serious MCU's, you might see things like VxWorks or QNX:

https://en.wikipedia.org/wiki/VxWorks

https://en.wikipedia.org/wiki/QNX

As hardware improved, we also saw trimmed down Linux like ucLinux, MontaVista Linux, and so on. It just went from there with increasing complexity (and reboots :).

Tron/Etron and variants most likely if any operating system at all. What powers non-smart refrigerators, dishwashers, washing machines, microwave ovents, etc? Tron for many of them.

https://en.wikipedia.org/wiki/TRON_project

Most of the really small stuff is written bare-metal in C or assembler. E.g. http://www.microchip.com/wwwproducts/en/PIC10F200 : 384 bytes of code space, 16 bytes of RAM. More constrained than the Atari 2600.

$0.31 each, available in 2mm x 3mm packages.

Would it be fair to say that, by and large, it powers the smallest general-purpose computers?

Linux will always be insecure. There's no fixing millions of lines of code running in supervisor mode.

What will happen instead is that the world will move on to a microkernel-based OS.

Ok Mr Tanenbaum, Linus and you already had this argument </sarcasm>

And looking at embedded OSes, L4, sandboxing in Apple, Google and Microsoft OSes, the future direction is quite clear.

Does Apple run on a MicroKernel? Microsoft? Google definitely doesn't (it runs on linux).

The problems they solve are orthogonal to kernel issues.

Sandboxing thwarts userspace attacks (any program I install has access to my userspace). Microkernels solve kernel side attacks.

Apple uses XNU which is a hybrid kernel based on the Mach 3 microkernel

https://en.wikipedia.org/wiki/XNU

OSX is effectively a microkernel in name only, its a microkernel with a single monolithic UNIX kernel client, and has virtually none of the advantages of a real microkernel setup with multiple clients sharing tasks.

The real irony is that Android might as well run on a microkernel, considering no OEM has any intention of ever making their firmware work on anyone else's hardware. Everyone's ROMs would be more or less just as incompatible as they are now, but at least they'd be faster and much more secure at the kernel level.

>but at least they'd be faster

The problem with microkernal's isn't compatibility, it's speed.

QNX, Genode and L4 have solved that problem longtime ago.

The problems with microkernels are mostly urban legends.

So why can't hurd get its act together?

Lack of resources and manpower.

Lack of volunteers.

Because they're still using Mach, and most capable contributors moved on to microkernel-based projects that actually aren't hopeless.

http://blog.darknedgy.net/technology/2016/01/01/0/

Google's working on Fuchsia. This might be exactly their plan.

Yes all of them do depend on some form on microkernels.

It is called L4 and is responsible for the baseband communications and secure enclave.

https://en.wikipedia.org/wiki/L4_microkernel_family#Commerci...

Guys...All of you are irrelevant. Doesn't matter if one driver can access another. I just need to read data in user home directory and I can find out everything I need.

Or go to random website look for .Git folders, recreate directory structure from object file, get MySQL passwords and steal user data (I'm not responsible for anyone using my comment for illegal purposes)

Microkernals are supposed to make OSes more stable but they don't. Linux work good enough due to automated testing and amazing kernel engineers.

GNU Hurd, Mach 3, Minix - so far track record isn't good. Stop flamewaring and fire up vim. Write a microkernals if you think you can do a better job

> Doesn't matter if one driver can access another. I just need to read data in user home directory and I can find out everything I need.

Well, you'd need the adequate permissions to do that in the firstr place.

Or you'd have to exploit the VFS (good luck with that), the disk driver (which is hidden behind VFS, good luck with that), or some other driver which hardware is for some reason not isolated via iommu (good luck with that).

> Linux work good enough due to automated testing and amazing kernel engineers.

You definitely do not run much Linux on production, else you'd know how amazing 2016 has been, regarding kernel vulnerabilities.

Some of them were even reliably exploitable on grsec/pax patched kernels.

> Microkernals are supposed to make OSes more stable but they don't.

Except most RTOSs and anything with high assurance requirements uses microkernels.

> GNU Hurd, Mach 3

Hurd uses Mach, a pre-liedtke, old world microkernel. Not really worth pointing at it, the same way 1971 UNIX isn't representative of Linux.

> Minix - so far track record isn't good.

Minix is doing quite well at what it set out to do: Fault-tolerance.

L4Linux on Genode. Problem solved.

Integrity PC, LynxSecure, and Turaya Desktop being commercial equivalents being sold now. Genode a dual-licensed work in progress. Minix 3 did it for availability with NetBSD layer.

Definitely proven to be doable but just few doing it.

Counterexample - OpenBSD.

Even a micro-kernel won't help. Even there, you have a few "keys to the kingdom", such as compromising the HD driver (If I can write what I want, I can modify the micro-kernel how I want).

There's also no rewriting millions of lines of code. There are a bunch of more realistic approaches, like making compilers much safer by default, sandboxing services, partially microkerneling critical pieces of code, for example: moving network stack out of the kernel and into the userspace with proper security measures, we even already have netmap to begin the process.

Like what Criswell et al are doing with SVA-OS and CHERI team are doing with CheriBSD.

Not a single mention of grsecurity and RAP, useless article.

Yep. More of the same. Despite most of the recent improvements to the Linux kernel essentially boiling down to cherry picking Grsec/PaX, no one gives them due credit. And no one's even talking about RAP.

Well, given the fact that the grsecurity folks violate the GPL, in not sure what recognition they deserve other than "you can now get their feature in a free software, mainline kernel".

Can you let me know exactly where I can get RAP?

You seems to be slandering grsec for no reason.

> You seems to be slandering grsec for no reason.

It's not without reason, I don't like people abusing free software in the manner the grsecurity people do it (https://grsecurity.net/agree/agreement.php). They license code under the GPL (because they have to) but then they effectively tell their customers that exercising their right to redistribute code will result in a termination of contract (which is at best against the spirit of the GPL, and at worst illegal).

You obviously have no clue how GPL works. Everything is explained very well on the agreement page.

> You obviously have no clue how GPL works.

I disagree.

> Everything is explained very well on the agreement page.

Yes, it's very clear that they're attempting to subvert the GPL by coercing customers into not exercising their freedom to redistribute (section 3, first sentence). I can't find it now (all I could find is https://news.ycombinator.com/item?id=11808914) but there was a thread about this issue earlier this year.

Essentially, in some people's view grsecurity is acting in bad faith which means that they are violating the GPL (not the license text itself, but the copyright law surrounding license agreements).

Exactly what I said, you don't understand how GPL works and you just slander grsecurity for no reason.

Even you said they're not breaking GPL multiple times. What they're doing is allowed.

Reply on news.ycombinator.com