No One Cares About the Security of Unlocked Android Phones | Hacker News Reader

No One Cares About the Security of Unlocked Android Phones

hackernoon.com

103 pointsbecewumuy40 comments

But who cares about security of your locked Android phone either?

That's sort of what I was wondering. Not the overall issue of security so much as the title's focus on "unlocked" devices.

Sounds like they're talking more about disreputable or negligent OEMs than anything to do with having an unlocked bootloader or unlocked SIM.

Past phones I've owned that weren't as good with security updates depended on me being able to unlock the bootloader so I could keep them as up to date as was feasible. No timely security update from Samsung or HTC? Find a patched version of the ROM image built by some helpful developer on XDA and flash the phone.

Even today, as I only buy Nexus/Pixel/etc Android phones, they're still sold as "unlocked" in terms of SIM because I don't have any desire to give a carrier more influence over my device than I have to. Again, not an issue with security as even my older Nexus devices are getting security patches (if not the big, hardware-dependent OS updates).

The folks developing these security features in Android and the Linux kernel do.

The general consumer really needs to start caring about this kind of stuff and start demanding more secure devices. They should refuse to upgrade their phones to the next model until devices are reasonably secure. Problem is that the average person cares far too much about convenience and having that sleek, next-gen gadget. Which is why this problem persists.

Personally, I purchased a BlackBerry Priv (which runs Android) and couldn't be happier. Phone is/was very cheap compared with the other flagship devices and it runs really fast. Came factory unlocked direct from BlackBerry and has zero bloatware on it. I get frequent O/S updates for security patches as well, which is far more than I can say about my previous phone (Galaxy S3 from AT&T).

Despite most people's apathy, or even hatred, of BlackBerry, they have always done security very well. The Priv is no exception - secure boot, hardware keystore, modified Linux kernel, FDE enabled by default, work/personal account separation, external SD card protection, their DTEK software, etc. Some of their security features are included as part of the base Android OS, yes, but their security model as a whole from start to finish is far ahead of all competitors.

is it also ahead of the Nexus / Pixel (and if so, how ? ) ?

Also, does it get the security patches in a timely manner ? I kinda remember them refusing to commit to that

Which is exactly why we need to fix this problem. Consumer products don't have good security at all and it's making the world a worse place

It's more complicated than that. If Google just produced a standard version of Android with a standard kernel version that all vendors would write for, refreshing and wiping phones would be as easy as Windows/Linux laptops. I wrote a post on this a while back:

http://penguindreams.org/blog/android-fragmentation/

Since then, I've become more and more frustrated with other ARM boards. Android fragmentation is directly related to ARM fragments and it's a huge mess. Things like device trees help, but ARM is missing the standardized architecture that Intel, Power, et. al. have.

> If Google just produced a standard version of Android with a standard kernel version that all vendors would write for

Then you wouldn't get all location data, call logs, and application usage data sent to China, you'd get them sent to the US, via Google, for better user experience and more targeted ads.

The result would be literally the same.

If you are in the US, at least your data isn't being sent to another country. Outside the US, I think your comment stands on its own.

Indeed I am outside the US, and I'm surprised the comment got that many downvotes.

EDIT: At the time, it was at -3

One approach would be to define an ABI-like interface above the kernel layer which all Android userlands would adhere to. It would specify the functions for libraries like libhardware and libstagefright, as well as the GLES or Vulkan extensions needed to be supported. Google would takeover software updates against this certified base, with the OEM providing the base system for their hardware.

are you sure the problem is arm? How can google use a standard kernel version? I mean it is quite standard and only changes between major releases doesn't it? The thing is that linux being monolithic requires all the drivers baked in, which is fine like it is fine the whole flashing ROMs stuff, or maybe it was a few years a go when phones where phones and not pocket pcs so they benefited from the whole packaging. Magenta by google seems to use userspace drivers, so if that is ever gonna get used in phones it might be a solution for a more standard kernel

Linux modules are very kernel specific. If you have modules compiled against the same kernel version, but with slightly differently flags, you won't be able to load it and will get a lot of invalid symbols.

There are thousands of kernel variants between every Linux distro. You always need to recompile drivers. nVidida and AMD/ATI get by this by providing binary blobs and a shim layer than can compile and link the two.

In the Windows/Mac world there is one version of the kernel officially maintained and distributed by their respective companies. They can keep the kernel consistent for a given release. That's what you have one set of drivers for Windows 7, one for 8 and one for 10, instead of a different set of drivers for each and every service pack.

Android could, at a minimum, standardize the kernel for every Android version. With that, binary drivers could work across devices.

Yes, the problem is ARM.

How do you want to boot your kernel? There is no BIOS or UEFI or other standardized firmware, that would initialize at least one CPU, RAM, storage and load your kernel from there. Every ARM implementation boots in different way.

After you boot up, how do you enumerate devices that your kernel can use? There is no PCIE or other plug and play bus, that can enumerate attached devices. Your OS has to know what is available. Poke a wrong port and your board freezes. This is the reason, why Device Tree is a thing.

Linux kernel does not require all drivers baked in - kernel modules existed for decades already. Monolithic does not mean that everything is one big blob. NT is also monolithic, for example.

I don't see what the monolithic kernel has to do with it. Kernel modules are dynamically have been loadable. Yes, they run in kernel mode, and yes their version tightly bound to the running kernel -- but how is that a problem for abstracting of varying hardware?

The strange thing is that I have less people around me with virus problems, stolen card problems, scam problems, etc than 10 years ago. Despite the fact that we deem those devices less secure.

Something is off.

I guess a lot of people have moved to platforms which are essentially virus-proof, like the iPad. I have several members of my family who used windows computers before, now they use iPads exclusively for all their work and pleasure. Previously any of them would open anything that they got in an email, and I guess they still do - it's just that with some devices, it's not an issue. A zipped up virus won't do any harm on an iPad, and probably most Android devices are secure from that too.

So while I think that windows devices are as easy to infiltrate as ever, a lot of people have simply stopped using them, and replaced them with - coincidentally, not intentionally - more secure platforms.

Pretty much this, security isn't improving, its just those infected zip & doc files usually aren't targeted at Android or iOS.

From trivial to apply app and OS updates to code signing and disabled sideloading, the mobile platforms (either one) make it really much harder to fall prey than on desktop OSes, by design. Malware authors have to hit a homerun on 0-days to even begin to get a foothold on the mobile OSes† these days.

† on properly updated devices such as the Apple ones as well as Nexus+Pixel. Probably this is where some form of vertical integration starts to really matter in practice.

Maybe criminals are more subtle now. For example most people who own devices that are part of the Mirai botnet are not aware of it.

I think you're right. Unless you're running crypto malware there's hardly any reason to let your victim know you've infected them. In fact it's best if they never notice anything is amiss.

It's a common pattern with a lot of "awareness" and media problems. There's a big problem with something, people start noticing it and "raising awareness" of it and publishing articles, books, etc on it. Now several things happen at the same time - people who are responsible for the systems that have the problem start addressing it and it gradually starts getting better in response to the publicity and complaints, but at the same time, the community of people finding and drawing attention to the class of problems gets bigger and develops more infrastructure and institutional culture. Groups get created and funded, people start full-time careers with those groups, regular magazines and websites get published and develop their own staffs, etc.

Usually, the underlying issue is complex enough that it takes years or decades to make the problem like 95% better. But the community around the issue has become entrenched, and won't go away just because the problem is basically solved. There's plenty of excuses at hand to justify the continued existence of the group - the problem is never 100% gone, so there's always something new to address, and they can always say that we have to be on guard for the problem coming back. But the effect is the same - the noise gets louder as the signal gets weaker.

If you're paying attention, you can see this pattern play out for all sorts of things.

In this case, we have both made the computers and browsers a lot more secure, and a lot of consumer-level computing activity has, for a bunch of reasons of which security is certainly one, moved to drastically more locked-down devices. Good luck building a botnet of iPads and Android phones. Many of the hacks that get the most publicity are super-complex one-offs that are in theory highly dangerous, but in practice are so valuable that they would only ever be used by state-level actors against handpicked national security targets, because you have to spend millions to find them, and they will become worthless about a week after the appropriate companies become aware of them.

Security on desktop OSes is still much worse, with even sandboxing being fairly rare.

Oh come on. The virus situation on Windows XP was appalling. The system was wide open. It's the primary reason I mainly switched to the Mac in 2006. Sane security was the one truly good thing that's come out of the post-XP era of MS operating systems.

Desktop OSes still run every app as the user, which gives them access to everything useful by default. Mobile OSes differ in this respect since they sandbox by default.

I commented about something similar two days ago, and once again there's no mention in the article or here about the fundamental problem of proprietary software:

https://news.ycombinator.com/item?id=12957927

True security and privacy cannot be had without free/libre software. It's not a solution in its own right, but it's a necessary step to mitigate issues such as these.

A commenter in the linked thread also mentioned other Android OSes working on hardening.

It's worth elaborating on exactly why this is.

When software is Free, the end-user's relationship is inherited from the developer's relationship to the software [0]. As such, the definition of security is a completely shared one.

When software is not Free, the developer's and end-user's perspective are at odds. For starters, they're likely on opposite sides of a financial transaction [1]. The security of non-Free software is thus defined in terms of the developer's interest. Many desires will still align, like securing against most third-party attackers. But some will certainly not, like the business interests of the company and its partners (including the domestic nation-state).

[0] Indeed, a source of much complaint / usability problem.

[1] I'm certainly not rejecting the idea of trading money for software/services, but highlighting a deep-seated principle agent problem. It'd be really nice to find a way to set up a workable economy around Free software, lest we continue to lose to app stores and "open-washed" webcrapps.

Oh, great. My BLU R1 HD from Amazon is sitting next to me as I type this. Anyone know if this is patched in the latest software update, or how I can tell if I'm affected? I don't see anything "AdUps" in the applications or services list.

edit: Per an email from Amazon, http://www.bluproducts.com/security/ has instructions.

The lack of corporate BS on that page really surprised me:

BLU Products has identified and has quickly removed a recent security issue caused by a 3rd party application which had been collecting unauthorized personal data in the form of text messages, call logs, and contacts from customers using a limited number of BLU mobile devices. ... The affected application has since been self-updated and the functionality verified to be no longer collecting or sending this information.

Similarly, their phones are refreshingly free from carrier-lock or (obvious) crapware.

Well their website doesn't even have SSL so that hardly fills me with confidence in their security.

As always the SoC manufacturers are to blame. Google could probably fix these problems by writing yet another layer of software to abstract the hardware even further but the simple solution would be to fix these problems at the root.

> at the root

While in theory everything could be made to work fine and the right people would be held accountable and dropped from any use, probably this is where some form of vertical integration starts to really matter in practice.

Why would Mediatek go through the trouble of changing the socket instead of removing the backdoor?

They want this data, and they know Google will let them get away with it. Just like how they segment SOCs based on what version of Android they support for each SOC, so if you want Android 6 or kernel 3.10, your paying for a higher end chipset.

Central.gov and the ministry of information probably asked them kindly.

"Google eventually accepted a CTS patch to check for the ADUPS system socket. That should have solved the problem, but then Mediatek just changed the name of the socket to purposely evade Google’s CTS check."

That just left me gaping at the sheer brass required to do this, but I understand how it could happen. I'm sure there are some people who want to fix the problem, and others who say "Why bother? We may lose a few technically savvy (aka pain in the neck) end users, but the great unwashed are never going to know or care about whether this was fixed. Our customers know that their customers are the great unwashed, so they aren't going to care either as long as we're cheaper for them."

Or TL;DR, "Screw 'em, what are they going to do, organize a boycott by people who think chips are something you eat?"

Maybe we should build a new bootloader that can be locked down once installed, but with our own keys in the device.

I'm flagging this article because it is making a blaming statement nobody cares about the security of my unlocked phone, which is provably false. Let's start eliminating dissonance from HN by taking the time to think about the content we are consuming and how it affects us!

If you're across the threshold for flagging, you can flag any story on the site in the sense that a link will appear and change to "unflag" when you click it.

If you expect your flag privileges to mean anything more than that, you should probably avoid using "flag" as a downvote, because your flag privileges can be quietly stripped from your account --- in fact, there's any number of heuristics that can do it by cron job, without the moderators even knowing who you are.

The "flag" feature is there to mark stories as off-topic and wholly inappropriate for HN. Nobody on HN thinks this is off-topic for the site.

Just some advice!

Reply on news.ycombinator.com