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)
[^] # 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)