Bonjour,
Il faut certes noter les limites du patch exec-shield mais il était de très bon ton d'en rappeler l'existence pour le noyau 2.6 me semble t il...
D'autant que je trouve Julien un peu injuste avec cette solution. Il est certes avéré que PaX, dans sa forme complète, c'est à dire celle qui n'est disponible que pour le noyau 2.4 (ou 2.2, il me semble qu'il a été "backporté" pour i386) fournit une protection plus complète que Exec shield.
Cependant ne sombrons pas dans une approche trop partiale : exec shield est un patch très léger qui rend de facto des services louables au prix d'un overhead infime.
Il empêche bien entendu toute exécution de la pile et même s'il peut être pris à défaut pour les raisons déjà fort bien évoquées par Julien lorsque l'attaquant met en oeuvre des techniques de "return in lib(c)" plus ou moins évoluées, il n'en reste pas moins d'un déploiement simple, avec une possibilité de commander son niveau d'activation au boot ou encore dynamiquement via /proc/sys/kernel/exec-shield... Même sans prendre de mesures particulières (pas de nouvelle édition de lien etc...), il fournit donc un premier niveau de protection louable d'autant que la grande majorité des attaques sont menées par des script kiddies qui seront arrétés par une telle protection aussi imparfaite soit elle ... (Attention je ne veux pas dire qu'il faut pour autant considérer que l'on est à l'abri... Je remarque simplement que exec shield pourra déjouer les premières attaques triviales suite à la divulgation d'une vulnérabilité...)
Enfin, Pourquoi serait il "très facile de relinker des exécutables vers ET_DYN" lorsque l'on évoque PaX mais que le flag ET_EXEC empêchant la "relocation" de l'executable dans l'ASCII ARMOR pour exec shield est présenté comme une faiblesse insurmontable ? Pourquoi citer l'excellent article de nergal dans phrack (numero 58, article 4) pour dénigrer seulement exec-shield alors que le titre de l'article est tout de même : "The advanced return-into-lib(c) exploits: PaX case study " et que cet article expose comment mettre à défaut PaX (même s'il est indiscutable que les techniques sont utilisables pour exec-shield ...) ?
Voila, je ne cherche définitivement pas à troller ni à sombrer dans de stériles débats sur les meilleurs patchs de sécurité... De toutes facons, la meilleure protection comme le notait vanhu, c'est de programmer proprement. Je souhaitais simplement jouer quelques instants l'avocat d'exec-shied qui est lui aussi, comme la partie ASLR de PaX, "un patch simple qui ne peut que améliorer les choses" ...
[^] # Re: autre patch sans controle d'accès pour le noyau 2.6
Posté par gary . En réponse à la dépêche ASLR pour le noyau 2.6. Évalué à 3.
Il faut certes noter les limites du patch exec-shield mais il était de très bon ton d'en rappeler l'existence pour le noyau 2.6 me semble t il...
D'autant que je trouve Julien un peu injuste avec cette solution. Il est certes avéré que PaX, dans sa forme complète, c'est à dire celle qui n'est disponible que pour le noyau 2.4 (ou 2.2, il me semble qu'il a été "backporté" pour i386) fournit une protection plus complète que Exec shield.
Cependant ne sombrons pas dans une approche trop partiale : exec shield est un patch très léger qui rend de facto des services louables au prix d'un overhead infime.
Il empêche bien entendu toute exécution de la pile et même s'il peut être pris à défaut pour les raisons déjà fort bien évoquées par Julien lorsque l'attaquant met en oeuvre des techniques de "return in lib(c)" plus ou moins évoluées, il n'en reste pas moins d'un déploiement simple, avec une possibilité de commander son niveau d'activation au boot ou encore dynamiquement via /proc/sys/kernel/exec-shield... Même sans prendre de mesures particulières (pas de nouvelle édition de lien etc...), il fournit donc un premier niveau de protection louable d'autant que la grande majorité des attaques sont menées par des script kiddies qui seront arrétés par une telle protection aussi imparfaite soit elle ... (Attention je ne veux pas dire qu'il faut pour autant considérer que l'on est à l'abri... Je remarque simplement que exec shield pourra déjouer les premières attaques triviales suite à la divulgation d'une vulnérabilité...)
Enfin, Pourquoi serait il "très facile de relinker des exécutables vers ET_DYN" lorsque l'on évoque PaX mais que le flag ET_EXEC empêchant la "relocation" de l'executable dans l'ASCII ARMOR pour exec shield est présenté comme une faiblesse insurmontable ? Pourquoi citer l'excellent article de nergal dans phrack (numero 58, article 4) pour dénigrer seulement exec-shield alors que le titre de l'article est tout de même : "The advanced return-into-lib(c) exploits: PaX case study " et que cet article expose comment mettre à défaut PaX (même s'il est indiscutable que les techniques sont utilisables pour exec-shield ...) ?
Voila, je ne cherche définitivement pas à troller ni à sombrer dans de stériles débats sur les meilleurs patchs de sécurité... De toutes facons, la meilleure protection comme le notait vanhu, c'est de programmer proprement. Je souhaitais simplement jouer quelques instants l'avocat d'exec-shied qui est lui aussi, comme la partie ASLR de PaX, "un patch simple qui ne peut que améliorer les choses" ...