On ne branche pas directement le SSD dans le port PCIe !

Installer un SSD M.2 NVMe dans le port PCIe d’une carte mère peut se faire simplement à l’aide d’un adaptateur vendu quelques euros. Nous avons testé un modèle de Sabrent avec un radiateur pour refroidir les puces de NAND qui pourraient chauffer lors de gros transferts.

Nous avons commandé il y a quelque temps un adaptateur M.2 pour les SSD NVMe afin de les installer dans un emplacement PCIe de carte mère. C’est l’occasion d’expliquer comment cela fonctionne. C’est simple : un PCB, quelques pistes et quasiment aucun composant.

M.2 NVMe et PCIe : blanc bonnet et bonnet blanc

La raison est simple : les SSD au format M.2 utilisant le protocole NVMe sont déjà avec un câblage en PCIe, il n’y a donc aucune conversion de signal à faire pour les brancher sur un connecteur PCIe, il faut simplement emmener les broches du SSD au bon endroit sur le port PCI Express. Ce n’était pas le cas de l’adaptateur M.2 vers USB dans lequel, pour rappel, un contrôleur Realtek se chargeait de la conversion du signal.

• #Nextpresso Test d’un boitier « sans outil » USB Type-C à 10 Gb/s pour SSD M.2, à 15 euros

Le PCB de notre adaptateur de marque Sabrent était vendu 10 euros sur Amazon il y a quelques mois quand nous l’avons acheté, mais il est désormais à 18 euros, ce qui est largement au-dessus de la moyenne pour ce genre de produit. Il en existe d’autres marques (ou sans marque) à 10 euros sur la marketplace d’Amazon.

Un PCB quasiment vide, et c’est normal

Le même bout de PCB (en no-name, sans la marque Sabrent, mais le reste du PCB est identique) est vendu quelques euros sur les plateformes chinoises, mais sans radiateur.

L’intérêt de ce modèle est qu’il est livré avec un pad thermique à poser sur les puces de mémoire NAND du SSD et un radiateur métallique qui englobe entièrement le SSD.

L’installation nécessite un peu de dextérité avec une vis pour faire tenir le SSD dans son emplacement M.2 (des trous sont disponibles pour les SSD au format 2230, 2242, 2260 et 2280, c’est-à-dire en 30, 42, 60 et 80 mm de long) et quatre autres pour fermer le boîtier. Dans le bundle, nous avions également un petit tournevis adapté aux vis, pratique.

À y regarder de plus près, on remarque quelques composants, à vrai dire. Deux condensateurs pour l’alimentation électrique, quatre LED et autant de résistances pour ces dernières. Aucun des composants ne sert au transfert des données.

Sur les photos ci-dessous, vous pouvez voir que seuls les deux premiers morceaux de PCB du port PCIe sont connectés, ce sont ceux qui correspondent à du x4. Les autres ne sont pas branchés, ce qui explique qu’on peut mettre la carte dans un emplacement x4, x8 ou x16.

Il suffit donc d’installer l’adaptateur dans un port PCIe de votre ordinateur. Il doit être en x4 minimum (il n’est pas compatible avec les ports x1), mais il peut aussi être en x4, x8 ou x16. Dans tous les cas, le câblage interne est en x4 maximum.

Sur la seconde rangée d’images, vous pouvez voir l’installation dans un emplacement x16, puis dans un emplacement x4 et enfin en face d’un emplacement x1 qui n’est pas compatible.

Cinq vis plus tard, 3 Go/s comme prévu avec notre SSD

Nous avons installé un SSD Kingston NV2S de 500 Go, qui est au format M.2 avec une interface NVMe en PCIe x4 Gen 4. Attention, cet adaptateur n’est compatible qu’avec les SSD M.2 avec une interface en PCIe, pas ceux en S-ATA !

• Tout savoir sur le M.2 : un connecteur, trois sockets, des dizaines de possibilités

Notre SSD était déjà partitionné et considérablement rempli, mais les performances sont équivalentes à celles obtenues s’il était directement branché sur la carte mère. Nous avons ainsi un peu plus de 3 Go/s en lecture et près de 2,4 Go/s en écriture.

Rien de surprenant puisque, une fois encore, cet adaptateur ne fait que mettre les broches du SSD M.2 au bon endroit sur le port PCIe, rien de plus ni rien de moins.

Des adaptateurs pour 2 ou 4 SSD existent, attention à la bifurcation !

Si vous avez des SSD à brancher sur votre ordinateur et plus (ou pas) d’emplacement M.2 disponible, alors ce genre d’adaptateur est fait pour vous, à condition d’avoir au moins un port PCIe x4 de libre. Nous n’avons testé qu’un seul modèle, mais il existe des dizaines de déclinaisons, avec un ou plusieurs emplacements M.2.

Sur les adaptateurs avec quatre emplacements, vous verrez parfois une mention du type : nécessite la fonction de bifurcation. Cette technique permet de diviser un port x16 en deux ports x8 ou en quatre ports x4. C’est nécessaire pour utiliser quatre SSD M.2 sur une même carte. Nous en avions déjà parlé il y a plusieurs années.

• SSD PCIe et bifurcation x4/x4/x4/x4 : quelle plateforme pour y passer sans se ruiner ?

Même encore aujourd’hui, mieux vaut vérifier ce qu’il en est sur le manuel de votre carte mère. Première chose, bien différencier le format du connecteur PCIe et son câblage. Un emplacement x16 peut ne proposer que du x4 ou x8, cela peut même varier en fonction du CPU (qui peut proposer plus ou moins de lignes PCIe).

Un exemple ? La X670-P-CSM avec un port PCIe x16 en x16 et deux autres ports PCIe x16 en… x4. Ne comptez donc pas y installer plus d’un SSD M.2. Asus propose aussi une page dédiée à la bifurcation et aux différentes possibilités… vous allez voir que c’est plus complexe qu’il n’y parait.

Je vais passer au Wi-Fi filaire, ça sera plus simple !

Les points d’accès Wi-Fi proposent souvent la possibilité de créer plusieurs réseaux pour séparer les utilisateurs et gérer les accès. Problème, des chercheurs montrent que cette isolation peut facilement voler en éclats, via trois méthodes. Ils ont testé 11 routeurs, 11 étaient vulnérables. Certains auraient corrigé le tir, d’autres ne le pourraient pas.

Lors du Network and Distributed System Security (NDSS) Symposium qui se tient du 23 au 27 février à San Diego, des chercheurs de l’université de Californie à Riverside et de la Katholieke Universiteit de Louvain (Belgique) ont présenté leurs travaux baptisés « AirSnitch : démystifier et briser l’isolement des clients dans les réseaux Wi-Fi ». Un papier technique a aussi été mis en ligne (.pdf).

Attention, on parle bien ici de l’isolation des utilisateurs sur un même point d’accès, pas de casser le chiffrement du Wi-Fi. Si le WEP est depuis longtemps obsolète, WPA2 AES (pas en version TKIP, cassé avec KRACK) et WPA3 tiennent encore. Rien ne change avec AirSnitch, les chercheurs ne s’attaquent absolument pas au chiffrement des données, qui reste intact.

• Chiffrement et sécurité dans tous leurs états, du WEP à la distribution quantique de clés

Wi-Fi invité : faites comme chez vous… heu wait !!

Pour être mises en œuvre, les attaques décrites dans leur papier nécessitent que l’utilisateur puisse se connecter à la borne Wi-Fi, que ce soit sur le même SSID ou un autre, du moment que le point d’accès est le même. Mais c’est aussi plus large, suivant les configurations.

Les chercheurs ajoutent en effet que des attaques sont également possibles entre plusieurs points d’accès, « mais aussi réalisables dans les réseaux d’entreprise et de campus où plusieurs points d’accès sont connectés sur un même réseau filaire ». Une solution pour limiter les dégâts est de mettre en place des VLAN, à condition de bien le faire évidemment.

Pour le grand public et certaines petites entreprises, les risques peuvent donc être importants si vous avez, par exemple, un réseau « invité » largement accessible.

Des protections sont en théorie en place depuis longtemps : « Pour empêcher les clients Wi-Fi malveillants d’attaquer d’autres clients sur le même réseau, les fournisseurs ont introduit l’isolation des clients, une combinaison de mécanismes bloquant la communication directe entre les clients. Cependant, l’isolation des clients n’est pas une fonctionnalité standardisée, ce qui rend ses garanties de sécurité incertaines », expliquent les chercheurs en guise d’introduction.

AirSnitch : trois vecteurs d’attaques

Ils ont identifié trois principaux vecteurs permettant de casser l’isolation. La première vient « des clés Wi-Fi protégeant les trames de diffusion qui sont mal gérées et peuvent être détournées ». Il s’agit des clés GTK (Group Temporal Key) qui sont les mêmes pour tous les clients sur un même réseau.

Autre faiblesse : « l’isolation est souvent appliquée uniquement au niveau MAC ou IP, mais rarement aux deux ». Enfin, la dernière est la conséquence d’une « faible synchronisation de l’identité d’un client à travers toute la pile réseau », permettant d’usurper son identité sur la partie la plus faible du réseau pour ensuite la garder et capter le trafic.

Les chercheurs détaillent les risques qu’ils ont identifiés. Un attaquant pourrait accéder aux paquets IP, ce qui pourrait faciliter certaines attaques car « aujourd’hui encore, 6 % et 20 % des pages chargées sous Windows et Linux, respectivement, n’utilisent pas HTTPS […] Nos attaques permettent également l’interception de sites web ou de services intranet locaux, plus susceptibles d’utiliser des connexions en clair ». Et même si HTTPS est utilisé (les données ne sont pas déchiffrées via les attaques), « les adresses IP utilisées sont toujours révélées, ce qui est souvent suffisant pour savoir quel site web est visité ».

Comme un « attaquant peut intercepter et exploiter tout trafic en clair de la victime […], il peut intercepter le trafic DNS et empoisonner le cache DNS du système d’exploitation de la victime. Il peut également modifier l’enregistrement DHCP et changer l’adresse de la passerelle et le serveur DNS utilisés par la victime. Ces attaques peuvent avoir un impact durable sur la victime, même après que l’attaquant a cessé d’être un intermédiaire ».

Netgear, D-Link, TP-Link, Ubiquiti… plus d’une dizaine de routeurs vulnérables

Onze routeurs ont été testés et tous ont été vulnérables à au moins une des attaques : Netgear Nighthawk X6 R8000, Tenda RX2 Pro, D-Link DIR-3040, TP-Link Archer AXE75, ASUS RT-AX57, DD-WRT v3.0-r44715, OpenWrt 24.10, Ubiquiti AmpliFi Alien Router, Ubiquiti AmpliFi Router HD, LANCOM LX-6500 et Cisco Catalyst 9130. Pour ceux qui voudraient tenter eux-mêmes l’expérience (et qui ont du matériel compatible), du code est disponible dans ce dépôt GitHub.

Les chercheurs détaillent une attaque de bout en bout sur un routeur Netgear R8000. Il est configuré avec quatre SSID, deux invités et deux de « confiance », chacun sur les 2,4 et 5 GHz. Le routeur est connecté à Internet via un câble réseau.

L’attaquant est sur le réseau invité et veut lancer une attaque de type « homme du milieu » (MitM), afin d’intercepter tout le trafic montant et descendant d’une victime sur le réseau de « confiance ». « L’attaquant commence donc par se connecter au SSID invité avec l’adresse MAC de la victime, mais sur une fréquence différente afin d’éviter toute déconnexion ». On vous épargne la partie technique (page 10 de ce document .pdf) pour arriver à la conclusion.

Les techniques mises en place « amènent le point d’accès à rediriger le trafic descendant de la victime vers le SSID invité. L’attaquant renvoie ensuite le trafic intercepté à la victime grâce à la technique de rebond de passerelle. De même, il intercepte le trafic montant en usurpant l’adresse MAC du point d’accès (c’est-à-dire le routeur passerelle) et le renvoie au serveur de la victime. L’attaque complète dure environ deux secondes. Pendant toute la durée de l’attaque, la victime regarde une vidéo YouTube en streaming sans subir de latence significative ».

Ars Technica s’est entretenu avec le premier chercheur de la publication, Xin’an Zhou. Nos confrères ont glané quelques informations sur les réactions des constructeurs de bornes et points d’accès : « Zhou a indiqué que certains fabricants de routeurs avaient déjà publié des mises à jour atténuant certaines attaques, et que d’autres étaient attendues. Il a toutefois précisé que certains fabricants lui avaient confié que certaines failles systémiques ne pouvaient être corrigées qu’en modifiant les puces sous-jacentes qu’ils achètent auprès des fabricants de semi-conducteurs ». Nos confrères n’entrent pas davantage dans les détails.

À la fin de leur publication, les chercheurs affirment avoir « signalé les vulnérabilités aux fournisseurs concernés, ainsi qu’à la Wi-Fi Alliance. La Wi-Fi Alliance a pris acte de leurs conclusions et ils attendent sa décision ».

Prudence sur les Wi-Fi publics et invités… comme toujours

Côté utilisateur, pas grand-chose à faire si ce n’est faire preuve de prudence. Il faut déjà se méfier des points d’accès publics, mais donc aussi de ceux plus confidentiels. Éviter aussi de donner accès à un Wi-Fi invité à n’importe qui (on espère que vous n‘avez pas attendu cette actualité…).

Une autre solution, les VPN : « Une partie de la menace peut être atténuée en utilisant des VPN, mais cette solution présente tous les inconvénients habituels. D’une part, les VPN sont réputés pour la fuite de métadonnées, des requêtes DNS et d’autres trafics utiles aux attaquants, ce qui limite la protection. Et d’autre part, trouver un fournisseur VPN réputé et digne de confiance s’est avéré historiquement difficile, même si la situation s’est améliorée récemment. En fin de compte, un VPN ne devrait pas être considéré comme plus qu’un simple pansement », explique Ars Technica.

Il n’est pas forcément nécessaire de passer par un tiers, si vous avez une Freebox avec Freebox OS, elle peut faire office de serveur VPN Wireguard, vous permettant ainsi d’utiliser votre connexion Internet en déplacement, de manière sécurisée. Vous pouvez également utiliser un VPS pour y installer un serveur VPN, nous aurons prochainement l’occasion d’en reparler. Surtout, soyez prudent face aux petits et gros mensonges des vendeurs de VPN.

• [Édito] Au pays des VPN menteurs…
• Le protocole VPN Wireguard disponible sur Freebox : comment ça marche ?

Comme le rapporte Videocardz, suite à la mise en ligne des pilotes 595.59 WHQL par NVIDIA, plusieurs utilisateurs remontent des soucis au niveau de la gestion des ventilateurs, principalement sur les cartes GeForce RTX 50 : « Les utilisateurs affirment que certains ventilateurs cessent de répondre, que les courbes personnalisées des ventilateurs sont ignorées, ou qu’un seul capteur apparaît dans des outils comme HWiNFO, GPU-Z et les utilitaires des fabricants », expliquent nos confrères.

Ce n’est pas tout. D’autres utilisateurs pointent du doigt « une baisse du boost après la mise à jour. Les utilisateurs rapportent des fréquences de pointe plus faibles et suggèrent que le pilote limite la tension GPU à environ 0,95 V », avec pour conséquence de limiter la fréquence sur certaines cartes. Les retours sont nombreux sur les forums de NVIDIA.

Dans la foulée de la mise en ligne, NVIDIA a retiré les pilotes et demande à ses utilisateurs qui rencontrent des soucis d’effectuer un retour en arrière sur la précédente version, comme indiqué dans une mise à jour des notes de version : « Nous avons découvert un bug dans les pilotes WHQL Game Ready et Studio 595.59 et avons temporairement supprimé les téléchargements pendant que notre équipe enquête. Pour les utilisateurs qui ont déjà installé ce pilote et rencontrent des problèmes de contrôle des ventilateurs, veuillez revenir à 591,86 WHQL ».

Les notes de version des 595.59 renvoient désormais vers une page vide.

Deux semaines après la mise en ligne de la première version bêta d’Android 17, Google remet le couvert. Plusieurs nouveautés sont mises en avant. Pour la partie interface et expérience utilisateurs, les « bulles » arrivent. Cette fonctionnalité, distincte de l’API des bulles de messagerie (arrivée avec Android 11), permet de passer une application en mode fenêtre.

« Les utilisateurs peuvent créer une bulle d’application sur leur téléphone, leur appareil pliable ou leur tablette en maintenant longuement enfoncée une icône d’application dans le lanceur ». Un exemple ci-dessous avec l’Agenda.

Le billet de blog associé propose plusieurs animations présentant le fonctionnement des nouvelles fonctionnalités. Pour les développeurs d’applications, de la documentation est disponible ici.

Passons ensuite à EyeDropper. C’est une API au niveau du système qui « permet à votre application de demander la couleur de n’importe quel pixel de l’écran sans nécessiter d’autorisations sensibles pour capturer l’écran ».

Plusieurs autres petits changements sont apportés sous le capot, notamment pour le sélecteur de contacts qui permet d’accorder des autorisations temporaires (au niveau de la session) en lecture aux seuls champs de données demandés par l’utilisateur, une meilleure prise en charge des pavés tactiles, etc.

Pour la connectivité inter-appareils, Google annonce « une nouvelle API Handoff permettant de spécifier l’état de l’application à reprendre sur un autre appareil, comme une tablette Android ». Sur la partie Ultra Wide Band, « UWB DL-TDOA qui permet aux applications d’utiliser UWB pour la navigation intérieure ».

Côté Wi-Fi, la fonctionnalité Proximity Detection de la Wi-Fi Alliance est prise en charge. « Cette technologie offre une fiabilité et une précision accrues par rapport aux spécifications de portée existantes basées sur le Wi-Fi Aware », qui permet aux appareils compatibles de communiquer directement entre eux.

Google continue de viser un rythme annuel pour la sortie majeure de son SDK (chaque deuxième trimestre), accompagné d’une mise à jour au quatrième trimestre. L’entreprise est confiante dans le calendrier : « Nous allons rapidement passer de cette bêta à notre jalon Platform Stability prévu pour mars », c’est le moment où les API seront figées pour permettre aux développeurs de s’adapter.

La compatibilité des smartphones est la même que précédemment : les Pixel de Google à partir des versions 6. Tous les détails se trouvent sur ce site dédié à Android 17.