Author: Øyvind Stegard

Categories
Hardware

Sony+Android is a security failure

Sony Xperia XZ1 compact

My last couple of smart phones have been Sony Xperia compacts, the latest being an Xperia Compact XZ1. It is a robust piece of hardware, and it has a perfect size, with its 4.6 inch screen. I dislike big smart phones, and since they are just getting bigger every year, I plan on keeping my current phone for as long as possible. This might prove difficult, due to Sony’s lack of product support. It is already well known that Android is a failure when it comes to phone manufacturers not supporting their products with software updates for a reasonable amount of time, especially within the category of security fixes. This is just another example of the sad state of affairs, I guess.

The phone currently runs Android 9 using the latest Sony firmware version 47.2.A.11.228. Security patch level is dated September of 2019, which means my phone is missing a year’s worth of upstream security fixes to the Android operating system. For example high severity Bluetooth vulnerabilities listed on the February 2020 security bulletin like CVE-2020-0022 (aka “BlueFrag”):

On Android 8.0 to 9.0, a remote attacker within proximity can silently execute arbitrary code with the privileges of the Bluetooth daemon as long as Bluetooth is enabled. No user interaction is required and only the Bluetooth MAC address of the target devices has to be known. For some devices, the Bluetooth MAC address can be deduced from the WiFi MAC address. This vulnerability can lead to theft of personal data and could potentially be used to spread malware (Short-Distance Worm).

https://insinuator.net/2020/02/critical-bluetooth-vulnerability-in-android-cve-2020-0022/

My phone is a critical device in my every day life, and having it hacked like this would certainly lead to a miserable few days. So now I must rigidly remember to keep Bluetooth off, which is inconvenient at best. And I must assume that many of the vulnerabilities listed from October 2019 and going forward, apply to my phone.

Sony customer support

I had picked up information that Sony was cutting support for my phone model early in 2020. Normally I would not bother interacting with large corporation customer support channels, but this time I was annoyed enough to fill out the form. As expected, it was a pain, and the form post failed a couple of times with server side errors. But eventually I got it through and then didn’t hope for anything. After all, attempting to communicate with big corporations is like screaming directly at /dev/null.

My question was regarding the security patch level of my phone and when Sony was planning to fix it, pointing out the Bluetooth vulnerabilities. Very simple. This is the first response I got, translated from Norwegian:

Thank you for contacting Sony Support. It worries us that you are worried about the update. I have confirmed your IMEI number. Your phone is running the latest version of Android. I will forward your question to a specialist to get the best possible information, and for this I need you to answer a couple of questions: 1) which mobile network operator are you using ? 2) regarding your question about security, are you using any Bluetooth accessories ?

Response #1, 22 May 2020, from Sony customer support Norway.

I followed up by providing the information requested. The second response came about a week later:

Thanks for your patience regarding the response time for your question. We understand that you are worried about the mentioned [Bluetooth] vulnerability. Today I have received a reply from a [person] responsible for this at our place, and we have no more information regarding the [firmware] update in your question.

Response #2, 1 June 2020, from Sony customer support Norway.

I am not surprised by this response, nor am I amused. The answer was too vague, so I decided to push them a little harder, by simply asking “does this mean Sony will not fix the mentioned security issues on this phone model ?”. About a week later, the third response came:

Thank you for your email. This is a question related to product development. Unfortunately we cannot answer questions directly related to product development.

Response #3, 30 June 2020, from Sony customer support Norway

At this point, customer support stops providing any references to my actual case and responds with some rubbish about product development information policies. While they could have simply said “no more soup for your phone model” in the very first response, this instead looks more like an attempt to hide behind hazy replies and using stalling tactics.

After some time, I decided to have another go, since I have an allocated case number, and it only requires me to send off an email. This time I state that I am not asking Sony to divulge any internal product development information, along with the following question: “How should I as and end-user deal with this situation, considering the security issues at hand ? Do you recommend continued use of the phone ?”. A day later another response arrives:

We cannot at this time confirm when the next update will happen for this model.

Response #4, 25 August 2020, from Sony customer support Norway

There is really no point in continuing this conversation. I replied with a simple statement of disappointment. Sony later replied with a confirmation on support period, finally:

We would like to inform you that updates on our phones stop after two years, since that is the end of the Sony product warranty period. Of course you still have the customer warranty for this product.

Response #5, 25 August 2020, from Sony customer support Norway

Ok, apparently I have a useless customer warranty on a product with security issues that will never be fixed ? Case closed.

There needs to be a distinction between product warranty period, and product lifetime and security support. A smart phone needs software updates beyond a measly two year period after product launch, just like a regular computer operating system does. Otherwise users are put at risk due to lack of security fixes.

Wasted hardware

I purchased the phone brand new in February 2018. Sony ended its software support for the model with the last update in September 2019. That’s less than two years of support since time of purchase. And my phone is in excellent condition. The built-in battery still has great capacity, the screen is mostly free from scratches, and everything works fine. The hardware is easily capable of running Android 10, and I’m willing to bet also Android 11, to be released later this year.

The hardware has a lifespan that greatly extends beyond the period that Sony is willing to provide security updates for the device. So the end user is forced to either buy a new device prematurely, or risk the consequences of continued use with an increasing number of security vulnerabilities appearing every month. Manufacturers of Android based devices really need to wake up and take responsibility for their products, their customers and the environment. Because that is certainly a guarantee today with Android: you will be left behind if you take good care of your phone and want to keep it for several years.

What are my options ?

In order of likelihood.

  1. Install a custom Android ROM like Lineage OS. But it requires work and time and comes with no guarantees that things will function properly. I am especially concerned about hardware quirks and driver issues. (Still thinking about it, though.)
  2. Continue using the outdated Sony firmware, while limiting risk by keeping Bluetooth off and taking other precations. This is where I am currently at.
  3. Buy a new Android phone. But they are all too big these days, and I am tired of the bad support.
  4. Buy a “dumb” feature-phone and leave oversized smart phones behind. The options are limited. But I suspect I would manage just fine without phone apps in my life.
  5. Buy an iPhone. I’ll give credit to Apple for their device support with software updates over time, and also selling smaller form factors. But I can never be part of Apple’s walled garden, so this is not a realistic option.
Categories
Other

About trust and the Norwegian contact tracking app

The Norwegian government is doing their best to combat the pandemic. Well, mostly. The digital contact tracing initiative, in the form of an app called “Smittestopp”, from the institute of public health is a clear exception. Dear government, a question arises: how do you expect to gain trust when at each important turn your decisions, actions and elusiveness only creates distance, suspicion and speculation ?

You keep the source code closed. And defend this decision with arguments to the likes of security by obscurity, commerical interest, “we are not used to open sourcing” and an unsubstantiated fear of tech leakage to other not so nice governments. Weak at best !

Be open, honest, collaborative and willing to share, gain trust.

You pollute what should be the maximally important purpose: contact tracing. By use of centralized (and foreign) storage of detailed GPS tracking data for research purposes. (Then also failing to describe how exactly the anonymization process will work.)

Keep it to the point, do privacy by design, gain trust.

You release the app with permanent user identifier broadcasting. Leading to real world security issues in production.

Respect privacy, listen to expert advice, gain trust.

The CEO of Simula Aslak Tveito calls for shame in a public letter. On those who elect not to install a voluntary and heavily criticised application.

https://www.simula.no/news/thank-you-simulas-ceo, April 21 2020

Be humble, understanding and generous, gain trust.

I can only hope there will be a new simpler version of the app made solely for the purpose of contact tracing. Open source and with privacy by design.

Categories
Linux

Backups now and in the future

I have never lost a single piece of data valuable to me in 20 plus years of computing. That is a very boring fact. But anyway. Deep in some archives, I even have copies of the very first web pages I made, back in 1996 (ugly and embarrassing, but funny stuff). These days, internet services (or “cloud” if you like) is all the rage for backups. There are the huge players, like Dropbox, Google Drive, OneDrive, iCloud and so forth. They all have client agents able to synchronize local data off to remote cloud storage. For mobile devices, everything’s automated to the point where the user doesn’t have to worry at all. (Except for their own privacy.) There are basically tons of services where you can send off your data and not worry about the details of how it is kept safe. I want more control over how and when my personal data is shipped off, so I only use such services for one thing related to backups: store gigabytes of locally encrypted backup archives that I upload manually about once a month.

If I was to make a list of 10 general requirements to a site backup system, well, this would probably be it:

  1. No human involvement: Backups must be performed automatically and regularly.
  2. Low maintenance: Backup must require little effort to setup on client machines (very little configuration).
  3. Availability: Backups must not interfere with regular usage of client devices.
  4. Storage efficiency: Backup snapshots must be stored incrementally (using some delta-scheme).
  5. Versioning: Older versions of files must be kept, and the most recent backup snapshot should be easily accessible.
  6. Privacy: Backups must always be encrypted at the source end before being sent off to a remote storage location or saved onto external media.
  7. Redundancy: Backup archives should be kept at multiple physical sites, to avoid complete loss of everything in case one site burns down to the ground.
  8. Redundancy: Encrypted backup archives of the latest snapshots should be transferred to an offsite storage location regularly, but not necessarily as often as automated local site backups are performed.
  9. Redundancy: The encrypted backup archives should also be kept at the local site.
  10. Monitoring: an automated backup system must warn promptly if problems arise, but otherwise stay silent and do its job. For details, a log of all operations must be available somewhere locally.

This list is of course not a random selection of 10 good points about data safety best practices. I have had a custom system in place for several years, which satisfies most of these criteria. It automates all steps except for number 8; I manually upload encrypted archives to offsite cloud storage (currently using Google drive). The archives themselves are automatically generated at the end of each month, so all I need to do is open a browser, access a local network share and initiate the upload procedure. This requires very little of my time.

My setup is based around a central backup server model, where the server pulls data from client hosts that are online on the local network. It’s a rather substantial shell script solution with support for configuration as code, pattern based exclusion rules, pluggable hooks and it uses rdiff-backup as the engine internally. Backup snapshots are saved to backup server local storage. The most recent (current) host snapshots are directly available at all times on the backup server (an advantage of rdiff-backup). The backup job runs at regular intervals and retries hosts missed in previous attempts within the course of a day. The snapshots are complete, in that all operating system files are backed up, in addition to personal data. The ssh protocol is used for transport across network.

In general this setup has worked very well over the years. Client setup is very lightweight, only requiring the installation of OpenSSH server, rdiff-backup and ssh key setup for root user. That procedure is automated using Ansible. An obvious weakness is that there is no support for Windows hosts or mobile devices. I don’t regularly use Windows-clients except for work-related things, so it is not a big deal. But a simple solution I’ve used in the past is to simply [shadow] copy from Windows host to a network share on a Linux host that is backed up.

So, in this modern age, is my trusty but crusty backup regime still a good solution ? All in all, yes, since data still boils down to files with valuable bytes in them, and my solution gives me absolute control and privacy. It has some disadvantages, though. Laptop clients will not be backed up when they are not present on my local network, since it is a pull model. So I am considering some options like dejadup, but it needs to support complete system backups. I have not investigated how well that works with dejadup. (rdiff-backup has proven itself to be excellent in this respect and happily creates full file based host system snapshots without issue.)