[Attel Malagate]

Citation :

Publié par Airmed / Ildefonse

Genre l'état chinois fait une backdoor détectable à cause d'un délais de 0.5s ?

Ouais enfin le code malveillant a été totalement découvert par hasard
https://youtu.be/bS9em7Bg0iU?t=150

[Eyce Karmina]

Parce que le texte, c'est la vie, un article sur le sujet chez Ars Technica :
What we know about the xz Utils backdoor that almost infected the world | Ars Technica

[Borh]

Ça me rappelle une interview de Jean-Baptiste Kempf, le lead de VLC qui expliquait qu'il y a très régulièrement des tentatives pour insérer du code malicieux dans VLC. La plupart du temps, c'est fait de façon grossière. Mais parfois se sont des contributeurs anciens, qui participent activement et ont gagné la confiance. Ils attendent des années avant de faire leur tentative d'insérer du code malicieux, et ceux là sont clairement les plus dangereux.
Forcément, le code est moins vérifié quand il vient de contributeurs de confiance.

Ça rend complètement paranoïaque, on ne peut faire confiance à personne.


Pour le contributeur malveillant, il a un nom Chinois, mais je sais pas un agent chinois aurait pas plutôt utilisé un nom d'un autre pays. En tout cas, ça ne veut probablement rien dire.

[Eyce Karmina]

Citation :

Publié par Borh

Ça rend complètement paranoïaque, on ne peut faire confiance à personne.

C'est une menace qui est connue depuis longtemps, mais dont tout le monde ne prenait pas forcément la mesure (certains se focalisent sur les gestionnaires genre npm ou pip, mais tout est concerné).
Là au moins on a un exemple concret qui permettra, peut-être, de faire évoluer les choses.

[Dr. Troy]

Citation :

Publié par Borh

Ça rend complètement paranoïaque, on ne peut faire confiance à personne.


Pour le contributeur malveillant, il a un nom Chinois, mais je sais pas un agent chinois aurait pas plutôt utilisé un nom d'un autre pays. En tout cas, ça ne veut probablement rien dire.

Quand tu vois ce dont sont capables certains particuliers, oui ça fait froid dans le dos quand tu t'imagines ce qui est possible à un niveau étatique (et quand tu vois la raison pour laquelle on écarte une piste US).

Citation :

The backdoor’s careful design could be the work of US hackers, Raiu notes, but he suggests that’s unlikely, since the US wouldn’t typically sabotage open source projects—and if it did, the National Security Agency would probably use a quantum-resistant cryptographic function, which ED448 is not. That leaves non-US groups with a history of supply chain attacks, Raiu suggests, like China’s APT41, North Korea’s Lazarus Group, and Russia’s APT29.

La piste chinoise peut effectivement être un leurre :

Citation :

At a glance, Jia Tan certainly looks East Asian—or is meant to. The time zone of Jia Tan’s commits are UTC+8: That’s China’s time zone, and only an hour off from North Korea’s. However, an analysis by two researchers, Rhea Karty and Simon Henniger, suggests that Jia Tan may have simply changed the time zone of their computer to UTC+8 before every commit. In fact, several commits were made with a computer set to an Eastern European or Middle Eastern time zone instead, perhaps when Jia Tan forgot to make the change.

“Another indication that they are not from China is the fact that they worked on notable Chinese holidays,” say Karty and Henniger, students at Dartmouth College and the Technical University of Munich, respectively. They note that Jia Tan also didn't submit new code on Christmas or New Year's. Boehs, the developer, adds that much of the work starts at 9 am and ends at 5 pm for Eastern European or Middle Eastern time zones. “The time range of commits suggests this was not some project that they did outside of work,” Boehs says.

Source: https://www.wired.com/story/jia-tan-xz-backdoor/

Peut être qu'ils se font passer pour chinois pour ne pas qu'on pense qu'ils soient chinois aussi

Mais la bonne nouvelle, c'est que ça donne une raison plus valable pour cracher sur Arch (et autres rolling distro) que "on est en 2024 c'est le mal de faire tout en manuel".

[Airmed / Ildefonse]

C'est quoi le rapport avec Arch ?

[Dr. Troy]

Citation :

Publié par Airmed / Ildefonse

C'est quoi le rapport avec Arch ?

Rolling release, comme debian testing ou d'autres, du coup tu te tapes la mise à jour vérolée vu que t'as en permanence les dernières versions.
Enfin c'est pas nouveau comme critique du système de rolling release, mais la c'est un bel exemple.

[Airmed / Ildefonse]

A cause des délais entre la stable et la testing, je pense qu'une majorité sont sur du testing ou unstable pour le cas de debian.

[Eyce Karmina]

Plus que les rolling releases, c'est le côté cutting edge qui est en cause ici.
Fedora 41, Debian testing, ne sont pas des RR, mais des versions en test donc ce genre de problème on s'y attend.

[Mamat]

Et être sur une RR ne veut pas dire que tu met à jour à tout va, en tout cas pour ceux qui savent ce qu'implique une RR, je ne parle pas de ceux qui installent une arch pour faire "power user" mais seraient tout aussi bien sur une Ubuntu.

Et même si on parle de RR, il y a quand même un contrôle de la part des mainteneurs avant de rendre les paquets dispo sur les repos.

Donc à moins d'avoir planifié une maj automatique journalière sans garde -fou ou d'être un excité de la maj manuelle, il y a peu de chance que cette faille ait la possibilité de faire des ravages. À condition bien sur qu'elle ait été détecté.

Mais c'est un bon exemple des failles que possède le tout open source, tout communautaire si il n'y a pas un contrôle strict et rigoureux de ce qui est ajouté / modifié dans le code.

C'est assez fréquent par exemple d'avoir des soucis avec des packages sur NPM.

[Dr. Troy]

Citation :

Publié par Eyce Karmina

Plus que les rolling releases, c'est le côté cutting edge qui est en cause ici.
Fedora 41, Debian testing, ne sont pas des RR, mais des versions en test donc ce genre de problème on s'y attend.

Oui pas faux, j'ai fait un amalgame, cela dit on ne s'attend pas à de la stabilité avec une testing mais pas ce genre de problèmes non plus

Citation :

Publié par Mamat

Et être sur une RR ne veut pas dire que tu met à jour à tout va, en tout cas pour ceux qui savent ce qu'implique une RR

À la base c'était pour troller gentiment, mais en réalité, pas sûr que la majorité des utilisateurs d'Arch soient bien conscients de ce que ça implique (on parle d'une bonne partie d'utilisateurs qui s'intéressent à du unixporn ou du jeu vidéo). Je dis pas que c'est systématique, mais le risque est plus élevé.

[Eyce Karmina]

Citation :

Publié par Dr. Troy

Oui pas faux, j'ai fait un amalgame, cela dit on ne s'attend pas à de la stabilité avec une testing mais pas ce genre de problèmes non plus

Je me suis mal exprimé : je voulais parler "avoir une version foireuse d'un composant qui impose un rollback potentiellement douloureux" et pas "une backdoor d'un acteur malveillant qui y a probablement passé plusieurs années"

(et j'ai apprécié ton petit troll que j'esquivait avec ma Fedora 40 de test qui était touchée elle aussi )

[Caniveau Royal]

Sur Debian 12, Gnome, Je tapais à fond les manettes un texte sur Firefox, et j'ai utilisé une séquence de touches - je me demande bien laquelle -
et j'ai perdu la capacité à taper des dead char, par exemple, le e accent circonflexe, ê, je ne l'ai plus, parce que le circonflexe est "pris" mais il n'est pas restitué avec le e.

Le circonflexe ne s'affiche même plus.
Pareil pour Ctrl-Shift-u + 2192, ça ne fait plus le caractère flèche droite. Il avale les nombres, en bloquant le curseur, mais il ne restitue plus rien.

Ca vous dit quelque-chose, ce truc-là ?

[Eyce Karmina]

Si ça ne concerne que FF, c'est probablement l'input source switching, qui permet de changer le clavier pour toutes les fenêtres ou juste celle qui est active.

Tu y vois aussi la séquence de touches utilisée pour switch.

[Caniveau Royal]

C'est une régression de Debian.
Ils ont voulu corriger une CVE et ont raté un truc... Du coup, gare à pas installer la 6.1.0.21 tout de suite, on perd les dead keys et le Ctrl-Shift-u + <code>

J'ai vu l'autre jour dans un message un :

Make Debian Great Again

qui m'a fait sourire. C'est que les gens commencent à être un peu éprouvés...
Toutes les trois releases, ils se plantent. Il faut qu'ils revoient leurs processus de tests.

[Anthodev]

Citation :

Publié par Dr. Troy

Mais la bonne nouvelle, c'est que ça donne une raison plus valable pour cracher sur Arch (et autres rolling distro) que "on est en 2024 c'est le mal de faire tout en manuel".

C'est bête parce que la faille ne concernait pas Arch et ses dérivés (bon après c'est de la chance que le code ne visait que les système Debian/Fedora) :

Citation :

Update: To our knowledge the malicious code which was distributed via the release tarball never made it into the Arch Linux provided binaries, as the build script was configured to only inject the bad code in Debian/Fedora based package build environments. The news item below can therefore mostly be ignored.

Source : https://archlinux.org/news/the-xz-pa...en-backdoored/

[Airmed / Ildefonse]

Citation :

Publié par Caniveau Royal

Make Debian Great Again

qui m'a fait sourire. C'est que les gens commencent à être un peu éprouvés...
Toutes les trois releases, ils se plantent. Il faut qu'ils revoient leurs processus de tests.

Oky doki.
Tu as évidemment une source ?

[Herlatt]

Citation :

Publié par Anthodev

C'est bête parce que la faille ne concernait pas Arch et ses dérivés (bon après c'est de la chance que le code ne visait que les système Debian/Fedora) :

Pour le coup non, c'est pas de la chance, le code malicieux en question s'appuyait sur le fait que les devs des distributions concernées patchent certaines bibliothèques (un patch sshd pour ajouter une ref à systemd, dans ce cas). Et c'est cette version modifiée de sshd qui a rendu la faille possible.

Donc pour le coup, c'est plutôt un problème de mauvaise pratique (patcher une bibliothèque existante pour se faciliter la vie au risque d'y créer des failles de sécurité) que de malchance pour les distributions ciblées.