Dans le cadre de mon taf, je fais un peu de veille sur le monde de l'informatique, donc je me dis que je peux aussi en parler ici.

Et on commence par un bug, trouvé il y a quelques heures, qui affecte Firefox, et plus particulièrement le protocole HTTP/3. Si votre navigateur est configuré pour utiliser automatiquement des services en HTTP/3, le bug sera déclenché plus rapidement (par exemple DoH ou la télémétrie). Ce bug fait tourner Firefox en boucle et le rend inutilisable, y compris la partie qui s'occupe d'en faire les mises à jour automatique.

Si vous êtes affecté.e.s, le plus simple est de désactiver HTTP/3 : aller dans about:config, chercher la clé 'network.http.http3.enabled', et la mettre à False.

Bien entendu, les conséquences pour le navigateur risquent d'être gigantesques, sachant qu'il est déjà en perte de vitesse.

Source

Pour la petite blague, une équipe de hackers a été amenée à inspecter le code informatique d'un train en Pologne. Ils ont découvert que le constructeur avait bloqué les trains s'ils restaient plus de 10 jours dans un garage de maintenance d'un concurrent (la détection se faisait en utilisant les coordonnées d'un module GPS installé dans le train). Le constructeur proposait en effet un service de maintenance un peu plus coûteux. Les fonctions de blocage n'étaient pas documentées (bien entendu) dans le manuel. La société constructrice me semble avoir un déni plausible et poursuit en diffamation et pour violation de la propriété intellectuelle. De l'autre côté, il y a en ce moment en Pologne des trains qui roulent en ayant théoriquement perdu la validation du code qui tourne à bord (ce qui devrait être interdit).

Source 1 : https://badcyber.com/dieselgate-but-for-trains-some-heavyweight-hardware-hacking/
Source 2 : https://www.railtech.com/policy/2024/01/03/poland-hackers-used-to-unblock-trains/?gdpr=deny

C'est assez vieux ça non ?

C'est le genre de comportement auquel on peut voir aussi typiquement de la part de plus en plus de gros "constructeurs" qui forcent les réparations dans leurs propres boutiques (bien évidemment, à prix complètement abusifs). C'est le genre d'argument au coeur du droit à la réparation.

___

The seagull / wonder if she is sad / left alone without being touched / by the blue of the sky / or the blue of the sea.

Satori9960 a écrit :

> C'est assez vieux ça non ?

Le premier article date de début décembre 2023, et ça semble être la fin de l'embargo que les hackers avaient, la conférence au 37C3 date du 27, donc non, ce n'est pas très vieux.

> C'est le genre de comportement auquel on peut voir aussi typiquement de la part de plus en
> plus de gros "constructeurs" qui forcent les réparations dans leurs propres boutiques
> (bien évidemment, à prix complètement abusifs). C'est le genre d'argument au coeur du droit
> à la réparation.

Oui, c'est le même genre de problème, mais ce n'est pas exactement le même niveau quand il s'agit d'un téléphone portable ou d'un train (parce que si tu briques ton téléphone, ça ne cause pas de mort).

Les instructions et règlementations sur la conception, la fabrication ou la maintenance des trains est extrêmement rigoureuse, les fonctions critiques doivent être certifiées SIL 4 (le plus haut niveau possible). Si on parle de développement informatique (qui est une partie que je maitrise un peu), cela se traduit par un coût énorme, puisque :
- on utilise des logiciels de sécurité avec lesquels on fait prouver que le code obtenu est conforme à une spécification (donnée en langage mathématique). La RATP utilise systématiquement la méthode B (c'est dans le cahier des charges des appels d'offre pour tout soft ferroviaire de sécurité).
- ces langages ont des capacités très limitées par rapports aux logiciels récents. Impossible d'utiliser de l'allocation de mémoire dynamique, par exemple, donc exit toutes les structures fancy des langages. De toute façon, sauf quand la conception n'est pas ouf, on s'en fout du temps de calcul, tout doit être super simple et tous les calculs doivent se terminer (de manière garantie) en une fraction de seconde.

Ici, les compagnies ferroviaires qui ont acheté du Newag auraient certainement refusé de leur commander des trains s'ils étaient liés à eux pour la réparation (pour commencer, Newag peut couler, et il faut pouvoir continuer à utiliser le train). L'appel d'offre mentionnait certainement la nécessité d'avoir les manuels d'entretien, et ceux-ci doivent être suffisants pour démonter/entretenir/réparer le train, ce qui n'était pas le cas ici (la version polonaise de l'article, traduite automatiquement, ajoute cette information : "Any restrictions on the serviceability, including the limitations introduced in the software, may constitute a potential civil law dispute between the contracting authority and the manufacturer.").

Allez, pour la blague : quelqu'un connait la marque obscure… Nvidia ?

Elle est "méconnue" du grand public, il parait.

C'est toujours marrant d'imaginer la différence entre la sécurité que s'imaginent les hackers et celle de la vraie vie.

Un type a mis la main sur un portable utilisé dans une prison. C'est un portable avec pas mal de restrictions (pas de boot externe, des fonctionnalités très limitées, pas de port USB, un reset automatique du bios à chaque coupure de courant, bios protégé par mot de passe, etc.) et une coque transparente. À un moment, en désassemblant le code du bios, il arrive au fait que le mot de passe maitre passe à travers une moulinette pseudo-aléatoire dont il connait le résultat. Le jeu est donc de chercher un mot de passe tel qu'à travers la moulinette, il obtienne 'f8c1b9...6dccf'.

Ils commencent par tester les mots de passe les plus fréquents, puis les mots de passe du dictionnaire, puis des variations en changeant un caractère ou 2, etc. Quelqu'un dit qu'il va essayer de programmer un GPU pour essayer de le craquer (les GPU sont habiles pour ça parce qu'ils peuvent faire en parallèle des millions de tests de mots de passe).

Au final le mot de passe était "'N%(dU32p", trouvé dans une vidéo random d'un type qui explique comment faire un reset de cet ordi.

lien vers le thread d'analyse de l'ordi

lien vers la vidéo de reset (mdp au moment)

Bien entendu, il y a un xkcd pour raconter ça.

Un bug a été trouvé il y a 3 jours par hasard dans une bibliothèque de compression de données sous linux. Ce bug a obtenu la note de gravité maximale selon NIST.

Sur le plan technique : une personne malveillante a obtenu la gestion du projet liblzma et a inséré une backdoor dedans. La "charge utile" du trou de sécurité était cachée dans des fichiers de test (tests/files/bad-3-corrupt_lzma2.xz et tests/files/good-large_compressed.lzma). Un programme m4/build_to_host.m4 servant à l'installation du package .deb ou .rpm était ajouté, tout en étant différent de la version présente sur git, et il contenait du code bash permettant d'extraire le code malicieux et de le faire tourner, compromettant la machine (plus spécifiquement son serveur ssh).

Une partie importante de l'exploit a consisté à bien cacher les modifications. La modification n'a été perçue que parce que Andres Freund, développeur postgres, a constaté sur des benchmarks que son serveur ssh était inhabituellement lent et gourmand en CPU, et a investigué.

Sur le plan humain maintenant, l'ex et à nouveau-développeur principal de liblzma a été poussé tranquillement vers la sortie alors qu'il subissait les conséquences mentales d'un burnout :

I haven't lost interest but my ability to care has been fairly limited
mostly due to longterm mental health issues but also due to some other
things. Recently I've worked off-list a bit with Jia Tan on XZ Utils and
perhaps he will have a bigger role in the future, we'll see.

(Jia Tan est le nom du compte qui a finalement récupéré la responsabilité du dépot et installé la backdoor)

Cela remue pas mal dans la communauté du logiciel libre sur les ambiances de travail et les dépendances de sécurité entre des paquets.

Une timeline si ça vous intéresse. Ça fait vraiment roman policier.

Post pour trasher les IA

Vous aimez bien l'IA, quand elle sert de nobles causes et permet de réduire les travaux pénibles ? Genre les hôte.sse.s de caisse, c'est super chiant.

C'est l'idée derrière Just Walk Out, la chaine Amazon, dont vous avez peut-être vu des pubs : on rentre dans un magasin, on scanne un QR-code, puis on prend ce qu'on veut et on se casse. Et on est débité automatiquement.

Problème : autant c'est marrant quand une IA générative crée une image un peu gênante (ou carrément déplacée), autant si vous vous faites débiter de 15$ pour avoir acheté du tofu alors que vous détestez les végans, ça fait chier. Donc il faut de la fiabilité. Comment on fait une IA fiable ? On fait travailler des gens.

Ainsi, selon the information (derrière paywall) et rapporté par l'insider, 70% des transactions nécessitaient une vérif manuelle. Réalisée par des travailleurs pauvres, qui surveillent des écrans et indiquent correctement les produits achetés.

Au passage, Amazon a finalement abandonné ce modèle.

Par contre, il y a des cas où c'est manifestement moins grave de se tromper un peu. Selon +972, revue israelo-palestinienne (warning : elle est classé "à gauche" et a affirmé par le passé qu'Israël était un état d'Apartheid), l'armée d'Israel utilise une IA, lavender, pour cibler des terroristes gazaouis. Les cibles pouvaient se faire tuer par des bombes envoyées sur leurs domiciles pendant la nuit (pour s'assurer qu'ils sont bien chez eux). La review des profils ciblés prenait environ 20s en moyenne alors que la machine était connue pour avoir un taux d'erreur d'environ 10%.

Extrait :
The following investigation is organized according to the six chronological stages of the Israeli army’s highly automated target production in the early weeks of the Gaza war. First, we explain the Lavender machine itself, which marked tens of thousands of Palestinians using AI. Second, we reveal the “Where’s Daddy?” system, which tracked these targets and signaled to the army when they entered their family homes. Third, we describe how “dumb” bombs were chosen to strike these homes.

Fourth, we explain how the army loosened the permitted number of civilians who could be killed during the bombing of a target. Fifth, we note how automated software inaccurately calculated the amount of non-combatants in each household. And sixth, we show how on several occasions, when a home was struck, usually at night, the individual target was sometimes not inside at all, because military officers did not verify the information in real time.

Je fais juste un point rapide mais ça pourra être étoffé plus tard, en réaction à un post dans Bavardage.

La sécurité informatique ce n'est pas quelque chose qui est binaire.

Déjà, il y a plusieurs facettes. Souvent on donne les 3 suivantes :
- la confidentialité, c'est le fait que les données d'un programme ne soient pas lisibles par des gens qui n'en ont pas le droit (genre un pirate qui récupère votre mdp parce qu'il est transmis en clair *kof kof*)
- l'intégrité, c'est le fait que les données ne soient pas modifiables par des personnes qui n'en ont pas le droit (genre un pirate qui modifie votre mot de passe en utilisant une faille de sécurité)
- la disponibilité, c'est le fait qu'un système soit utilisable (genre un pirate qui ferait une attaque par déni de service pour mettre un site hors ligne, il n'a aucun accès aux données, juste il interdit d'utiliser le site).

On pourrait aussi ajouter la capacité d'un système à détecter un problème sur ces aspects (une sorte de réflexivité de la sécurité), mais passons.

En fonction du contexte, une de ces facettes est plus importantes qu'une autre (par exemple, une banque doit préserver les 3, mais dans l'ordre c'est intégrité > confidentialité > disponibilité). Pour un fichier de secrétariat d'hopital, cela risque d'être surtout la confidentialité qui prime (normalement tout le reste subit des doubles voire triple checks).

Pour la suite, je vais me concentrer sur la confidentialité, vu que c'est l'aspect en jeu quand quelqu'un dit "vous êtes fiché.e.s". Eh bien même quand on ne parle que de ça, ça ne veut pas dire grand chose. Un problème est toujours à évaluer à l'aune d'une menace ou d'un modèle de menace, et on ne se protège pas de la même manière en fonction du modèle qu'on affronte.

Si vous êtes un agent terroriste qui se protège contre un état, alors sans doute qu'un téléphone portable que vous portez allumé sur vous est un fichage inacceptable.
Si votre modèle de menace est votre partenaire de relation romantique dont vous préfèreriez qu'il/elle ne découvre pas que vous l'avez trompé.e, alors avoir un portable allumé sur vous n'est sans doute pas un problème. Si ledit/ladite partenaire a les capacités d'installer un mouchard sur votre téléphone et que vos rendez-vous galants ont lieu dans un endroit identifiable, ça redevient un problème.

(j'ai pris des exemples éthiquement discutables à dessein)

TL;DR : Si vous avez pas défini votre modèle d'attaque, alors l'existence d'une vulnérabilité n'a aucun sens.