Linux : une faille de sécurité en pressant 28 fois la même touche

Nicolas Furno |

Il y a des failles de sécurité qui se dénichent facilement et d’autres qui nécessitent beaucoup de hasard et probablement une bonne pincée de chance. C’est le cas de cette faille qui concerne la majorité des distributions Linux, puisqu’elle se trouve dans GRUB 2, le programme d’amorçage (ou bootloader) utilisé par défaut. Au démarrage, c’est ce logiciel qui lance le chargement de la distribution, ou qui donne le choix à l’utilisateur s’il a installé plusieurs distributions.

Photo Anne Swoboda (CC BY-SA 2.0)
Photo Anne Swoboda (CC BY-SA 2.0)

Des chercheurs en sécurité ont découvert qu’en appuyant 28 fois sur la touche d’effacement et de retour arrière (delete ou back space), on pouvait lancer le mode « rescue » et à partir de là, accéder aux données stockées dans l’ordinateur sans mot de passe. Après 28 (ni 27, ni 29) pressions, un terminal s’affiche et on peut exécuter du code. De quoi, par exemple, installer un logiciel malveillant dans la distribution et rendre impossible sa désinstallation.

La faille est présente dans la dernière version de GRUB, mais elle n’est pas récente. Ces chercheurs ont réussi à l’exploiter avec une version sortie en 2009 et peut-être qu’elle a déjà été exploitée. Les risques sont néanmoins minimes, puisqu’il faut un accès physique à la machine.

Quoi qu’il en soit, si vous utilisez un ordinateur avec Linux et que GRUB est installé, la correction est d’ores et déjà disponible pour Ubuntu, Debian et Red Hat. Une mise à jour devrait être proposée rapidement pour ces distributions et probablement toutes celles qui utilisent le programme.

avatar CM-S | 

Linux c'est so 2006

avatar occam | 

Comme Google. Comme IBM. Comme Amazon Elastic Cloud. Comme…

avatar oomu | 

Les machines de Turing c'est ringard, jetez les.

avatar Hercule Poirot | 

Et le binaire aussi, so old.

avatar MacTHEgenius | 

@Hercule Poirot :
Le code, c'est trop "mainstream". Vive le binaire

avatar heret | 

Il s'agit de GRUB, pas de Linux. S'il y a un multiple boot on aurait aussi bien pu accéder à Windows.
De plus, pour appuyer 28 fois sur une touche, il faut avoir un accès physique à la machine. Pour ça, soit on en est son propriétaire, soit une autre faille de sécurité concernant l'accès physique aux locaux a été exploitée auparavant.

New racoleuse pour générer des revenus publicitaires. Macg est tombé bien bas...

avatar BeePotato | 

@ heret : « De plus, pour appuyer 28 fois sur une touche, il faut avoir un accès physique à la machine. Pour ça, soit on en est son propriétaire, soit une autre faille de sécurité concernant l'accès physique aux locaux a été exploitée auparavant. »

Ou alors, on est quelqu’un qui a légitimement le droit de se trouver devant la machine, sans pour autant avoir le droit de faire n’importe quoi dessus. Un employé, un étudiant, un invité… les cas sont nombreux.
C’est dingue comme la vie peut proposer une multitude de situations plus complexes que les quelques cas basiques auxquels tu aimes bien tout ramener, hein ? :-)

Et au fait, ça avance ta découverte des implémentations par défaut dans les protocoles en Swift ? ;-)

avatar aldomoco | 

28 fois la même touche pour comprendre qu'il faut effacer, c'est le plus rapide de la famille lui !

avatar C1rc3@0rc | 

Ben si tu regardes le code C qui est a l'origine du bug tu te rends compte qu'il s'agit de l'utilisation d'une des spécificités de ce langage qui est a l'origine d'innombrables bugs du meme genre.

On est la typiquement face a une erreur de programmation du et encouragée par le C.
Typiquement les failles liees a une "buffer underflow" ou "buffer overflow" sont tres faciles a eviter lors de l'ecriture du programme mais sont tres difficiles a trouver apres, et leurs ravages sont considerables.
Bref si le C peut etre considere comme un langage pertinent pour ecrire des parties d'un OS, il faut encore prendre garde a eviter les mauvaises pratiques nombreuses que ce langage favorise...
Apres avoir passé des annees a laisser ce dangereux langage comme seul moyen d'ecrire des applications, Apple revient a un peu plus de serieux et de securite en proposant maintenant Swift

avatar robrob | 

@C1rc3@0rc
A t'ecouter on se demande comment OS X et iOS arrivent a tenir debout.
Plus qu'a attendre qu'ils soient entierement reprogrammes en Swift pour boucher toutes les failles actuelles.

avatar oomu | 

"A t'ecouter on se demande comment OS X et iOS arrivent a tenir debout."

ils arrivent à tenir debout après un titanesque travail.

iOS et Os X repose sur un noyau dont le développement à commencé en 1984 (8-4, 7 ans après Star Wars) dans une université américaine

qui fut repris (entre autre) par NeXT puis continué dans Apple.

Tout un pan de Os X et IOS repose sur le projet Freebsd (entre autre). Freebsd a 22 ans de développement (mais dans le détail, faut plutôt parler de la partie userland et autre libC)

Le runtime Objective C a servi pour divers pan du système, avec C et C++

Cocoa lui même a de la bouteille derrière lui (Openstep, etc) et effectivement Objective C a aidé à compenser les problèmes inhérents de C pour les applications de hauts niveaux (mieux vaut se plaindre d'un objet mal utilisé que d'exploser)

BREF ! si on survit aux manques de protections de C (mais par contre, on est proche du fonctionnement de la machine) c'est suite à beaucoup DE boulot par beaucoup de gens. oui.

-
après, dire "Apres avoir passé des années à laisser ce dangereux langage comme seul moyen d'ecrire des applications" est exagéré et sensationnaliste.

Non seulement Os X propose Objective-C (qui est effectivement une extension de C) depuis le début mais C a ses avantages (portabilité, performance).

Objective-C permet de ne pas se reposer sur des tableaux C, d'utiliser des mécanismes modernes, dynamiques etc. La situation n'était donc pas "dangereuse".

Swift est une continuité des progrès fait en langage depuis la programmation orientée objet.

-
Dans le fond, on en revient au fait que Grub en tant que programme utilisateur n'aurait pas du être écrit en C. Mais quand on boote une machine, on a pas tout le loisir souhaité. Grub est ancien. D'un temps avant les PC avec les EFI super girly hype de maintenant.

-
Sans cryptage du disque (et une passphrase conséquente) de toute façon, le mot de passe grub ne protégeait pas d'une personne motivée.

avatar C1rc3@0rc | 

Je me suis peut etre mal exprime.
Le C est un langage éminemment dangereux dans les mains d'un ingenieur systeme sous pression et plus encore dans celles d'une personne mal formée (voire pas formée comme le sont beaucoup de gens qui écrivent de l'applicatif)

Objective-C est un magnifique langage qui reprend beaucoup d'avancées de Smalltalk et de Simula mais souffre toujours des incoherences du C.

Il y a eu des tentatives de securisation du C avec notamment C++ (dont le sous ensemble non objet repris d'ADA). Mais c'est comme soigner une jambe brisée en mettant juste un bandage. Qui va s'enquiquiner avec la genericite et les templates alors qu'un tableau de pointeurs C semble faire pareil en une seule ligne...

ADA permet de faire du bas niveau, comme Pascal ou Eiffel et Lisp d'une autre maniere. Et dans les cas critiques on peut faire des appels a des procedures ecrites en assembleur. Donc la justification de l'arithmétique sur les pointeurs comme necessaire pour du soft système c'est du flan.

La ou les choses sont dangereuses avec Objective-C c'est que c'etait le seul langage pour faire de l'applicatif. Si on programme majoritairement avec des appels a la librairie Cocoa et que l'on utilise les classes NS pour la gestions des donnees, il n'en demeure pas moins que l'on peut utiliser n'importe quand des tableaux C et de l'arithmétique de pointeur (ce qu'est d'ailleurs un tableau C). De plus n'importe quel langage (a commencer par Python ou Ruby) peut servir de liant pour assembler des appels d'une librairie: il suffit de disposer d'une API adaptee.

Le fait est qu'en C on peut faire n'importe quoi, on peut programmer en imperatif ou en fonctionnel et meme en pseudo objet. Pour ma part j'ai souvent ecrit des soft en style fonctionnel en Pascal avec des structures similaires a celle du Lisp. J'ai aussi ecrit des pans entier de soft en C avec des pointeurs sur des procedures et des switch... bref des qu'on depasse le niveau du Basic on peut tout faire.

avatar robrob | 

@C1rc3@0rc
"Qui va s'enquiquiner avec la genericite et les templates alors qu'un tableau de pointeurs C semble faire pareil en une seule ligne..."
Desole mais ce genre de phrase montre que tu ne sais pas vraiment de quoi tu parles. En outre c'est totalement oppose a ce que tu essayes de demontrer sur la dangerosite du C. Les templates permettent d'avoir du code optimise resolu au moment de la compilation et safe.
Si tu arrives a faire la meme chose avec un tableau de pointeur, bravo.

Et si tu ne vois pas l'interet de l'utilisation des pointeurs en optimisation c'est que tu n'as probablement pas besoin de ce type d'optimisation. C'est pas grave hein, j'ai fait des applis OS X sans avoir a utiliser de vrai pointeur et d'autres ou j'ai eu besoin d'optimisation pour traiter des images et les pointeurs etaient la seule maniere d'obtenir cette performance.
Chaque outil est adapte a des besoins specifiques.

avatar Philactere | 

@robrob :
Techniquement je ne comprend rien au débat, n'étant pas informaticien :-)

Par contre dans la phrase de C1rc3@0rc "Qui va s'enquiquiner avec la genericite et les templates alors qu'un tableau de pointeurs C semble faire pareil en une seule ligne..." Il y a justement le mot "semble" qui indique que C1rc3@0rc sait très bien que les tableaux de pointeurs n'ont pas la même utilité que les templates.
Le "semble" dans cette phrase s'adresse "aux autres" (qui) et souligne ironiquement que si pour beaucoup de monde il ne "semble" pas y avoir de différence entre ces deux techniques, lui-même la connaît très bien et n'utilise pas de tableaux de pointeurs là où il est plus indiqué d'utiliser la genericite et les templates.

Voilà, désolé si je suis à côté de la plaque si je n'ai rien compris techniquement, mais l'ironie de cette phrase rend tout à fait cohérent le commentaire de C1rc3@0rc.

avatar Sometime | 

@Philactere :
J'aimerais bien cependant qu'on l'on me précise à quoi il pense quand il utilise ce "semble" entre template et tableaux de pointeurs...

avatar BeePotato | 

@ C1rc3@0rc : « La ou les choses sont dangereuses avec Objective-C c'est que c'etait le seul langage pour faire de l’applicatif. »

Ben non, en fait.

avatar marc_os | 

@C1rc3@0rc :
C'est quoi les incohérences de C ?
Tu peux donner des exemples stp ?

avatar robrob | 

@oomu
En tant que dev C et C++ depuis tres longtemps je pouvais me passer de la lecon d'histoire avec un petit ton condescendant.
Oui le C demande de faire attention mais il ne faut pas non plus faire croire que ca demande un travail de dingue pour faire du bon code C, sauf pour les devs qui n'ont jamais touche qu'a du haut niveau.
Et non je ne pense pas que le C soit le langage ideal pour tout non plus.

avatar ever1 | 

Parce que évidemment, bien que swift est ultra jeune, il est ultra mature et inviolable. Une oeuvre de perfection...

avatar oomu | 

Tout bô, tout neuf :)

avatar C1rc3@0rc | 

Swift a des défauts mais il offre une certaine sécurité qui fait cruelement defaut a C et ses derivés.

Le plus important c'est qu'il offre des mécanismes sécurisés qui sont accessibles meme au tout debutant. C lui favorise des pratiques qui sont éminemment dangereuses sauf entre les mains d'un expert qui a le luxe de prendre son temps pour écrire du code robuste.

Sachant que la majorite des gens qui vont ecrire des app pour iOS ou pour Mac OS X sont sous pression (temps) et sont rarement des experts dans la sécurité du logiciels, Swift est une avancee majeure. Ca veut pas dire qu'il n'y a pas d'autres langages aussi bons, ou meme meilleurs (perso je suis un adepte d'Ada d'Eiffel et d'Haskell et j'ai une grande curiosité pour OCaML), mais Apple impose un diktat quant aux possibilités de l'outil de developpement, dont acte.

avatar Gueven | 

@C1rc3@0rc :
C'est quoi le rapport entre le buffer overflow et le C ?
Tous les langages de bas niveau ont leurs avantages et inconvénients. Pour un boot loader je te défie d'utiliser un langage au niveau qui aura besoin d'une mmu, d'un système allocation dynamique, ... et qui ne pourra pas adresser la mémoire physique directement.

avatar C1rc3@0rc | 

Regardes le code responsable du bug: typique du C!

avatar robrob | 

@C1rc3@0rc
Ou de l'assembleur. Ou de n'importe quel systeme qui n'ajoute pas de controle supplementaire a ce qu'on lui demande.
Le C est un outil puissant qui fait exactement ce que tu lui demandes et pas plus.
Si tu veux optimiser en Swift il faut que tu coupes les controles et tu te retrouves dans la meme situation.

avatar marc_os | 

@C1rc3@0rc :
Éclaires nous stp.

Pages

CONNEXION UTILISATEUR