CPUID, l’éditeur des utilitaires CPU-Z et HWMonitor, a été victime d’un hack ayant permis à des malandrins de distribuer un cheval de Troie à la place de ces deux outils. Les liens de téléchargement officiels ont été modifiés pour pointer vers des fichiers malveillants. L’attaque a eu lieu entre les 9 et 10 avril. La situation est désormais sous contrôle.

Ces deux logiciels comptent des millions d’utilisateurs. CPU-Z est un outil d’identification des composants d’un PC, HWMonitor surveille les capteurs (température, ventilos, etc.). Ceux qui ont eu le malheur de télécharger ces utilitaires durant l’attaque se sont retrouvés avec une variante malveillante de HWiNFO, un outil de diagnostic créé par un autre développeur.

Le logiciel piégé, baptisé « HWiNFO_Monitor_Setup », installe un malware d’origine russe depuis un nom de domaine compromis, détaille vx-underground. Il agit de manière progressive en plusieurs étapes pour ne pas éveiller les soupçons, exécute ses actions directement dans la mémoire vive en évitant d’écrire sur le disque du PC, et utilise des techniques d’évasion pour échapper aux antivirus et aux systèmes de détection. 

Le fichier compressé de l’application vérolée est tout de même identifié par une vingtaine d’antivirus, qui le classent comme un cheval de Troie ou un infostealer. Samuel Demeulemeester, alias Doc Teraboule, le développeur derrière CPU-Z et HWMonitor, a assuré que la faille avait été identifiée et corrigée. 

Si l’enquête est toujours en cours, il semble qu’une fonction secondaire (une API annexe) a été compromise « pendant environ six heures entre le 9 et le 10 avril ». Doc TB précise à Next que les liens vers le fichier vérolé sont restés en ligne sur le site de CPUID entre 2 h et 8 h (heure française). Seules les dernières versions de CPU-Z et HWMonitor proposées sous la forme d’un fichier compressé .ZIP ont été touchés, pas les .EXE. Il précise aussi que l’app malveillante n’étant pas signée, elle déclenchait donc Windows Defender immédiatement à l’extraction. De quoi limiter l’impact de l’infection.

Important aussi à avoir en tête : les fichiers hébergés sur le serveur de CPUID n’ont pas été compromis, uniquement les liens du site web. Les mises à jour automatiques des logiciels n’ont pas été touchées. Concernant l’attaque en elle-même, son envergure était a priori prévue pour être plus importante encore, puisque les pirates sont parvenus à compromettre les clés TLS privées en exploitant une faille Apache (les certificats compromis ont été révoqués).

Le développeur, toujours à pied d’œuvre, a pu réagir rapidement grâce aux experts en sécurité (et Reddit !) qui lui ont donné un coup de main.

• Après Trivy, Axios : une attaque chirurgicale et violente de la supply chain

Meta gêné aux entournures. Le géant des réseaux sociaux a nettoyé Facebook, Instagram, Threads et Messenger de dizaines de publicités pour des firmes d’avocats proposant leurs services… contre Meta. Fin mars, l’entreprise et YouTube étaient condamnés par une cour californienne à verser un total de 6 millions de dollars à une jeune plaignante souffrant de troubles de la santé mentale suite à son usage de leurs services.

Il a été démontré que Meta et YouTube avaient mis en place des fonctions visant à créer une dépendance à leurs plateformes. Les deux groupes ont annoncé faire appel, mais tout de même : cette décision de justice pourrait faire jurisprudence.

On a même parlé d’un moment « big tobacco » pour ces réseaux sociaux, en référence à ces grands procès des années 90 qui ont établi la responsabilité des fabricants de cigarettes, non seulement pour les dégâts provoqués par leurs produits sur la santé, mais aussi pour les mécanismes d’addiction qu’ils avaient eux-mêmes contribué à mettre en place.

Évidemment, la comparaison n’est pas flatteuse et Meta ne veut absolument pas être pris dans cette nasse. Les appels confirmeront ou infirmeront la décision judiciaire, mais sans attendre, les avocats spécialisés dans les litiges cherchent à en tirer profit. Des publicités ont ainsi commencé à fleurir sur les réseaux sociaux du groupe, pour recruter de nouveaux plaignants en vue de constituer des actions collectives. Ces procédures (« class actions ») peuvent déboucher sur des indemnisations substantielles, synonymes d’honoraires substantiels.

Dans une de ces pubs repérées par Axios, on peut lire : « Anxiété. Dépression. Dépendance. Automutilation. Ce ne sont pas de simples phases de l’adolescence — ce sont des symptômes liés à l’addiction des enfants aux réseaux sociaux. Les plateformes le savaient et ont continué à cibler les plus jeunes malgré tout. » Meta n’a pas apprécié, et a supprimé ces réclames. Quelques-unes seraient toujours actives, mais l’entreprise veille au grain.

Meta s’appuie sur une clause de ses conditions d’utilisation qui lui permet de supprimer des contenus « si nous estimons que c’est raisonnablement nécessaire pour prévenir ou limiter une utilisation abusive de nos services ou des conséquences juridiques ou réglementaires défavorables pour Meta ».

Un porte-parole confirme que l’entreprise supprimera les publicités visant à recruter des plaignants sur la base de cette décision de justice. « Nous ne permettrons pas à des avocats spécialisés dans les litiges de tirer profit de nos plateformes tout en affirmant qu’elles sont nocives. »

La Wii est un Mac comme un autre, la preuve : la vénérable console de Nintendo peut faire tourner Mac OS X ! Il n’y avait fondamentalement aucun obstacle insurmontable, il suffisait « juste » de plonger les mains dans le cambouis très profondément. Bryan Keller, développeur de son état, avait cette envie depuis l’université, en 2013. Mais difficile de se lancer dans un tel projet sans une solide motivation (et un peu de temps devant soi).

Le déclic est arrivé l’an dernier, lorsqu’il a appris que Windows NT avait été porté sur la Wii. La console est ouverte à la bidouille : Linux et NetBSD peuvent ainsi fonctionner dessus. Porter Mac OS X (10.0 Cheetah, la première version du système d’exploitation de 2001) n’était pas, sur le papier, complètement farfelu. Après tout, la Wii tourne avec un processeur PowerPC 750CL, une évolution du PowerPC 750CXe utilisé dans l’iBook G3 et présent dans certains modèles d’iMac G3.

Côté logiciel, Mac OS X repose sur un cœur open source (Darwin) dont les composants peuvent être modifiés pour permettre aux éléments propriétaires, comme le Finder, le Dock et les apps d’Apple, de tourner sans avoir à les modifier. Sur la Wii, une partie du travail a été mâché grâce au jailbreak de la console.

Il a fallu ensuite se plonger dans les spécificités matérielles de la console, comme par exemple Hollywood. Ce système-sur-puce intègre un coprocesseur ARM pour que le processeur de la Wii puisse communiquer avec son GPU, la carte SD, le stockage, le Wi-Fi, le Bluetooth, etc. Bryan Keller a développé un pilote pour Hollywood, mais aussi pour le lecteur de carte SD afin de booter sur Mac OS X.

Une fois ces bases posées, le système tentait bien de lancer l’interface graphique de Mac OS X, mais sans pilote adapté, impossible d’afficher quoi que ce soit correctement. Le composant WindowServer, chargé de gérer l’affichage, refusait tout simplement de fonctionner. Le bidouilleur a dû s’attaquer à un élément fondamental : le framebuffer. C’est une zone de mémoire vive contenant les données de chaque pixel affiché à l’écran. Faute de pilote compatible avec le matériel de la Wii, il a donc fallu en écrire un de toutes pièces pour permettre à Mac OS X d’afficher son interface.

On vous passe les autres péripéties techniques qui ont occupé Bryan Keller de longues heures (jours/semaines). Le résultat est là : Mac OS X tourne donc sur une Wii, qui prend même en charge un clavier et une souris via son port USB. « Il y a quelque chose de profondément satisfaisant dans le fait de réussir quelque chose dont on n’était même pas sûr, au départ, que ce soit possible », explique-t-il.

Pour les amateurs qui voudraient s’occuper le temps d’un week-end, le développeur a publié tout l’attirail logiciel de sa solution wiiMac sur GitHub.

Little Snitch est un utilitaire bien connu des utilisateurs de Mac. L’outil surveille et contrôle les connexions sortantes des applications installées sur sa machine. La première version remonte à 2003, ce qui ne rajeunira personne, et les mises à jour régulières distribuées par le studio autrichien Objective Development ont achevé d’en faire un logiciel essentiel sur la plateforme. C’est donc une petite surprise de voir débouler une version Linux ! Cette mouture est en fait la conséquence d’un besoin personnel du développeur Christian Starkjohann, qui a migré sur Linux et qui s’est senti « tout nu » sans Little Snitch.

Comme sur Mac, Little Snitch sur Linux révèle l’activité réseau des applications, et donne à l’utilisateur la possibilité d’agir, c’est-à-dire de bloquer la connexion si elle n’a pas été autorisée. L’application permet de voir la manière dont les logiciels interagissent avec les serveurs, et lesquels. On a également l’accès à l’historique du trafic ainsi que des volumes des données échangées.

Avec l’aide de listes de blocage, Little Snitch est en mesure de bloquer d’un coup des catégories de trafic indésirable. Ces listes peuvent être téléchargées depuis des sources distantes, et le logiciel se charge de les mettre à jour automatiquement. Attention cependant, le format .lsrules de la version macOS n’est pas compatible. L’utilisateur a aussi la possibilité de créer ses propres règles pour cibler un processus ou un port spécifique. 

Le logiciel peut être configuré pour réclamer une authentification préalable de l’utilisateur, pour éviter toute manipulation malintentionnée. Les développeurs soulignent que sur Linux, Little Snitch est conçu pour la confidentialité, mais pas pour la sécurité contrairement à la version Mac qui offre de solides garanties dans ce domaine.

La base sur laquelle repose le logiciel est eBPF, un mécanisme du noyau analysant les flux réseau qui impose des contraintes strictes en termes de stockage et de complexité des programmes. Quand le trafic est important, le suivi des connexions perd en fiabilité et certaines informations ne peuvent être reconstituées qu’approximativement, explique le studio. Sur Mac, il est possible d’inspecter les paquets pour réaliser les associations d’une manière plus fiable.

L’interface de Little Snitch est une web app (le logiciel en lui-même est développé en Rust). Un choix qui peut paraitre curieux pour un tel outil, mais qui permet de surveiller les connexions réseau d’un serveur Linux distant à partir de n’importe quel appareil. L’application a trois composants : le programme du noyau eBPF et l’interface web sont disponibles en open source sur GitHub, le démon est quant à lui propriétaire. Mais il est autorisé de l’utiliser et de le redistribuer gratuitement.

Linux ne manque pas d’outils de surveillance des connexions réseau, à l’image d’OpenSnitch, sans oublier les outils en ligne de commande. Mais comme sur Mac, Little Snitch facilite la vie des utilisateurs qui auront sous les yeux une seule interface pour observer le trafic réseau, et pour le bloquer le cas échéant. Le logiciel, compatible avec le noyau 6.12 de Linux et au-delà, est gratuit et il le restera pour toujours, promet Objective Development.

Retour vers le futur, en version 32 bits

Au bout de 49 jours, 17 heures, 2 minutes et 47 secondes, un Mac resté allumé tout ce temps commencera à perdre sa connexion réseau. La seule solution ? Le redémarrage de l’ordinateur. En cause : un problème d’horloge interne…

Une « bombe à retardement », c’est ainsi que Photon, un service qui connecte des agents IA à iMessage d’Apple, qualifie sa découverte sur Mac. L’image est parlante, mais un rien exagérée car il suffit d’un redémarrage pour que tout revienne à la normale. Néanmoins, cette « date d’expiration » peut représenter un sérieux problème dans les organisations qui ont besoin de faire tourner des Mac en continu.

Une horloge interne en panique

Le noyau XNU de macOS en charge des ressources du Mac, s’appuie sur un compteur interne pour suivre le temps dans la gestion des connexions réseau, sous la forme d’un entier non signé sur 32 bits. Il peut donc contenir des valeurs allant de 0 à 4 294 967 295 (2³²). Si on se sert d’un entier non signé de 32 bits pour compter le temps en millisecondes, le compteur peut donc aller jusqu’à 4  294  967 secondes, soit 49 jours, 17 heures, 2 minutes et 47 secondes. Au-delà ? Ça dépend des cas : retour à zéro, plantage…

• Les nombres en informatique : entiers, virgule flottante, simple et double précision (FP32/64), Tensor Float (TF32)…

Photon a découvert que sur Mac, une vérification mal conçue dans le noyau empêche le système de reconnaître correctement ce basculement après les 49 jours, 17 heures… Tant que le compteur peut augmenter, tout fonctionne normalement. Mais quand il atteint sa limite et repart de zéro, la machine se grippe. macOS considère alors, à tort, que le nouveau temps est « inférieur » à l’ancien et refuse de l’enregistrer.

Le sujet n’est pas nouveau et largement documenté. On le trouve par exemple dans le bug de l’an 2038 sur Linux. Un petit changement sur Debian depuis la version 13 a permis de résoudre le souci : la distribution utilise le format 64 bits (au lieu de 32 bits), de quoi repousser l’échéance de… 292 milliards d’années. Si on remonte dans le temps à l’époque de Windows 95, certains se souviendront peut-être que le système plantait aussi après 49,7 jours d’utilisation.

Résultat, l’horloge TCP reste figée à sa dernière valeur valide. Tous les mécanismes qui dépendent du temps, à l’image de la suppression des connexions fermées, cessent de fonctionner normalement. Il en va ainsi des ressources réseau qui dépendent des connexions TCP : elles s’accumulent jusqu’à saturation, ce qui rend impossible l’ouverture de nouvelles connexions.

Le redémarrage, ultime solution pour l’instant

Photon s’est rendu compte du problème en surveillant sa flotte de Mac qui font tourner plusieurs services iMessage. Des machines qui fonctionnent 24/7 et ne redémarrent qu’en cas de nécessité absolue. Plusieurs de ces Mac ont cessé d’établir de nouvelles connexions TCP 49,7 jours après leur dernier redémarrage.

« Les pings continuaient de fonctionner. Les connexions existantes restaient actives. Mais toute tentative nécessitant l’ouverture d’un nouveau socket TCP échouait », écrit le service. Seule solution : un redémarrage. Cela concerne donc les Mac fonctionnant en continu pendant plus de 49 jours et 17 heures sans redémarrer et qui ont une activité réseau TCP (tous les Mac connectés, au fond). 

Selon Tidbits, il semblerait que le bug soit circonscrit à macOS Tahoe, la dernière version du système d’exploitation (macOS 26). Les précédentes moutures de l’OS ne seraient pas affectées, ce qui explique pourquoi le problème n’a jamais été remonté auparavant. Photon de son côté laisse entendre que le bug pourrait remonter à Catalina… Apple ne s’est pour le moment pas exprimé.

Par ailleurs, un Mac en veille devrait aussi repousser l’échéance fatale. De plus, sur un ordinateur peu sollicité, l’épuisement des ports peut aussi mettre beaucoup plus de temps pour devenir perceptible. Pour le grand public, ce n’est pas nécessairement un bug handicapant : même si l’habitude d’éteindre son ordinateur tous les soirs en partant du bureau s’est perdue, il arrive tout de même assez régulièrement de devoir redémarrer sa machine. Ne serait-ce que pour installer une mise à jour du système.

Pour savoir depuis quand un Mac est allumé, il suffit de saisir la commande uptime dans un Terminal :

Ce compteur défectueux posera davantage de problème dans des environnements professionnels, comme c’est le cas chez Photon mais aussi dans des entreprises qui se servent de Mac Pro ou de Mac Studio pour des tâches très longues (rendu, compilation, simulation…) ou au sein de structures hébergeant des Mac en colocation administrés à distance.

Ou encore dans les fermes de Mac mini pour le partage de calcul ou les infrastructures de test. Néanmoins, ces services évitent de faire tourner leurs serveurs Mac avec la version la plus à jour de macOS, pour des questions de sécurité et de fiabilité. Il n’empêche qu’il s’agit tout de même là d’un bug qu’Apple serait avisée de corriger rapidement.

Amazon ferme la porte de sa bibliothèque aux anciens Kindle. Les liseuses et les tablettes Kindle Fire sorties avant 2012 ne pourront plus accéder à la boutique de livres numériques à compter du 20 mai. Les bouquins déjà stockés sur ces appareils continueront d’être lisibles, mais il ne sera plus possible d’en acheter et télécharger de nouveaux.

Ces appareils se transformeront donc petit à petit en presse-papiers de luxe, ce d’autant qu’en cas de problème, une réinitialisation dans les paramètres d’usine rendra la liseuse ou la tablette complètement inutilisable. Il en ira de même si on a le malheur de retirer son compte de la liseuse : on ne pourra plus s’y reconnecter. Sur les Kindle Fire, les services autres que l’achat de contenus resteront fonctionnels.

L’obsolescence programmée de ces appareils concerne le Kindle de première génération, celui sorti en 2007, les Kindle DX/DX Graphite (2009/2010), le Kindle Keyboard (2010), les Kindle 4 et Kindle Touch (2011), ainsi que les Kindle 5 et Kindle Paperwhite 1ère génération (2012). Du côté des tablettes, sont touchées les Kindle Fire 1re et 2e génération (2011), Kindle Fire HD 7 et 8,9 (2012).

• [Écosystème 6/7] Démonter, remonter, recycler

L’entreprise se justifie auprès d’Engadget : « Ces modèles ont été pris en charge pendant au moins 14 ans – certains jusqu’à 18 ans – mais la technologie a énormément évolué depuis… » Selon Amazon, la fermeture définitive du Kindle Store touchera 3 % des utilisateurs actuels. Pour faire passer la pilule, l’entreprise va contacter ces lecteurs en leur proposant une remise de 20 % sur une sélection de nouveaux modèles, ainsi qu’un crédit pour acheter des livres.

Si les tablettes d’Amazon ne sont pas forcément les plus durables du marché, les liseuses du constructeur sont des terminaux solides qui peuvent encore rendre bien des services. Ne plus pouvoir accéder à de nouveaux livres sur ces appareils – ce qui est leur seule et unique fonction – est pour le moins malheureux. Mais pas si étonnant au vu de la politique de verrouillage d’Amazon. Ainsi, depuis le 26 février 2025, la fonction de téléchargement et de transfert via USB depuis le site web du commerçant n’existe plus.

Celle-ci permettait de transférer par USB des livres Kindle (AZW3, KFX) téléchargés sur son ordinateur vers une liseuse de la marque. Amazon avançait des raisons de sécurité, en précisant que les nouveaux contenus pourront toujours être envoyés par Wi-Fi (un composant dont les Kindle ont été privés jusqu’en 2010 et le Kindle Keyboard).

On peut toujours transférer des fichiers sur une liseuse Kindle, y compris des PDF et des ePub, avec l’outil Send to Kindle, disponible sous forme d’application (à utiliser avec un câble USB) ou en ligne. Mais la limite est de 200 Mo. Le célèbre logiciel Calibre peut aussi être d’un précieux secours pour transférer des livres sur les Kindle ainsi qu’un grand nombre d’autres appareils.

Les possesseurs d’anciens Kindle qui ne veulent plus s’embêter à jongler avec les formats propriétaires et les verrous logiciels ont l’embarras du choix pour aller voir ailleurs. Les liseuses concurrentes des Kindle sont légion et, à l’instar des modèles de Kobo ou de PocketBook, les constructeurs affichent clairement leur soutien à des écosystèmes plus ouverts.