Grub2 : la demande de mot de passe peut être court-circuitée par la touche retour arrière

Grub2 : la demande de mot de passe peut être court-circuitée par la touche retour arrière

28 frappes plus tard

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

21/12/2015 5 minutes
78

Grub2 : la demande de mot de passe peut être court-circuitée par la touche retour arrière

Grub2, utilisé par un grand nombre de distributions Linux, est victime d’un bug ouvrant la voie à une importante faille de sécurité : si un utilisateur appuie précisément 28 fois sur la touche retour arrière, il peut passer outre la protection par mot de passe. Le problème a été découvert par deux chercheurs espagnols, qui proposent déjà un patch correctif.

Grub2 est un bootloader, un gestionnaire de démarrage que l’on retrouve dans un grand nombre de distributions Linux. Il sert à initialiser la machine et peut prendre notamment en charge les menus multiboot, permettant de choisir le système d’exploitation que l’on veut lancer. Il est particulièrement connu comme solution autorisant par exemple une machine à pouvoir démarrer sur Windows ou Linux. Il peut par ailleurs ajouter une couche de protection à la machine en réclamant un mot de passe, en plus de celui que l’on attribue d’ordinaire à la session Linux.

Une faille introduite dans le code de Grub2 il y a six ans

Deux chercheurs de l’université de Valence (Espagne) ont cependant trouvé une erreur pour le moins très étrange dans le gestionnaire de boot : il suffit d’appuyer 28 fois sur la touche retour arrière pour passer outre la demande de mot de passe. Le chiffre est précis, et l’utilisateur obtient en fait l’accès à la console « Grub rescue shell ». Une vulnérabilité testée avec succès sur les versions 1.98 à 2.02 de Grub2.

Les deux chercheurs espagnols ont d’ailleurs pu remonter jusqu’à la source du problème : un « commit » (validation de code) qui a eu lieu dans la version 1.98, soit en décembre 2009. Le plus impressionnant finalement dans la découverte de cette vulnérabilité est qu’elle soit restée totalement inconnue pendant presque six ans, malgré la simplicité extrême de sa mise en oeuvre.

Un bug arithmétique

Le souci réside dans la gestion du nombre entier correspondant à une variable dans le code de Grub2 (integer underflow), et qui se retrouve déclenchée à la 28e itération. Tous les détails techniques sont expliqués par les chercheurs sur leur blog.

Une fois la faille exploitée, l’accès à la console de récupération de Grub2 permet d’effectuer un certain nombre d’opérations. Un utilisateur malintentionné pourrait s’en servir pour accéder aux données locales, les copier, voire les supprimer. La console permet également de démarrer sur un autre environnement, et laisse donc de larges possibilités en cas de piratage de la machine, y compris l’installation d’un malware.

Signalons tout de même que la récupération des données se fait de manière brute. Si le possesseur de la machine a décidé de les chiffrer, les fichiers ne pourront évidemment pas être lus. Par ailleurs, court-circuiter Grub2 ne permet pas pour autant de s'authentifier sur le ou les systèmes d'exploitation présents sur la machine.

Les chercheurs ont averti dans la foulée l’ensemble des parties concernées. De nombreuses distributions Linux ont publié des patchs correctifs en fin de semaine dernière, notamment Ubuntu, Red Hat et Debian. Comme toujours dans ce genre de cas, les utilisateurs concernés devront vérifier dans les dépôts de leurs distributions si des mises à jour sont à effectuer.

Faille GRUB2

La sécurité physique est aussi importante que les autres

En tant que telle, la faille est impressionnante par la facilité de sa mise en oeuvre et l’exploitation conséquente qui peut en être faite. Cependant, on soulignera deux points importants qui relativisent sa dangerosité. D’une part, elle ne semble pas avoir été découverte précédemment, bien qu’elle ait pu être trouvée et tenue secrète par un groupe de pirates ou n’importe quelle agence de renseignement, toujours friande de ce type d’informations comme l’ont montré les documents d’Edward Swowden.

D’autre part, cette brèche de sécurité réclame obligatoirement un accès physique à la machine, interdisant de fait son exploitation à distance. Elle ne peut donc pas être considérée comme critique, d’autant que sa mise en oeuvre ne peut pas être automatisée. C'est d'ailleurs également la conclusion du National Institute of Standards and Technology (NIST) qui qualifie la dangerosité de cette brèche de « medium » avec un score de 6,9/10. L'impact sur la machine est de 10/10, mais son exploitation bien plus compliquée ne lui vaut que 3,9/10.

Cela étant, cette vulnérabilité a le mérite de rappeler justement que la sécurité sur le réseau n’est pas la seule à prendre en compte. Une menace réclamant un accès physique n’est pas une menace nulle, comme Stuxnet l’a montré avec les machines déconnectées d’un réseau ou d’Internet. De fait, les possibles interactions de l’utilisateur avec la machine doivent être prises en compte, car ce type de bug peut mener efficacement à une fuite d’informations.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une faille introduite dans le code de Grub2 il y a six ans

Un bug arithmétique

La sécurité physique est aussi importante que les autres

Commentaires (78)


Toujours tout chiffrer, TOUT <img data-src=" />


Ce genre de faille me fait penser au underhanded C contest. Le but du concours est de faire du code qui semble le plus normal possible, qui peut passer une code review ou un audit sans souci, mais qui en plus de faire ce qu’il est supposé a un comportement secret.

Exemple de 2014 : faire une messagerie façon twitter ou SMS, mais qui fait discrètement fuiter les messages qui correspondent à certains critères ou permet de les modifier.


Faille introduite il y a 6 ans.



Les barbus c’est plus ce que c’était <img data-src=" />


“sur un autre environnement, et laisse donc de larges possibilités en cas

de piratage de la machine, y compris l’installation d’un malware”

Euh, pourquoi y aurait-il besoin d’un autre environnement pour faire ça ?



Bon sinon, ça montre qu’on sait aussi être ridicules chez linux, c’est pas réservé aux autres (et c’est un fan de OpenSUSE qui le dit).


J’ai fait un dnf update de ma Fedora, RAS point de vue mise à jour.



Je suis toujours en Grub 2.02…



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />


C’est pas vraiment clair, est-ce que ça permet juste de contourner le mot de passe de Grub, c’est à dire un truc que personne n’utilise et dont on ignorait l’existence ? Ou est-ce que ça donne un accès root au système ?



EDIT: apparemment c’est le mot de passe Grub. Truc que personne n’utilise, voilà pourquoi il a fallu 6 ans avant de s’en rendre compte. C’est pas vraiment un exploit de fou dans le sens où booter sur un LiveCD ou une clé USB permet aussi de contourner grub.








Obidoub a écrit :



C’est pas vraiment clair, est-ce que ça permet juste de contourner le mot de passe de Grub, c’est à dire un truc que personne n’utilise et dont on ignorait l’existence ? Ou est-ce que ça donne un accès root au système ?



EDIT: apparemment c’est le mot de passe Grub. Truc que personne n’utilise, voilà pourquoi il a fallu 6 ans avant de s’en rendre compte. C’est pas vraiment un exploit de fou dans le sens où booter sur un LiveCD ou une clé USB permet aussi de contourner grub.





C’est exactement ca. Je savais même pas que ce mot de passe existait, et je ne vois pas ni à quoi il sert ni ce que les utilisateurs en attendaient car c’est forcément facilement contournable.



En terme de sécurité, les seules options sérieuses qu’on ait:




  • mot de passe bios

  • mot de passe de session avec chiffrement des données utilisateurs



    Bon après une faille reste une faille, et il faut la patcher. Mais en tant que tel, le bon patch à mon sens serait d’enlever cette feature.





Le plus impressionnant finalement dans la découverte de cette vulnérabilité est qu’elle soit restée totalement inconnue pendant presque six ans, malgré la simplicité extrême de sa mise en oeuvre.





Au contraire, cela n’est pas du tout étonnant.



Ce n’est pas parce que cela parait simple une fois expliqué que pour autant cela saute aux yeux à la lecture du code.



Et un utilisateurs qui appuie 28 fois sur la touche backspace au démarrage de sa machine, cela doit quand même être assez rare (heureusement…).



Pour le reste, je suis très étonné qu’on parle seulement d’une faille aussi insignifiante sur une fonctionnalité aussi peu utilisée : je n’ai encore jamais vu quelqu’un mettre un mot de passe au niveau du grub.

Et de toute façon, quand on à l’accès physique à une machine, il y a bien plus dangereux et plus simple…



Celui qui veut sécuriser ses machines par rapport a l’accès physique, il activera plutôt le chiffrement sur son disque dur.



Oui je me pose du coup la question. A quoi sert cette fonctionnalité au final ?


Je pense que l’intérêt d’une telle fonctionnalité serait entre autre bloquer un PC pour démarrer sur une configuration précise pour une borne par exemple.

Sur certaines distributions il était aussi possible de lancer le debug mode qui se lançait avec les droits root. Je ne sais pas si ça existe encore.


À introduire ce genre de bogue, en vertu d’un corollaire de la loi de Murphy <img data-src=" />


C’est sûr que vu comme ça.



En tout cas, il y a plus intéressant aujourd’hui : sortie de Wine 1.8.


Ca permet de pouvoir démarrer un système Linux en mode single-user, donc possiblement se retrouver authentifié en root sans demander de mot de passe si ce mode n’a pas été protégé.



Ca reste donc un peu embêtant même s’il y a plusieurs façons de l’éviter. En même temps le démarrage d’une machine à laquelle on a un accès physique ne peut jamais être vraiment sécurisé, et certainement pas par une seule mesure.


Sur les vieux systèmes du moins.


Protéger Grub permet d’éviter cette fonctionnalité de grubhttp://www.symantec.com/connect/forums/recover-root-grub



Grilled



le boot sur root ?

meme sur un os recent tu peux passer outre le mot de passe root et booter sur une ligne de commande, changer le pwd root et rebooter en normal








seb2411 a écrit :



Oui je me pose du coup la question. A quoi sert cette fonctionnalité au final ?







C’était utile à l’époque où l’on ne pouvait pas chiffrer les partitions; ce qui paraît aujourd’hui désuet face à une telle possibilité.



Avec le chiffrement, le contournement est impossible, puisque seul la possession de la bonne clé permet de déchiffrer et donc d’accéder aux données.









zefling a écrit :



…En tout cas, il y a plus intéressant aujourd’hui : sortie de Wine 1.8.







  • 1 que du bon <img data-src=" />



Du coup, des solutions comme Sophos SafeGuard sont d’autant plus utiles.


Depuis que j’ai quitté les études (15 ans), je n’ai pas vu une machine avec mot de passe sur le bootloader (ou le bios).








Commentaire_supprime a écrit :



J’ai fait un dnf update de ma Fedora, RAS point de vue mise à jour.



Je suis toujours en Grub 2.02…



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />





bah, forcément, avec dnf, tu vas attendre encore longtemps avant que ça sorte. <img data-src=" />









damaki a écrit :



Ce genre de faille me fait penser au underhanded C contest. Le but du concours est de faire du code qui semble le plus normal possible, qui peut passer une code review ou un audit sans souci, mais qui en plus de faire ce qu’il est supposé a un comportement secret.







Ce n’est pas le cas ici. Le bug est du niveau d’un premier TP en informatique: ne pas avoir testé les limites hautes/basse pour l’indice du tableau.



En résumé:



if (key == BACKSPACE) pos–; else buffer[pos++]=key;



<img data-src=" />



Ptain ils rigolent pas chez toi, moi mon premier TP c’était afficher un titre en html !&nbsp;<img data-src=" />










zefling a écrit :



C’est sûr que vu comme ça.



En tout cas, il y a plus intéressant aujourd’hui : sortie de Wine 1.8.







Ah ben tiens, mon Anyrail qui ne veut rien savoir avec Wine (quand le logiciel se lance, la fenêtre correspondante s’ouvre et se referme aussitôt) va peut-être enfin fonctionner… A suivre !



syslinux FTW. <img data-src=" />


je serais très étonné que dans les premiers TP de programmation en C on n’apprenne pas a remplir un tableau… et donc qu’on n’évoque pas le problème des limites basse/haute de l’indice.








damaki a écrit :



Ce genre de faille me fait penser au underhanded C contest. Le but du concours est de faire du code qui semble le plus normal possible, qui peut passer une code review ou un audit sans souci, mais qui en plus de faire ce qu’il est supposé a un comportement secret.

Exemple de 2014 : faire une messagerie façon twitter ou SMS, mais qui fait discrètement fuiter les messages qui correspondent à certains critères ou permet de les modifier.





Super site, je ne connaissait pas ! :)









psn00ps a écrit :



Sur les vieux systèmes du moins.





C’est pas une question de récent ou non, mais certainement qu’il y a plus de distributions (mais certainement pas toutes) qui ajoutent une protection de cet accès maintenant qu’auparavant.



Cependant “par défaut” il est toujours actuellement non protégé, parce qu’il nécessite un accès physique et qu’il faut d’autres mesures que ça pour protéger l’accès en tant que root. Sinon un boot sur un Linux sur CD ou USB suivi d’un chroot donne le même résultat.



Étonnant que personne ne soit encore passé ici en mode revanchard: “ahah! Et on vient nous dire que Linux est plus sécurisé parce que le code peut être lu afin de vérifier.”

6 ans la faille, ça fait assez long pour un système qui évolue constamment.








127.0.0.1 a écrit :



je serais très étonné que dans les premiers TP de programmation en C on n’apprenne pas a remplir un tableau… et donc qu’on n’évoque pas le problème des limites basse/haute de l’indice.





Un peu de réalisme. Tout premier TP correspond à faire un “Hello World” !



Ridicule! La première chose à apprendre aux enfants qui découvrent la programmation, c’est bel et bien le buffer overflow. C’est une question de priorité!








MuadJC a écrit :



Étonnant que personne ne soit encore passé ici en mode revanchard: “ahah! Et on vient nous dire que Linux est plus sécurisé parce que le code peut être lu afin de vérifier.”

6 ans la faille, ça fait assez long pour un système qui évolue constamment.







Un vrai troll revanchard envers les barbus intégristes ca serait plutot de reprendre leurs expressions dans un message du genre :



“Grub? c’est quoi? La meilleure façon de sécuriser Grub reste de formatter son PC et d’installer Windows”



Sur Fedora, un boot niveau S passe en mode maintenance et demande le mot de passe root. (systemd)


Sur un système sécurisé, le bios est verrouillé, pas de possibilité de changer la séquence de démarrage.

Si on craint le démontage, alors il y a le chiffrement.


Heureusement que le logiciel était Open Source. Comme çà il a été possible au plus grand nombre d’avoir accès au code, de faire des reviews dessus, et ainsi çà garanti qu’il n’y a aucune faille de sécurité ni backdoor… oh wait !


Au contraire, c’est exactement le cas ici, que le bug soit volontaire ou pas. Le code n’est pas spécialement suspect, a sans aucun doute passé moulte code reviews et en plus, les problèmes d’extrême, ça fait exactement partie d’une des classes de bugs les plus courantes : l’integer overflow. Et le clou du spectacle est que vu qu’il faut presser 28 fois retour arrière, c’est suffisamment obscur pour pas qu’on le déclenche involontairement.








hadoken a écrit :



Heureusement que le logiciel était Open Source. Comme çà il a été possible au plus grand nombre d’avoir accès au code, de faire des reviews dessus, et ainsi çà garanti qu’il n’y a aucune faille de sécurité ni backdoor… oh wait !







Bah, c’est bel et bien le cas. Ça a permis à des chercheurs n’ayant rien à voir avec l’équipe de développement du projet d’auditer le code, de déceler un problème et d’y apporter un correctif. Ça a juste pris un peu plus de temps que prévu.



Et tout irait bien plus vite si les millions d’entreprises de par le monde qui utilisent du logiciel libre pour leur activité contribuaient financièrement aux projets qu’ils utilisent, voir aux quelques grosses fondations qui gravitent autour (Linux Foundation, Free Software Foundation…)



Le bug est présent dés le premier appui sur backspace. C’est l’exploitation du Bug en faille de sécurité qui nécessite 28 appuis.



<img data-src=" />


On notera d’ailleurs que GNU GRUB est un projet de la Free Software Foundation, qui n’a qu’un budget ridicule tournant autour du million de dollars, alors qu’ils gèrent pourtant un paquet de projets particulièrement utilisés.



La FSF vient d’ailleurs de lancer une campagne de dons avec un objectif de 450K USD.



L’appel a également été traduit en français.


Un bug sur une fonctionnalité peu utilisée sur un OS peu utilisé, bref <img data-src=" />








MuadJC a écrit :



Étonnant que personne ne soit encore passé ici en mode revanchard: “ahah! Et on vient nous dire que Linux est plus sécurisé parce que le code peut être lu afin de vérifier.”

6 ans la faille, ça fait assez long pour un système qui évolue constamment.







Non, ça n’est pas long. Et aussi étonnant que cela paraisse au profane, cela n’a rien d’exceptionnel.



Pour que les non spécialistes comprennent, résumons les données du problème.



Un programmeur, même s’il est excellent produit un certain nombre de bugs et de failles pour 1000 lignes de code.



Connaissant le nombre de lignes de code d’un Os complet qui se compte en centaines de millions, on sait de manière statistique que même sur l’Os le plus sûr du marché, il y a potentiellement des dizaines de milliers de failles.



Le travail de relecture permet de trouver un nombre de failles. Et c’est en cela qu’un code ouvert aide beaucoup et sera toujours meilleur qu’un code fermé.



L’ennui, c’est qu’on cherche des aiguilles dans une gigantesque botte de foin. Quelque soient les efforts, il en restera toujours…



Le zéro faille est une utopie que personne ne peut atteindre.



Le problème, ce sont ces failles difficiles à déceler qui constituent des failles dormantes. Certaines peuvent parfaitement passer inaperçu pendant des décennies.



Conclusion, si vous voulez un Os sans failles, la seule vraie solution, c’est de débrancher votre ordinateur <img data-src=" />



Cette conclusion peut paraître effrayante pour le non spécialiste, elle est malheureusement vraie. Les ordinateurs ne sont pas sûrs.



Et le deuxième c’est “Hello {name}”… donc scanf() et la structure tableau (char[])



C’est pour ca que j’ai mis au pluriel: “les premiers TP”. <img data-src=" />


Il faut un chiffrage COMPLET de la machine, sans quoi ce n’est pas suffisant.



LE chiffrage du /home permet de protéger les données, mais toute personne avec un accès physique à la machine peut alors booter en mode console root, et y foutre un keylogger/trojan lancé en root ou what else et donc récupérer tout ce que tu as….



Bref la seule réelle solution c’est chiffrage complet du disque, et encore certains arrivaient bien à installer un trojan dans le firmware du disque dur…


Et on sait que toute argumentation qui commence par “on sait que” est statistiquement fausse.


edited








Okki a écrit :



Bah, c’est bel et bien le cas. Ça a permis à des chercheurs n’ayant rien à voir avec l’équipe de développement du projet d’auditer le code, de déceler un problème et d’y apporter un correctif. Ça a juste pris un peu plus de temps que prévu.







D’ailleurs, il est amusant de constater que certains fustigent Linux parce qu’on y trouve des failles.



Je leur laisse l’illusion de se croire en sécurité sur des Os sur lequel on n’en trouverait pas.



Mais je remarque que ces derniers temps, les failles de Linux sont beaucoup plus médiatisées que celles des autres Os. Ce n’était pas le cas auparavant.



Certes, dans le libre, la transparence a toujours été un état d’esprit.



Mais cela ne devrait pas aboutir à donner aux profanes des impressions trompeuses.


















Okki a écrit :



Bah, c’est bel et bien le cas. Ça a permis à des chercheurs n’ayant rien à voir avec l’équipe de développement du projet d’auditer le code, de déceler un problème et d’y apporter un correctif. Ça a juste pris un peu plus de temps que prévu.&nbsp;





Oh oui, trois fois rien. 6 ans.









sr17 a écrit :



D’ailleurs, il est amusant de constater que certains fustigent Linux parce qu’on y trouve des failles.



Je leur laisse l’illusion de se croire en sécurité sur des Os sur lequel on n’en trouverait pas.



Mais je remarque que ces derniers temps, les failles de Linux sont beaucoup plus médiatisées que celles des autres Os. Ce n’était pas le cas auparavant.



Certes, dans le libre, la transparence a toujours été un état d’esprit.



Mais cela ne devrait pas aboutir à donner aux profanes des impressions trompeuses.





Marrant d’inverser les situations. En près de 50 commentaires, je ne vois personne fustiger Linux parce qu’il y a une faille qui a été découverte. Personne n’a dit être en sécurité sur son OS en crachant sur Linux au passage.



Les seuls qui le font remarquer, c’est plutôt en fustigeant certains utilisateurs qui pensent qu’il n’y a pas de failles sur Linux et qui se déchainent sur les autres OS dés qu’un truc est mis à jour. D’où mon propos d’inversion : généralement, ce sont les trolls linux qui fustigent les autres OS en se croyant intouchables avec&nbsp;leur OS.

C’est un peu comme ceux qui disent qu’il n’y a pas de virus sur Mac..



Marrant les gens qui pensent qu’un bug de grub est un bug de Linux.

Certes on est dans des mondes fortement corrélés, mais au cours de mes divers emplois, j’ai:




  • Manipulé des PC sur lequel grub servait à choisir quelle version de Windows démarrer (exotique, j’en conviens)

  • Créé des configurations embarqués avec Linux mais qui démarraient sans grub. Ce ne sont pas les choix qui manquent en la matière (jusque «boot-straper maison»).








127.0.0.1 a écrit :



Ce n’est pas le cas ici. Le bug est du niveau d’un premier TP en informatique: ne pas avoir testé les limites hautes/basse pour l’indice du tableau.



En résumé:



if (key == BACKSPACE) pos–; else buffer[pos++]=key;



<img data-src=" />







En même temps, les débordement de tableau c’est le genre d’erreur très facile à faire en C.



Mais il n’y a pas de secret en programmation, soit tu utilises du boundcheck comme en pascal, Java ou C# et tu perds de la vitesse. Soit tu ne l’utilises pas et… il faut faire plus attention.



Le C, c’est la formule 1 des langages.



Mais quand tu te plantes, c’est comme de prendre un mur à 300km/h….









sr17 a écrit :



Le travail de relecture permet de trouver un nombre de failles. Et c’est en cela qu’un code ouvert aide beaucoup et sera toujours meilleur qu’un code fermé.





Oui et non.



Si cela est vrai en théorie, en pratique aujourd’hui, les failles ne sont quasiment jamais trouvées par relecture, mais par des moyens spécifiques, comme le fuzzing, et qui sont valables pour le proprio comme l’open source.



Sur le reste, je te rejoins, un OS sans faille, ça n’existera pas tant que ce seront les humains qui programment.









Wawet76 a écrit :



Depuis que j’ai quitté les études (15 ans), je n’ai pas vu une machine avec mot de passe sur le bootloader (ou le bios).





moi je vois que ca









YamaLandia a écrit :



Marrant d’inverser les situations. En près de 50 commentaires, je ne vois personne fustiger Linux parce qu’il y a une faille qui a été découverte. Personne n’a dit être en sécurité sur son OS en crachant sur Linux au passage.







Certes, c’est vrai que pour ce coup la, ça reste modéré. Mais j’anticipe parce que une manière générale, depuis un certain temps, dès qu’on voit une faille de base sur Linux, c’est la fête du troll.



Alors ça m’hérisse un peu le poil…





Les seuls qui le font remarquer, c’est plutôt en fustigeant certains utilisateurs qui pensent qu’il n’y a pas de failles sur Linux et qui se déchainent sur les autres OS dés qu’un truc est mis à jour. D’où mon propos d’inversion : généralement, ce sont les trolls linux qui fustigent les autres OS en se croyant intouchables avec leur OS.





En ce moment, je n’ai pas l’impression que ça ait tendance à troller à chaque Windows Update.



Mais en même temps, il ne faut pas oublier que le règne de Windows XP a été très long et que ça a logiquement laissé des traces dans les esprits.



De nos jours, tous les monde prends la sécurité très au sérieux. Reste une différence de modèle code ouvert/fermé qui déchaînera toujours les discussions.





C’est un peu comme ceux qui disent qu’il n’y a pas de virus sur Mac..





Oui, le grand public à tendance à tout exagérer.



Et en même temps, c’est quand même vrai qu’on est un peu moins embêté avec Linux et MacOs. Mais ce n’est pas pour autant qu’il faille se penser à l’abri de tout. Les malwares existent sur Linux…









ActionFighter a écrit :



Oui et non.



Si cela est vrai en théorie, en pratique aujourd’hui, les failles ne sont quasiment jamais trouvées par relecture, mais par des moyens spécifiques, comme le fuzzing, et qui sont valables pour le proprio comme l’open source.



Sur le reste, je te rejoins, un OS sans faille, ça n’existera pas tant que ce seront les humains qui programment.







En informatique, chaque technique à ses points forts et ses points faibles. Si on pouvait découvrir toutes les failles par des méthodes automatiques, il n’en resterait pas…



Mais ceci dit, c’est vrai qu’il y a des méthodes modernes qui apportent beaucoup pour aider à sécuriser le code natif.



Je me sers juste pour NotePad++ (parfois j’ai pas mieux) et pour Path of Exile.








sr17 a écrit :



En informatique, chaque technique à ses points forts et ses points faibles. Si on pouvait découvrir toutes les failles par des méthodes automatiques, il n’en resterait pas…



Mais ceci dit, c’est vrai qu’il y a des méthodes modernes qui apportent beaucoup pour aider à sécuriser le code natif.





<img data-src=" />



La relecture est un premier point qui permet d’éviter des erreurs flagrantes, après, et surtout en C où le code peut vite devenir imbuvable, quand le code est complexe, on utilise plutôt des outils d’audits du code.









sr17 a écrit :



Et en même temps, c’est quand même vrai qu’on est un peu moins embêté avec Linux et MacOs. Mais ce n’est pas pour autant qu’il faille se penser à l’abri de tout. Les malwares existent sur Linux…







Articles de moins d’un an sur un site dédié à l’univers Apple…








Si tu veux bloquer le boot sur une seule configuration tu ne met qu’un choix dans Grub et un timer à 0, ou en UEFI pas de Grub du tout.








Guinnness a écrit :



Si tu veux bloquer le boot sur une seule configuration tu ne met qu’un choix dans Grub et un timer à 0, ou en UEFI pas de Grub du tout.







Ou tu boots avec syslinux…









Inodemus a écrit :



Sinon un boot sur un Linux sur CD ou USB suivi d’un chroot donne le même résultat.





Même pas besoin de chroot, si tu te fout de laisser des traces une fois booté sur ton liveCD/USB tu édites le fichier où sont stockés les hashs des mots de passe et tu colles une chaine vide à la place comme ça tu peut booter direct sur le système auquel tu voulais accéder sans mot de passe. (si la partition n’est pas crytée bien entendu)



Ouais aussi <img data-src=" />








Guinnness a écrit :



Si tu veux bloquer le boot sur une seule configuration tu ne met qu’un choix dans Grub et un timer à 0, ou en UEFI pas de Grub du tout.





Ta première proposition n’est pas pratique si on veux un boot pour configurer à coté (surtout quand la première configuration est pour un appareil en accès libre genre “borne internet” et que tu veux éviter à toutes interface de configuration dans cette “configuration”).

Ta seconde proposition c’est quand même du bidouillage, ça ne garantie rien.

Ta dernière : en effet, UEFI à rendu (presque) totalement remplacé GRUB. Mais ça revient au même, il faut un mot de passe UEFI.



même scite ?


C’était pour un module, en général j’utilise plutôt Kate.


Le ‘C’ ‘est un assembleur, ou presque. Donc un risque d’erreur à chaque ligne mot.

&nbsp;Sinon, pour ceux qui veulent du code vraiment sûr, il y a la méthode B . Mais c’est pas à la portée de tout le monde.

&nbsp;


Sauf si on voit les pointeurs avant et qu’il faut alors une bonne centaine de séances de TP… <img data-src=" />


pointeurs ou tableaux c’est un peu kifkif.

Jamais compris pourquoi certains ont si peur des pointeurs c’est quand même pas insurmontable <img data-src=" />








Gundar a écrit :



pointeurs ou tableaux c’est un peu kifkif.

Jamais compris pourquoi certains ont si peur des pointeurs c’est quand même pas insurmontable <img data-src=" />





génération java, podoprogrammation et confusion entre pointeur et pointé&nbsp;<img data-src=" />&nbsp;

rien ne vaut un bon TP en asm !









kosame a écrit :



génération java, podoprogrammation et confusion entre pointeur et pointé <img data-src=" /> 

rien ne vaut un bon TP en asm !







C’est clair…



Assembleur et C/C++, ça leur ferait aussi comprendre aussi à quel point Java est mauvais….






ouais, z’avez trop raison, les jeunes de maintenant, z’ont pas connu les cartes perforées, donc z’y connaissent rien de la vraie vie. Z’apprennent rien à l’école.&nbsp;De not’ temps, c’était quand même autre chose.&nbsp;<img data-src=" />&nbsp;<img data-src=" />


Pour information/anecdote, voici les “CVSS v2 Base Score” des dernières grosses failles bien connues (un score plus élevé signifie une gravité plus élevée) :




 &nbsp;POODLE : 4.3 MEDIUM   

&nbsp;Heartbleed : 5.0 MEDIUM

&nbsp;Grub2 "28 chars" : 6.9 MEDIUM



&nbsp;Shellshock : 10.0 HIGH


Dans ton cas de borne internet publique tu utilise SU à partir de ton shell utilisateur, c’est fait pour ça et c’est apparemment nettement plus sécure qu’un mot de pesse Grub.








sr17 a écrit :



Assembleur et C/C++, ça leur ferait aussi comprendre aussi à quel point Java est facile….



<img data-src=" />



Il ne faut pas oublier son principal avantage face aux langages de bas niveau.



Sauf que c’est un score composite calculé automatiquement, et qui ne tient pas compte du fait que cette vulnérabilité ne devrait normalement pas donner accès à des données sensibles.



En entreprise, les données sensibles n’ont rien à faire sur un poste utilisateur, elles sont stockées sur des machines qui sont dans des locaux protégés, et les personnes ayant accès physique à la machine sont les administrateurs.








brazomyna a écrit :



ouais, z’avez trop raison, les jeunes de maintenant, z’ont pas connu les cartes perforées, donc z’y connaissent rien de la vraie vie. Z’apprennent rien à l’école. De not’ temps, c’était quand même autre chose. <img data-src=" /> <img data-src=" />







Cette discussion fait combo avec ceci :

http://xkcd.com/1601/

Plus un autre que je n’arrive pas à retrouver avec des artistes au fil des époques qui disent “si seulement j’avais le talent des anciens” pour finir avec l’homme préhistorique qui contemple ses peintures murales en se disant : “je suis le meilleur”.









Guinnness a écrit :



Dans ton cas de borne internet publique tu utilise SU à partir de ton shell utilisateur, c’est fait pour ça et c’est apparemment nettement plus sécure qu’un mot de pesse Grub.





Que tu accèdes comment si tu bloques l’interface utilisateur au seul navigateur internet (cas d’une borne internet)?

(bon ok, dans le cadre d’une borne internet, potentiellement tu peux peut être laisser le SSH ouvert, mais ça reste un moyen détourner demandant un réseau pour accéder à l’administration d’un ordi, ceci n’est pas universel)









sr17 a écrit :



En informatique, chaque technique à ses points forts et ses points faibles. Si on pouvait découvrir toutes les failles par des méthodes automatiques, il n’en resterait pas…&nbsp;





quand tu encodes une vidéo il y a des erreurs, et pourtant c’est pas un humain qui effectue le processus d’encodage









trekker92 a écrit :



quand tu encodes une vidéo il y a des erreurs, et pourtant c’est pas un humain qui effectue le processus d’encodage







D’un point de vue informatique, cela n’est pas des erreurs…