[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.

[Dr. Troy]

Je tente ma chance ici.

Sur mon serveur (debian), j'ai un client transmission (bittorrent) qui ne veut plus écrire dans son dossier de téléchargements.

Je ne sais pas à quoi ça correspond (pas le souvenir d'une maj du client, et les seuls trucs que j'ai pu faire entre temps n'ont pas trop de rapport - comme ajouter un onduleur connecté au serveur avec nut - ).

Sachant que sous debian, transmission crée un utilisateur (debian-transmission), et qu'il a bien les droits d'écriture sur le dossier (j'ai même tenté de donner tous les droits à tout le monde, ça ne veut toujours pas...). J'avais aussi créé une règle polkit pour autoriser un utilisateur à démarrer et stopper le service, mais j'ai également testé avec et sans, en lançant depuis le root, ça ne change rien non plus.
Enfin dans tous les cas ça fonctionnait avant (mais avant quoi ? haha) du coup je sèche un peu.

Une idée de ce que je peux regarder ? Un bug lié à une maj récente ?

[Airmed / Ildefonse]

Citation :

Publié par Dr. Troy

Je tente ma chance ici.

Sur mon serveur (debian), j'ai un client transmission (bittorrent) qui ne veut plus écrire dans son dossier de téléchargements.

Je ne sais pas à quoi ça correspond (pas le souvenir d'une maj du client, et les seuls trucs que j'ai pu faire entre temps n'ont pas trop de rapport - comme ajouter un onduleur connecté au serveur avec nut - ).

Sachant que sous debian, transmission crée un utilisateur (debian-transmission), et qu'il a bien les droits d'écriture sur le dossier (j'ai même tenté de donner tous les droits à tout le monde, ça ne veut toujours pas...). J'avais aussi créé une règle polkit pour autoriser un utilisateur à démarrer et stopper le service, mais j'ai également testé avec et sans, en lançant depuis le root, ça ne change rien non plus.
Enfin dans tous les cas ça fonctionnait avant (mais avant quoi ? haha) du coup je sèche un peu.

Une idée de ce que je peux regarder ? Un bug lié à une maj récente ?

vérifier que tu as de la place ? : df -h
Sinon regarder les logs : journalctl -b
ou le lancer manuellement et voir ce qu'il donne comme information

[Eyce Karmina]

C'est du stockage local ?

Normalement sudo journalctl -f devrait te donner des pistes quand tu restart le service / lance un dl.

Gaffe en faisant des tests comme lancer un service en root, t'es pas à l'abri de te retrouver avec un fichier en 600 pour root qui t'empêche le service de tourner par la suite quand tu repasses sur l'utilisateur normal.

[Caniveau Royal]

Regardes sur Le Stack Exchange Linux ou sur Super User si quelqu'un a déjà eu le problème.

Et si tu n'as pas de compte Stack Exchange Linux, je te recommande de t'en créer un et d'y poser ta question.
C'est bien rare qu'ils n'aient pas de réponses à un problème : cette stack est l'une des meilleures que je connais.

[Dr. Troy]

Citation :

Publié par Airmed / Ildefonse

vérifier que tu as de la place ? : df -h
Sinon regarder les logs : journalctl -b
ou le lancer manuellement et voir ce qu'il donne comme information

Citation :

Publié par Eyce Karmina

C'est du stockage local ?

Normalement sudo journalctl -f devrait te donner des pistes quand tu restart le service / lance un dl.

Gaffe en faisant des tests comme lancer un service en root, t'es pas à l'abri de te retrouver avec un fichier en 600 pour root qui t'empêche le service de tourner par la suite quand tu repasses sur l'utilisateur normal.

Oui j'ai bien de la place, et j'ai bien consulté le journal (qui me confirme le problème de permission).

Citation :

Couldn't create "/mnt/ssda/share/downloads/Nom.du.dossier.du.film.de.mes.vacances.TEAM[VACANCES].2024": Permission denied (fdlimit.c:174)
Couldn't create "/mnt/ssda/share/downloads/Nom.du.dossier.du.film.de.mes.vacances.TEAM[VACANCES].2024": Permission denied (file-posix.c:243)

J'ai pensé à la longueur des noms de dossiers/fichiers mais ça me le fait aussi pour des beaucoup plus courts (et il me semble que c'est uniquement un problème avec Windows la longueur des noms).

Le service se lance bien au nom de debian-transmission, que ce soit via un utilisateur ou le compte root (je le lance avec systemctl).
Et le service en lui même ne m'affiche pas d'erreurs, c'est uniquement quand je lance un téléchargement, une fois qu'il veut commencer à écrire que ça bloque (les connexions & cie fonctionnent bien).

Les torrents fonctionnent normalement sur une autre machine.

Ce que je trouve vraiment bizarre c'est que même en recréant le dossier et en faisant un chmod 777 dessus, ça veut pas (je peux écrire dans le dit dossier avec mon compte normalement, via samba aussi, etc...). Et surtout que ça fonctionnait bien avant (je me rappelle avoir du donner les droits d'écriture, mais comme on le fait pour n'importe quoi d'autre).

Je viens d'essayer en créant un sous-dossier, dossier et sous-dossier avec comme proprio et groupe debian-transmission, full access, rien n'y fait.
Sur un autre disque aussi des fois que... Et quand j'insiste de temps en temps le service plante. Je pige vraiment pas la.

J'ai fini par assigner le groupe debian-transmission au dossier share (parent de downloads) et ça remarche.
Par contre j'explique pas pourquoi ça fonctionnait sans, si quelqu'un a une explication logique

Ok j'ai trouvé, j'avais pas les bonnes permissions sur le dossier share. J'ai du faire une fausse manip

Citation :

Publié par Caniveau Royal

Regardes sur Le Stack Exchange Linux ou sur Super User si quelqu'un a déjà eu le problème.

Et si tu n'as pas de compte Stack Exchange Linux, je te recommande de t'en créer un et d'y poser ta question.
C'est bien rare qu'ils n'aient pas de réponses à un problème : cette stack est l'une des meilleures que je connais.

J'avoue je lurk depuis des années sans avoir de compte, faudrait que j'y songe !

[Caniveau Royal]

Citation :

Publié par Dr. Troy

J'avoue je lurk depuis des années sans avoir de compte, faudrait que j'y songe !

Ça en vaut la peine. J'y ai posé 80 questions en cinq ans, le plus souvent répondues.

[Dr. Troy]

Dites, histoire de remonter un peu le fil mais j'irai faire mes petites recherches...

Vous utilisez SELinux sur vos machines ?

Je suis passé sur Fedora 41 pour ma nouvelle machine, j'en suis content, sauf que j'ai (eu) pas mal de bugs ou divers messages d'erreurs avant de comprendre que SELinux était activé par défaut et me bloquait pas mal de trucs.

Pour certains j'ai fait des règles pour autoriser (typiquement rsync ne voulait absolument pas fonctionner), mais j'ai régulièrement des erreurs causées par ça et j'avoue que ça me gonfle un peu qu'il soit pas paramétré pour un usage normal (j'ai des erreurs quand je fais des mises à jour, il va me bloquer systemd qui est censé relancé des services après update alors que je fais mes maj avec dnf, bref rien d'exotique).

Du coup la question sous-jacente, c'est une couche de sécurité nécessaire et il y a moyen de bien le paramétrer sans y passer des heures ou tout le monde s'en fout et le désactive ? (c'est souvent la réponse que je trouve à mes erreurs)

Je me demande pas aussi si c'est le fait d'être parti d'une Fedora "minimal", des linuxo-joliens sur la dernière Fedora peut être ?