Bonjour,
une faille de sécurité est apparu sous Linux, rien de bien exceptionnel
me direz-vous, si ce n'est qu'il s'agit d'un **sabotage volontaire**
d'un développer, qui a patiemment planifié son coup sur une période de
1.5 à 2 ans.
En fait, il s'agit bien plus d'un backdoor / malware, que d'une
simple faille de sécurité.
Le programme impacté est "xz", un algorithme de compression de
données, et liblzma, sa librairie qui lui est associée.
La faille a été intégré par un développeur qui n'est pas le
développeur originel de xz, et qui a simplement proposé de fournit son
aide au projet, il y a 1.5 ans => Social ingineering
Le but du sabotage n'est pas de pourrir la compression des données
(en fait, les fichiers compressés et décompressés ne sont pas impactés).
Il semblerait que le but soit d'impacter un autre logiciel (SSHd) qui
peut être amené à l'utiliser, si il est lié à liblzma (linkage dynamique).
SSHd n'est ni plus ni moins que LE logiciel de référence qui permet
de se connecter à distance sur une machine.
L'analyse est en cours, mais il semblerait que le but était
d'accéder aux clés privées de SSH, ce qui est excessivement grave.
Plus d'informations et de commentaires ici (Français)
https://linuxfr.org/news/xz-et-liblzma-faille-de-securite-volontairement-introduite-depuis-au-moins-deux-mois
https://linuxfr.org/users/ytterbium/journaux/xz-liblzma-compromis
Et cette page (EN) qui résume tout le process :
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
La subtilité du truc, c'est que le code de la backdoor était placé
dans un innocent fichier de test, appelé "bad-3-corrupt_lzma.xz", qui se
faisait passé pour un fichier dédié au test du code de xz.
La mécanique afin d'injecter le code malicieux est très subtile et
indirecte, et note d'une volonté du développeur de bien planquer sa
backdoor :
- un jour X, il a poussé dans le GIT le fichier de test
"bad-3-corrupt_lzma.xz". En fait, c'est un binaire linux compilé (ELF),
mais dont il a tripatouillé certains caractères et certains blocs de
données, afin que cela n'apparaissent pas comme de l'ELF. Notamment, les
premiers caractères du fichier de test n'ont pas le header d'un ELF,
mais d'un fichier compressé "xz" tout ce qu'il y a de standard. Donc si
l'on tente de le décompresser, cela va planter, comme son nom l'indique
"bad-3-corrupt_lzma.xz".
- le jour Y, il a poussé sur le GIT un 2nd fichier, (build-to-host.m4),
qui est exécuté par la chaîne de compilation, afin de compiler le
programme. Ce fichier *.m4 va avoir plusieurs instructions, dont le le
but final, avec l'aide de scripts bash eux-aussi lancés par la chaîne de
compilation, est de rajouter la backdoor aux programmes compilés. Et
notamment, à la librairie "liblzma*.o", qui peut-être linké à sshd, via
systemd (le mécanisme de boot des Linux, qui remplacé les scripts d'init).
- lorsqu'un utilisateur télécharge les fichiers de GIT, ou via un
.tar.gz , il récupère:
+ le code source "propre"
+ la backdoor qui n'est pas reconnu comme un ELF, mais comme un xz
corrompu. Disons que c'est une backdoor "démilitarisée"
+ toute la chaîne de compilation, qui va permet de "re-militariser" la
backdoor, et l'injecter dans le "liblzma*.o"
+ l'intérêt de faire cette manipulation via la chaîne de compilation,
c'est que c'est une étape obligé afin de re-générer le programme, et que
les utilisateurs vont plus se concentrer sur le code du programme,
plutôt que la chaîne de compilation
Il y a un diagramme qui décrit tout le processus:
https://img.linuxfr.org/img/68747470733a2f2f7062732e7477696d672e636f6d2f6d656469612f474a2d366d443961494141526169593f666f726d61743d6a7067266e616d653d39303078393030/GJ-6mD9aIAARaiY?format=jpg&name=900x900
La faille a été découverte par un utilisateur qui n'a rien à voir
avec le projet, et qui a simplement constaté que sa connexion ssh était
plus lente de 0.5s, suite à une mise à jour de sa machine ... Chapeau à
lui !!!
La faille a impactée Debian Testing pendant 1 mois. Debian a
immédiatement réagit en remettant une ancienne version de xz, qui date
d'avant les modifications du développeur malicieux. La commande
ci-dessous montre que la machine est corrigé:
$ dpkg -l|grep xz
ii xz-utils 5.6.1+really5.4.5-1 amd64 XZ-format compression utilities
Le développeur (incriminé a poussé Ubuntu pour que son code soit
intégré, probablement avant la prochaine LTS, mais heureusement cela n'a
pas été fait.
Fedora, Kali, OpenSUSE, ArchLinux sont aussi sur le coup.
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
