Category: Hardware

Computers, devices, accessories, gadgets, quad copters ..

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
Hardware

Slow HP Elitebook 840 laptop ?

I currently use an employer issued HP Elitebook 840 G4-laptop for development work. It has annoyed me. It has bothered me. It has always been totally under-performing, despite its Intel Core i7 CPU, and even with power connected and all Windows power management settings verified to be sane. I didn’t figure out why until recently ..

As it turns out, the laptop has unfortunate default BIOS-settings coupled with a power supply that is probably too weak. At a glance, all the important settings look ok: CPU turbo boost enabled, multi-core, hyper threading and virtualization enabled, runtime power management enabled. But there is another option that turns out to be extremely important for performance. It’s buried under “Built-in device options”, and it’s called “Boost Converter”. Off by default. There is no explanation in the BIOS itself about what this option does. (Hello, hardware vendors: how difficult can it be to provide a one sentence explanation for ALL the settings ?)

Eventually I found a PDF document online that explains various HP BIOS options. And it describes “Boost Converter” as:

Draws power from the battery to give the CPU a momentary performance gain.

http://h10032.www1.hp.com/ctg/Manual/c03481740

Check ! Enabled. And the laptop suddenly becomes much more powerful when connected to A/C power. Because now, CPU turbo boost actually works. Instead of maxing out at 2,8GHz core speed, it now happily jumps up to 3,8GHz when needed. (There is also a BIOS option to enable turbo boost when only running on battery power, but I left that off.)

I now enjoy more fan noise, in addition to faster software builds, faster Docker containers and a faster IntelliJ. And in case you wondered, the battery still charges, even though it us used for extra power in addition to A/C when needed.

Categories
Hardware Linux

VirtualBox + Secure Boot + Ubuntu = fail

Here are the steps I did to enable VirtualBox to work properly in Ubuntu with UEFI Secure Boot fully enabled*. The problem is the requirement that all kernel modules must be signed by a key trusted by the UEFI system, otherwise loading will fail. Ubuntu does not sign the third party vbox* kernel modules, but rather gives the user the option to disable Secure Boot upon installation of the virtualbox package. I could do that, but then I would see an annoying “Booting in insecure mode” message every time the machine starts, and also the dual boot Windows 10 installation I have would not function.

*Ubuntu 16.04 on a Dell Latitude E7440 with BIOS A18, and with a dual boot Windows 10 installation.

Credit goes to the primary source of information I used to resolve this problem, which applies specifically to Fedora/Redhat:
http://gorka.eguileor.com/vbox-vmware-in-secureboot-linux-2016-update/

And a relevant Ask Ubuntu question:
http://askubuntu.com/questions/760671/could-not-load-vboxdrv-after-upgrade-to-ubuntu-16-04-and-i-want-to-keep-secur

Steps to make it work, specifically for Ubuntu/Debian

  1. Install the virtualbox package. If the installation detects that Secure Boot is enabled, you will be presented with the issue at hand and given the option to disable Secure Boot. Choose “No”.
  2. Create a personal public/private RSA key pair which will be used to sign kernel modules. I chose to use the root account and the directory /root/module-signing/ to store all things related to signing kernel modules. 
    $ sudo -i
# mkdir /root/module-signing
# cd /root/module-signing
# openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=YOUR_NAME/"
[...]
# chmod 600 MOK.priv
  3. Use the MOK (“Machine Owner Key”) utility to import the public key so that it can be trusted by the system. This is a two step process where the key is first imported, and then later must be enrolled when the machine is booted the next time. A simple password is good enough, as it is only for temporary use. 
    # mokutil --import /root/module-signing/MOK.der
input password:
input password again:
  4. Reboot the machine. When the bootloader starts, the MOK manager EFI utility should automatically start. It will ask for parts of the password supplied in step 3. Choose to “Enroll MOK”, then you should see the key imported in step 3. Complete the enrollment steps, then continue with the boot. The Linux kernel will log the keys that are loaded, and you should be able to see your own key with the command: dmesg|grep 'EFI: Loaded cert'
  5. Using a signing utility shippped with the kernel build files, sign all the VirtualBox modules using the private MOK key generated in step 2. I put this in a small script /root/module-signing/sign-vbox-modules, so it can be easily run when new kernels are installed as part of regular updates: 
    #!/bin/bash

for modfile in $(dirname $(modinfo -n vboxdrv))/*.ko; do
  echo "Signing $modfile"
  /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 \
                                /root/module-signing/MOK.priv \
                                /root/module-signing/MOK.der "$modfile"
done

    # chmod 700 /root/module-signing/sign-vbox-modules
  6. Run the script from step 5 as root. You will need to run the signing script every time a new kernel update is installed, since this will cause a rebuild of the third party VirtualBox modules. Use the script only after the new kernel has been booted, since it relies on modinfo -n and uname -r to tell which kernel version to sign for.
  7. Load vboxdrv module and fire up VirtualBox: 
    # modprobe vboxdrv

The procedure can also be used to sign other third party kernel modules, like the nvidia graphics drivers, if so is required. (I have not tested that myself.)