 Nous sommes maintenant en train d'ouvrir le BSD 6.6, et les systèmes opérés sont rapidement installés avec une excellente documentation et beaucoup de sécurité. Mais les mesures de mitigation, notre prochain speaker va regarder systématiquement les mesures de mitigation Sting. Bonjour tout le monde, je suis une Sting et on va parler des mesures de mitigation d'OpenBSD. Je vais expliquer pourquoi je suis sur la Sting et ensuite on va aller regarder les mesures de mitigation d'OpenBSD et à la fin on va avoir une conclusion. Donc pourquoi je suis là ? Comme toutes les bonnes histoires, ça commence à regarder. Donc j'étais avec des potes qui parlaient d'exploitation plus de narrabilité et quelqu'un disait. Et quand je dis Rapshain, je me rappelle pourquoi j'utilise OpenBSD. Je ne connaissais pas beaucoup OpenBSD donc je demande à pourquoi. Et parce qu'OpenBSD, ils aiment la sécurité. C'est quand même beaucoup. Donc je lis beaucoup sur le code d'OpenBSD, les documents de design, les PDF. Et ensuite je reviens à regarder et un pote me dit tu devrais faire une présentation au CCC. Tiens c'est une bonne idée, on peut les accepter donc pourquoi pas. Et donc voilà. Donc OpenBSD c'est un système d'exploitation comme Windows ou Linux. Sauf que c'est basé sur InternetBSD qui a été forqué en 1995 par Théodorat. Les buts c'est de faire attention à la sécurité avant que quelqu'un d'autre ne s'en occupe et d'être le système d'exploitation le plus sécurisé du monde. Et donc les solutions devraient être basées sur le mérite technique. Et donc il y a des gens qui pensent que c'est des bêtises qui ont décidé de préconstruire sur mon IT. On va essayer de voir ce que ça va donner. Donc lorsque j'ai ouvert, lorsque ça a été annoncé cette présentation, il y a eu beaucoup de réponses. Donc regarder les innovations, regarder les ventes. Donc comment est-ce que vous avez dit que c'est passé que OpenBSD a beaucoup de mitigations mais je veux savoir si elles fonctionnent ou pas. Et si c'est suffisant. Et il n'y a pas d'exploitation sur OpenBSD. Il n'y a pas non plus d'exploitation sur Haiku pour Temple et je ne suis pas certain qu'ils sont aussi sécurisés. Donc OpenBSD c'est super et c'est pour ça que je l'utilise. Mais c'est pas à propos d'OpenBSD, des logiciels qui sont livrés. OpenBSD c'est juste à propos d'un SBC. Et donc on va voir. Et pourquoi est-ce que tu essayes de taper dessus. Ne n'ose pas les critiquer. Quelqu'un d'autre va voir sur un de les points organiques qui est un site. Et à chaque fois il y a une nouvelle mitigation. Et personne n'a encore réussi à critiquer les mitigations. Ils disent, tiens là tu as eu une faille. Où j'ai des potes qu'ils ont décrit. Il y a des gens qui généralement ne se plaignent pas sur les mitigations. Le titre c'est du clickbait. Et effectivement c'est pas trop super clickbait parce que la salle n'est pas pleine. Donc comment est-ce qu'on mesure la sécurité ? Donc on a le mitigateur qui essaye de faire des expressions plus difficiles. Comment est-ce que tu peux faire ton design pour la mitigation ? Donc je n'aime pas écrire des block postes. Pour avoir une bonne mitigation, il faudrait avoir une certaine classe de bugs que tu tues. Ou est-ce que tu es 1, 2, 3, 4 ? Ou combien de temps ? J'ai râché un loop pour une boucle pour que ce soit plus difficile de faire un attaqueur. C'est pas une bonne idée. J'ai écrit cette mitigation pour tuer cette classe de bugs. Est-ce que tu peux essayer ? Et où est-ce qu'elles viennent, les mitigations ? Est-ce que tu as lu un papier ? Ou est-ce que tu as eu cette idée ? Est-ce que l'autre l'utilise ? Est-ce que c'est le code est plus complet ? Donc ça ne garantit pas. Mais au moins il faut voir qu'elles viennent de des bonnes principes. Des bonnes habitudes. Quelqu'un qui s'appelle Brian Malley a expliqué pourquoi il a essayé de définir une règle de base. Si je ne peux pas expliquer exactement dans ce qu'entre quoi tu te protèges, c'est en forçant à l'attaqueur à voir quelque chose de plus complexe. Dans cette présentation, je vais vous montrer un sous-ensemble arbitraire de mitigation utilisé dans OpenBSD. De choses qui ont été faites ou améliorées par OpenBSD, dans quelles mesures elles sont efficaces. Et comment par exemple d'autres types de systèmes comme Linux ou Windows peuvent être comparés face à OpenBSD en termes de sécurité et de mitigation. J'ai choisi un sous-ensemble arbitraire parce que bien sûr je n'ai que 45 minutes. Donc il n'y a pas beaucoup de sources dans ma présentation parce que je n'ai pas énormément d'espace. Mais à la fin je donnerai un lien qui donnera toutes mes références. Donc j'utilise également une notation au pied de mes slides pour donner quelques opinions. Donc d'abord la réduction de la surface d'attaque. Donc quelqu'un chez EP0 a montré que la réduction de la surface d'attaque est quelque chose de très impactant pour la sécurité. Donc la séparation des privilèges et la réduction des privilèges compressibles. Donc en 97, Daniel Bertschneid a écrit eCumay qui est composé de plusieurs processus dont un seul tourne en route. Donc par exemple un processus qui communique avec Internet aura des privilèges plus faibles par exemple. En 97 on a eu la même chose pour PostFix et en 2002 on a eu un drop de privilège pour OpenSSH ce qui est pas mal. Maintenant tous les programmes qui sont écrits pour OpenBSD utilisent ces notions de séparation des privilèges et de réduction des privilèges. Donc par exemple quand on fait un ping sur Linux, un ping est SatuID. Donc d'abord il tourne avec des hauts privilèges et ensuite il les drop très rapidement. Donc par exemple on a un Xorg qui ne tourne plus en route depuis 2014 mais qui a gardé quand même la notion de SatuID. Donc dans le monde de Linux il y a quelque chose qui s'appelle SecCom qui a été créé en 2002, qui a été mergeé en 2005. Ok, donc seuls les systèmes SIGSIT et quelques autres sont autorisés. Donc SecCom BPF a été créé en 2012 et ça a permis de limiter les appels systèmes qu'un programme peut effectuer. Donc OpenBSD s'est mis à faire ça pour tous les programmes également ce qui est quelque chose de très efficace en termes de mitigation. Ok, donc par exemple si on a un Cisco on se demande s'il est vraiment nécessaire etc. Là le problème ne se pose pas trop parce qu'on va dire ok ce programme il peut faire seulement ça. Par exemple il va pouvoir faire de la DNS résolution. Donc par exemple on va avoir un programme il va faire différentes choses. Et on va avoir différents privilèges et donc utiliser différents appels systèmes. Donc il y a SecCom qui est utilisé par exemple pour Docker où se pourrait répéter à certains moments ou quelques autres programmes peut-être. Mais dans OpenBSD il y a 850 appels pour pledge, c'est à dire que c'est beaucoup plus d'illisé. C'est très impressionnant et ça fonctionne très bien, c'est très efficace. Il y a aussi Unvale qui est un peu comme pledge mais pour les fichiers. L'idée c'est que pledge te permet de bloquer sur, ça permet de bloquer la vue du site un de fichiers pour certains programmes. C'est à dire que le programme n'a besoin de voir que le fold d'un browser c'est juste pour les download et un autre c'est pour les caches et les cookies et c'est tout en fait. Ça ne s'arrête pas sur les violations. Donc tu vas peut-être avoir un message de log mais le programme ne va pas s'arrêter automatiquement. Donc c'est utilisé par les 77 programmes en Disneyland. Et c'est beaucoup parce que OpenBSD ne vient pas avec beaucoup de programmes. C'est comme à part mort mais c'est bien fait. Je pense que c'est mieux fait puisque la police est dans le programme. Et si tu dis WGate pour envoyer des fichiers, tu peux faire le 6ème fichier Read Only puisque WGate récupère le fichier sur ton disque et télécharge. Ou lorsque tu télécharges un fichier tu as besoin de simplement rendre le fichier destination en écrit, d'accès en écriture. Et il n'y a pas plus que ça en fait. Donc la surface d'attaque dépend de ce que vous faites avec le programme. On a des vulnérabilités sur le hardware. On en a eu beaucoup ces dernières années. Là, le plus intéressant c'est le temps de réaction puisque c'est plus rapide de mettre à jour le système d'exploitation que la CPU, le processeur. Donc il y a des gens qui s'amusent à faire des proof of concept en quelques heures. Donc les gens qui se prennent ça au sérieux vont vraiment faire des exploits tous les semaines. Donc hyper what. Donc il fait le hyper threading par défaut en 2018. C'est sympa parce que tout le monde dit OpenBSD n'a pas besoin de ne s'occuper de la performance parce qu'ils ont. Et au moins ils ont pu éviter deux, trois vulnérabilités. Donc par exemple Lyft dans userland ou MDS et ses variantes aussi dans userland. Donc c'est aussi une réduction de surface d'attaque, mais je trouve que c'est cool. C'était un mouvement qu'il fallait loser. Et donc voilà. Ensuite Spectre 1, 2 et 3. Donc c'est une production de branches d'exploitation spéculative dans la CPU avec des effets de port. Et un attaqueur peut essayer de manipuler ça pour lier à des données. Donc Spectre version 1, la médiation. Sous Windows c'était sur le compilé. Linux était eu d'enlever certains gadgets et OpenBSD n'a pas besoin de rien faire. V2 paraît Red Pauline. Et des 0 pour armes et trois montes pour current et MDK. 64. C'est pas super long. Et Spectre 3, KPTI. C'est aussi réellement rapide. Le passement intéressant, ça a été KPTI. Après Dragonfly, BST. Sinon il y en a d'autres. Donc Lyft, MDS, WAPK. Et donc tout le monde a utilisé les mêmes mitigations. Sauf que OpenBSD n'a pas réussi à les avoir puis à causer les patrées d'émi. Donc c'est... voilà. Et pour Lyft, 9 jours après l'embarco, Théo de Rad disait qu'il n'y aurait pas de mitigations, même si ça qu'il était supporté à l'époque. Il a envoyé ça sur la mailing list, mais je suis pas certain. Donc la randomisation. Donc OpenBSD se concentre pas mal sur le fait de randomiser tout ce qui est randomisable. Donc d'abord la SLR. Donc l'idée, c'est d'adresser des espaces-mémoires à des localisations différentes. Par exemple c'est le cas pour la pile, pour le heap. Donc en 2001 on a eu le PAX projet pour Linux. Donc en 2001 OpenBSD a également ajouté des offsets aléatoires pour la stack. Donc techniquement on devrait parler de ASR et pas de ASLR. Parce que par exemple, lorsque l'on fait tourner un vinaire pour la première fois, c'est l'offset en par exemple vers le début de l'alibré. Et aussi OpenBSD, ils ont prétendu être les premiers grosses OS à utiliser ASLR. Mais je suis pas sûre que ce soit tout à fait exact. Donc ensuite le position independent code executable. Donc quand on va faire tourner le programme, il va être mapé à une localisation aléatoire. Et du coup en 2001 on a eu su PAX. On a eu PAX qui a implémenté payeux. En 2003 on a eu des choses similaires pour gain2. Et pour Fedora. Donc ensuite en 5 ans après en 2008 OpenBSD s'est mis à supporter les payeux. En 2011 les payeux sont utilisés par défaut sur iOS et OS X. En 2012 ça a été le cas pour Android. Et en 2012 également pareil pour OpenBSD. Donc ça c'est bien. Et sur le site d'OpenBSD c'est écrit que OpenBSD 5.3 a été le premier OS utilisé de manière importante à activer ça par défaut. Sauf que pour cette plateforme matérielle différente, sauf que ce n'est pas le cas pour Android. Il y a eu Android qui a été le premier par exemple pour cette plateforme etc. Donc KRL. En 2017 OpenBSD relink les objets carnelles dans un ordre aléatoire après chaque bout du système. Donc c'est pas le cas par exemple pour le système. Par exemple sur Ubuntu à chaque fois qu'on reboute le carnet il ressemble à la même chose. Donc ça pour OpenBSD c'est pas mal. Parce que par exemple si on peut liquer un pointeur vers le noyau on va savoir mais ça ne va pas donner énormément d'informations. Parce que je vais pouvoir écraser quelque chose mais je ne maîtrise pas quoi. Ceci est utile contre les attaquants qui n'ont pas des lectures invitraires. Et en termes de debugging c'est assez horrible parce que tout le monde a des spayiers différents. Et du coup pour debuguer c'est pénible parce que du coup par exemple on va prendre un screenshot et en fait ça va pas être suffisant puisque on ne sait pas à quoi le carnet ressemble à ce moment. Et ça pose également des problèmes par rapport au trusted boot mais je pense qu'en fait OpenBSD s'en fiche en plein. Donc il y a également d'un randomisation au boot pour la libc et la libcrypto. Donc ça existe depuis 2016. Ça permet d'éviter les léliques de single pointers et les overwrites relatives. Mais par contre ça ne fonctionne pas, ça ne permet pas de se protéger contre par exemple un read arbitraire. Donc à un moment du coup ça a permis une petite amélioration de l'ASLR. Mais dans le cas de la libc ou de la libcrypto on a finalement déjà assez de gadget. Et en termes d'anthropie, l'anthropie est assez réduite. Et voilà. Et voilà. Et voilà. Et voilà. Et voilà. Et voilà. Et voilà. WX, c'est une mitigation. L'idée c'est d'avoir quelque chose qui est écrit ou on peut l'exécuter mais pas en même temps. C'est relativement vieux. Ça a été fait en 90, quelque chose. Il y a aussi un patch kernel pour Linux et on peut éviter l'exécution. Et en fait quelqu'un qui vient de juste écrire sur une section ne peut pas l'exécuter directement. OpenBasey a été relativement tard. Donc ça a été fait en 2002 pour les Allende et puis 2015 pour kernel. C'est super. C'est super sauf que... Il me manque pax and protect, comme... Ou alors ACG sur Windows. Ou l'équivalent hardware dans Apple. L'idée c'est que le system d'exploitation va tracer la location de mémoire. Et c'est une page écrite qu'on peut écrire. On peut pas la matte-p comme étant exécutable. Et donc il faut d'abord l'écrire, ensuite la matte-p a été matte-p comme exécutable. Et donc ça bloque l'exécution de code arbitraire. Puisque... Donc je peux allouer une section. J'écris, je mets ma payload dedans. Ensuite je la remap à comme exécutable et je l'exécute. Donc c'est l'attaqueur... En fait il faut... Ça complique l'installation de la payload pour l'exécuter. Donc WX Revealment. Un peu plus tard ça a été affiné. Teo a dit qu'il volait les appels Cisco de ces endroits-là. Forçant les attaqueurs à avoir des attaques plus complexes. Ou probablement plus difficiles d'appeler les Cisco. C'est quoi l'idée ? C'est un petit peu comme pas que c'est protect. Ils bloquent des Cisco d'exécution pour un attaquant. C'est quelqu'un qui a de la mémoire. Et en fait c'est bloqué la mémoire qui n'a pas le drapeau M6 flag. Quand ton binary est en train de se lancer, tu peux lancer uniquement tes Cisco de cette version-là, d'une certaine version du manaire. Donc Samuel Crow a fait une présentation d'un exploit qui bloque... qui contourne complètement cette mitigation. Comme attaqueur, vous avez suffisamment de contrôle pour avoir quelque chose en écrité. Et généralement si vous avez suffisamment de contrôle pour écrire quelque part, pour changer en exécutable et pour l'exécuter généralement, vous avez aussi un contrôle pour contrôler Cisco. Maintenant c'est la version la plus juteuse des mitigations. Donc elle mentent la pile en Ducaland. Le tarp. Désolé, et Daniel Miller. Donc c'est absolument superbe. C'est des métadonnées hors bandes. Donc on a les données, et les métadonnées sont gardées de façon séparée. C'est à que si un overflow, on va avoir... ils vont pouvoir... c'est une lecture read-only. Si on a été d'accord, Henri-Douard a été abriter. L'idée, ça va être que lorsque le programme aura pu besoin de l'exécutable, que le programme aura pu besoin d'une zone mémoire, ça va pouvoir être libéré. Sauf qu'en fait ça va pas être libéré immédiatement, donc on va pouvoir la mettre un petit peu en quarantaine, et cette zone mémoire sera libérée un petit peu après. Et si en tant qu'un attaquant, on essaie de regarder cette zone mémoire, on va pas être capable de liquer ce qui se trouve dedans. Donc on a aussi les protections par Canary. Donc pour le page alignment, en tant qu'un attaquant, on a un overflow. En fait ça ressemble un peu à un Canary mais pour des pages entières. Et dès qu'un attaquant commence à les toucher, tout va exploser et du coup on va se rendre compte qu'il y a un problème. Donc les optional guard pages, c'est quelque chose qui est vraiment pas mal aussi. Donc on a des benchmarks qui montrent que, par exemple, Potomalock est douce fois plus lent que l'équivalent. Donc ça c'est un peu plus compliqué à expliquer. Mais par exemple si on a un programme qui a besoin d'une fonction de fin qui vient d'une autre librairie, par exemple Printef pourra ficher quelque chose. Donc le programme va dire, ah bah attend, où est la fonction Printef ? Donc cet élément va dire, ah bah attend, je vais regarder. Il va envoyer un réponse au programme et ensuite un appel à Printef va être effectué. Donc l'idée ici c'est que le cache qu'il va être utilisé pour faire ça, il va être rendu Ridonly. Pour éviter des choses où par exemple on aurait compromis le cache et où la prochaine fois qu'on pensera à Printef en fait on appellerait autre chose. Mais il y a quand même un problème, donc OpenBSD a toujours un autre type de bindings. Et la façon dont ils font ça c'est qu'ils utilisent un nouveau syscall qui s'appelle KBind qui permet au programme d'avoir une écriture habitraire sur une zone mémoire qui est mappée. Donc même si la zone est Ridonly, le programme peut quand même écrire dedans. Donc la première fois que la CUNE fonction est utilisée, on va enregistrer si c'est passé. Et ensuite ça implique une sorte de cookie un peu magique. Donc je pense que c'est un syscall qui est un peu dangereux. Et je pense qu'en fait on aurait dû avoir un autre type de bindings et pas garder le système de lazy bindings. Ensuite les Trap Slides. Donc en 2017, ça date de 2017, donc l'idée c'est d'enlever les Nobsled et des librairies, des bibliothèques. Donc les Nobsled, ils datent quand la stack est encore exécutable. Et si on regarde tous les exploits que l'on peut trouver n'importe où, personne utilise les Nobsled. Dans Visual Studio, on avait une fonction similaire qui était brandée comme une fonction de sécurité. Donc en ce qui concerne le fait d'enlever les gadgets pour l'autre. Pour exemple, au lieu de faire un move de A à A, on va faire un exchange sur A et B, on va move B à A et exchange B à A. Et concernant Red Guard, on va en discuter un petit peu plus tard. Et les gadgets drop, mais pourquoi en fait ? Parce qu'il y a un gadget qui s'appelle RobGadget.PI. Et en fait, personne utilise ça à part les gens qui font du CTF et encore ça ne marche pas tous les coups. Et la façon de mesurer ce succès, c'est de faire tourner ça sur différents binaire et d'essayer de générer une chaîne complète avant et après mitigation et de voir si on peut encore générer la chaîne. Et en enlevant les RobGadget, on fait tomber le nombre de gadgets à à peu près 11% sur AMD64. Mais en fait, ça ne fait pas une si grande différence parce qu'il y a toujours plein de gadgets qui traînent un peu partout. Donc j'ai essayé de faire tourner RobGadget.PI et en fait, si on fait tourner ça sur le niveau avec kernel, on a toujours plein de gadgets disponibles qui vous permettent de faire des returns un peu n'importe quoi. Et on pourrait penser que ça, c'est assez puissant sauf qu'en fait, le fait d'enlever les RobGadget finalement, on pourrait penser que ça améloie la sécurité mais sinon en certains cas, ça peut diminuer au contraire. Donc si on parle de Redguard maintenant. Donc Crispin Coan et d'autres personnes en 97 ont publié StackGuard, StackGuard. Il y a une valeur secrète qui est sauvegardée et si quelqu'un réécrit dessus, la valeur est perdue et donc on peut détecter qu'il y a eu un changement qui a été fait. Donc il faut savoir qu'en fond d'un appel, il faut envoyer et il faut savoir où revenir. Donc vous allez mettre l'adresse de retour sur la pile et vous allez faire une explication et c'est-à-dire que si en attaqueur je peux écrire sur cette valeur, je peux croiser le programme là où j'étais. Et donc ça a été fait en 2003 et de façon intéressante, ils utilisent des données aléatoires sur un segment et le compiler a vérifié et il le faisait des zéro puisque il voulait que ce n'était pas utilisé. Donc ça simplifiait les compoteurs. Donc en 2007, c'est de faire un XOR sur l'adresse au début de la pile avec la valeur du pointeur en elle-même séparée et si on peut simplement écrire une partie du pointeur et si vous pouvez lire le tas, c'est bon. Donc si vous avez ASLR et en fait vous pouvez récupérer le cookie, donc c'est des passes super géniales. C'est pour ça qu'ils ont amélioré en 2018. Voilà un peu l'assemblée. Donc l'idée c'est de mettre le Red Guard de faire un XOR avec RSP. A la fin, la fonction, il y a une vérification. Donc il y a un SO et ensuite un SLED et ensuite on retourne. C'est cool. C'est bien. Donc R11 est toujours sur la pile, lorsqu'on appelle la méthode. Donc on peut liquer la valeur du cookie. Il y a un cookie par fonction. Et ce cookie est stocké dans un segment dédicacé. Donc on ne peut pas écrire dessus. Et l'intégrité de la valeur d'autour en elle-même. La valeur d'autour en elle-même. Donc l'intégrité, la valeur, c'est vrai. Et donc même avec un écritur de l'arbitraire, on ne peut pas l'écrire. Donc c'est un petit peu mieux que les cookies de stack, le cookie de pile normal. Mais si vous avez une lecture arbitraire, c'est quand même game over. Donc nulle des refs dans cannelle, l'idée c'est que lorsque vous avez un nulle pointer, une référence sur un pointer nulle. Il faut par exemple un pointer de fonction initialisé qui est en nulle. Le cannelle va sauter vers une nulle. Et il doit donc pour que l'attaquante doit se mettre sur le code pour avoir une exécution de code. Et le projet Pax l'a tué en 2004. Et sinon en 2006. Il y a un spruddle en 2023 C3. Il parlait d'un usual bug où il avait par exemple ce genre d'exploit. Donc il y a une mitigation par Linux, un peu plus, dans 2007. Et tous les débuts de l'esprit space. En 2007, tout le monde faisait un copy & paste des exploits. En 2008, a aussi midi-game, 0 de rade. C'est le chef. Il n'est pas super fier de la solution mais c'est la meilleure solution face à la décision architecturale d'Intel. Ça lui a pris deux ans pour l'implementer. Donc je pense que c'est dans l'autre sens. SMAP, SMAP et leurs amis. L'idée que vous pouvez en forcer au niveau de la CPU. Que les choses qui sont en train de tourner en supervisor ne peuvent pas accepter le userland. C'est à dire qu'on ne peut pas pour éviter d'écrire leur payload en userland. Et d'exploiter l'appavizer. Donc il faudrait simplement pour forcer l'attaquant à écrire directement dans le canal. C'est... Donc Intel, AMD, Federeze, SMAP. SMAP c'est pour le canal et SMAP c'est AXSEI. C'est 2012, tout le monde a eu du support pour ça. Et donc en OpenBSD ils ont obligé de... Il y a eu un bug avec un trivial, avec un... Évitement trivial jusqu'à la descente parce qu'ils ont oublié de mettre un flag à zéro. Donc MAP Stack, ça existe dans Linux. Donc Windows avait aussi quelque chose de similaire. Ça a été en l'avenir 2012. Donc l'idée c'était... C'était de vérifier que lors d'un Cisco, le stack pointer pointait vers quelque chose qui était bien dans la stack. Donc l'idée c'était de mettre son payload dans quelque chose qui pointait vers MAP. OpenBSD ont un peu utilisé les choses de Windows mais sans en parler dans aucun papier. Donc pour Ae, ce qu'ils font c'est qu'ils vérifient l'état du stack pointer à la fois lors des Cisco et aussi je ne sais plus parmi. Donc les SIN cookies, donc à nouveau Daniel Bernstein. Donc là l'idée c'est d'avoir un stockage qui est stateless pour les handshakes SIN. Donc si on a un client qui envoie à la suite plein de SIN, il faut que le serveur en garde la trace. Et ici l'idée c'est d'avoir un cookie qui permet de stocker ça de manière stateless. Donc ça a été implementé dans OpenBSD l'année dernière. Et aujourd'hui tout le monde sur Internet peut faire des doses pour un coût moindre en envoyant plein de SIN. Donc ensuite MAP Conceal. L'idée c'est qu'on ait des adresses mémoires qui soient pas capables d'accès de disque. Et ça permet par exemple d'avoir, d'éviter d'avoir des credits de l'ordre de crash qui m'a été créé sur le disque. Donc le nom Conceal a été choisi parce que ça a permis une certaine flexibilité. Par exemple ça empêche l'utilisation de Petras. Donc concernant les pratiques de développement, je pense que ça c'est important. Ils ont pas de trackers de bugs, tout se fait par mail. Pour savoir qui gère un bug, en fait il faut aller voir sur la mail, par exemple. Donc par exemple lorsqu'on bouge du code ça va être... Théo a dit que c'était bon ou quelqu'un d'autre a dit que c'était bon. Il n'y a pas de revue de code public. Ensuite il n'y a pas de justification pour les choix qui sont faits en termes de mitigation. Donc quand il y a une vulnérabilité qui est fixée en fait on nous dit juste... On a juste une page où il y a marqué dans telle version, telle vulnérabilité est fixée. Mais on n'a pas le contexte qu'il va avec en fait. Donc par exemple on ne sait pas si ça affectait le kernel line, le user line. On ne sait pas, il y a juste marqué mettez un jour et patchez ça et c'est tout. Il n'y a pas de système d'intégration continue. Et la branche Current de temps en temps est juste cassée. Si on a un jour le système bout de pluie. Pour la gestion de version, ils utilisent CVS. Il y a à la moitié des messages de comites qui font moins de 10 caractères de long. Donc par exemple Hello World ça fait 11 caractères déjà. Donc en conclusion, juste attends. OpenBSD a inventé des petites choses vraiment intéressantes, par exemple tout le malloc. Et a fait des choses pas mal sur par exemple le hardening d'OpenSSH. Ils ont de bonnes idées. Ils ont également amélioré des idées que d'autres avaient eues. Par exemple le pledge, le password hashing, Bcrypt. Il y a aussi des choses. C'est hilarant, par exemple si on regarde les histoires de TrapSled, WX, etc. Mais par exemple si le bypass sur SMAP, il n'aurait jamais dû exister pendant aussi longtemps. Mais ils ont aussi des mitigations qui sont inutiles et jouent pas en quoi. Ça peut fonctionner de développer ça de cette manière. Et... Ils ont quelques mitigations qui sont un peu inutiles aussi au sens où elles vont retarder le développement d'exploit mais pendant pas très longtemps. Voilà, merci beaucoup. Donc on ne vit pas, donc on va aller voir ce site. Mais je pense que c'est important que les gens peuvent comprendre pourquoi, les questions que j'ai posées, pourquoi. Donc merci, Stein, pour cette revue systématique. Donc allons voir les questions. Est-ce qu'on a des questions sur internet ? Non, pas de questions sur internet. Est-ce qu'il y a des questions dans la salle ? Je ne vois personne de microphone. Personne ? Un petit peu plus de temps pour penser à une question. Allez, dites quelque chose. Pas de question. Microphone 2, il y a quelqu'un. Quand vous montrez les temps de réponse dans certaines médications. Est-ce que vous savez si les gens d'OpenBSD avaient accès aux informations avant la publication, comme par exemple les gens Linux ou Windows ? Est-ce que je pense qu'ils auraient pu aussi créer les médications en temps et en heure ? Et là je ne suis pas certain. C'est une bonne question. Je n'ai pas parlé de ça, puisque c'est un apparemment c'est relativement sensible. Théo dit que OpenBSD n'a jamais cassé un embarco. Mais ils se sont connus pour ne pas jouer gentiment avec les embarcots. Et donc en partie ils sont exclu des embarcots. Donc il a fallu qu'ils réagissent de façon rapide. On a une question d'Internet ? Oui. Est-ce que vous avez une réponse ? Oui. Est-ce que vous avez une réponse ? Oui. Est-ce que vous avez une réponse ? Oui. Est-ce que vous avez une réponse au Statement de Brian Steele qui disait que MAPStack est quelque chose de complètement différent de ce qu'il y a à implementer dans Linux et Windows ? MAPStack c'est le mapping que je vais faire voir le slide. Voilà. MAPStack c'est Windows. Windows ça a été enlevé. Mais c'est la même idée de vérifier le pointer de stack sur chaque Cisco OpenBSD, l'améliorer avec les page faults. C'est un peu mieux, mais c'est pas absolument superbe comme mitigation. Microphone 4. Comment vous pariez pledge avec les systèmes de possibilité de Linux ? Où est-ce que c'est différent ? Sous Linux. Vous entendez quoi par possibilité ? Par exemple, il y a Cap. Cap Network Bind. Capabilité pour ping. Pour créer une socket. Je vois de quoi vous parlez. C'est confus. Il y en a beaucoup de documentation et il n'y en a pas beaucoup de documentation. Et je pense qu'il y a quelqu'un qui a décrit les capacités, qui disait que c'est le bazar c'était. Mais comme c'est pas vraiment utilisable par un human normal, c'est pas une bonne musication. Ce que j'aime à propos de pledge, c'est que ça c'est l'entrée ou pas. Ou alors, enfin, entrée est sortie, ou alors je vais le réseau. Où est-ce que j'ai besoin ? Il n'y a pas besoin de dire, est-ce que j'ai rend besoin de ce type spécifique de socket, vachement exotique ou pas ? Autre question du microphone 5. Il y avait ce channel pour les développeurs d'IACB. Est-ce que c'est quelque chose qui existe encore ? Je n'en sais pas beaucoup sur l'écosystème autour de OpenBSD. Et concernant les mitigations, ils n'ont pas du tout interagé avec leur communauté. D'autres questions ? Une question supplémentaire d'Internet. Dans le contexte de votre présentation, comment OpenBSD peut être comparé à FreeBSD ? Je n'en sais pas beaucoup là-dessus. Plus sérieusement, il y a un fork de FreeBSD qui vise à améliorer la sécurité de FreeBSD. Mais je n'en sais pas beaucoup à ce sujet. D'autres questions ? On a toujours du temps. Internet peut-être ? Plus de questions. On va donc terminer cette session. Donc applaudissez à nouveau notre présentateur pour cette présentation.