Journal Les BSD sont‐ils tous égaux devant les bugs ?

Posté par (page perso) . Licence CC by-sa
Tags :
68
28
juil.
2017

J’ai découvert via le blog du développeur OpenBSD Ted Unangst (certificat auto‐signé), cette présentation d’Ilja van Sprundel au sujet des bogues noyau des BSD : https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf.

Cela commence par une petite citation de Theo de Raadt (datant de 2005) et qui affirme que les développeurs du noyau Linux ne se préoccupent pas vraiment de la qualité, à la différence des devs OpenBSD.

Si l’on regarde les CVE, on voit qu’effectivement les vulnérabilités noyau de Linux sont plus nombreuses que celles des BSD. Est‐ce parce que, comme l’affirme Theo, les devs Linux se foutent de la qualité et de la sécurité ? Est‐ce simplement parce qu’il y a beaucoup plus de lignes de code dans Linux ? Est‐ce parce qu’il y a beaucoup plus de relecteurs de code (eyeballs) dans le monde Linux et donc les bogues sont détectés plus facilement ?

Ilja van Sprundel, un spécialiste du pen test, a donc décidé de mettre son nez là‐dedans et d’auditer pendant plusieurs mois les codes des trois grands BSD (juste le noyau, pas le userland) afin d’introduire un peu de rigueur dans le débat.

Je vous laisse lire les diapos, mais voici quelques conclusions qui font réfléchir :

  • quand on audite le code des noyaux BSD, il est facile de trouver plein de bogues ;
  • trois mois d’audit de code : 30 bogues trouvés sur FreeBSD, 25 bogues trouvés sur OpenBSD, 60 bogues trouvés sur NetBSD ;
  • il n’y a pas assez de coopération entre les BSD (les bogues corrigés sur l’un existent toujours chez les autres) ;
  • OpenBSD sort clairement vainqueur (surface d’attaque réduite par rapport aux autres, qualité du code plus constante) ;
  • NetBSD sort clairement perdant (plein de code legacy, beaucoup de variation de qualité du code) ;
  • FreeBSD entre les deux.

La conclusion d’Ilja semble donc que la qualité du code BSD n’est pas le facteur qui explique le faible nombre de CVE. C’est plutôt le grand nombre de relecteurs de code dans le monde Linux qui est à l’origine de la différence du nombre de vulnérabilités découvertes.

  • # Il manque encore un peu de travail pour conclure :)

    Posté par (page perso) . Évalué à 6 (+10/-6).

    Je trouve bizarre d'adopter une démarche scientifiques dans ce cadre et d'en tirer une conclusion impossible avec les éléments présentés.

    Il a comparé de manière propre les 3 BSD et a trouvé des failles et en tire une hiérarchie entre elles. Pourquoi pas, je n'ai rien à redire dessus.

    Mais comment dans le même temps conclure que Linux c'est mieux, alors qu'il n'est même pas le sujet de l'étude ? Certes les BSD ne sont pas invulnérables (et j'ose espérer que personne n'y croyait) mais Linux non plus. Il faudrait une étude sur la qualité du code de Linux de manière globale. Et bien sûr normaliser les résultats par rapport à la taille du code (le noyau Linux ayant beaucoup plus de code et de pilotes que les autres noyaux libres existants, qu'il ait une surface d'attaque plus grande est naturelle).

    Il faudrait également un comparatif des mécanismes de protections entre le noyau Linux et les différents BSD (que ce soit contre les attaques directs vers le noyau, tout comme les interactions avec l'espace utilisateur).

    • [^] # Re: Il manque encore un peu de travail pour conclure :)

      Posté par . Évalué à -1 (+1/-3).

      Yep, bizarre de dire que Linux = plein de bugs trouvés parce qu'il y a plein de gens qui regardent… alors que s'il y a bien une chose qui est critiquée, c'est le fait que personne ne puisse décemment faire un audit du code à cause, vous l'aurez deviner, de sa taille démesurée (~9 à 10 fois la taille du kernel d'openbsd).

    • [^] # Re: Il manque encore un peu de travail pour conclure :)

      Posté par (page perso) . Évalué à 10 (+14/-0).

      Mais comment dans le même temps conclure que Linux c'est mieux, alors qu'il n'est même pas le sujet de l'étude ?

      Je ne vois pas où l’auteur conclut que « Linux c’est mieux ».

      Le constat initial était que Linux a beaucoup plus de vulnérabilités que les noyaux BSD, ce que de Raadt mettait sur le compte du fait que les développeurs BSD, eux, se préoccupent vraiment de la Qualité (la majuscule est d’origine) — ce que je me permettrais de traduire grossièrement par « BSD c’est mieux ».

      L’auteur montre simplement que quand on cherche des vulnérabilités dans les BSD, surprise : on en trouve. À aucun moment il ne dit que ça signifie que Linux est « mieux ».

    • [^] # Re: Il manque encore un peu de travail pour conclure :)

      Posté par (page perso) . Évalué à 10 (+8/-1).

      Mais comment dans le même temps conclure que Linux c'est mieux

      Il me semble que cette conclusion n'apparait ni dans le pdf d'Ilja ni dans mon journal.
      La question était juste "Est-ce que la qualité intrinsèque du code des noyaux BSD peut expliquer le faible nombre de CVE ?". L'étude démontre qu'en regardant de plus près le code on trouve plein de bugs donc la réponse à la question est "Non".
      C'est la seule conclusion rigoureuse qu'on puisse tirer. Il faut donc chercher une autre explication au faible nombre de CVE des BSD.

      Mais pas question de dire (et personne ne le fait ici) que Linux c'est mieux.

      En fin de pdf Ilja propose juste (sans éléments rigoureux pour étayer ça) que le nombre de relecteurs doit jouer un rôle.

      Many eyeballs …
      Gut feeling, I suspect this is a factor.
      Say what you will about the people reviewing the Linux kernel code, there are simply orders of magnitude more of them.

      • [^] # Re: Il manque encore un peu de travail pour conclure :)

        Posté par (page perso) . Évalué à 5 (+6/-3).

        Pour moi la conclusion :

        La conclusion d'Ilja semble donc que la qualité du code BSD n'est pas le facteur qui explique le faible nombre de CVE. C'est plutôt le grand nombre de relecteurs de code dans le monde Linux qui est à l'origine de la différence du nombre de vulnérabilités découvertes.

        n'est pas valide avec les données actuelles.
        Comme je l'ai dit, l'article montre certes qu'en creusant un peu, on trouve des CVE dans les BSD, mais on ne sait pas s'il y en a tant que ça par rapport à d'autres projets que ce soit le noyau Linux ou des projets de taille comparable.

        Donc on ne sait pas si les BSD ont un faible nombre de CVE d'une part, et on ne sait pas, si c'est le cas, à quoi c'est vraiment dû.

        Pour en savoir plus, il aurait fallu inclure le noyau Linux dans la boucle, voie un projet de taille similaire. Cette conclusion est bien hâtive.

      • [^] # Re: Il manque encore un peu de travail pour conclure :)

        Posté par (page perso) . Évalué à -2 (+2/-5).

        La question était juste "Est-ce que la qualité intrinsèque du code des noyaux BSD peut expliquer le faible nombre de CVE ?".

        Oui, et donc ? Combien de CVE ?

        L'étude démontre qu'en regardant de plus près le code on trouve plein de bugs

        Plein ?

        donc la réponse à la question est "Non".

        Mouais, au vu du peu de rigueur de l'étude, la réponse reste «'faut voir.»


        Des bugs, des commits, tout plein: https://freshbsd.org/

  • # Partage

    Posté par . Évalué à -4 (+0/-5).

    Je pensais que les BSD partageaient le même noyau. Niveau partage de ressources, c'est pas ça non plus.
    Bon vendredi

    • [^] # Re: Partage

      Posté par . Évalué à 4 (+2/-0).

      Ce sont des systèmes d'exploitation différents donc userspace et noyau différents, il n'y a que le nom "BSD" qui est commun.

  • # dragonflybsd oublié

    Posté par . Évalué à 4 (+2/-0).

    Dommage que Van Sprundel n'ait pas non plus évalué dragonflybsd, un fork relativement récent (à l'échelle bsdéologique) de freebsd.

  • # Certif autosigné

    Posté par . Évalué à 5 (+6/-2). Dernière modification le 28/07/17 à 12:48.

    Au sujet du certif autosigné de tedu@, lire https://www.tedunangst.com/flak/post/moving-to-https et https://www.tedunangst.com/flak/post/live-off-the-chain sur le pourquoi du comment.. et avant que quelqu'un saute sur l'occasion pour mentionner Let's Encrypt, j'imagine qu'il ne l'a pas utilisé intentionellement.

    Je note au passage qu'on est vendredi et qu'il y'a bien du monde pour commenter sur le fait que "c'est facile de trouver des bugs dans les noyaux BSD" mais bien moins de commentaires sur la news sur EuroBSDCon ( https://linuxfr.org/news/eurobsdcon-2017-en-septembre-a-paris) qui sera à paris..

    • [^] # Re: Certif autosigné

      Posté par (page perso) . Évalué à 5 (+2/-0).

      La news EuroBSDCon (j'ai réparé la typo dans ton lien) est très bien rédigée et informative. Peut-être qu'il n'y a pas grand chose à y ajouter ?

      Oui les blogposts de tedu@ sont intéressants. Je me permet de coller également un lien vers un post récent de David Madore au sujet du HTTPS.
      C'est plein de food for thought !

    • [^] # Re: Certif autosigné

      Posté par (page perso) . Évalué à 2 (+3/-3).

      Au sujet du certif autosigné de tedu@, lire https://www.tedunangst.com/flak/post/moving-to-https et https://www.tedunangst.com/flak/post/live-off-the-chain sur le pourquoi du comment..

      Je ne peux pas lire, vu que mon navigateur dit (avec raison) qu'il ne peut pas faire confiance, et comme HTTP est redirigé vers HTTPS c'est bien que l'auteur dit qu'il vaut mieux que j'ai confiance avant de lire non?
      Bon, OK, j'ai lu quand même mais n'ai pas trouvé d'argument autre que "tout est mal mais je n'ai rien d'autre à proposer".

      Et sinon, oui, de nos jours on a Let's Encrypt, vraiment plus aucune raison de ne pas utiliser un tiers de confiance, et la chaine de vérification s'est grandement améliorée, avec Certificate Transparency, OCSP stapling, HSTS Preloading… Et surtout, pour le moment on a rien trouvé de mieux pour gérer la première connexion.

  • # La qualité dépends de l'attention porté à la sécurité.

    Posté par . Évalué à -4 (+5/-9).

    Sans rentrer dans une grande étude, il est assez évident que la fiabilité d'un système dépends de l'attention porté sur la qualité du code et sur sa sécurité. OpenBSD étant de base orienté vers la sécurité il est tout a fait normal qu'il soit le plus sûr et de loin. Les autres BSD portant leur attention sur la qualité et la simplicité UNIX sont probablement plus fiable que Linux qui porte son attention sur beaucoup plus de point. Linux fait en sorte d'être le noyau ultime, il reçoit donc énormément de modifications en permanence que ce soit pour le support de matériel ou des fonctionnalité avancés (de sécurité, d'optimisation ou d’adaptation a un type spécifique). Alors si l'on prends la dernière version de Linux, elle est probablement moins fiable que BSD. Mais elle possède une si grosse communauté que très vite le code est patché et optimisé et les version du noyau un peu plus ancienne sont aussi fiable que BSD (OpenBSD reste au dessus).

    Rappelons que BSD s'est séparé en 3 versions : OpenBSD pour la sécurité, NetBSD pour le multi-architecture (Sa devise était "Il tourne même sur un grille-pain") et FreeBSD pour le serveur/PC "normal" (surtout X86) (DragonflyBSD reste proche de FreeBSD avec une approche un peu plus moderne). En toute logique NetBSD qui a le plus grand périmètre est moins fiable. En comparaison, le périmètre de Linux est gigantesque; il est adapté aussi bien pour l'embarqué que pour le Supercalculateur en passant par le PC et smartphone et pour tous les usages (Sécurisé, cloisonné, virtualisé, avec ou sans sous-couche sur-couche… ).

    On a donc 2 philosophie tellement différentes adaptés a des usages tellement différent et intéressant…

    • [^] # Re: La qualité dépends de l'attention porté à la sécurité.

      Posté par (page perso) . Évalué à 10 (+13/-2).

      Les autres BSD portant leur attention sur la qualité et la simplicité UNIX sont probablement plus fiable que Linux

      Et donc tu sors ça d'où ? Tu as fait une étude rigoureuse quelconque ou bien c'est juste du vent ?

      si l'on prends la dernière version de Linux, elle est probablement moins fiable que BSD

      Même question.

      OpenBSD reste au dessus

      Même question.

      L'avantage de l'étude d'Ilja c'était justement d'introduire de la rigueur dans toutes ces spéculations oiseuses qui courent sur la fiabilité relative des OS libres. Lui il s'est retroussé les manches et il a plongé dans le code pendant 3 mois pour essayer d'y voir plus clair.
      Toi tu t'appuies sur quoi pour tes affirmations ?

      • [^] # Re: La qualité dépends de l'attention porté à la sécurité.

        Posté par . Évalué à 3 (+3/-1).

        L'intuition du commentaire parent n'est pas infondée si l'on en croit Coverty. Le projet définit une « densité en défauts », soit le taux de défauts par 1 KLOC. Taux actuels :

        1. le noyau d'OpenBSD, code du 26/01/2017 : 0,06 ;
        2. le noyau de NetBSD, code du 02/03/2009 : 0,32 ;
        3. Linux, code du 24/07/2017 : 0,47 ;
        4. le noyau de FreeBSD, code du 26/07/2017 : 0,78.

        Disclaimer : je suis une tanche dans la discipline de Sécurité Informatique mais il ne me semble pas aberrant de prendre au sérieux le caractère scientifique d'un projet qui s'est construit ce genre de notoriété.

        • [^] # Re: La qualité dépends de l'attention porté à la sécurité.

          Posté par . Évalué à 3 (+1/-0).

          Y a pas des chiffres plus récents, pour NetBSD ? Difficile de le comparer, alors que sa densité a été calculée il y a 8 ans, avec les 3 autres pour lesquels la densité date de ces derniers 6 mois…

          Ceci étant dit, il y a des écarts assez impressionnants ! Même entre BSD… Il n'y a donc plus rien de commun entre eux, à part le nom ?

          • [^] # Re: La qualité dépends de l'attention porté à la sécurité.

            Posté par . Évalué à 5 (+4/-0).

            Y a pas des chiffres plus récents, pour NetBSD ?

            Ce qui est publié sur le site de Coverity ne reflète pas l'état de collaboration entre un projet scanné et le scanneur. J'ai lu je ne me souviens où qu'après scan, Coverity envoie confidentiellement les résultats aux personnes concernées (responsible disclosure au cas où il y aurait des failles critiques). Celles-ci peuvent alors en faire ce qu'elles veulent : corriger silencieusement les vrais positifs, s'asseoir là-dessus, les rendre publics, les faire passer par un script qui en affichera le résumé sur le site web de Coverity … Certains projets ont des instances privées de Coverity (pour rappel, ce n'est plus un projet de l'université de Stanford mais un logiciel propriétaire) où on fait passer n'importe quel code, sans attendre l'avis des responsables upstream : c'est ainsi que j'ai découvert l'existence même de Coverity en lisant sur une liste de diffusion un message d'un employé de Redhat qui rapportait des failles pointées par un scan de Coverity, sans que les responsables du projet scanné aient eu une connaissance préalable que leur code se faisait analyser. Cas d'espèce : NetBSD est toujours scanné comme en témoigne le WiKi du projet et d'autres pages web.

            Il n'y a donc plus rien de commun entre eux, à part le nom ?

            Même pour des profanes des arcanes des BSD (dont je suis car utilisant du GNU), il est de notoriété publique que les trois OS se sont longtemps éloignés les uns des autres du point de vue partage de code. Au-delà de cette généralité, il y a de la littérature qui documente les choses plus finement, par exemple dans l'article "A Case Study of Cross-System Porting in Forked Projects" de Baishakhi Rᴀʏ et Miryung Kɪᴍ ; version publique ici. Deux des questions auxquelles l'article répond :

            • « À quel point les modifications sont-elles portées de projet en projet ? » La figure 2 figure-2 est une matrice des pourcentages de ports ayant comme sources la première ligne (en-tête) et comme destination la première colonne (en-tête). On y observe qu'en cumulé, la moyenne la plus élevée est de 15 % et on ne peut donc pas dire que les sources sont synchronisées entre les trois BSD.
            • « Quelles sont les sous-arborescences des sources qui reçoivent le plus de ports d'une BSD à une autre ? » La figure 7 figure-7 montre qu'encore une fois, il n'y a pas de partage avancé du code.

            Bref, les trois sont des systèmes d'exploitation différents. Il n'est pas étonnant que quand on les analyse statiquement, on tombe sur des résultats différents.

          • [^] # Re: La qualité dépends de l'attention porté à la sécurité.

            Posté par . Évalué à 2 (+0/-0).

            Même entre BSD… Il n'y a donc plus rien de commun entre eux, à part le nom ?

            Si bien sûr: la licence (enfin, je dis ça, j'en suis même pas sûr au final).

          • [^] # Re: La qualité dépends de l'attention porté à la sécurité.

            Posté par . Évalué à 2 (+0/-0).

            Il n'y a donc plus rien de commun entre eux, à part le nom ?

            L'essentiel de ce qu'ils ont en commun c'est [url]de la généalogie.[/url] Même la licence, si elle est compatible n'est pas toujours exactement la même.

            Cela-dit il reste des bouts de code en commun, il y'a des composants de certains BSD qui finissent adoptés par d'autres comme par exemple le firewall pf de openbsd a été porté à freebsd et netbsd et est je crois régulièrement synchronisé depuis l'upstream mais ignoré par dragonflybsd. Dragonflybsd garde cependant pas mal de code de freebsd du fait d'un fork plus récent.

            Mais essentiellement c'est de l'historique. Une fois que ces OS forkés peu de chose reste développé en commun et rien n'est synchronisé de façon systématique.

        • [^] # Re: La qualité dépends de l'attention porté à la sécurité.

          Posté par (page perso) . Évalué à 3 (+0/-0).

          Mmm…y'a un truc bizarre pour le scan Coverity d'OpenBSD : https://scan.coverity.com/projects/openbsd-kernel
          Il est indiqué que le nombre de lignes scannées est seulement de 15 858.

  • # Je me demande quel est l'intéret de cette étude ...

    Posté par . Évalué à 0 (+2/-4).

    Pour moi c'est comme si on comparait un slip, un ensemble chemise/costard/cravate/chaussures, une tenue complète de mariée (de la tête aux pieds) une combinaison de ski (idem de la tête aux pieds). Le seul point commun est que ce sont des vêtements.

    • [^] # Re: Je me demande quel est l'intéret de cette étude ...

      Posté par (page perso) . Évalué à 10 (+12/-0).

      Je me demande quel est l'intéret de cette étude …

      Le seul point commun est que ce sont des vêtements.

      Bah si j'ai bien compris, savoir lequel te laisse le plus le cul à l'air.

      • [^] # Re: Je me demande quel est l'intéret de cette étude ...

        Posté par (page perso) . Évalué à 2 (+1/-1).

        Bah si j'ai bien compris, savoir lequel te laisse le plus le cul à l'air.

        bin j'ai retenu ce qui permet de sortir en société :

        • perso un calbuth plutôt qu'un slip qui serre par endroit
        • pas de costard ni cravate qui ressemble plus à un déguisement (je le subis genre tous les 3 ans… si c'était obligatoire au jour le jour, ce serait sans moi)
        • pour le casual day j'ai inauguré l'absurdité du t-shirt remington et du hoody de la quadrature, personne ne l'a compris, ce que je craignais :/ bah ça viendra

        après, tu t'habilles bien comme tu peux, dans nus et culottés ils se débrouillent bien Hans et Mout :-)

      • [^] # Re: Je me demande quel est l'intéret de cette étude ...

        Posté par . Évalué à 4 (+1/-0).

        Si le but c'est de savoir lequel est le moins sûr face à l'attaque utilisant une faille, je ne suis pas sûr que ce soit suffisant:

        De part sa notoriété, je pense que Linux attire bien plus d'attention, aussi bien bienveillante que malveillante, que NetBSD par exemple.
        Du coup, est-il plus sûr d'utiliser le système qui sera le premier choix d'un assaillant qui s'attaque à des cibles au hasard, ou un système relativement sûr mais tout de même bien plus marginal sur le marché, et donc avec beaucoup moins de chance d'attirer les opportunistes?

        Pour une attaque ciblée, l'histoire montre qu'il est souvent plus simple d'y aller par ingénierie sociale.

        Bon, je passe mon serveur sous Debian/Hurd, suis certain d'être quasiment unique!
        -----------> [ ]

  • # Fixes

    Posté par . Évalué à 3 (+2/-0).

    Pour info, une petite douzaine des bugs considérés 'importants' ont été corrigés (cf Cf http://undeadly.org/cgi?action=article&sid=20170804053102 et http://www.openbsd.org/errata61.html) dans les branches 6.0 et 6.1, et les patches binaires sont disponibles.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.