Il y a déjà deux mois qu’un groupe de hackers baptisé Fail0verflow a publié une vidéo d’une Nintendo Switch en train de faire tourner Linux. Mis à part la brève mention de la boot ROM (la mémoire de démarrage) dans ces développements, rien de vraiment croustillant n’avait vraiment filtré, mais des détails commencent à être publiés.Dans une FAQ parue le 4 avril dernier, la team ReSwitched balise le chemin vers la compréhension de la vulnérabilité – baptisée « Fusée Gelée » – avant d’enchaîner il y a peu avec la publication d’un dépôt GitHub plutôt détaillé. La faille au sein de la Nintendo Switch réside bel et bien dans sa mémoire de démarrage. En substance, c’est la pile logicielle USB contenue dans la boot ROM qui est le talon d’Achille de la console. ReSwitched a publié une portion de la fonction rcm_read_command_and_payload en cause ; celle qui permet à la Switch de gérer les requêtes de contrôle émises par un hôte au travers du port USB.
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 | // Temporary, automatic variables, located on the stack.
uint16_t status;
void *data_to_tx;
// The amount of data available to transmit.
uint16_t size_to_tx = 0;
// The amount of data the USB host requested.
uint16_t length_read = setup_packet.length;
/* Lots of handler cases have omitted for brevity. */
// Handle GET_STATUS requests.
if (setup_packet.request == REQUEST_GET_STATUS)
{
// If this is asking for the DEVICE's status, respond accordingly.
if(setup_packet.recipient == RECIPIENT_DEVICE) {
status = get_usb_device_status();
size_to_tx = sizeof(status);
}
// Otherwise, respond with the ENDPOINT status.
else if (setup_packet.recipient == RECIPIENT_ENDPOINT){
status = get_usb_endpoint_status(setup_packet.index);
size_to_tx = length_read; // <-- This is a critical error!
}
else {
/* ... */
}
// Send the status value, which we'll copy from the stack variable 'status'.
data_to_tx = &status;
}
// Copy the data we have into our DMA buffer for transmission.
// For a GET_STATUS request, this copies data from the stack into our DMA buffer.
memcpy(dma_buffer, data_to_tx, size_to_tx);
// If the host requested less data than we have, only send the amount requested.
// This effectively selects min(size_to_tx, length_read).
if (length_read < size_to_tx) {
size_to_tx = length_read;
}
// Transmit the response we've constructed back to the host.
respond_to_control_request(dma_buffer, length_to_send); |
Le souci avec cette dernière est qu’un attaquant a la possibilité de manipuler l’entier non signé length_read à sa guise au travers d’un paquet émis par un hôte connecté à la console. La suite ne se comprend mieux qu’avec la cartographie mémoire de la boot ROM d’un SoC Tegra 210 de Nvidia. Le contrôle de la variable length_read permet à l’attaquant de provoquer un dépassement de tampon dma qui se répercute sur la pile d’exécution de la boot ROM. Si l’on ajoute que dans le Recovery Mode (RCM) – prévu par Nintendo pour l’installation d’images en usine ou la récupération de consoles défectueuses –, les données chargées dans les tampons dma proviennent d’une zone mémoire contrôlée par l’attaquant, alors on éclaire un gros pan de l’obscurité qu’il y avait autour du procédé employé par Fail0verflow pour parvenir à lancer Linux sur la console. Le passage en mode RCM permet donc d’exécuter du code non signé par Nvidia.
Pour ne pas laisser à ReSwitched toute la gloire liée à la publication de ces détails, Fail0verflow a également posté des détails sur l’exploitation de la vulnérabilité, notamment, sur la façon d’accéder au Recovery Mode à l’aide d’un tweak matériel. Dans leurs notes d’information, Fail0verflow et ReSwitched indiquent qu’il suffit de provoquer un court-circuit entre certaines broches du connecteur USB. Fail0verflow a publié des images d’un gadget de sa conception qui permet de réaliser l’opération.
De façon brossée, l’exploitation de la faille requiert donc de réaliser cette adaptation matérielle puis de se connecter à la console au travers du port USB pour charger le code nécessaire ; pas simple pour un néophyte. La vulnérabilité est toutefois fâcheuse pour Nintendo, car le géant du gaming japonais ne peut la corriger en diffusant un correctif logiciel comme on en a l’habitude. Le seul moyen pour l’entreprise de rectifier le tir est de programmer de nouvelles ROM pour les prochaines consoles qui sortiront de ses laboratoires – tâche qui se fera en tandem avec Nvidia qui est le fournisseur des systèmes sur puce que la console utilise ; bienheureux donc les bidouilleurs qui possèdent déjà une Switch puisque la faille demeure exploitable dans leur cas, et ce, à jamais.
Sources
Dépôt GitHub de « Fusée Gelée »
Fail0verflow
Et vous ?
Qu’en pensez-vous ? Ces détails vous donnent-ils envie d’acquérir une Switch pour reproduire la manœuvre ? Si oui, pour quel usage particulier envisagez-vous de le faire ?Voir aussi
Plus de 10 millions de Nintendo Switch écoulées en l'espace de neuf mois, la Switch rencontrera-t-elle le succès de la PS4 ou de la Wii ? Gaming : un émulateur Nintendo Switch en cours de développement, Yuzu sera disponible sur Windows, macOS et Linux Les développeurs d'un émulateur WiiU reçoivent 24 000 dollars par mois pour leur travail, leur Patreon grimpe depuis la sortie de Zelda 
Envoyé par Ryu2000
