OSMC Security update for OSMC 2017.05-2 and earlier - OSMC


#1

Platforms affected:

A vulnerability [1] has been discovered in the Linux kernel's approach to memory management which could allow an application to access a region of memory that is not allocated to it. The vulnerability is also referred to as Stack Clash.


This is a companion discussion topic for the original entry at https://osmc.tv/2017/06/osmc-security-update-for-osmc-2017-05-2-and-earlier/

#2

This update caused me some headache. Tho I don’t know if the update is causing this or my osmc installation had some earlier issues which hit the update.

Problem is, that the new kernel 4.9.29-7-osmc fails to install, because the post-install hook /etc/kernel/postinst.d/apt-auto-removal-osmc is exiting with exit code 1.

After looking what’s going on, I found out that it cannot get the list of kernels from apt setting “APT::OSMCKernelPackages”. As far as I can see, this config should be set in /etc/apt/apt.conf.d/01autoremove-osmc. Sadly in my case, this file is missing and I cannot find out how to recreate it. dpkg -S shows that this is not part of any package.

So well… how can I now break this deadlock? How can I recreate a usable 01autoremove-osmc?

EDIT: I got puzzled with 01autoremove-osmc and 01autoremove-kernel-osmc. Corrected.


#3

Thanks for letting me know about his. We’re looking in to this. There only seem to be two reports of this issue, so we will need to work out what’s unique to these setups and causing issues.

You can probably change /etc/kernel/postinst.d/apt-auto-removal-osmc to set +x and debug from there, however I’m not sure how comfortable / willing you are to investigate this issue

Cheers

Sam


#4

I’m happy to help and already did this. That’s how I found out that it cannot get the kernel list. That’s where it stops.

root@osmc:~# /etc/kernel/postinst.d/apt-auto-removal-osmc 4.9.29-7-osmc
+ apt-config shell APT_CONF_D Dir::Etc::parts/d
+ eval APT_CONF_D='/etc/apt/apt.conf.d/'
+ APT_CONF_D=/etc/apt/apt.conf.d/
+ test -n /etc/apt/apt.conf.d/
+ config_file=/etc/apt/apt.conf.d//01autoremove-kernels-osmc
+ apt-config shell DPKG Dir::bin::dpkg/f
+ eval DPKG='/usr/bin/dpkg'
+ DPKG=/usr/bin/dpkg
+ test -n /usr/bin/dpkg
+ installed_version=4.9.29-7-osmc
+ uname -r
+ running_version=4.9.29-6-osmc
+ grep .*-image
+ apt-config dump --no-empty --format %v%n APT::OSMCKernelPackages
+ image_list=

From there I tried
apt-config dump --no-empty --format '%v%n' 'APT::OSMCKernelPackages'
and found it coming back empty

Now apt-auto-removal-osmc has a documentation header where it told me, this setting is maintained in /etc/apt/apt.conf.d/01autoremove-osmc. And that’s where I couldn’t find anything.


#5

This should now be resolved in the following commit:

You might need to wait an hour or so for it to reach your local mirror, but you should then be able to update without any issues. You may want to run:

#!/bin/bash
sudo apt-get update
sudo wget https://raw.githubusercontent.com/osmc/osmc/7d1f77cf0f2cbcf67704a2caa6aaf2a59b9970ab/package/base-files-osmc/files/etc/kernel/postinst.d/apt-auto-removal-osmc -O /etc/kernel/postinst.d/apt-auto-removal-osmc
sudo apt-get dist-upgrade -y
sudo reboot

The list of kernels is device specific, and as such, is provided by the *-device-osmc package. But we don’t PreDepend on a new version, so there’s no guarantee the file would be there at the time of kernel upgrade. I suspect the majority of users have been OK because they’ve updated from a recent version and we didn’t push a new kernel in this update.

However had this been our June update this could have caused a lot of problems for users, so thank you for the report. For now – it’s fine for us to bail gracefully and skip the autoremoval process until we have the file brought in from *-device-osmc

I’d appreciate it if you could run the above commands and report back

Cheers

Sam


#6

Thank you!

In the meanwhile I already finished the install by adding an “exit 0” to the post hook script temporarily. So this did basically the same as your commit, just in a very crude way that I immediately removed afterwards. With that the update ran without further issues. So this way I am sure your change will do the trick, but I cannot test it natively anymore, sorry about this.

Now everything is clean again and up-to date. I have rbp1-device-osmc 1.1.9 but this did seemingly not bring back the missing /etc/apt/apt.conf.d/01autoremove-osmc. I even tried reinstalling rbp1-device-osmc in case it creates the file via postinstall script, but it did not.

So the remaining question is: How is osmc supposed to get this 01autoremove-osmc file in first place?


#7

It will come in the next update, which will update the version of *-device-osmc.
This update was concerning Stack Clash, so we only updated the minimal amount of packages to introduce these changes.

Sam