La commande Linux wall est un vestige de la façon dont les machines Unix étaient utilisées. C'est l'abréviation de Write to ALL, et il a été inclus pour la première fois dans AT&T Unix, en 1975. wall est un outil qu'un administrateur système peut utiliser pour envoyer un message à la session de terminal de tous les utilisateurs connectés. Jusqu’à présent, rien de très excitant du point de vue de la sécurité. Là où les choses deviennent un peu plus intéressantes, c'est la prise en compte des codes d'échappement ANSI. Ce sont les codes de contrôle qui déplacent le curseur sur l’écran, également hérités de l’époque des terminaux.
Le moderne wall le binaire fait en fait partie de util-linux, plutôt que d'être une continuation de l'ancienne base de code Unix. Sur de nombreux systèmes, wall fonctionne comme un setgid, donc le comportement du binaire système compte vraiment. Il est admis que wall ne devrait pas être en mesure d'envoyer des codes de contrôle, et lors du traitement d'un message spécifié via l'entrée standard, ces codes de contrôle sont rejetés par le fputs_careful() fonction. Mais lorsqu'un message est transmis sur la ligne de commande, en tant qu'argument, cet appel de fonction est ignoré.
Cela permet à tout utilisateur pouvant envoyer wall messages pour envoyer également des codes de contrôle ANSI. Est-ce vraiment un problème de sécurité ? Il existe deux scénarios dans lesquels cela pourrait se produire. La première est que certains terminaux prennent en charge l'écriture dans le presse-papiers du système via des codes de commande. L'autre problème, plus créatif, est que le résultat de l'exécution d'un binaire pourrait être écrasé par du texte arbitraire. Texte comme :Sorry, try again.
[sudo] password for jbennett:
Vous avez peut-être des questions. Par exemple, comment un attaquant saurait-il quand une telle commande serait appropriée ? Et comment cet attaquant pourrait-il capturer un mot de passe saisi de cette manière ? La réponse simple consiste à consulter la liste des processus en cours d’exécution et le journal système. De nombreux systèmes disposent d'une fonction de commande introuvable, qui imprimera la commande défaillante dans le journal système. Si cette commande défaillante est en réalité un mot de passe, alors elle est à portée de main. Maintenant, vous pensez peut-être qu’il s’agit d’une surface d’attaque très étroite qui ne sera pas très utile dans le monde réel. Et c'est probablement assez exact. C’est une idée vraiment fascinante à réfléchir et qui mérite vraiment d’être corrigée.
API privée d'Edge
Il y a donc une drôle de chose qui se produit lorsque vous visitez microsoft.com dans le navigateur Edge. Il existe des boutons intitulés « Essayer maintenant » pour diverses fonctionnalités, comme la fonction de partage de fichiers Drop. Lorsque vous cliquez sur le bouton, le navigateur ouvre la barre latérale déroulante pour montrer son fonctionnement. Rétrospectivement, cela aurait dû paraître vraiment étrange. Le secret est que lorsque Microsoft crée Edge à partir de la source Chromium, il ajoute le edgeMarketingPagePrivate API, donnant à une certaine liste de pages Microsoft plus d'autorisations pour faire des choses dans le navigateur.
L'une de ces autorisations pose un petit problème : l'installation de thèmes. Le sale secret est qu’un thème Chromium est en réalité une extension Chromium, avec un sous-ensemble de fonctionnalités et d’autorisations. Edge donne à Javascript des pages Microsoft l'autorisation spéciale d'installer un thème. La véritable vulnérabilité ici est que cette API permet également involontairement l’installation silencieuse de n’importe quelle extension, pas seulement de thèmes. Et les extensions peuvent être particulièrement puissantes, avec la possibilité de lire et de modifier des pages Web, d'accéder aux cookies, etc.
Même si ce n’est évidemment pas génial, il faut penser à la surface d’attaque limitée. Pour en abuser, un attaquant doit pouvoir placer JS sur un site Microsoft. Il existe des scénarios farfelus mais pas impossibles, comme un acteur malveillant chez Microsoft ou une vulnérabilité XSS (Cross Site Scripting) découverte sur l'un de ces sites. Il existe ensuite des vecteurs d'attaque plus réalisables, comme une extension de navigateur malveillante avec peu d'autorisations, qui utilise ce bug pour installer une extension avec toutes les autorisations. Ou qu'en est-il d'une appliance de sécurité d'entreprise dotée d'un certificat SSL de confiance, capable de surveiller les pages Web ? Il semble possible que si un tel appareil était compromis, insérer un peu de Javascript dans une page Microsoft ne soit pas impossible.
Quoi qu'il en soit, la version 121.0.2277.98 d'Edge contenait un correctif, ajoutant une vérification indiquant que seuls les thèmes peuvent être installés via cette API. Ce correctif a atterri un peu moins de 90 jours, le 9 février.
Va chercher
Au moins une personnalité Internet bien connue a qualifié la dernière divulgation de vulnérabilité d’Apple de porte dérobée. Cela semble exagérer un peu le problème. Ce que nous avons réellement, c'est un canal secondaire qui peut exposer les clés. Les processeurs M1 et M2 d'Apple disposent d'un préfetcher dépendant de la mémoire de données (DMP) qui anticipe l'exécution du programme et tente de charger la mémoire dans le cache avant qu'elle ne soit nécessaire.
Le problème est que l'une des techniques pour y parvenir consiste à rechercher dans la mémoire du programme des valeurs de type pointeur et à mettre en cache le contenu de la mémoire à ces emplacements. Cela signifie qu’une opération de cryptographie par boîte noire peut modifier l’état du système de manière détectable. Le résultat final est que si un attaquant contrôle les données sur lesquelles il agit dans un processus cryptographique et peut exécuter un deuxième processus sur la même machine, les clés elles-mêmes peuvent être dérivées.
Collisions SHA-256 – presque à mi-chemin
C’est le genre de chose qui glace le sang d’un passionné de sécurité pendant un moment. Nous avons désormais des attaques pratiques contre SHA-256 — pour les 31 premières étapes. Cela nécessite un peu de contexte. SHA-256 est une fonction de hachage cryptographique qui prend une entrée et la présente dans un calendrier de messages, puis effectue 64 étapes d'opérations de mixage. Ce sont ces étapes de mélange qui réalisent la nature unidirectionnelle de SHA-256. Ce qui est affirmé ici, c'est que si nous créions une version de SHA-256 qui n'utilisait que 31 étapes de mélange, nous pourrions effectuer des attaques par collision.
Première collision pratique SHA-256 en 31 étapes. #fse2024 pic.twitter.com/qBo3tOLPGB
– Frank ⚡ (@jedisct1) 26 mars 2024
Le papier pour ce travail a atterri et est aussi rempli de cryptographie lourde qu'on pourrait s'y attendre. La bonne nouvelle est que nous sommes encore *très* loin d'une véritable attaque SHA-256, et l'état de l'art évolue assez lentement. Oui, vos bitcoins sont toujours en sécurité.
Ce n'est pas une vulnérabilité
Mais les serveurs sont toujours compromis. Le framework Ray est de plus en plus adopté en tant que service facilement déployable pour mettre en place des modèles d'IA et effectuer un travail réel. Et malheureusement, le framework Ray est attaqué lors d'une campagne en cours. Et une instance Ray est une cible assez juteuse, avec de nombreuses données à récupérer, ainsi que de nombreuses infrastructures de calcul juteuses sur lesquelles exploiter la crypto-monnaie. Ce qui est intéressant, c'est que Ray n'a pas de couche d'authentification de par sa conception.
En raison de la nature de Ray en tant que cadre d'exécution distribué, la limite de sécurité de Ray se situe en dehors du cluster Ray.
Ce n'est pas la première application populaire conçue de cette façon, et la leçon commune est que lorsque vous donnez aux utilisateurs un pistolet comme celui-ci, un pourcentage important d'entre eux l'utilisera avec plaisir. Un CVE a été émis pour manque d'authentification, mais a été (à juste titre) contesté par Anyscale.
Il y a une distinction importante à faire ici : ce n'est pas parce que ce problème n'est pas une véritable vulnérabilité qu'il ne s'agit pas d'un problème ou qu'il ne devrait pas être amélioré. Et c’est finalement la conclusion à laquelle Anyscale est arrivé. Ce qui est maintenant disponible est un script de test officiel, qui devrait être inclus dans Ray 2.11, qui recherche l'exposition et en avertit. Le temps nous dira si une future version de Ray bénéficiera d’une authentification complète par défaut.
Bits et octets
Dans une première intéressante, Zenhammer permet le retournement des bits de mémoire DDR5 lors d’une attaque au marteau, mais dans une seule des dix clés de mémoire testées. Pour réussir l'attaque contre un processeur Zen, la fonction d'obscurcissement des adresses DRAM a dû faire l'objet d'une ingénierie inverse et quelques autres techniques spécifiques à Zen ont dû être utilisées. D’après ma lecture, Micron semble sortir vainqueur de la petite taille de l’échantillon utilisé.
Deux vulnérabilités SharePoint utilisées lors du concours Pwn2Own de l'année dernière figurent désormais sur la liste des vulnérabilités activement exploitées. Il est un peu humoristique que les vulnérabilités soient connues depuis plus d'un an et que ce n'est que maintenant que les agences fédérales américaines sont obligées de les corriger.
En parlant de ça, le concours Pwn2Own de cette année vient de se terminer. Plus d'un million de dollars ont été gagnés par les chercheurs, Manfred Paul occupant la première place. Nous attendons avec impatience que tous les bugs de cette année soient corrigés et divulgués.
Et enfin, Google a prêté attention à l'annonce de Loop DoS et a publié un rapport sur une attaque DoS réelle qui incluait un élément de boucle vraisemblablement involontaire. CLDAP, une implémentation partielle UDP de LDAP, a été utilisée il y a plusieurs années dans une attaque par réflexion contre l'infrastructure QUIC de Google. Les serveurs QUIC ont répondu avec des paquets de réinitialisation à chacun des serveurs CLDAP. Et une poignée de ces serveurs ont renvoyé les paquets réinitialisés, ce qui a entraîné une boucle de 20 millions de paquets par seconde sur Internet. La solution est également fascinante : assurez-vous que les paquets de réinitialisation sont toujours plus courts que le paquet auquel on répond, jusqu'à un seuil où les paquets ont simplement été ignorés. Chouette.
