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