Impact of the two recent security vulnerabilities on YunoHost

English version - French below / Version en anglais, version française ci-après

Update: talked about ARMbian kernel version number

tl;dr:

  • for the xz security issue YunoHost (based on debian bulleyes) is not impacted

  • for the privilege escalation is has been fixed on debian bulleyes on which YunoHost is based since quite some time: make sure you are up to date and that the correct version of the linux kernel is running using uname -a (you need the version 5.10.209-2 or a superior version, if you are using armbian please look here for the version number)

Please not that, at least regarding the XZ backdoor, information about this subject are evolving rapidly and that this post can be modified in that regard

Hello everyone,

Some of you might have noticed the recent news about 2 majors vulnerabilities in the Linux world and might be afraid that you are impacted.

The 2 vulnerabilities are:

  • a privilege escalation via the linux kernel (meaning: someone that has a user account on a linux can get root access while not having the permissions to do so), it’s called CVE-2024-1086

  • a backdoor in the XZ library that seems to be doing sketchy things with SSH (the backdoor hasn’t been analyzed completely yet so we don’t know exactly that it is doing), it’s called CVE-2024-3094

So, are you vulnerable if you are using YunoHost?

For the XZ library backdoor: no, it’s only for bleeding edge distribution that has already taken the latest version of the XZ library from github, debian bulleyes, on which YunoHost is based, is not impacted (see below)

For the privilege escalation, you need: the updated debian packages which fix this issue and that are already available (since the end of January), so if you are up to date AND that your system has rebooted and thus have the good version of the kernel (or a superior one), you are safe. Please note that to be able to exploit this vulnerability, an attacker needs to have a linux account on your system with malicious intentions.

To check that you are running the correct version of the kernel on YunoHost please check the Diagnosis results, or run the command uname -a. You should get 5.10.209-2 (2024-01-31) or a newer version, if you are using armbian please look here for the version number. If not, please check that your packages are updated using the YunoHost web interface of the CLI.

If you aren’t sure on how to do that, please use those shell commands:

apt update

apt full-upgrade -y

systemctl reboot # /!\ this will REBOOT your YunoHost /!\

Then check again with uname -a and it should contain 5.10.209-2 (2024-01-31) or a newer version (if you are using armbian please look here for the version number.)

Useful links about the XZ backdoor:

Useful links about the privilege escalation:


Impact des deux récentes failles de sécurité sur YunoHost

tl;dr :

  • pour le problème de sécurité xz, YunoHost (basé sur Debian Bulleyes) n’est pas impacté

  • pour l’escalade de privilèges, elle a été corrigée sur Debian Bulleyes (sur laquelle YunoHost est basé) depuis un certain temps : assurez-vous que vous êtes à jour et que la bonne version du noyau Linux tourne en vérifiant votre iagnostic ou en utilisant uname -a (vous avez besoin de la version 5.10.209-2 ou d’une version supérieure, si vous utilisez ARMbian, regardez ici pour le numéro de version)

Tenez compte du fait que les informations concernant ces événements, au moins à propos de XZ, évoluent rapidement et il se peut que ce poste soit édité en conséquent.

Bonjour à toustes,

Des personnes parmi vous ont peut-être remarqué les récentes nouvelles concernant 2 vulnérabilités majeures dans le monde Linux et ont peut-être peur d’être impactées.

Les 2 vulnérabilités sont :

  • une escalade de privilèges via le noyau linux (ce qui signifie qu’une personne qui a un compte utilisateur sur un linux peut devenir root alors qu’il n’a pas les permissions pour le faire). Il s’agit de la vulnérabilité CVE-2024-1086

  • une porte dérobée dans la bibliothèque XZ qui semble faire des croquis avec SSH (la porte dérobée n’a pas encore été complètement analysée et nous ne savons donc pas exactement ce qu’elle fait). Il s’agit de la vulnérabilité CVE-2024-3094.

Alors, êtes-vous vulnérable si vous utilisez YunoHost ?

Pour la porte dérobée de la bibliothèque XZ : non, c’est seulement pour les distributions très récentes qui ont déjà adopté la dernière version de la bibliothèque XZ sur Github. Debian Bulleyes, sur lequel YunoHost est basé, n’est pas impacté (voir ci-dessous).

En ce qui concerne la vulnérabilité liée à l’escalade de privilèges, vous avez besoin des paquets Debian mis à jour qui corrigent ce problème et qui sont déjà disponibles (depuis fin janvier). Donc si vous êtes à jour ET que votre système a redémarré et a donc la bonne version du noyau (ou une version supérieure), vous êtes en sécurité. Veuillez noter que pour pouvoir exploiter cette vulnérabilité, un attaquant doit disposer d’un compte Linux sur votre système - et qu’il doit avoir des intentions malveillantes.

Pour vérifier que vous utilisez la bonne version du noyau sur YunoHost, ouvrez le Diagnostic ou exécutez la commande uname -a et vous devriez obtenir une réponse contenant 5.10.209-2 (2024-01-31) ou une version plus récente, si vous utilisez ARMbian, regardez ici pour le numéro de version. Si ce n’est pas le cas, vérifiez que vos paquets ont été mis à jour en utilisant l’interface web de YunoHost ou le CLI.

Si vous n’êtes pas sûr de savoir comment faire, utilisez ces commandes shell :

apt update

apt full-upgrade -y

systemctl reboot # /!\ cela va redémarrer votre YunoHost /!\

Ensuite, vérifiez à nouveau avec uname -a et il devrait contenir 5.10.209-2 (2024-01-31) ou une version plus récente (si vous utilisez ARMbian, regardez ici pour le numéro de version).

Liens utiles au sujet de la porte dérobée XZ :

Liens utiles sur l’escalade des privilèges :

15 Likes

With the command
uname -v
I get this response:

#1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023

which is not really clear.

But if I use the command
uname -a
I get this:

Linux cybervalley.org 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

more clear?

P.S.: thanks for the report!

Are you sure it’s a YunoHost server? :sweat_smile:

1 Like

I have the same behavior, probably related to armbian.

Quite sure or, at least, I hope so :sweat_smile:

Thanks for your feedback @lnoferin and @gwenlg, I have updated the announcement accordingly.

Okay so for ARMbian to know the version number you want to have for the running kernel on, it’s … quite a mess:

  • first you need to pick the version of armbian you are using
  • then look at this table Armbian - Wikipedia to see if you are based on bulleyes OR bookworm (please don’t yunohost on bookworm) (please don’t use YunoHost on Ubuntu T_T)
  • then look at this page CVE-2024-1086 to find the matching package number and ensure that this is the one you are running

(why does armbian always makes things more complicated -_-)

1 Like

Hi,

Thanks for this very useful and detailed post.

However, I do have a doubt in my case:

  • Running uname -a i get :
    Linux Yunohost 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64 GNU/Linuxso my server is supposed to be ok.

  • But in the diagnosis (webadmin) i get :
    image

I suppose it is ok to believe uname, so it is just the diagnosis which doesn’t display the right info? (sorry, not very used to read / understand this kind of informations).

it’s because the diagnosis page uses uname -r, --kernel-release while uname -v, --kernel-version and uname -a, --all shows the kernel version

i don’t know why or for what it’s different, i’m sure the technical reasons are fine but i don’t know

so, yeah, you should trust the kernel-version and not the kernel-release number:

$ uname -a
Linux yuno.example.com 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64 GNU/Linux
$ uname -v
#1 SMP Debian 5.10.209-2 (2024-01-31)
$ uname -r
5.10.0-28-amd64
2 Likes

Thanks a lot for your answer!

I am confused. When I log on my machine it displays Armbian 23.8.1 Bullseye, which in not in the Wikipedia page.

Also having Armbian 23.8.1 Bullseye, I updated the server and rebooted but still seem to have a vulnerable version if I follow the bookworm version number. The version number is 6.1… so it doesn’t align that much with the bullseye section. And the date displayed is in 2023.
Have someone figured out how it works on armbian?
Other non-armbian servers updated to an appropriate version without issue.

Following these instructions (including apt update, apt full-upgrade and rebooting) I get:
Linux SUB.MYDOMAIN.TLD 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux

Not sure why the update didn’t pick up any kernel updates since last year?!