• # Quelques commentaires

    Posté par (site web personnel) . En réponse à la dépêche Exploit local dans le noyau Linux 2.6.30. Évalué à 10.

    >>> Brad profite de l'exploit pour dire tout le mal qu'il pense de la gestion de la sécurité dans le noyau Linux

    Brad a toujours été hyper-critique sur la sécurité du noyau Linux. Il faut bien voir que son gagne pain c'est grsecurity c'est à dire un patch de sécurité à appliquer sur le noyau vanilla. Il a donc tout intérêt à dénigrer le noyau normal afin de souligner la plus-value de son patch.
    Donc il faut prendre ce qu'il dit avec un gros grain de sel.
    Néanmoins on est forcé de constater que ses déclarations ont plus de force quand elles sont accompagnés d'un exploit 0-day qui passe à travers SELinux ;-)

    Il faut vraiment lire tout le blabla qu'il a mis en commentaire du fichier exploit.c car c'est très instructif sur le coté technique de la faille mais aussi sur le personnage qu'est Brad.
    Ce qui m'a étonné c'est qu'il colle des extraits de mails issus de la liste de diffusion vendor-sec.
    Cette liste est faite pour que des informations circulent entre les développeurs et les entreprises du libre au sujet des problèmes de sécurité. Bien entendu la liste est privée et dévoiler ainsi des mails privés comme le fait Brad est plus qu'impoli. Je me demande même si ce n'est pas illégal.

    Il faut savoir que Brad avait commencé par poster des vidéos de son exploit à l'oeuvre mais sans donner de détails techniques. Dans les commentaires d'exploit.c il se délecte de lire les échanges de mails sur vendor-sec (en ne donnant pas le nom du type qui lui a fourni les mails) ou les gens essayent, en ayant la vidéo pour seule information, de comprendre d'ou peut bien venir la faille.
    Il distribue les bons points et les mauvais points en fonction des analyses proposés, il casse du sucre sur le dos de Linus Torvalds, qualifié d'expert sécurité en fauteuil (arm-chair security expert) et enfin il balance un paragraphe final sur la sécurité du noyau qui serait déplorable.

    Ci-dessous je traduis l'ironique paragraphe d'introduction et le paragraphe final (je refuse de traduire les mail privés de vendor-sec).

    "Un mec monté sur son cheval m'a apporté ces informations : toutes mes félicitations aux membres de vendor-sec pour leur excellente analyse de la vidéo de mon exploit, dans la même veine que leurs analyses des vulnérabilités du noyau. Regardez les maitres à l'oeuvre".

    "Aux membres de vendor-sec : Même si vous ne me remercierez jamais (ou sgrakkyu ou Julien) vous êtes les bienvenus pour toute cette recherche gratuite dans le domaine de la sécurité qui aurait aussi bien pu être vendue dans le privé à la place. L'industrie (NdT : le marché des exploits) n'est plus ce qu'elle était en 2000, les gens ne publient plus les exploits maintenant : ils font du fric avec.
    Ne pas voir débouler des exploits ne signifie donc pas que vous faites du bon travail. Avez-vous noté les exploits très complexes qui apparaissent impossiblement rapidement juste après qu'une faille soit finalement patchée ? Il y a une raison pour ça.
    Si le code vulnérable avait été incorporé dans le 2.6.29 au lieu de l'être dans le 2.6.30 je n'aurai pas publié mon exploit. Je n'ai pas l'utilité de cet exploit...mais une bonne poilade ne se refuse jamais.
    - Ma suggestion est que vous engagiez des gars comme sgrakkyus ou Julien plutôt que ces vieux qui n'ont jamais écrit un exploit de toute leur vie. A part Stealth je ne connais personne de doué dans cette industrie et qui soit employé par vous.
    - Deuxième suggestion : Comme vous êtes des compagnies qui poussent l'open source et le logiciel libre ce serait bien si les justifications pour vos classifications de vulnérabilités étaient plus transparentes (ou même qu'elle soient publiées tout simplement). La vieille habitude que vous avez de classifier toute faille pour laquelle un exploit n'a pas été écrit en Denial of Service devient très fatigante et ne trompe plus personne.
    - Troisièmement, la politique officielle qui consiste à ne pas mentionner les informations qui concernent la sécurité lors des modifications du code de Linux est une honte et un mauvais service que vous rendez à vous même, aux autres vendeurs et à vos clients. Cela démontre un manque d'intégrité et de confiance dans vos propres produits. Je sais que vous n'avez aucune intention de changer cette politique puisque vous profitez grâce à celle-ci d'une réputation de sécurité indue et qui ne se base pas sur la réalité. Dire la vérité sur les vulnérabilités de vos logiciels ternirait votre image et ce n'est pas bon pour le business. Vous êtes félicités quand vous dissimulez des choses et pourtant c'est Microsoft qui à une mauvaise réputation.
    Si vous suivez les conseils que je vous donne alors peut-être que votre sécurité ne sera plus la risée de toute l'industrie
    ".

    A noter, pour répondre à une partie des critiques de Brad, que les mainteneurs des versions stables des noyaux se refusent à classer les corrections de bugs en fonction de critères de sécurité car pour eux il n'est pas possible de savoir à l'avance toutes les implications en matière de faille d'un bug donné.
    Brad affirme que cette politique de non classification empêche les gens de faire des choix quand aux corrections à appliquer et les mainteneurs lui répondent qu'il n'y a pas de choix à faire et qu'il faut de toute façon appliquer toutes les corrections.

    Bien malin celui qui peut dire qui a raison et qui a tort dans cette controverse, si les développeurs du noyau sont suffisamment attentifs aux problèmes de sécurité ou pas, si la réputation de Linux est vraiment surfaite ou si Brad exagère afin de pousser sa solution.
    Les pauvres péons que nous sommes sont bien en peine de trier et d'évaluer vraiment les affirmations des uns et des autres...mais en tout cas la controverse est lancée et la situation ne peut que s'améliorer.