Linux Phones [are less secure than mainstream Android]
madaidans-insecurities.github.io
madaidans-insecurities.github.io
I think it's quite simple,
* if you are a more casual user with strong security and privacy needs, then the Linux phone distros are not there yet. Use something else.
* if you are a Linux enthusiast/developer/hacker who is interested in getting away from Google and Apple eco systems, consider getting involved in one of these Linux phone projects and helping out there.
This should not be seen as competition, it's all free and open source software. Android hardening projects focus on delivering a reasonable solution today while Linux phone projects focus on getting something truly independent in the long run.
> the Linux phone distros are not there yet
Is there any indication that Linux is going to catch up to Android/iOS in terms of security?
From my perspective, not only has Linux userspace security barely improved at all over the past few decades (almost all programs run as the user with all of their privileges, no sandboxing, barely any permission/access control to speak of (and yes, I know that there are some projects that aim to fix this, but they're all woefully immature and barely adopted)), but the Unix philosophy itself seems opposed to these security measures. Am I just being overly pessimistic?
Could using something like Fedora Silverblue or OpenSUSE MicroOS (immutable OSes) plus Flatpak (containerized apps) plus SELinux (access controls) get you almost there?
These already exist, but I've seen the push back to the concepts in real life among admins around me, so I wouldn't expect the mass adoption it'd need to stabilize anytime soon. I'm not even including the Internet rage and arguments about these technologies.
Citation needed. Android does plenty of homecalling and also a lot of phones came preloaded with bloatware with tracking functions.
You have to provide some justification to claim that a Linux phone protects users privacy less than Android.
In comparison on Android or iOS Autors directly upload unauditable binary blobs to an app store that then pushes app updates without almost any user control, often fully automatically. Sandboxing makes more sense in this context as a result.
There area already many closed source apps such as Spotify client or Slack. Nothing is stopping those apps to read your browser cookies if they want, in case they are installed as regular apps and not sandboxed.
No, sandboxing exists in Linux and tools like firejail are built-in in Debian/Mobian.
> How are app specific permissions handled?
With fine grained security profiles.
Besides, this is all largely irrelevant when the average android TORCH app is a blob of closed source code that can do telemetries.
Contrasted to FOSS applications developed in the open, reviewed by package managers and users, built reproducibly.
> How full e2ee or secure boot is implemented?
It's there and it works. And secure boot is really unimportant for the attack vectors of most phones.
> By default, you have to add alot in top of Linux kernel.
Not at all, it's all supported by seccomp, cgroups and co.
Large firms offer platforms that are secure against anyone other than themselves (and their partners, such as states).
Google tracks and collects huge data through various channels, and Apple scans your information in your own device (and its operating system is even closed source and cannot be verified). Their platforms might be incrementally more secure against advanced expensive attacks, e.g., targeted attacks performed by a company such as NSO.
If you are an average user, do you worry more about maximizing the security or major privacy concerns, namely: automatic mass data collection, tracking and profiling by governments and those in power, or fancy attacks targeted to you?
Open source may be better in certain ways, but a statement that closed source cannot be verified as to what it’s doing is narrow and incomplete. Android’s key parts are also closed source (there’s a lot more in “Android” than AOSP).
- The article confuses FireWire and USB in the last paragraph. USB, to my knowledge, doesn't do DMA, while FireWire does. (USB-C can if it has thunderbolt, but Linux phones don't have thunderbolt). The article then references this link for why USB is bad: https://madaidans-insecurities.github.io/linux.html (here's an archived link: https://web.archive.org/web/20210903200926/https://madaidans... )
But a crtl+f "USB" comes out empty.
- While the accelerometer hack is theoretically possible, it's practically infeasible, EVEN if the accelerometer takes measurements above 4 KHz (being extremely generous here, you probably really want close to 8-10 KHz). But you need that high of a sampling rate to overcome Nyquist. Accelerometer are much closer to 100-500 Hz, so Nyquist will tell you that theorically, you can only recover audio data below 250 Hz.
I'm all for discussing security tradeoffs with Linux Phones vs Android vs iOS, but seeing those two issues alone makes me question the other claims that I don't have knowledge about.
Edit: For a paper on using an accelerator as a microphone:
https://crypto.stanford.edu/gyrophone/files/gyromic.pdf
So on this paper looking at it, the experiment is done where the speakers are at 75 dB and the phone is one foot away (See Section 3.4). 75 dB looks to be about as loud as a vacuum cleaner. The phone is also completely still, so there is no other data that is being recorded besides (very loud) audio.
I believe he's not; the paragraph about USB and the one about FireWire are separate ones. And his point that kernel isolation of the modem is flawed because of properties of the Linux kernel seem accurate, though I don't have the expertise to confirm that (you'd need to ctrl+f "kernel", not "USB", since the point is a general one)
Same with referring to the other article, there's a general link to another article, where the reader is left guessing where they are making the point. To me, if you reference an article in this manner:
"Linux kernel USB stack which is not a strong barrier as shown in the Linux article"
I would expect the linked article to reference....well the USB stack, or USB in general. Or reference what section you mean, or quote it and bring it in to the article.
Here's how 8 bps mono speech at 4kHz sounds like: https://vocaroo.com/102J6NRULedu (download link: http://fpaste.dy.fi/oyU/dl)
Sounds pretty good. At 2kHz it gets a bit hard to listen to but I can still understand a fair proportion of it. I imagine it shouldn't be too hard to come up with an algorithm (or neural net) to resynthesize the higher frequencies and make it easier to understand.
2kHz sample: https://vocaroo.com/18F3LkYrsPNQ (download: http://fpaste.dy.fi/rvy/dl)
(Obviously these are not accelerometer recordings, just normal microphone recordings downsampled with sox)
I agree it's a bit silly complaint though. I see it a lot in security circles: if some feature doesn't give you perfect protection against all possible attacks, it's a problem. At the same time, the same people advocate mitigations and techniques that only apply to certain attacks. It's as if there's no silver bullet, but it's a damn shame if you deploy something that isn't a silver bullet!
So on this paper looking at it, the experiment is done where the speakers are at 75 dB and the phone is one foot away (See Section 3.4). 75 dB looks to be about as loud as a vacuum cleaner. The phone is also completely still, so there is no other data that is being recorded besides (very loud) audio.
Good to know about the various phones though. I'm honestly not sure why such a high sample rate is even needed/wanted (though in the paper, it is mentioned that there are ones with much lower sampling rates, so if this is a real concern, populate you device with a chip with a lower sampling rate).
Gyroscopes apparently are now rated at degrees per second, so, 4000 degrees/s for example.
The higher those numbers, the more time the ADC has to sample, be that on the sensor itself (digital output, say SPI, 1-wire, or serial) or an intermediary (arduino, ADC board with digital output) if the sensor is analog. The sensors in even mid-range cellphones is probably enough to determine what road you're driving on and how fast, judging by viewing the graph output form something like Torque Lite or some other sensor display app.
I had some $12 9 degree of freedom sensor, gyroscope, accelerometer, compass (or something), and when displaying the combined gyro and accelerometer as a line on a graph you could watch me leave the room (footsteps, doors) walk all the way across the house, and turn off a loud radio. The sensor was on a desk.
[0] https://www.adafruit.com/category/682
P.S. the Bosch sensors are crazy. expensive, but if you can find a SoC board with a bosch (BNO is the part prefix) sensor for like $50, get it. Atomic Pi is one board that has a Bosch on, and it's barely over $35 itself!
In practice, these phones are more secure because nobody will bother to target this vanishingly small installed base - except for a highly targeted attack, in which case Android probably isn't going to protect you any better either.
When it talks about security models and "modern security features", it assumes that the running software utilities aren't trusted.
One interesting point is the firmware being difficult to update. I guess that that could hypothetically become an issue if the firmware were open-sourced or reversed, but still it seems like a reasonable decision once you realize that firmware updates can introduce new bugs/vulnerabilities.
As opposed to having only old bugs and vulns…
Author rails against separating the modem, claiming iommu is sufficient (yeah, google qualcomm iommu cve, you'll find plenty of fun to be had). Then goes on claiming that chips connected by usb 2.0 (a protocol explicitly used because it doesn't have rdma) might be vulnerable to some rdma attack.... because firewire exists?
They rail against being unable to swap out "the firmware", while failing to mention that "the firmware" in question is nothing more than the ddr4 memory training blob.
I also slightly editorialized the title, since it is extremely non-descriptive of article contents.
What % of Android devices have their bootloader unlocked or root enabled? Or have the ability to enable signature spoofing for MicroG? I doubt that malware targeting such weaknesses would be economically profitable to develop, considering also that the typical hardcore user is less likely to just install random Play Store or unverified APKs .
This seems a list of security weaknesses against _targeted_ attacks - the inclusion of "evil maid" attacks is exemplary. If somebody gains physical access to my phone, by far the greatest risk to me is that they will steal it and immediately wipe it, not that they will install bootloader malware and put it back.
So yeah, if you're e.g. a professional user and might be the target of industrial espionage, follow the author's advice to the T (going with GrapheneOS or not depends on whether your company trusts Google with your business data). Graphene > Google > Lineage > Linux. If you just don't want to have your personal data tracked by Google and want better control over the apps you install, Graphene > Lineage > Linux > Google.
Which is the most common security risk for common people let's be realistic. Yeah they are we could say ""protected"" by the trusted boot but in reality the google & manufacturer blobs sending their data somewhere are their main security threat, much more than any other kind of attacks.
If any significant number of people had switched, we’d have seen announcements by Purism and Pine.
Pure OS, and the Librem phone get a lot of coverage but they aren't the totality of Linux phones.
As I understand it Ubuntu Touch, which is the most mature Linux phone OS, does have app sandboxing.
This blog post might be a little out of date but is hopefully useful; https://ubports.com/blog/ubports-news-1/post/ubuntu-touch-sa...
https://sailfishos.org/wiki/Security
https://forum.sailfishos.org/t/privacy-and-security-of-sailf...
But personally I don't think sandboxing is the the one and only ideal solution - already I can introspect the environment on my Sailfish OS device much better than an Android device with hundreds of opaque proprietary services running in background doing something.
Also basically all the third part native apps are open source & developed by long term trusted community members.
So I personally trust Sailfish OS devices much more to be secure and private just as a result of these things.
How is this "BS"? If you can replace the software to whatever you like, so can the baddies. Readers of a "hacker site" (you do realize the "hacker" in hn refers to hackathons rather than bad guys breaking into servers?) might accept this trade-off, but it still means it's less secure
And how are we confident that the ROM preinstalled is itself secure? Nobody can assert that and the owner is even prevented to check it.
The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs, all behind the so-called trusted boot.
And what about your linux phone's rom? Do they have reproducible builds yet? Sure, it might be open source, but did anyone audit the millions of line of code to make sure it's actually backdoor/bug free? Moreover, HN readers might actually understand this stuff, but what about non-technical people? They're probably better off using a locked down phone with OEM ROM (you already have to trust the OEM) than with a locked down phone that can possibly be replaced with malicious firmware.
>The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs
source?
Here's a reminder that there's not a single android phone on the planet which runs AOSP.
> They're probably better off using a locked down phone with OEM ROM (you already have to trust the OEM) than with a locked down phone that can possibly be replaced with malicious firmware.
I don't think so, unless OEM are going to increase their standards, a thirdparty ROM will always be better since they can be reviewed and have at least a list of what's in there. That's a very low bar indeed but preinstalled ROMs have such low standards, that makes it better.
> source?
Which source? They aren't publishing any. Those services blobs have full permission to do whatever they want. They update in the background, can escape the sandbox, send device data home...
What can you meaningfully do with this information?
>Here's a reminder that there's not a single android phone on the planet which runs AOSP.
Again, for the people who don't care about running a full FOSS stack, why does it matter?
>a thirdparty ROM will always be better since they can be reviewed
You mean how on lineageos, most devices have a grand total of two maintainers?
>That's a very low bar indeed but preinstalled ROMs have such low standards, that makes it better.
motorola and google puts out mostly vanilla android on their phones.
>>>The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs
>> source?
>Which source?
You're being obtuse here. "source?" in this context obviously refers to me asking you for evidence for your claim you made.
Check the security of my device and my data? It would help build a trust with my device. Until that happens, phones are at best toys and not real computers you can trust.
> Again, for the people who don't care about running a full FOSS stack, why does it matter?
It's not about FOSS but basic freedom & security here.
> You mean how on lineageos, most devices have a grand total of two maintainers?
As opposed to preinstalled roms which have exactly zero external people reviewing them. Yes, the standards are THAT low.
> motorola and google puts out mostly vanilla android on their phones.
No they don't. Some people are trying to replicate the ROMs for other phones (like https://download.pixelexperience.org/ ) but that's some community effort. There's nothing vanilla about motorola or google phones.
> You're being obtuse here. "source?" in this context obviously refers to me asking you for evidence for your claim you made.
Why though? Even Android admits it, just go into Settings > Security and Settings > Account and look the amount of stuff that they say runs in the background. That's only what they want to admit though, who really knows what it's doing.
A phone operating system probably uses hundreds of libraries/codebases. Are you seriously keeping tabs on all of them?
>It's not about FOSS but basic freedom & security here.
Sounds like you're more objecting to the "FOSS" label than the general attitude of "the entire software/hardware stack has to be open source".
>As opposed to preinstalled roms which have exactly zero external people reviewing them. Yes, the standards are THAT low.
exactly zero? https://twitter.com/topjohnwu/status/1234547148785475585?lan...
>No they don't. Some people are trying to replicate the ROMs for other phones (like https://download.pixelexperience.org/ ) but that's some community effort. There's nothing vanilla about motorola or google phones.
1. I said "mostly" vanilla
2. what's your definition of vanilla? If google makes android, then arguably whatever they puts out can be considered vanilla, even if it isn't part of AOSP. Of all the chromium based browsers out there, I'd still consider google chrome "mostly vanilla", even if it does has proprietary bits that aren't part of the chromium project.
>Why though?
Because you're making the claim.
>Even Android admits it, just go into Settings > Security and Settings > Account and look the amount of stuff that they say runs in the background.
"There's a lot of stuff running" =/= "The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs"
No but I have a right to inspect & modify whatever is running on my device and check it's behavior / replace it if I want to.
> Sounds like you're more objecting to the "FOSS" label than the general attitude of "the entire software/hardware stack has to be open source".
I have no problem with apps being closed source providing that they can use open formats. For operating systems / drivers though, it's kind of essential to have access to the source for security reasons & long term support of devices.
Additionally, openness is even more important to me than open-source and I would still be okay with a closed-source system but very open in mentality, Android currently lacks both.
> exactly zero? https://twitter.com/topjohnwu/status/1234547148785475585?lan...
This guy is from Google and reviewing Android software, that's not an external review and that's not even a rom review itself but a security bug...
> 2. what's your definition of vanilla? If google makes android, then arguably whatever they puts out can be considered vanilla, even if it isn't part of AOSP. Of all the chromium based browsers out there, I'd still consider google chrome "mostly vanilla", even if it does has proprietary bits that aren't part of the chromium project.
Vanilla for me is flashing AOSP straight into the device and booting it. This represents zero device on earth right now.
> "There's a lot of stuff running" =/= "The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs"
Just ask your average user if he knows that all his behaviour & data is recorded and sent to Google on a standard ROM by default and see their reaction.
So you're saying that there are hundreds of LineageOS maintainers who overlap each other and test a lot of the same things, but have a relatively few number of things only they're responsible for. Additionally, many of the third-party open source libraries have ecosystems of their own that are looking after their libraries source code. That sounds pretty good to me, especially when you consider the transparency that Linux provides.
Actually, yes.
> Sure, it might be open source, but did anyone audit the millions of line of code to make sure it's actually backdoor/bug free?
Yes, that's what Linux distribution, large companies and independent researchers do. I reviewed an amount of code myself. Also wrote sandboxes.
What are you talking about? A "baddie" can grab my phone, replace my OS, and I won't even notice? How does he know my encryption passphrase to set it back? Or he would insert malicious software into a powered-off encrypted block device?
Is that so hard to believe when you consider that you're unconscious 8 hours a day? Even when you're awake I don't imagine it's too hard to find some time where you're separated from your phone.
>How does he know my encryption passphrase to set it back? Or he would insert malicious software into a powered-off encrypted block device?
He inserts malicious software into the bootloader, which can't be encrypted. See: https://en.wikipedia.org/wiki/Rootkit#Bootkits
Yes. It's virtually impossible with the physical security measures I employ. Also, if someone did that, my phone would either be left off/prompting encryption passphase - which would be incredibly suspicious, or prompting the screen unlock code, which I could safely insert, realize the phone was tampered, re-install my system and use a different screen lock password having given no useful information, even if the attacker was sophisticated enough to emulate my wallpaper.
In the comically-absurd case you still need to protect yourself against that, having a separate device with /boot in a safe location is simple.
Do you live in a bunker or something? I'm interested in knowing what types of security measures you employ that protects your phone when you're unconscious for 8 hours. Moreover, the fact that you can adopt such security measures doesn't mean everyone else can or is willing to, and they'd rather have a technological solution. This is especially true if they're not the type of person to compile and flash their own ROMs.
>Also, if someone did that, my phone would either be left off/prompting encryption passphase - which would be incredibly suspicious,
Phones shut off all the time. It doesn't seem too implausible to fake an excuse, eg.
1. battery ran out
2. the power button was held too long (from being in an awkward position in your pocket?), forcing a reboot
3. flaky software crashing/hanging
> re-install my system
How can you trust the system was actually reinstalled? Do you disassemble your phone and flash the chips with your computer?
>having a separate device with /boot in a safe location is simple.
1. that doesn't actually fix the problem, just moves it around
2. I know of exactly zero phones that can boot off a removable device.
I know several, including Librem 5 and PinePhone.
That said, the author isn't very convincing when he mentions trivial stuff like verified boot. My takeaway is that Linux (or PureOS) has some issues but Android still has more closed source.
Running software from your distro's repos? That's safe, I mean, how could you use a system and not trust the people who make it? The only alternative here is writing your own OS (analyzing everything is much harder than that).
Running something else? Firejail is really simple to use. Sometimes flatpak or docker can get you covered (just don't assume it's safe by default). You can always use SELinux if you have to.
You can't prove linux-libre is less safe than a slightly more recent non-libre, and it'd be surprising if that were the case.
Not having kill switches isn't better than having them.
The rest either have been considered acceptable in the safety-paranoid Linux community for years or are absurd. Claiming something like DMA is possible from the isolated modem is a VERY strong claim presented with zero evidence.
An important distinction to make: open-source software has a high chance of not being malicious. It doesn’t make them safe, especially with the overwhelming majority of them being C all the way down. A single bug (of which they are not absent at all) can introduce security implications depending on their usecase. Eg a firefox bug can easily make your device running untrusted code without any other remaining defense on your device.
So open-source is orthogonal to security.
Putting "ls" in a sandbox would make it much less useful and doesn't provide much benefit. On the other hand, the .NET Core CLI utilities, which collect telemetry on Microsoft's behalf, would benefit from sandboxing.