 Hello, so we're ready to start. My pleasure to introduce to you... Bienvenue pour la conférence de QNX sous le scalpel. Nous allons analyser le système d'exploitation QNX. Donc je vous passe tout de suite la parole. Applaudissement. Très bien. Bienvenue à tout le monde. QNX sous le scalpel. Analysé sur QNX. Je suis Yos Fetzol. Je suis un chercheur de sécurité sur Midak Lou. Je m'intéresse au système intégré. Je suis à l'université. Et ceci faisait partie de mon mémoire de maîtrise. Bonjour, je suis Alia Passi. Et je fais mon doctorat aussi. Et je suis à l'université de Borum en Allemagne. Mon alme à recherche. C'est sur la sécurité dans les systèmes... Voilà. Donc une discussion sur QNX. Nous allons ensuite discuter la génération de nombres pseudo-aléatoires. C'est quoi QNX ? Donc c'est un système d'exploitation propriétaire qui a été depuis 1982. Et ça a été acheté par Blackberry. Donc c'est un système intégré. C'est un système 64 bits. Donc c'est utilisé dans Blackberry. Mais c'est le haut du iceberg. Donc ça a 50% du marché. Et c'est dans plusieurs voitures. Donc QNX c'est vraiment un système d'exploration qui est utilisé dans les voitures, dans les véhicules embarqués. C'est un système d'exploration intégré. Il y a aussi dans les routers de Cisco. Et QNX est utilisé dans, comme vous le voyez, sur la faille. C'est intéressant pour les problèmes de sécurité, pour les attaques de sécurité et pour d'autres systèmes critiques. Ainsi que des systèmes militaires. La sécurité des trains. Il y a beaucoup d'applications de sécurité. Donc l'année dernière, vous vous rappelez peut-être que nous avons aussi donné une conférence. Donc on s'est intéressé aux problèmes PRNG. Et puis maintenant nous allons parler un petit peu de différentes choses. Nous allons parler de l'espace kernel de QNX 6 et 7. Nous allons parler des exploits possibles. Donc introduction à l'architecture et aux systèmes d'exploitation. Donc l'architecture de sécurité de QNX. Donc c'est une architecture, c'est un véritable micro kernel. Donc ça veut dire que la plupart des composants de ce système d'exploitation sont hors du kernel. Donc ce que vous attendez dans le kernel n'est plus là en fait. Des choses comme le système de fichiers, les pilotes, les pilotes, le stack, tout ça c'est à l'extérieur du kernel. Et ce que vous avez c'est juste vraiment un petit micro kernel qui a beaucoup d'avantage par exemple le plus grand étant que c'est plus sûr, c'est beaucoup plus sûr. Il y a moins de chance de faire des erreurs. Et ce qui causerait que le système d'exploitation crache. Mais il y a aussi quelque chose qui, il y a moins d'opportunités pour les hackers en fait. Parce qu'il y a une surface plus petite pour les attaques, pour attaquer le kernel. Le kernel est un micro kernel. Donc en général les systèmes d'exploitation de micro kernel sont bien certifiés par la NSA. Donc voilà, le micro kernel. Mais si on met tous ces composants à l'extérieur du micro kernel, comment est-ce qu'ils vont communiquer, comment est-ce qu'ils vont travailler ensemble ? Donc ce que vous avez c'est un bus de messages qui donne une fonctionnalité, un programme comme un réseau, une communication de réseau. C'est tout à fait similaire. Ce que vous avez c'est une application dans le user space qui veut communiquer avec le système de fichier. Donc il envoie un message au micro kernel et le micro kernel le passe à l'application ciblée. Mettons par exemple le système de dossier et ce message va être passé à l'application. Donc ça c'est le bus de messages. Et le micro kernel, son boulot c'est de faire suivre ce message aux autres composants. Mais une chose intéressante par rapport à QNX c'est que cette architecture combinée avec ce qu'on appelle QNET en QNX ça donne une fonctionnalité où tu peux avoir plusieurs micro kernels qui communiquent entre donc on peut avoir deux micro kernels qui parlent par ethernet qui donnent plus de fonctionnalité pour le networking ou pour la communication de réseau en plus de cela QNX rend possible les six calls mais bon c'est pas comme dans Linux où on peut avoir plus de 300 six calls là il y en a un peu moins de 90 et also et aussi QNX est compatible avec les librairies libc donc là on utilise un compiler QNX et ce compiler compile les fonctions libc dans des messages Bon la configuration de la mémoire il y a un kernel space et un user space mais la seule chose qui reste dans le kernel c'est le micro kernel lui-même et en fait il y aura une séparation du user space il n'y a pas de possibilité que des processus à l'intérieur du user space aille l'un sur l'autre parce qu'il y en a qui sont sensibles donc il y a un support de la mémoire du management mémoire mais il y a aussi un accès au processus qui est semblable à QNX donc le layout mémoire donc la couche de mémoire donc vous avez l'image du programme et puis il y a l'odeur et puis il y a l'objet et les librairies qui sont chargées par le loader mais cela dit dans le kernel space toute l'adresse de base elle commence de façon statique par CPU on a un stack différent donc chaque CPU a son stack donc voyons voir le management des processus donc le management des processus est un peu différent on va dire qu'il y a un processus qui s'appelle Proketeo c'est le manager mais la plupart des choses c'est dans le micro kernel et une autre partie est dans le user space donc c'est le route qui commence avec l'idée de 1 et puis de la même façon que les autres microprocesseurs mais la différence c'est qu'il a un flag UPF0 qui lui donne 0 privilège en plus de cela Unix soutient les trucs POSIX habituels mais aussi QNX utilise l'elf format mais si le système de dossier est par bloc et que les blocs sont chargés dans la mémoire alors que le système de fichiers est en liaison avec la mémoire memory mapped comme on dit donc ça peut être le même processus qui partage la mémoire aussi QNX donne la possibilité de sandboxing donc c'est pareil que Linux en fait on peut restreindre certaines actions même pour les processus route on peut restreindre certaines actions même pour les processus route mais on a des domaines on a des c'est similaire à Linux mais ça dépend de l'intégration du système comment est-ce qu'ils vont le faire c'est pas vraiment un problème du système d'exploitation mais ça dépend à l'intégration du système comment est-ce que les gens qui intègrent le système vont prendre cette fonctionnalité mais également QNX supportent les processus de user management donc shadow, les passwords, les groupes et puis les choses comme logging, su et su donc toutes ces choses-là un peu analogues à Linux donc il y a bien sûr des tables de hash chars 256 chars 512 mais aussi c'est compatible avec md5 et le chiffrage md5 qui sont un peu plus faibles donc si quelqu'un peut craquer le mot de passe md5 et ben on peut aussi craquer cela donc en fait il y a les attaqueurs en plus de temps pour attaquer quand c'est compatible avec des versions plus faibles mais bien sûr on peut aussi patcher donc il y a des kdf2 qui est activé et c'est par défaut donc voyons l'histoire de la sécurité de QNX donc la plupart de la recherche a été faite par Blackberry qui est le propriétaire de QNX entre 2011 et 2014 et très intéressant en 2016 il y a une conférence de Alex Plasquet sur la communication entre les processus dans QNX, je vous recommande de la regarder et il y a aussi divers articles de 2008 mais le plus intéressant c'est un leak de Wikileaks Vault 7 qui a montré que la NSA a été intéressée à s'attaquer à s'attaquer à QNX ils ne l'ont pas encore fait avant 2014 mais on ne sait pas s'ils l'ont fait après donc il n'y a pas grand chose qui a été fait jusqu'ici sur les exploits pour éviter les exploits et sur PRNG je vais parler de l'implémentation de PRNG 7 donc voyons PRNG qui est le pseudo-aléatoire générateur de nombre pourquoi est-ce que nous regardons cela ? parce que c'est très important c'est quelque chose de fondamental pour l'écosystème cryptographique par exemple SSA, SSL tout cela utilise ce truc et donc les exploits eux-mêmes sont affectés il y a des faiblesses dans PRNG qui peuvent être exploités et donc quand on essaie d'éviter les exploits c'est intéressant de s'y intéresser donc intéressons-nous à DEVRANDOM l'implémentation de DEVRANDOM comme récapitulation donc ce que nous avons dit l'année dernière le PRNG de l'année dernière c'était sur un autre produit donc c'était il y avait des problèmes de design le plus gros problème c'était un problème des cides, des graines ils avaient un gros problème de graines et puis une entropie de mauvaise qualité et puis la source d'entropie qui était basée sur l'intégration au système donc il y a des choses qui peuvent foirer quand on utilise le système d'opération pour ça c'est mieux donc NX7 après notre analyse donc maintenant ils utilisent une autre implémentation, Fortuna ils utilisent d'autres sources d'entropie et ils ont des meilleurs contrôles de mécanisme pour les graines, pour les cides comme on dit donc la qualité a l'air beaucoup mieux que sur QNX6 c'est pas encore parfait il y a des problèmes sur le design mais il peut toujours avoir des attaques mais le système d'opération est quand même beaucoup mieux donc voyons ce qui a changé vous ne pouvez, vous n'avez pas besoin de tout regarder regarder et les carrés verts c'est les carrés verts qui ont changé donc la première chose le problème de l'entropie sur le temps de bout c'est le dossier de graines, de cides donc maintenant on peut avoir une aléatoire une entropie qui vient du boutage du bout donc ça peut être actualisé pendant le runtime mais le framework donne différents fichiers de cides, de graines mais aussi l'entropie est générée par les utilisateurs donc différentes sources d'autre part c'est étrange qu'ils utilisent getUID et getPID qui sont pas random du tout c'est complètement statique et getTimeOfDay donc la date du jour c'est pas random non plus mais bon c'est pas trop mal voyons le kernel prng de qnx7 qnx7 un nouveau kernel prng et une implementation en tant que fonction random value dans le micro kernel de qnx il va être utilisé pour les canaris de stack par le micro kernel donc ce que vous voyez ici vous avez différentes sources d'entropie ils utilisent le PID ils utilisent le temps en nanosecondes actuel ils utilisent le CPU ce genre de choses ainsi que des graines aléatoires qu'on peut mettre dans le bloc prng et puis une fonction chat de 156 et donc la sortie va être divisée en 8 blocs et le premier bloc va être utilisé comme un sel et le deuxième bloc va être utilisé pour l'output pour la sortie des 32 bits de valeur aléatoire il y aura des itérations à chaque fois qu'on aura besoin d'une nouvelle valeur aléatoire donc ces itérations vont bouger de 0, 1, 2, 3, etc à chaque fois la location qu'on va choisir les 32 octets vont changer donc qnx 7 le kernel prng donc maintenant comment éviter les exploits merci beaucoup Ali donc regardons comment éviter les exploits pourquoi essayer de faire ça parce que l'évitement d'exploit que nous utilisons ne vient pas du ciel il n'est pas tombé du ciel il y a une longue histoire de faiblesse de bypass donc on peut voir sur le slide il n'y a rien de cela pour qnx ça veut dire qu'il y a vraiment suffisamment de possibilités pour trouver des choses intéressantes donc qnx 6.5 il y a des supports par défaut il y a stack canaries toutes les choses que l'on voit sur la table mais ils ne sont pas activés par défaut mais si les intégrateurs de système ne font pas le choix explicite d'activer ces fonctions ils ne le sont pas pour des features beaucoup plus avancées comme le kernel data code isolation la cpi cfi commençons par la data execution prevention pour éviter l'exécution de payloads injectés dans la mémoire donc en fait il y a deux styles d'architecture pour la cpu Harvard ou il y a code et données qui est séparée d'autre c'est la fond de Neumann où les données et la mémoire sont mélangées et pour éviter l'exécution de payloads injectés il faut mieux avoir Harvard que fond de Neumann et c'est fait sur le x64 donc la mémoire Harvard est beaucoup plus adaptée à cela et vous avez un bit par exemple qui régule l'exécutabilité donc QNX DEP a un support pour ce genre de flag le support est sur x86 x64 il le supporte sur ARM mais il n'a pas ce support sur MIPS et sur l'architecture ppc Savary donc selon l'architecture du cpu le plus gros problème c'est que les défauts ne sont pas sûrs donc même si on a le support Harvard et si on a une version QNX qui a le support sur DEP mais le stack est quand même exécutable même si le heap ne l'est pas donc ça c'est quelque chose qu'il faut vraiment avoir en l'esprit donc le stack que nous est ignoré par le loader du programme donc ça va être exécutable même si il y a le flag c'est possible de faire ce stack non exécutable même en faisant en changeant un flag mais le problème c'est que c'est un setting qui est dans le système complet donc ça veut dire que si vous avez des exécutables qui doivent être exécutables eh ben ils seront aussi désactivés avec ce flag donc nous l'avons dit nous avons rapporté cela aux intégrateurs systèmes mais cette issue n'a pas été changée sur QNX 7 la deuxième chose pour éviter les exploits c'est address space layout randomization pour compliquer la réutilisation de codes en rendommisant les adresses donc l'exploitation typique à droite vous voyez du code qui existe à réutiliser c'est un snippet qui est schedulé et puis il y a il y a une technique pour éviter ça en utilisant l'aléatoire la location aléatoire si l'adresse est aléatoire vous ne pouvez pas retrouver les snippets de code en tout cas c'est l'idée QNX ASLR est donc activé avec le flag MR les processus enfants hérite de leurs processus parents ce genre de setting le setting ASLR mais par défaut c'est voilà j'ai pas compris donc les c'est pas très granulaire parce que le random c'est à la base et la plupart des objets mémoires sont randomisés donc c'est pas un vrai problème un problème c'est un problème en pratique c'est que PAI est désactivé par défaut ça veut dire qu'à moins d'activer PAI tous les binaires même les binaires ne auront pas la randomisation de la mémoire et donc si on regarde beaucoup d'images firmware de QNX sur le marché vous verrez que la mémoire code est rarement randomisée donc ça réduit beaucoup l'utilité de cette fonction voyons voir comment ça marche sous le capot donc on a fait, on a reversé l'ingénierie et on va vous épargner tous les détails en fait tout est un map dans le micro kernel et donc voyez les deux les deux carrés bleus ce sont les deux fonctions et elles ont besoin de la même génération de nombre aléatoires donc la première de ces fonctions map find via donc c'est une randomisation des adresses virtuelles et il soubstrait une valeur random à l'adresse et cette valeur random est obtenue en prenant de 32 bits et puis en les chiffrant de 12 et en extractant en extractant en extractant l'adresse randomisée dans cette façon en regardant la qualité de l'ingénierie en général la deuxième fonction stack randomize c'est ce qui randomise les adresses commençant ou il fait ça dans la même façon que le fonction avant il prend les derniers 32 octets du dépendant de la taille du stack et cela il fait un bit masque avec 7 bits d'entropie et donc ça arrange un petit peu parce que c'est combiné avec les résultats de la fonction précédente mais en pratique c'est pas vraiment très très important je bois une gorgée d'eau donc maintenant ces ces valeurs sont un peu optimistes que vous voyez là parce que on peut l'appeler un PRNG parce qu'ils utilisent une source d'entropie mais vous doutez que c'est un donc c'est spécifique à l'architecture de la de la slide vous pouvez voir l'architecture des cpu et l'implémentation qui est spécifique la première chose qui saute à l'esprit si on veut garantir le secret avec ASLR il faut être capable de reproduire un point mais il y a de l'entropie faible donc dans ce scénario leur loge doit être secret ce qui n'est pas puisque c'est un accès privilégié donc je vais faire une petite pause excusez-moi et donc on a mesuré plusieurs sortes de processus travers plusieurs sessions de bout et puis on a utilisé une source d'entropie niste afin d'estimer le euh et c'est bon de voir que c'est un c'est un c'est un c'est un de voir que la même bah donc reprenons donc l'entropie minimum 4,47 bits donc c'est très très faible quand on voit d'autres systèmes d'exploitation 30 bits linux par exemple entre 8 bits d'entropie donc donc selon les systèmes d'exploitation il y a plus ou moins d'entropie et QNX est un peu faible pourquoi c'est un problème ? parce qu'il y a un potentiel pour les attaques brute force donc si vous avez un daemon de réseau donc chaque connexion qui vient tu fais spawn avec un nouveau processus child et donc à cause de la memory layout il y aura le processus enfant aura le même layout que son parent et comme c'est appliqué après que a slr a été appliqué donc la slr est aussi copiée et c'est statique à chaque fois que ce child est spawned encore une fois donc si on essaie de deviner l'adresse pour un certain morceau de code bah on va essayer une adresse et puis on va mesurer la réponse et puis si le child crash et bah on va essayer un autre et s'il y a pas suffisamment d'entropie ça peut être efficace donc en un temps raisonnable voilà donc une attaque brute force pourrait être efficace est-ce que ça marche en pratique donc voyez ça marche nous avons fait un essai il y a un service vulnérable il y a un port de réseau qui est ouvert donc a slr est activé et vous pouvez voir l'exploitation via le network brute force 23 secondes pour avoir le route donc c'est effectivement efficace bien sûr brute force a slr est intéressant mais les ligues d'information sont encore plus intéressantes typiquement tu trouves dans une application une ligue d'information mais c'est bien surtout pour les vulnérabilités locales d'avoir un ligue d'information de tout le système il y a pas mal de ce genre de choses dans qnx donc le premier ligue d'information c'est le procfs ligue d'information et on l'a exploité parce que qnx a un file system processus donc il y a un processus de file system donc on peut utiliser l'API donc on peut savoir la valeur des registres on peut utiliser le mapping des registres ce que l'on voit ces valeurs ne se soucie pas des privilèges ils sont lisibles donc on peut écrire une application très simple qui prend les privilèges regarde le layout de la mémoire et puis c'est encore plus facile d'en inclus dans qnx l'utilité PID qui donne cette fonctionnalité par défaut donc si vous avez juste la chance vous pouvez avoir cette utilité que vous pouvez lancer donc le deuxième ligue il est dans les variables de debug c'est une variable d'environnement qui peut spécifier des requêtes de debugging et si on choisit toutes les options on a plein d'informations de debug et entre autres les adresses des librairies partagées et ce qui est intéressant sur linux ou sur BST cette option a des privilèges donc si on essaie de faire ça pour cette UID et on n'est pas à le route il ne va pas donner cette information mais sur qnx il n'y a pas de checks sur les privilèges il y a une option et exploiter cette UID donc après que nous ayons dit cela ils ont fait des améliorations dans qnx 7 et qnx 7 a toujours à slr désactivé mais ils utilisent un autre prng de kernels que nous avons dit tout à l'heure et ça c'est bien plus fort parce que malgré tout ça malgré qu'ils ont un adresse space de 64 bit ils ont oublié d'enlever ce masking pour la fonction de randomisation donc en fait ils ont 7 bits d'entropie pour le stack address ils n'ont pas assez de bits d'entropie en fait pour l'adresse de stack un autre chose intéressante sur la droite de la slide c'est la memory code est chargée dans l'adresse space dans le bas de l'adresse space dans les premiers 32 bits donc ils ont fixé la variable de debug mais pour les attaqueurs ils n'ont pas complètement tout réparé donc sur procfs ils n'ont pas réparé donc on peut toujours utiliser la utility on ne peut plus utiliser la tidy mais on peut toujours écrire un petit truc pour s'octroyer une élévation de privilège et récupérer les informations le prochain évitement d'attaque c'est les stacks canaries donc stacks canaries qui sont utilisés pour les overflow ceux qui ne connaissent pas cela ça marche comme ça vous générez des canaries value c'est d'un nombre aléatoire vous le mettez entre les variables locales vous l'insérez et vous sauvez l'adresse sur le stack donc vers les metadata donc quand un attaqueur va attaquer l'adresse de retour de la fonction donc là il va le canary donc le canary va être comparé et au lieu de retourner à l'adresse safe c'est prévu il va voir qu'il a été réécrit donc QNX utilise une implementation de stacks canaries qui s'appelle stacks matching protector donc du côté compiler c'est bon mais du côté système d'exploitation c'est fait main c'est custom donc les master canaries de user space générer au départ du programme c'est épsé et chargé donc sur différentes plateformes ils ont différentes implementations mais c'est souvent la même chose sur Linux par exemple mais QNX il a une fonction init cookies et c'est là où est le problème parce que c'est encore un générateur de nombre aléatoire qui est faible donc il utilise les cycles les variables l'adresse de la fonction et donc ça contribue pas vraiment d'entropie ouais l'entropie est trop faible c'est là le fond du problème donc on a décidé d'évaluer 3 configurations sans ASLR avec ASLR et avec ASLR une autre et un setting particulier et on a vu l'entropie minimum était de 7,79 bits mais c'est pas idéal parce qu'ils auraient dû avoir au moins 24 bits d'entropie minimum surtout qu'ils ont une nulle byte une octenule en fait c'est un problème à cause des attaques de brute force dans le kernel space le problème est encore pire parce que le micro kernel n'est pas lié n'est pas linké à libc donc ils auraient dû l'implémenter dans le kernel mais ils ont oublié de le faire donc le micro kernel est protégé par avoir à plusieurs fonctions qui utilisent les stack canaries mais les stack canaries ne sont pas initialisés donc évidemment c'est toujours les mêmes donc ça ne ça n'avance à rien donc on a dit ça à blackberry et maintenant les stack canaries sont activés par défaut et ils génèrent sur un voilà et ils ont une valeur basée sur les best practices ils prennent un nombre aléatoire de 64 bits ils le transportent au processus user space pour le mélanger avec leur cookie ding leur truc cookie et ensuite ils utilisent et ils créent le canary ils créent un canary plus fort beaucoup plus fort ils ont réparé ce problème ça nous amène aux dernières stratégies d'évitement d'explore donc ce que vous pouvez voir c'est que la relocation read-only donc si vous avez une fonction qui est pendant le runtime et vous avez une librairie partagée donc ce sera voilà vous l'avez utilisé donc c'est un angle d'attaque assez populaire car vous avez des adresses statiques malgré asr donc vous pouvez hijacker le flow de contrôle donc relro a été inventé donc les données et les programmes voilà il y a des relocations où en fait la partie de la mémoire où il y a le programme et la partie de la mémoire où il y a l'adresse et a été replacé donc pendant le programme donc la table de offset va rester editable pendant le runtime donc comment ils font ils vont désactiver le lazy binding ils ont implementé ça sur QNX6 c'est pas mal mais leur implementation est cassée comme on voit sur la gauche c'est sur des biens c'est la façon dont c'est bien vous avez vous avez les sections programmes et les sections adresses et sur la droite le QNX6 c'est pour la même application donc certaines des sections de données sont avant les sections de programmes et l'un droit le plus intéressant n'est pas précédé ne précèdent pas les données en fait ils sont pas bien placés, les blogs devraient être placés d'une autre façon ils sont pas bien placés donc on est encore vulnérables aux attaques et donc la cause c'est la section de linker et donc en pratique ça a l'air ça vous avez des biens et on ne peut plus sur des biens c'est bien implementé et sur QNX c'est mal implementé donc c'est cassé donc en plus de ça on a trouvé un bypass local donc toujours ce ld debug il y a une fonction qui s'appelle on a une on a une élevation de privilège possible donc pour utiliser les 7uid les binaires 7uid il y a beaucoup de ce genre de choses dans l'histoire de QNX ces deux problèmes ont été rapportés à Blackberry et ils l'ont réparé avec des patchs et donc dans QNX7 c'est bon cela nous amène aux dernières remarques nous avons donné tous ces problèmes à Blackberry ils ont réparé la plupart des choses il y a des patchs qui sont disponibles et vous pouvez le voir dans le lien en bas un avertissement quand même tous les attaqueurs et les défendeurs oui d'accord il y a des systèmes qui sont intégrés donc jusqu'à ce qu'ils aient les patchs cela peut durer longtemps donc les mises à jour ne sont pas forcément mises en place partout donc en conclusion la plupart des évitements d'exploit sont bien du côté de la toolchain c'est un problème des systèmes d'exploitation intégrés en fait parce que QNX ne peut pas être si on fait quelque chose sur un système d'exploitation normal cela ne peut pas être appliqué directement sur QNX parce que ce n'est pas la même architecture donc ils ne finissent pas faire des trucs un peu fait maison pour éviter les exploits mais ce n'est pas forcément le mieux donc il y a beaucoup de vulnérabilités qu'on trouve là parce que les recherches les gens qui font de la recherche n'ont pas fait attention donc attention les générateurs de nombres aléatoires intégrés ça reste un sujet difficile rien que par le design de ce produit donc il faut le savoir donc maintenant quelque chose de positive QNX essaie de rester à la hauteur à la hauteur de la sécurité des systèmes d'exploitation généraux et ils répondent assez rapidement BlackBerry intègre notre feedback dans leur code, dans leur patch donc j'aimerais bien que vous ayez votre attention à la sécurité des systèmes intégrés dans les voitures c'est des systèmes très critiques des systèmes militaires donc intéressez vous nous allons continuer à nous intéresser à QNX et nous allons continuer à vous informer si vous avez des questions les questions du public merci Ali à Bazi merci beaucoup maintenant nous avons du temps pour les questions réponses venez devant les microphones, si vous avez une question à poser je suis l'auteur de ce que vous avez fait sur une des slides c'était je suis vraiment désolé quelle est votre nom une autre question peut-être bien une autre question pour le problème où les stacks canaries n'étaient pas mis en place comme il faut c'était un problème initial où c'est où ils n'ont pas été pris du storage pour être mis au bon endroit donc le problème c'est la façon dont ils l'ont implémenté ils n'ont pas d'initialisation pour le master canary donc la référence de la canary est là mais il n'est pas initialisé parce que le micro kernel les stacks canaries du micro kernel étaient dans le bss qui était initialisé par 0 donc en fait c'était toujours 0 donc ils l'ont utilisé mais ils n'ont pas initialisé donc en fait si le canary est toujours 0 c'est comme si on n'avait pas est-ce que quelqu'un d'autre à une question ne soyez pas timide quelqu'un s'approche du micro non bien s'il n'y a plus de questions merci beaucoup pour votre conférence très intéressante voilà et il est temps pour nous