Six chercheurs d'UC San Diego et d'Oberlin College ont présenté le 13 août dernier à l'USENIX Security Symposium de Baltimore un implant assez petit qui se branche sur un port de maintenance de la baie électronique d'un Boeing 737 et s'intercale ainsi entre le calculateur de vol et l'écran par lequel les pilotes le programment.

La trappe présente sur l'avion, qui y mène n'a ni serrure ni contrôle d'accès et est accessible depuis le sol, sans échelle. Les chercheurs estiment que ça peut se mettre en place en moins de 60 secondes, ouverture et refermeture comprises. Le boîtier, lui, disparaît sous le capuchon anti-poussière du connecteur.

Hé oui c'est un simple capuchon en plastique qui "protège" l'accès aux commandes de navigation d'un avion de ligne. C'est beau non ?

Ce connecteur donne un accès aux bus ARINC 429 qui transmette les échanges entre le calculateur, le FMC, et le clavier-écran du cockpit, le MCDU. La norme date de 1977 et ne prévoit aucune authentification et comme vous vous en doutez, c'est connu depuis longtemps, même si le plus souvent, les attaques envisagées sur les systèmes d'un avion visaient plutôt ses liaisons radio.

Toutefois, se brancher sur le bus ne suffit pourtant pas à le contrôler, puisque les autres équipements continuent d'émettre par-dessus. Sauf que les émetteurs légitimes passent par des résistances de 37,5 ohms qui brident leur courant, alors que le connecteur de maintenance, lui, attaque le bus en direct.

L'implant en profite alors pour pousser plus de courant que l'émetteur d'origine et écraser physiquement son signal. Les chercheurs appellent ça une attaque Bus Driver, et elle donne une interception complète du dialogue sans couper ni épisser le moindre fil.

Une fois ce dialogue sous contrôle, le boîtier ajoute un point de passage à la route programmée. Normalement, sur un 737, cette modification doit être confirmée par le pilote, qui appuie sur le bouton EXEC. Mais l'implant, lui, appuie tout seul, l'autopilote change de cap, et comme le voyant du bouton passe par le même bus, il reste éteint. Et comme les pages affichées sont réécrites en live pour montrer encore l'ancienne route, rien à l'écran ne trahit le changement.

Le même mécanisme peut servir aussi à fausser la masse de l'appareil saisie avant le départ, ou la température retenue pour calculer la poussée. Une masse sous-évaluée ou une température trop basse, et le calculateur commande alors une poussée insuffisante au décollage.

Bref, c'est la cata assurée... Et cela vaut pour tous les 737 NG et MAX.

Maintenant, reste à savoir dans quelles conditions cette attaque peut être réalisée. Car jusqu'à présent, tout a été validé mais uniquement sur un banc de vraies pièces de 737 câblées selon les schémas Boeing, et jamais sur un avion en service. Le Wi-Fi est bien intégré au boîtier, mais le papier précise que les auteurs n'ont pas pu tester si le signal de la cabine traverse le plancher de la baie.

Boeing a bien sûr été prévenu en avril 2020, et les chercheurs ont rejoué l'attaque avec succès sur le banc d'essai du constructeur en décembre 2023. Ils proposent de boucher ce type de connecteur, ou d'y déplacer les résistances de limitation. Boeing, lui, estime que "les couches de protection en place sur l'avion" limitent déjà "significativement la faisabilité et le risque d'attaques en conditions réelles".

Ouais les gars ont la flemme de sécuriser leur truc on dirait...

Source

Hé oui, ENCORE LUI !!

Jonathan Blow, le développeur de Braid et de The Witness, a annoncé hier (le 12 août) sur X qu'il laissait tomber VLC... La raison c'est 33 putain de secondes d'attente entre un clic sur un fichier MP3 et le début de la lecture, sous Windows (évidement). C'est vrai qu'une demi-minute pour lancer un son sur une machine récente, c'est abusé ! Du coup, il est repassé au bon vieux lecteur multimédia de Microsoft.

Son point de vue c'est que "tout un secteur du logiciel open source est dans un état franchement embarrassant" dès qu'il s'agit de tourner Windows. Je peux pas lui donner tord, c'est vrai que le ralentissement est réel sous Windows 11, sans qu'on sache vraiment pourquoi...

Mais heureusement, la réponse de VideoLAN ne s'est pas faite attendre et a replacer correctement le débat. Pour l'équipe de VLC, la lenteur vient d'un bug de Microsoft Defender arrivé avec une mise à jour de Windows 11, qui a mis le cache de plugins de VLC en quarantaine. L'antivirus maison de Windows a donc classé comme suspect, puis mis de côté, un fichier que VLC génère lui-même. VideoLAN écrit qu'il s'est retrouvé là "comme par magie".

Pour remettre VLC d'aplomb, VideoLAN propose donc de réinstaller le logiciel ou de régénérer ce cache. Mais pas besoin d'aller jusqu'à la réinstallation, puisque l'installeur Windows officiel dispose déjà d'un raccourci qu'il faut dans le dossier VideoLAN du menu Démarrer, "VLC media player - reset preferences and cache files".

Ce raccourci lance vlc.exe avec les deux options de remise à zéro, la configuration et le cache de plugins, puis referme aussitôt le lecteur. Ça devrait faire le taf même si attention, vos préférences partent aux chiottes avec le reste, donc si vous avez bricolé vos réglages de sortie audio, vos raccourcis clavier ou vos sous-titres, vous les perdrez. Mais ensuite, le cache, lui, se reconstruira au lancement suivant.

Après régénérer le cache n'empêche pas Defender de le rechoper par la suite. L'autre option, c'est donc d'exclure une bonne fois pour toutes vlc.exe de la liste d'analyse de l'antivirus.

Bref, ce genre de faux positif n'est pas nouveau chez Windows Defender, qui y'a pas longtemps a même pris des certificats DigiCert pour un cheval de Troie, sans parler des ISO Linux qui se font flagger régulièrement .

Voilà, hormis la comm de VLC pour le moment, personne n'a encore publié de détails techniques, et Microsoft n'a rien dit.

Source

ShieldBreak est un nouvel exploit qui vise l'antivirus livré avec Windows. Cela permet à un compte utilisateur limité de passer SYSTEM sur un Windows entièrement à jour, grâce notamment à Windows Defender qui lui sert de marchepied.

Le chercheur Nightmare Eclipse a sorti le code de son exploit en public y'a 2 jours, quelques heures après un Patch Tuesday qui corrigeait plus de 400 failles. Mais pas celle-ci évidemment... Une machine parfaitement à jour reste donc exposée.

Kevin Beaumont, ancien de chez Microsoft, a testé l'exploit et confirme qu'il fonctionne sur un Windows 11 à jour. Sa lecture technique, en revanche, diffère de celle du chercheur. Nightmare Eclipse présente ShieldBreak comme un contournement complet du correctif de RoguePlanet, sa faille précédente, alors que Beaumont souligne que les deux reposent sur des mécanismes très différents.

L'attaque réclame un accès local et l'exécution du programme, elle ne s'attrape pas en visitant une page web. Elle a été testée sur Windows 11 25H2 et Windows Server 2025, Windows 10 étant déclaré vulnérable sans être pris en charge par le code publié. Et il faut que Defender soit activé pour que ça marche.

Cette publication sans préavis n'arrive pas de nulle part. En mai, Microsoft a publié un billet qualifiant d'injustifiables les divulgations non coordonnées qui mettent du code d'exploitation entre les mains d'acteurs malveillants, en rappelant que sa Digital Crimes Unit continuerait à poursuivre ces acteurs. Le texte ne visait pas nommément les chercheurs. Le milieu de la sécurité l'a quand même reçu comme une menace.

Microsoft a fait ensuite machine arrière sur les réseaux sociaux, en assurant ne pas vouloir s'en prendre à ceux qui publient de la recherche. Le billet d'origine, lui, est toujours en ligne et les publications n'ont pas ralenti pour autant : une dizaine de zero-days Windows depuis avril, dont BlueHammer et GreatXML dont je vous ai déjà parlé.

Microsoft dit avoir connaissance de la vulnérabilité signalée et enquêter sur la validité des affirmations mais pour le moment, la faille n'a même pas d'identifiant CVE à elle, et reste rattachée au correctif qu'elle est censée contourner. Bref, si ça vous fait flipper comme faille, désolé, il n'y a rien à installer pour l'instant pour fixer le problème.

En attendant, Beaumont a mis en ligne des requêtes de "chasse" pour Defender for Endpoint qui repèrent quand un processus étranger à Defender charge ses bibliothèques, ou qu'un processus non validé charge celles de l'API Cloud Filter. Tout ça via le même processus.

Mais c'est de la détection, et pas un correctif...

Source