![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59So blah blah Superfish blah blah trivial MITM everything's broken.
Lenovo deserve criticism. The level of incompetence involved here is so staggering that it wouldn't be a gross injustice for the company to go under as a result[1]. But let's not pretend that this is some sort of isolated incident. As an industry, we don't care about user security. We will gladly ship products with known security failings and no plans to update them. We will produce devices that are locked down such that it's impossible for anybody else to fix our failures. We will hide behind vague denials, we will obfuscate the impact of flaws and we will deflect criticisms with announcements of new and shinier products that will make everything better.
It'd be wonderful to say that this is limited to the proprietary software industry. I would love to be able to argue that we respect users more in the free software world. But there are too many cases that demonstrate otherwise, even where we should have the opportunity to prove the benefits of open development. An obvious example is the smartphone market. Hardware vendors will frequently fail to provide timely security updates, and will cease to update devices entirely after a very short period of time. Fortunately there's a huge community of people willing to produce updated firmware. Phone manufacturer is never going to fix the latest OpenSSL flaw? As long as your phone can be unlocked, there's a reasonable chance that there's an updated version on the internet.
But this is let down by a kind of callous disregard for any deeper level of security. Almost every single third-party Android image is either unsigned or signed with the "test keys", a set of keys distributed with the Android source code. These keys are publicly available, and as such anybody can sign anything with them. If you configure your phone to allow you to install these images, anybody with physical access to your phone can replace your operating system. You've gained some level of security at the application level by giving up any real ability to trust your operating system.
This is symptomatic of our entire ecosystem. We're happy to tell people to disable security features in order to install third-party software. We're happy to tell people to download and build source code without providing any meaningful way to verify that it hasn't been tampered with. Install methods for popular utilities often still start "curl | sudo bash". This isn't good enough.
We can laugh at proprietary vendors engaging in dreadful security practices. We can feel smug about giving users the tools to choose their own level of security. But until we're actually making it straightforward for users to choose freedom without giving up security, we're not providing something meaningfully better - we're just providing the same shit sandwich on different bread.
[1] I don't see any way that they will, but it wouldn't upset me
Lenovo deserve criticism. The level of incompetence involved here is so staggering that it wouldn't be a gross injustice for the company to go under as a result[1]. But let's not pretend that this is some sort of isolated incident. As an industry, we don't care about user security. We will gladly ship products with known security failings and no plans to update them. We will produce devices that are locked down such that it's impossible for anybody else to fix our failures. We will hide behind vague denials, we will obfuscate the impact of flaws and we will deflect criticisms with announcements of new and shinier products that will make everything better.
It'd be wonderful to say that this is limited to the proprietary software industry. I would love to be able to argue that we respect users more in the free software world. But there are too many cases that demonstrate otherwise, even where we should have the opportunity to prove the benefits of open development. An obvious example is the smartphone market. Hardware vendors will frequently fail to provide timely security updates, and will cease to update devices entirely after a very short period of time. Fortunately there's a huge community of people willing to produce updated firmware. Phone manufacturer is never going to fix the latest OpenSSL flaw? As long as your phone can be unlocked, there's a reasonable chance that there's an updated version on the internet.
But this is let down by a kind of callous disregard for any deeper level of security. Almost every single third-party Android image is either unsigned or signed with the "test keys", a set of keys distributed with the Android source code. These keys are publicly available, and as such anybody can sign anything with them. If you configure your phone to allow you to install these images, anybody with physical access to your phone can replace your operating system. You've gained some level of security at the application level by giving up any real ability to trust your operating system.
This is symptomatic of our entire ecosystem. We're happy to tell people to disable security features in order to install third-party software. We're happy to tell people to download and build source code without providing any meaningful way to verify that it hasn't been tampered with. Install methods for popular utilities often still start "curl | sudo bash". This isn't good enough.
We can laugh at proprietary vendors engaging in dreadful security practices. We can feel smug about giving users the tools to choose their own level of security. But until we're actually making it straightforward for users to choose freedom without giving up security, we're not providing something meaningfully better - we're just providing the same shit sandwich on different bread.
[1] I don't see any way that they will, but it wouldn't upset me
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2015-02-19 08:50 pm (UTC)Lack of ROM signing and pre-installed malware
Date: 2015-02-19 09:36 pm (UTC)"Anyone with physical access can...". Yes, that sounds like horrible security hole. You know, anyone with physical access can do anything to your hardware...
Re: Lack of ROM signing and pre-installed malware
Date: 2015-02-19 10:04 pm (UTC)Re: Lack of ROM signing and pre-installed malware
Date: 2015-02-19 11:39 pm (UTC)I see a big problem of programming environments that do stuff insecurely, in general. E.g., Perl, Python, Ruby, Haskell, etc. each have a language-specific packaging system. Will the Debian-packaged CPAN package manager check signatures when I tell it to install something? (Apparently "apt-get source" didn't until very recently; even "apt-get install" just requires you to type "y" to install if a signature check fails.) And some IDEs have an assumption that nothing "bad" can connect to 127.0.0.1; it kind of defeats the purpose of ssh privsep if the restricted user can open 127.0.0.1:30000 and send arbitrary Lisp commands to be executed as another user (if you're lucky it will wait for a password, and the parser won't be exploitable, and the IDE will have some way to verify it's talking to the real server before dumping the password).
Re: Lack of ROM signing and pre-installed malware
Date: 2015-02-20 12:02 am (UTC)> But if the maintainer is the type of person that might have ever piped stuff from curl to bash...
...and that why distributions like Debian have strict security policies, collaborative packages development/review and best practices.
Re: Lack of ROM signing and pre-installed malware
Date: 2015-02-20 12:04 am (UTC)no subject
Date: 2015-02-20 10:52 am (UTC)I'll be over there, in the corner, crying.
Re: Lack of ROM signing and pre-installed malware
Date: 2015-02-20 08:17 pm (UTC)What do distros do for review anyway? If I wanted to review some free software, where would I start? How do I find something that people consider important, and how to avoid duplicating work? It seems like we need some kind of public review server, maybe just a wiki or mailing list, to coordinate this type of thing, but I'm not aware of anything.
no subject
Date: 2015-02-20 08:22 pm (UTC)That's bad, but it brings up the point that the network should generally be treated as insecure. Way too much stuff is wide open once you're behind the (rarely maintained) firewall. Is there an easy way to send confidential documents to a network-attached printer, for example? It would be easy enough to have the device print its public key fingerprint given a special menu selection, then verify the fingerprint when you first connect your laptop to it... but I don't think CUPS can do that. I don't think there's even a standard for it.
no subject
Date: 2015-02-22 03:42 am (UTC)Re: Lack of ROM signing and pre-installed malware
Date: 2015-02-22 06:56 am (UTC)We know you love secure boot, but why even bring up secure boot, while it adds even a bit of an obstacle to running an open operating system? *most* people have secure boot enabled, and *most* of them are securely booting terrible software, even terribly insecure and malicious software, as recent events show. Why bother with the complexity?
Re: Lack of ROM signing and pre-installed malware
Date: 2015-02-22 07:01 am (UTC)Re: Lack of ROM signing and pre-installed malware
Date: 2015-02-22 07:36 am (UTC)Software complexity is the big problem which very few people care about. It undermines security, performance, everything.
Re: Lack of ROM signing and pre-installed malware
Date: 2015-02-24 12:47 am (UTC)You don't need to be corporate.
There is progress...
Date: 2015-03-05 06:36 pm (UTC)Overly optimistic: it makes it sound like if only all IT/developers/users *just cared a little more*, we would be fine. We would not. Our flagship kernel is huge, written in C, and moves far too fast to be carefully analyzed. *Linux will always have severe security bugs*, because *finding the security bugs in large C programs like Linux is far beyond the state of the art*. Add in codebases like Bash, SSL etc, and you can clearly see that we are all screwed *even if Google/MS each donated 10% of profits to securing the current open source ecosystem*.
Overly pessimistic: se4L is a microkernel *proved* to be correct and safe (with well documented caveats). Debian has reproducible builds for 80% of packages. NixOS allows system configuration state to be declaratively managed. So *the state of the art is moving* in the right direction. One day, we will have the basic "materials" from which to make systems about which we can *reason*, and in particular about security.
And then we'll still have to care.
Reverse-engineering required, if you want to continue receiving updates for your mobile toy
Date: 2015-03-12 09:49 am (UTC)Vendors of mobile devices often are reluctant to provide updates and quite soon they don't provide any at all, because you are supposed to buy a new device, or do some reverse-engineering, in order to replace the original OS.
Intel/Microsoft do it the other way around, they try to keep their old Wintel-alliace up, making reverse-engineering of recent Intel-hardware so expensive, that it becomes unattractive for everything else than Windows, which should be th OS of choice for most customers, because, well it kind of always has been and they have been making good money from that.
Re: Lack of ROM signing and pre-installed malware
Date: 2015-03-22 11:00 pm (UTC)On other hand...
Date: 2015-12-13 11:00 pm (UTC)So it is a question if we should consider it bug or feature. This way at least some of us can trash backdoored/misbehaving vendor shit and use device in relatively secure and friendly ways. In your scenario we'll be left with locked down devices where we can't have any security at all, except security of vendor to pwn users. That's how it works. Power corrupts...