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 ?
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.
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 ?
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.
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.
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.
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.
Article en français :
[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.
En combinant plusieurs facteurs, c’est possible :
D’autres possibilités : le mirroir utilisé est corrompu ou le proxy du réseau est corrompu.
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 
) :
Bref, je dirais qu’il est surtout urgent d’attendre d’en savoir davantage 
Bonne soirée,
Sangokuss
C’est ça qui me ferait peur, mais il me semble que les paquets étant signés, simplement corrompre le miroir ne suffirait pas ?
Gérer un miroir et se le faire compromettre … faut y allez en supposition déjà.
Suppositions qui se sont déjà souvent trouvées avérées, surtout pour le deuxième.
Des miroirs Debian, Redhat, Ubuntu etc … en bref des miroirs officiel et pas de distribution de geek tel que Arch/Manjaro etc …
Le dernier en date c’était Gentoo il me semble, j’élude complètement l’affaire Sourceforge.