Je pense qu'ils sont au courrant de ces craintes, car ils ont publié non seulement le code source, mais aussi tout le design rationale de FLASK et de leur système de type enforcement.
De ce fait, leur produit me semble parfaitement auditable, tout comme le sont par exemple les systèmes de crypto du monde entier proposés pour AES.
Il était très bon de parler de l'existance d'exec-shield pour le noyau 2.6, en fait je n'étais pas au courrant.
Tu ne sombres pas du tout dans le troll et tu as raison: en ce qui concerne le noyau 2.6 uniquement, exec-shield n'est pas surpassé par ASLR26 comme c'est le cas pour le noyau 2.4 entre exec-shield et PaX, qui lui offre beaucoup plus qu'exec-shield et beaucoup mieux fait (notamment garantie de l'impossibilité d'introduction d'un nouveau code exécutable dans l'espace d'adressage du processus, ce qui inclue une protection contre un mprotect() -sauf par mmap PROT_EXEC d'un fichier exécutable appartenant à l'attaquant, ce qui doit être restreint par un AC-)
En ce qui concerne un système ET_DYN, Redhat a poussé l'effort jusqu'à inclure dans la nouvelle version de ld un switch -pie permettant de générer de l'ET_DYN exécutable, effort fort louable mais qui n'a malheureusement pas été suivi ensuite par la distribution. Mais même dans le cas d'ET_DYN le patch ne pourra pas rendre non exécutable toutes les données à cause des limitations que j'ai déjà citées, et il n'est également pas vraiment prévu pour traiter séparément les exécutables ET_DYN: par chance, ceux-ci finiront quand même dans l'armure ASCII car les linkers mettent toujours leur base adresse à 0, cependant cela risque de poser des problèmes de "place", notamment a cause de la section .bss.
Quant à l'article de Nergal, il étudie en fait la faiblesse de tous les systèmes relogeant le code exécutable dans le cas des ET_EXEC, en expliquant qu'il n'est pas possible de reloger le GOT/PLT d'un ET_EXEC et que cela peut ête utilisé pour retourner où l'on veut (y compris localiser des fonctions dont l'adresse a été rendue aléatoire). Il s'applique donc tant à PaX qu'à exec-shield. La différence pour PaX est qu'il dispose déjà de plusieurs distributions entièrement ET_DYN qui lui sont dédiées, alors que Redhat semble avoir fait beaucoup de pub pour exec-shield dans leur distribution serveur mais n'a pas adapté sa distribution à son produit., espérons que cela changera!
Exec-shield est toutefois un "bon petit patch", il offre une meilleure protection de l'espace d'adressage qu'OpenWall qui est pourtant très utilisé car il a été prouvé qu'il repoussait beaucoup de script kiddies, il sera donc lui aussi efficace sur ce tableau.
Il est tout à fait juste que l'information leaking rend l'ASLR caduque (j'ai d'ailleurs mentionné ce problème dans ma réponse au post de free2 ci dessous), l'information leaking peut même être réalisé facilement sans aucun bug du programme lui même si l'attaquant a un compte local via /proc/pid/maps ou stats (d'ou le PaX obscurity patch qui sera inclu dans aslr26 cette semaine).
Cependant je pense qu'il est un peu exagéré de dire qu'elle ne sert presque à rien dans le cas des format strings. En effet il est clairement possible de dumper la pile dans le cadre de format strings, mais il n'est pas toujours possible d'obtenir par ce moyen toutes les adresses que l'on veut. On peut toutefois généralement assez facilement dumper la pile assez loin pour obtenir l'adresse de retour dans __libc_start_main et en déduire ainsi la position de la libc, mais il ne sera par contre pas toujours facile d'obtenir l'adresse absolue d'une adresse de retour ou d'un pointeur de fonction à modifier à l'aide de la format string. On peut également tenter d'afficher "au hasard" des adresses et voir ce qu'on n'y trouve, mais ce n'est pas toujours facile, et si on plante le processus, tout est à refaire (l'espace d'adressage sera différent au relancement).
De plus, si on doit fonctionner en deux temps (afficher l'adress space, puis l'exploiter), cela réduit les cibles potentielles, en effet, seul les démons réalisant un fork() pourront être des cibles, car les autres programmes, une fois relancés auront leur espace d'adressage à nouveau randomizé.
La principale limitation de cette protection est à mon avis que la majorité des utilisateurs ne relinkera pas forcément ses exécutables sensibles en ET_DYN, rendant ainsi la protection beaucoup moins effective et vulnérabe à un return-to-PLT suivi d'un dl-resolve() par exemple.
Il est de toute façon clair qu'il s'agit là d'un patch simple qui ne peut que "améliorer les choses" en attendant que le reste de PaX soit porté. (Je m'attelerai peut être à PAGEEXEC -sur les archis suporant le bit d'exécution- et MPROTECT dans une semaine ou deux, SEGMEXEC sur noyau 2.6 ne verra certainement pas le jour avant plusieurs mois)
Il ne peut réaliser qu'une version "opportuniste" des pages non exécutables sur architecture i386. Si une zone exécutable doit être située dans l'espace d'adressage linéaire apres une zone non exécutable, alors cette zone non exécutable sera exécutable.
Pour réduire les défauts de cette implémentation, exec-shield essaie de mapper les zones exécutables le plus bas possible en mémoire, (et même dans l'ascii armor a fin d'éviter des return to libc). Cependant, cela n'est pas toujours possible, par exemple dans le cas d'exécutable ET_EXEC (cas de tous les ELFs dans toutes les distributions sauf Adamantix et Trusted Gentoo).
L'autre problème est que l'ascii armor ne stopera pas forcément les return to libc, en effet, à cause du manque d'information de relocation, exec-shield ne peut pas remapper le GOT/PLT d'un fichier ET_EXEC, ces parties ne seront donc pas dans l'armure ascii, il existe des techniques permettant d'attendre l'armure ascii depuis le GOT/PLT à l'aide d'enchainement de return-to-libc (cf. article de Nergal dans phrack).
Comparons ce qui est comparable, PaX n'est pas disponible sur noyau 2.6, seule une partie (l'address space layout randomization l'est). Même dans ce cas, l'ASLR constitue un modèle viable et "autonome" si utilisé avec des exécutables ET_DYN (il est très facile de relinker des exécutables vers ET_DYN) et une solution comme SEGVGUARD alors que exec-shield est toujours assez facilement contournable. Cependant l'ASLR a le defaut de l'information leaking que n'a pas exec-shield: il peut exiter des bugs qui semblent bénins et qui permettent de récupérer les adresses des structures du programme.
Pour résumer: si vous avez un système ET_DYN, ASLR26 sera certainement mieux que exec-shield26, dans les autres cas, les deux permetteront d'empcher certains exploits publiques de marcher. Si vous avez un noyau 2.4, PaX est par contre clairement la meilleure solution.
[^] # Re: ASLR pour le noyau 2.6
Posté par Julien . En réponse à la dépêche ASLR pour le noyau 2.6. Évalué à 2.
De ce fait, leur produit me semble parfaitement auditable, tout comme le sont par exemple les systèmes de crypto du monde entier proposés pour AES.
[^] # Re: autre patch sans controle d'accès pour le noyau 2.6
Posté par Julien . En réponse à la dépêche ASLR pour le noyau 2.6. Évalué à 1.
Tu ne sombres pas du tout dans le troll et tu as raison: en ce qui concerne le noyau 2.6 uniquement, exec-shield n'est pas surpassé par ASLR26 comme c'est le cas pour le noyau 2.4 entre exec-shield et PaX, qui lui offre beaucoup plus qu'exec-shield et beaucoup mieux fait (notamment garantie de l'impossibilité d'introduction d'un nouveau code exécutable dans l'espace d'adressage du processus, ce qui inclue une protection contre un mprotect() -sauf par mmap PROT_EXEC d'un fichier exécutable appartenant à l'attaquant, ce qui doit être restreint par un AC-)
En ce qui concerne un système ET_DYN, Redhat a poussé l'effort jusqu'à inclure dans la nouvelle version de ld un switch -pie permettant de générer de l'ET_DYN exécutable, effort fort louable mais qui n'a malheureusement pas été suivi ensuite par la distribution. Mais même dans le cas d'ET_DYN le patch ne pourra pas rendre non exécutable toutes les données à cause des limitations que j'ai déjà citées, et il n'est également pas vraiment prévu pour traiter séparément les exécutables ET_DYN: par chance, ceux-ci finiront quand même dans l'armure ASCII car les linkers mettent toujours leur base adresse à 0, cependant cela risque de poser des problèmes de "place", notamment a cause de la section .bss.
Quant à l'article de Nergal, il étudie en fait la faiblesse de tous les systèmes relogeant le code exécutable dans le cas des ET_EXEC, en expliquant qu'il n'est pas possible de reloger le GOT/PLT d'un ET_EXEC et que cela peut ête utilisé pour retourner où l'on veut (y compris localiser des fonctions dont l'adresse a été rendue aléatoire). Il s'applique donc tant à PaX qu'à exec-shield. La différence pour PaX est qu'il dispose déjà de plusieurs distributions entièrement ET_DYN qui lui sont dédiées, alors que Redhat semble avoir fait beaucoup de pub pour exec-shield dans leur distribution serveur mais n'a pas adapté sa distribution à son produit., espérons que cela changera!
Exec-shield est toutefois un "bon petit patch", il offre une meilleure protection de l'espace d'adressage qu'OpenWall qui est pourtant très utilisé car il a été prouvé qu'il repoussait beaucoup de script kiddies, il sera donc lui aussi efficace sur ce tableau.
[^] # Re: ASLR pour le noyau 2.6
Posté par Julien . En réponse à la dépêche ASLR pour le noyau 2.6. Évalué à 1.
Cependant je pense qu'il est un peu exagéré de dire qu'elle ne sert presque à rien dans le cas des format strings. En effet il est clairement possible de dumper la pile dans le cadre de format strings, mais il n'est pas toujours possible d'obtenir par ce moyen toutes les adresses que l'on veut. On peut toutefois généralement assez facilement dumper la pile assez loin pour obtenir l'adresse de retour dans __libc_start_main et en déduire ainsi la position de la libc, mais il ne sera par contre pas toujours facile d'obtenir l'adresse absolue d'une adresse de retour ou d'un pointeur de fonction à modifier à l'aide de la format string. On peut également tenter d'afficher "au hasard" des adresses et voir ce qu'on n'y trouve, mais ce n'est pas toujours facile, et si on plante le processus, tout est à refaire (l'espace d'adressage sera différent au relancement).
De plus, si on doit fonctionner en deux temps (afficher l'adress space, puis l'exploiter), cela réduit les cibles potentielles, en effet, seul les démons réalisant un fork() pourront être des cibles, car les autres programmes, une fois relancés auront leur espace d'adressage à nouveau randomizé.
La principale limitation de cette protection est à mon avis que la majorité des utilisateurs ne relinkera pas forcément ses exécutables sensibles en ET_DYN, rendant ainsi la protection beaucoup moins effective et vulnérabe à un return-to-PLT suivi d'un dl-resolve() par exemple.
Il est de toute façon clair qu'il s'agit là d'un patch simple qui ne peut que "améliorer les choses" en attendant que le reste de PaX soit porté. (Je m'attelerai peut être à PAGEEXEC -sur les archis suporant le bit d'exécution- et MPROTECT dans une semaine ou deux, SEGMEXEC sur noyau 2.6 ne verra certainement pas le jour avant plusieurs mois)
[^] # Re: autre patch sans controle d'accès pour le noyau 2.6
Posté par Julien . En réponse à la dépêche ASLR pour le noyau 2.6. Évalué à 5.
Il ne peut réaliser qu'une version "opportuniste" des pages non exécutables sur architecture i386. Si une zone exécutable doit être située dans l'espace d'adressage linéaire apres une zone non exécutable, alors cette zone non exécutable sera exécutable.
Pour réduire les défauts de cette implémentation, exec-shield essaie de mapper les zones exécutables le plus bas possible en mémoire, (et même dans l'ascii armor a fin d'éviter des return to libc). Cependant, cela n'est pas toujours possible, par exemple dans le cas d'exécutable ET_EXEC (cas de tous les ELFs dans toutes les distributions sauf Adamantix et Trusted Gentoo).
L'autre problème est que l'ascii armor ne stopera pas forcément les return to libc, en effet, à cause du manque d'information de relocation, exec-shield ne peut pas remapper le GOT/PLT d'un fichier ET_EXEC, ces parties ne seront donc pas dans l'armure ascii, il existe des techniques permettant d'attendre l'armure ascii depuis le GOT/PLT à l'aide d'enchainement de return-to-libc (cf. article de Nergal dans phrack).
Comparons ce qui est comparable, PaX n'est pas disponible sur noyau 2.6, seule une partie (l'address space layout randomization l'est). Même dans ce cas, l'ASLR constitue un modèle viable et "autonome" si utilisé avec des exécutables ET_DYN (il est très facile de relinker des exécutables vers ET_DYN) et une solution comme SEGVGUARD alors que exec-shield est toujours assez facilement contournable. Cependant l'ASLR a le defaut de l'information leaking que n'a pas exec-shield: il peut exiter des bugs qui semblent bénins et qui permettent de récupérer les adresses des structures du programme.
Pour résumer: si vous avez un système ET_DYN, ASLR26 sera certainement mieux que exec-shield26, dans les autres cas, les deux permetteront d'empcher certains exploits publiques de marcher. Si vous avez un noyau 2.4, PaX est par contre clairement la meilleure solution.
[^] # Re: ASLR pour le noyau 2.6
Posté par Julien . En réponse à la dépêche ASLR pour le noyau 2.6. Évalué à 1.
Cependant, tu as raison, cette solution doit être déployée avec un mécanisme tel que SEGVGARD afin de détecter d'éventuelles attaques "brute force".