Il se moque des améliorations liées à la sécurité dans le noyau Linux et insulte les développeurs noyau.
Tout d'abord, je tiens à préciser que le fait que je rapporte ses propos (ou ses vidéos) dans la catégorie sécurité (et les commentaires) ne veut pas dire que je cautionne son comportement. Je trouve son attitude, son égocentrisme et ses critiques gratuites à tout va déplacés.
En revanche, il faut noter que sur le plan de la réflexion en terme de sécurité, le projet grsecurity est très en avance sur la majeure partie des protections. Il faut donc absolument tenir compte de leurs arguments même si ils ne les expriment pas de la meilleure façon malheureusement.
Je pense que le travail de fond sur la randomization de l'espace d'adressage du noyau est une bonne chose.
Je pense que kASLR n'est pas une bonne idée. Les raisons sont simples et elles sont détaillés dans l'article sur le blog/forum de grsecurity :
- Le principe même d'ALSR est un cache misère et non pas une solution ;
- ASLR marche pour les processus parce les adresses mémoires changent à chaque exécution. Avec kASLR, ce n'est pas le cas, les adresses ne changent qu'au démarrage ;
- ASLR marche parce que l'intervalle disponible pour rendre les adresses mémoires aléatoires est très grand, donc les probabilités de trouver la bonne très faibles. Dans le cas de kASLR, l'intervalle est beaucoup plus petit : il est beaucoup plus facile de tomber sur la bonne adresse ;
- ASLR est efficace sur un système si et seulement si l'on dispose d'un mécanisme pour empêcher un programme en cours de brute force de s'exécuter après un certain nombre de crashs suspects. Ce n'est pas le cas de kASLR, puisqu'il est possible de faire crasher en continu un driver par exemple qui sera rechargé à nouveau et que l'on pourra continuer d'exploiter car les adresses ne sont changées qu'au démarrage de la machine. N'importe quel bug non fatal dans le kernel pourra être utilisé ainsi ;
- kASLR introduit de la complexité (inutile) dans le noyau au démarrage, lors du débogage...
il ferait mieux d'apprendre à communiquer avec les développeurs pour faire entrer ses grosses modifications GRSecurity dans le noyau.
On espère tous que cela se produira un jour. Je pense qu'il nous faut plutôt un courageux pour faire le boulot.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Siosm . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 10.
Tout d'abord, je tiens à préciser que le fait que je rapporte ses propos (ou ses vidéos) dans la catégorie sécurité (et les commentaires) ne veut pas dire que je cautionne son comportement. Je trouve son attitude, son égocentrisme et ses critiques gratuites à tout va déplacés.
En revanche, il faut noter que sur le plan de la réflexion en terme de sécurité, le projet grsecurity est très en avance sur la majeure partie des protections. Il faut donc absolument tenir compte de leurs arguments même si ils ne les expriment pas de la meilleure façon malheureusement.
Je pense que kASLR n'est pas une bonne idée. Les raisons sont simples et elles sont détaillés dans l'article sur le blog/forum de grsecurity :
- Le principe même d'ALSR est un cache misère et non pas une solution ;
- ASLR marche pour les processus parce les adresses mémoires changent à chaque exécution. Avec kASLR, ce n'est pas le cas, les adresses ne changent qu'au démarrage ;
- ASLR marche parce que l'intervalle disponible pour rendre les adresses mémoires aléatoires est très grand, donc les probabilités de trouver la bonne très faibles. Dans le cas de kASLR, l'intervalle est beaucoup plus petit : il est beaucoup plus facile de tomber sur la bonne adresse ;
- ASLR est efficace sur un système si et seulement si l'on dispose d'un mécanisme pour empêcher un programme en cours de brute force de s'exécuter après un certain nombre de crashs suspects. Ce n'est pas le cas de kASLR, puisqu'il est possible de faire crasher en continu un driver par exemple qui sera rechargé à nouveau et que l'on pourra continuer d'exploiter car les adresses ne sont changées qu'au démarrage de la machine. N'importe quel bug non fatal dans le kernel pourra être utilisé ainsi ;
- kASLR introduit de la complexité (inutile) dans le noyau au démarrage, lors du débogage...
On espère tous que cela se produira un jour. Je pense qu'il nous faut plutôt un courageux pour faire le boulot.