FontOnLake

Y’a quelqu’un qui pige kekchose à la vulnérabilité FontOnLake ?

Y’a pas d’info apparemment sur l’origine des paquets infectés, mais savoir que cat peut être vérolé c’est pas vraiment rassurant…

Pis c’est moi qui flippe tout seul, mais hier je regardais la conférence de Lunar à PSES 2015 sur la reproductibilité des builds et ça me rend parano…
Ce ne sont quand même pas les binaires de Debian qui sont contaminés ?

1 J'aime

Larticle me semble tout de même bien assez claire … en aucun cas on parle de compromission de paquet Debian ou autre mais de l’introduction d’une backdoor lors de l’installation d’applicatifs compromis … Si tu installe depuis les dépôts Debian et non des trucs exotiques ou peu surveillés PPA etc tu ne risque rien à priori.

Pour l’instant seul des kernel anciens ont été remontés, donc à priori sur des Debian récents les gens n’ont pas encore rencontré ce bouzin.

1 J'aime

Assez clair, oui et non…
En effet ils ne parlent pas de compromission de paquets à la source (c’est moi qui psychote tout seul après la conf’ de Lunar) mais ils disent qu’ils ne savent pas d’où vient la compromission des exécutables.

Tu as dû faire une faute de frappe, ta phrase ne veut rien dire ?

1 J'aime

Merci pour l’info.

  • kill - lists all running processes

A propos de lac, il paraît qu’il y aurait eu de l’eau dans ce lac de la planète Mars.

Oui merci, il manqué du monde …

Bien entendu c’est pour ça que les équipes de Eset ont même précisé avoir trouvé plusieurs exemple du malware.
Encore une fois si tu reste sur les dépôts Debian tu te garantie d’une forme de sécurité que tu n’aura pas en allant chercher des .deb ailleurs y compris sur les PPA de la plateforme Launchpad.

1 J'aime

En fait il s’agit d’applciatifs courant de linux, qui ont été compilés avec des trojan, ou dont le source contient du code de trojan
ensuite ce cote trojan est utilisé pour charger du code malicieux.

1 J'aime

Je rappelle que pour installer ce type de rootkit sur une machine il faut avoir obtenu un accès root. Donc soit une grosse bourde de l’administrateur système laissant une faille de sécurité béante, soit l’installation de logiciels à partir de sources absolument pas fiables.
Sur une machine correctement administrée, utilisant uniquement les dépôts officiels Debian (ou autre soigneusement vérifiés), le risque est nul.

1 J'aime

Nan mais je sais que je psychote, mais des exécutables comme cat ou kill personne ne va les chercher ailleurs que dans les dépôts normalement ?
Donc je comprends toujours pas (et comme les chercheurs non plus, ça ne me rassure pas).

Oui, une infection du compilateur (selon le principe exposé par Ken Thomson dans « Reflections on trusting trust ») est bien le risque dont parlait Lunar dans sa conf et la raison pour laquelle la reproductibilité des builds est importante.
Et aussi celle pour laquelle je psychote…

Parce que je le répète, je ne vois pas qui va chercher cat et kill ailleurs que dans les dépôts.

1 J'aime

Article en français :

1 J'aime

[mode_troll]
Salut,

mon sources.list n’est pas bon alors ?

 ~$cat /etc/apt/sources.list

deb http://deb.warez.org/debian/ stable main contrib non-free
deb http://deb.warez.org/debian/ stable-updates main contrib non-free
deb http://deb.warez.org/debian-security stable/updates main
deb http://deb.warez.org/debian bullseye-backports main

[/mode_troll]

Tu as plein de dépôts logiciels dans ce genre depuis quelques années : Cross-platform Rust rewrite of the GNU coreutils. C’est assez à la mode ces temps-ci de remplacer les outils de base du système par des trucs ré-écrits dans les langages à la mode du moment (souvent Go ou Rust). Le tout bien sûr sans passer par les dépôts de la distribution.

1 J'aime

En combinant plusieurs facteurs, c’est possible :

  1. Un binaire hors debian est ajouté
  2. Ce binaire ajoute une référence dans /etc/apt/sources.list.d/
  3. Les mises à jour se font automatiquement avec unattended-upgrades par exemple
  4. La nouvelle source pousse ses paquets debian comme coreutils ou procps
  5. Sans vérification, ça passe inaperçu

D’autres possibilités : le mirroir utilisé est corrompu ou le proxy du réseau est corrompu.

1 J'aime

Heureusement, unattended-upgrades ne met à jour que les paquets venant d’une liste donnée de dépôts. Avec son réglage par défaut il ne touche pas aux paquets d’éventuels dépôts tiers.

Ça se contourne bien sûr, mais c’est plus compliqué qu’un simple fichier à poser sous /etc/apt/sources.list.d/.

Bonjour,

Je vous lis avec intérêt, merci d’ailleurs pour ces échanges, car en effet, je me suis moi-même interrogé quant au(x) vecteur(s) possible(s), et non décrits, de cette attaque.

Néanmoins, j’ai deux (petites) remarques à vous soumettre (n’y voyez pas de #Troll, mais juste un questionnement à mon avis légitime :wink: ) :

  • tout d’abord, des sources officielles compromises, il me semble que l’histoire a démontré que c’était possible, et pas si rare que cela. Je dirais même que si j’étais un attaquant, cette option serait possiblement ma priorité, même si pas la plus simple.
  • ensuite, l’utilisation d’un dépôt tiers (compromis) pour un logiciel n’ayant rien à voir avec ceux qui posent problème peut tout à fait conduire, me semble-t-il, à la compromission des dits logiciels.

Bref, je dirais qu’il est surtout urgent d’attendre d’en savoir davantage :sweat_smile:

Bonne soirée,
Sangokuss