Au risque de marteler le message, je peux également signaler que je ne me suis pas réabonné a linux magazine à cause de la disparition du CD...
Et sans vouloir être désagréable, je me demande si plaider le bien du plus grand nombre pour ne plus proposer cette offre est honnete... La formule sans cd n'était elle pas moins rentable tout simplement ?
Les autres points qui m'ont poussé à ne pas renouveler mon abonnement sont les suivants :
-La part non technique du contenu devenait trop importante ( a ce sujet le transfert de certains articles vers linux pratique est une excellente chose)
-Les coquilles dans les articles techniques ne faisaient jamais l'objet d'errata meme lorsqu'elles etaient grossières et signalées...
Voila, enfin comme le signalait pappy qui, pour sa part, parvient a maintenir sa revue MISC à un excellent niveau, on est libre de s'abonner ou pas...
Voici donc les torts réparés ! ;))
Plus sérieusement, exec shield méritait tout de même une image un peu plus reluisante. D'autant qu'ingo Molnar ne cache absolument pas les limites de son patch. Par contre, contrairement à toi julien, je trouve ce patch très bien fait : le ratio (protection apportée) / (volume de code et overhead) me semble très bon... Mais oui, je le redis, dans le cas très improbable où cela aurait échappé aux lecteurs, PaX, dans sa forme complète, protège beaucoup mieux.. (Aborder l'aspect qualitatif de comment cela est réalisé est totalement distinct n'est ce pas ? )
Tu as raison de remarquer que la politique de Redhat ne permet pas encore de tirer le meilleur d'exec shield mais il ne faut pas non plus forcement associer exec shield à une distrib redhat : Le patch s'applique à un kernel vanilla sans aucun pb...
Enfin, pour l'article de Nergal, j'en avais bien compris la teneur et avais bien souligné que les techniques s'appliquaient aux deux patchs... Je reprochais simplement de le présenter seulement à charge d'exec shield alors qu'il s'agit de faiblesses communes...
J'espère tout au moins que ces discussions auront donné envie à quelques lecteurs d'appliquer l'un de ces patchs... ;-)
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: La présence du CD
Posté par gary . En réponse à la dépêche GNU/Linux Magazine France n°56. Évalué à 2.
Et sans vouloir être désagréable, je me demande si plaider le bien du plus grand nombre pour ne plus proposer cette offre est honnete... La formule sans cd n'était elle pas moins rentable tout simplement ?
Les autres points qui m'ont poussé à ne pas renouveler mon abonnement sont les suivants :
-La part non technique du contenu devenait trop importante ( a ce sujet le transfert de certains articles vers linux pratique est une excellente chose)
-Les coquilles dans les articles techniques ne faisaient jamais l'objet d'errata meme lorsqu'elles etaient grossières et signalées...
Voila, enfin comme le signalait pappy qui, pour sa part, parvient a maintenir sa revue MISC à un excellent niveau, on est libre de s'abonner ou pas...
[^] # 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é à 1.
Plus sérieusement, exec shield méritait tout de même une image un peu plus reluisante. D'autant qu'ingo Molnar ne cache absolument pas les limites de son patch. Par contre, contrairement à toi julien, je trouve ce patch très bien fait : le ratio (protection apportée) / (volume de code et overhead) me semble très bon... Mais oui, je le redis, dans le cas très improbable où cela aurait échappé aux lecteurs, PaX, dans sa forme complète, protège beaucoup mieux.. (Aborder l'aspect qualitatif de comment cela est réalisé est totalement distinct n'est ce pas ? )
Tu as raison de remarquer que la politique de Redhat ne permet pas encore de tirer le meilleur d'exec shield mais il ne faut pas non plus forcement associer exec shield à une distrib redhat : Le patch s'applique à un kernel vanilla sans aucun pb...
Enfin, pour l'article de Nergal, j'en avais bien compris la teneur et avais bien souligné que les techniques s'appliquaient aux deux patchs... Je reprochais simplement de le présenter seulement à charge d'exec shield alors qu'il s'agit de faiblesses communes...
J'espère tout au moins que ces discussions auront donné envie à quelques lecteurs d'appliquer l'un de ces patchs... ;-)
[^] # 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" ...