tag:blogger.com,1999:blog-5471711588314667861.post2508533031588321614..comments2022-04-06T21:33:12.837+02:00Comments on LeFAuxPlat: ASLR (Accélère? Vasistas?)lefahttp://www.blogger.com/profile/17406391448072605501noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-5471711588314667861.post-20434903438321561292014-03-12T23:15:30.795+01:002014-03-12T23:15:30.795+01:00TH. Cela donne du coup une bonne base pour s'i...TH. Cela donne du coup une bonne base pour s'intéresser aux architectures et programmes 64 bits lorsqu'il s'agit d'aborder ce sujet de sécurité (En outre, essayer des combinaisons de compilation en 32 bits/64 bits, porter des programmes 32 bits sous système 64 bits, etc.).Florent Yunoreply@blogger.comtag:blogger.com,1999:blog-5471711588314667861.post-19669261415515011802014-03-12T09:51:25.814+01:002014-03-12T09:51:25.814+01:00En fait, il y a plusieurs types de protections con...En fait, il y a plusieurs types de protections contre les débordement de tampon dans la pile:<br /> - les canaris (gcc -fstack-protector), mais certaines attaques peuvent inclure les canaris, donc efficacité pas garantie<br /> - l'interdiction d'exécution de code dans la pile (NX et autres variantes). Encore faut-il que l'application n'ait pas besoin d'exécuter du code généré dynamiquement dans la pile.<br /> - ASLR (j'y reviens après)<br /><br />L'exploitation d'un débordement de tampon, peut se faire de différentes manières:<br /> - injection d'un "shellcode" : la chaine va contenir le code de l'attaque. Et on va dérouter le programme vers ce code <br /> (en écrasant l'adresse de retour). Il faut alors avoir une "idée" de l'adresse du tampon pour trouver le code. On interdit ça<br /> effectivement avec les interdictions d'exécuter du code en pile (NX bit)<br /> - attaque de type "return-to-libc" (http://fr.wikipedia.org/wiki/Return-to-libc_attack) auquel cas la protection NX est inopérante.<br /> Dans ce cas, on déroute le programme vers une fonction de la libc ("Facile", elles sont toutes à disposition grâce aux librairies<br /> partagées!) Comme souvent les librairies partagées sont mappées à une adresse qui ne varie pas, les adresses sont faciles à <br /> déterminer. D'où l'introduction du mécanisme ASLR pour rendre les adresses de librairies (mais aussi des tampons dans la pile) <br /> plus difficile à déterminer. <br /><br />HTHlefahttps://www.blogger.com/profile/17406391448072605501noreply@blogger.comtag:blogger.com,1999:blog-5471711588314667861.post-44987092887399626812014-03-11T21:33:19.350+01:002014-03-11T21:33:19.350+01:00Merci pour le billet. La première chose que j'...Merci pour le billet. La première chose que j'ai pensé concerne les "protections" qu'on trouve au niveau CPU au sujet des dépassement de tampon (NX Bit je crois). Une protection plus efficace ?Florent Yunoreply@blogger.comtag:blogger.com,1999:blog-5471711588314667861.post-79835699678275815802014-03-04T15:41:32.476+01:002014-03-04T15:41:32.476+01:00Oui j'en avais déduit la même chose pour l'...Oui j'en avais déduit la même chose pour l'indirection de printf() sans vouloir creuser pour ne pas noyer la discussion, mais la remarque est pertinente! Pour le tas, j'étais moyennement surpris, disons c'est moins "surprenant" que pour printf(), l'essentiel était respecté : l'adresse est supérieure à celle des globales. Merci François pour ces précisions...DjiBeehttps://www.blogger.com/profile/16540685689159833868noreply@blogger.comtag:blogger.com,1999:blog-5471711588314667861.post-12662393495159726462014-03-02T17:55:31.600+01:002014-03-02T17:55:31.600+01:00Il y a deux petites surprises cachées dans le résu...Il y a deux petites surprises cachées dans le résultat sur "nivose" (SunOS):<br /> - l'adresse imprimée par le programme pour le tas peut surprendre.<br /> - l'adresse imprimée pour printf, n'est manifestement pas dans une zone de code!<br /><br />Si on ajoute un pause() à la fin du programme et qu'on en profite pour faire pmap pid, et voir l'espace d'adressage du processus, <br />on va voir que ces 2 adresses sont dans la même page (8KB sur SPARC) que les variables globales<br /><br />En fait, le tas démarre directement à la fin des données dans la dernière page des données globales. Si on ajoute un tableau de 7800 caractères pour occuper plus d'espace, l'adresse rendue par malloc va bien se retrouver dans la région suivante affichée par pmap.<br /><br />Le résultat de pmap montre que les bibliothèques dynamiques ne sont pas du tout à l'adresse imprimée. Je suppose qu'on doit probablement imprimer l'adresse d'une indirection. <br /><br />lefahttps://www.blogger.com/profile/17406391448072605501noreply@blogger.comtag:blogger.com,1999:blog-5471711588314667861.post-78385264104296418432014-03-01T16:53:08.727+01:002014-03-01T16:53:08.727+01:00Ah, cours de M2 Systèmes Avancés d'il y a une ...Ah, cours de M2 Systèmes Avancés d'il y a une semaine! :-)<br />Merci pour le complément!<br /><br />C'est effectivement fait pour ajouter un peu d'entropie de manière à ce que les attaques par buffer overflow, aient un peu plus de difficultés à trouver l'adresse du buffer écrasé dans la pile, et que les attaques de type return-to-libc aient un peu plus de mal à trouver les adresses dans la libc. <br /><br />Sur des architectures 32 bits, les analyses semblent montrer que la protection est quasi inefficace, les variations étant limitées. Sur 64 bits, l'effet de retardement des attaques est un peu meilleur, les possibilités de variations étant plus grandes.<br /><br />Sur Linux seuls la pile et les bibliothèques sont atteintes de bougeotte en cas d'ASLR. Sur Windows, et si je comprends bien sur Darwin, le code et les données sont aussi susceptibles d'avoir des adresses variables. <br /><br />Dans Linux, ça serait intéressant de regarder les effets de l'ASLR, avec les variations sur les espaces d'adressages "classiques" et "flexibles". lefahttps://www.blogger.com/profile/17406391448072605501noreply@blogger.com