Le programme de Google pour améliorer la sécurité des logiciels libres

Posté par  (site web personnel) . Édité par ZeroHeure, rootix et NeoX. Modéré par NeoX. Licence CC By‑SA.
Étiquettes :
51
11
oct.
2013
Sécurité

Le 9 octobre dernier Google a annoncé un nouveau programme visant à améliorer la sécurité de plusieurs projets de logiciel libre.

Depuis plusieurs années la firme de Mountain View maintient un "Vulnerability Reward Program" qui a pour objet de payer les programmeurs trouvant des bugs de sécurité dans les applications Google. La dernière annonce étend ce programme à plusieurs projets libres qui forment le soubassement technique d'internet (key third-party software critical to the health of the entire Internet).

Plus de détails dans la suite de la dépêche.

Les programmes visant à payer une personne ayant découvert un bug de sécurité (Bug Bounty) sont un grand succès depuis plusieurs années. Un article, issu du symposium USENIX sur la sécurité, et intitulé "An Empirical Study of Vulnerability Rewards Programs", permet de faire le point sur ce sujet. Les auteurs ont étudié en détail le programme de Google pour sécuriser Chrome et le programme Mozilla pour sécuriser Firefox.
La lecture de ce papier passionant, bourré de détails, est très éclairante sur les sommes mises en jeu ainsi que les bénéfices retirés par les projets :

Chrome VRP has cost approximately $580,000 over 3 years and has resulted in 501 bounties paid for the identification of security vulnerabilities. The Firefox VRP has cost approximately $570,000 over the last 3 years and has yielded 190 bounties.

Google, dans son annonce du 9 octobre souhaite maintenant aller plus loin que Chrome et la société est prête à payer pour améliorer la sécurité d'autres projets que les siens. Ici ce ne sont pas à proprement parler les bugs qui sont recherchés. Google veut récompenser les patchs qui améliorent structurellement la sécurité d'un projet :

We decided to try something new: provide financial incentives for down-to-earth, proactive improvements that go beyond merely fixing a known security bug. Whether you want to switch to a more secure allocator, to add privilege separation, to clean up a bunch of sketchy calls to strcat(), or even just to enable ASLR - we want to help !

La liste des projets visés par ce bounty program est la suivante :

  • Réseau : OpenSSH, BIND, ISC DHCP
  • Parseurs images : libjpeg, libjpeg-turbo, libpng, giflib
  • Fondations de Chrome : Chromium, Blink
  • Bibliothèques sensibles : OpenSSL, zlib
  • Noyau Linux

Dans l'annonce sur le blog du projet il est également indiqué que le programme va par la suite être étendu aux projets suivants :

  • Serveurs Web : Apache httpd, lighttpd, nginx
  • Serveurs SMTP : Sendmail, Postfix, Exim
  • Chaîne de compilation : GCC, binutils, llvm
  • Réseau : OpenVPN

Les récompenses prévues vont de 500 dollars à 3 133,7 dollars et leur attribution est du ressort de l'équipe de sécurité Google. Un point important qui mérite d'être souligné est le fait que Google ne veut pas court-circuiter les projets amonts. En effet un patch de sécurité, pour être admissible au programme "Patch rewards", doit avoir été soumis et accepté par les mainteneurs du projet amont (upstream). Non seulement ça, mais le patch doit avoir été déployé dans une version distribuée par le projet :

In order to qualify, your patch must first be submitted directly to the maintainers of the project, and you must work with them to have it accepted into the repository and incorporated into a shipping version of the program.

On ne peut que se féliciter de cette annonce du programme "Patch rewards" par Google. L'entreprise a bien compris que la qualité de ses services, et donc en définitive sa santé financière, dépendait du bon fonctionnement de tout un écosystème de logiciels libres. L'incitation à renforcer la sécurité de cet écosystème bénéficiera à tout le monde.

Aller plus loin

  • # Cachez ce sein que je ne saurait voir

    Posté par  . Évalué à -10.

    Google utilise des data-centers dans des lieux inconnus et il est impossible de savoir ce qu'adviennent les données des citoyens français. Des rumeurs circulent concernant Android, dont le système de master key permettrait d'installer des goodies à distance, sans laisser de trace. Alors c'est vraiment pour se donner bonne conscience.

    • [^] # Re: Cachez ce sein que je ne saurait voir

      Posté par  . Évalué à 1.

      Des rumeurs circulent concernant Android, dont le système de master key permettrait d'installer des goodies à distance, sans laisser de trace.

      Source(s) de l'information ?

      • [^] # Re: Cachez ce sein que je ne saurait voir

        Posté par  (site web personnel) . Évalué à 3.

        En 2010 :
        http://www.theregister.co.uk/2010/06/28/google_remote_android_application_install/

        par contre, je ne suis pas sur sur la partie "sans laisser de trace". Il y a des logs, mais comme personne ne va les lire, et comme ils peuvent être effacé, je pense qu'on est pas loin de ça en pratique.

        • [^] # Re: Cachez ce sein que je ne saurait voir

          Posté par  . Évalué à 3.

          Bon, en fait on a deux problèmes différents. D'une part celui des vulnérabilités d'Android qui permettent à toute application de devenir root, et donc d'effacer par la suite toute trace de l'opération, et qui ne peut être contré que par les mises à jour de sécurité.
          Et d'autre part le problème du "masterkey" de juillet dernier, qui, si j'ai bien compris, permet se substituer une application à une autre en leurrant le système de signature ; mais ce problème-là semble résolu (sauf pour les innombrables machines non à jour - et on retombe sur le même problème).

          Conclusion : Google fait bien de chasser les soucis de sécurité dans Android, mais devrait mettre la pression sur les constructeurs afin qu'ils appliquent les mises à jour …

    • [^] # Re: Cachez ce sein que je ne saurait voir

      Posté par  (site web personnel) . Évalué à 7.

      Google utilise des data-centers dans des lieux inconnus

      pas si inconnu que ça :
      https://www.google.com/about/datacenters/inside/locations/

      même si je pense que la liste est incomplète, vu qu'ils ont aussi des offres pour plein d'autres trucs :

      http://www.datacenterknowledge.com/archives/2008/11/25/a-closer-look-at-googles-european-data-centers/

    • [^] # Re: Cachez ce sein que je ne saurait voir

      Posté par  . Évalué à 4.

      Par definition, les rumeurs sont a prendre avec des pincettes. D'autant plus que pister ce qui sort d'un telephone est assez simple a realiser.
      Qui plus est, une bonne partie d'android est open-source ( si on exclu les drivers materiels).

      On peut ne pas aimer Google pour sa gestion des donnes, mais la ils offrent du cash pour ameliorer la securite de l'open source sans aucune intrusion dans la gestion des projets. Je ne connais pas beaucoup de boites qui en font autant…

      • [^] # Re: Cachez ce sein que je ne saurait voir

        Posté par  . Évalué à 3.

        D'autant plus que pister ce qui sort d'un telephone est assez simple a realiser.

        Il peut se passer pleins de trucs pas nets au niveau du matériel, genre une partie du matériel qui peut accéder directement à une autre partie du matériel (par exemple SoC qui accède directement à la mémoire, donc pourquoi aux trucs réseaux…).

        Écrit en Bépo selon l’orthographe de 1990

  • # Et le DNS ?

    Posté par  . Évalué à -4.

    C'est dommage qu'il n'y ai aucun serveur DNS dans le lot, c'est quand même une pierre angulaire.

  • # Il n’y a pas de petites économies.

    Posté par  . Évalué à -9.

    Au lieu de mettre des gars à eux sur un projet de ce genre, ils laissent faire les autres et avec des récompenses minables. Surtout en ce qui concerne Chromium et Blink !

    Foutage de gueule quand tu nous tient.

    • [^] # Re: Il n’y a pas de petites économies.

      Posté par  (site web personnel) . Évalué à 3.

      Chrome VRP has cost approximately $580,000 over 3 years and has resulted in 501 bounties paid for the identification of security vulnerabilities. The Firefox VRP has cost approximately $570,000 over the last 3 years and has yielded 190 bounties.

      Les chiffres parlent d’eux-mêmes.

      • [^] # Re: Il n’y a pas de petites économies.

        Posté par  (site web personnel) . Évalué à 7. Dernière modification le 11 octobre 2013 à 19:26.

        Les chiffres parlent d’eux-mêmes.

        Parlons chiffres :
        - Chiffre d'affaire : 50 000 000 000 $ / an. 500 000 $ est donc 0.001% du CA.
        - Nombre d'employés : 50 000. prenant très très grand avec des gens pas très bien payés aux USA, ça fait 5 personnes en bounties, soit 0.01% de personnel "en bouties".
        (j'ai la flemme de diviser par 3, car 500 000 est sur 3 ans et j'ai compté par an par flemme de faire autre chose que des divisions par 10…)

        Alors certes c'est bien, c'est carrément mieux que rien, mais il ne faut pas non plus en fait un grand truc énorme. Parce que quand je lis :

        Ces boîtes paient très cher, mais Google permet à ces personnes de faire un choix plus éthique tout en gagnant quelques sous.

        Faut rester un minimum sérieux : entre 3 000 (je suis gentil, je prend le max) et 300 000, "quelque sous" changera l'idée? 3 000, c'est un mois de salaire US et puis c'est tout, donc en terme d'investissement potentiel de "white hats"… Ca va commencer qu'avec des bidouilleurs passionnés "du dimanche" qui ne comptent pas leurs heures.

        Je ne parle pas de conspuer l'offre, elle est super. Juste qu'il faut rester sur terre : c'est pour le moment de la petite incitation.
        Bon, après, on peut voir ça comme un début, Google propose pour ses services jusqu'à 20 000 $, j'ai cru voir passer 100 000 $ de la part de Microsoft, ça augmente au fur et à mesure du temps, je prend les chiffres de l'annonce comme un premier essai dont les montant augmenteront dans quelques années (Google a tout interet à tout sécuriser, pour aléger ses protections à lui, les bots etc… Sans pour autant être motivé à filer 20 000 $ à plein de monde dès le départ, bef de la classique gestion de montée en charge)

        • [^] # Re: Il n’y a pas de petites économies.

          Posté par  . Évalué à 4.

          3000, un mois de salaire?
          Oula revoies ton ordre de grandeur, un dev pas mauvais de base, dans des technos pas specialement recherches, ca va taper dans les 2500-3000 net par quinzaine.
          Pour un gars pas mauvais en c et en secu, tu doubles ca, facile. Et ca c'est le net, et ca inclue pas les bonus, stock, contributions 401k et autres assurances santes.

          Pour des gens capables de faire des patchs corrects sur des softs decemment complexes et critiques, google leur offre gracieusement l'equivalent de 1 a 2 jours de paye par bounty. Perso je trouve que ca fait tres peu cher paye vu le temps passe sur un patch decent.

          Je sais pas, ptetre que l'idee c'est d'inciter les devs de boites qui gardent leurs patchs au chaud a les contribuer?

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: Il n’y a pas de petites économies.

      Posté par  . Évalué à 10.

      Si de nos jours un développeur trouve une vulnérabilité, il peut la corriger et envoyer son patch au projet. Il peut aussit créer un exploit et la vendre aux services secrets par l'intermédiaire d'une boîte comme Vupen.

      Ces boîtes paient très cher, mais Google permet à ces personnes de faire un choix plus éthique tout en gagnant quelques sous.

  • # BIND

    Posté par  . Évalué à -2.

    Tenter de sécuriser le pire serveur DNS de l'histoire…
    Sérieux, ils ne pouvaient pas promouvoir un autre serveur que BIND ?!

    • [^] # Re: BIND

      Posté par  . Évalué à 4.

      Le pire a quel point?

      • [^] # Re: BIND

        Posté par  (site web personnel) . Évalué à 9.

        Déjà, Bind a pas vraiment un historique en matière de sécurité qui est brillant :
        http://www.cvedetails.com/vulnerability-list/vendor_id-64/product_id-144/opdos-1/ISC-Bind.html

        Bind ( avant la version 10 ) n'avait ni bugtracker, ni de vcs publique ( ou alors, j'ai pas réussi à le trouver ). Pour les bugs, faut envoyer un email sur une liste. C'est assez rustique comme système, il faut reconnaitre.

        Ensuite d'un point de vue pratique, le format de configuration est baroque ( AMHA ) et difficile à parser, ce qui est un peu chiant.
        J'ai déployé nsd, unbound et d'autres serveurs, et ils sont en général bien plus facile à comprendre et à configurer. Les fonctionnalités ont mis du temps à venir, comme l'intégration avec les bases, SQL qui a longtemps été un patch à part.

        Et je pense que j'ai rarement croisé des sysadmins qui n'ont pas d'histoires bizarres avec bind. Genre les fichiers jnl corrompus, bind qui démarre quand même avec une zone incomplète et qui surprends tout le monde, etc, etc.

        Ensuite, bind marche correctement, se fait globalement oublié par les utilisateurs et je ne veux pas jeter la pierre. Mais quand même freebsd commence à ne plus vouloir de bind par défaut ( http://blog.des.no/2013/09/dns-in-freebsd-10/ ), on peut se dire que c'est pas non plus sans raison.

        • [^] # Re: BIND

          Posté par  . Évalué à 3.

          À vrai dire ce qui m'étonne le plus est que BIND reste la référence alors que c'est vraiment un logiciel de second plan par rapport à la concurrence. Il est déployé à très grande échelle, la quasi-totalité des documentations le concerne.
          Panurgisme , ou j'ai raté quelque chose ?

          • [^] # Re: BIND

            Posté par  (site web personnel) . Évalué à 7.

            Pour la défense de bind, il reste quand même bien souvent le premier à supporter les différents standards ( ou du moins, ç'est ma perception ), et c'est aussi comme tu dit une histoire de documentation, ie tout le monde qui sait comment installer un dns sait comment installer bind. À la fac, tu vois bind, c'est tout. Donc quand tu montes ton réseau, tu reprends ça. Tu arrives dans une boite, y a des chances que ça soit bind plutôt que nsd/powerdns/unbound/etc, pour raisons historiques.

            Et personne n'a de raison de faire une migration du DNS en général, vu que ça marche sans trop de souci, c'est rarement le plus urgent à corriger ou à déployer.

            Nous avons arrêtés bind au taf pour une partie des domaines pour passer par une boite noire qui fait le café, mais c'est pour des raisons autres ( interface web qui permet de déléguer la mise à jour avec des acls, failover automatique, etc, etc, même si l'interface reste lente et un peu daubé à mon sens, et nous fait perdre plus de temps au final )

            Donc oui, il y a bind car les alternatives sont pas connus, et je pense que la migration de freebsd a autre chose va peut être faire bouger les esprits chez les autres éditeurs à ce niveau.

          • [^] # Re: BIND

            Posté par  . Évalué à 6.

            Écoute, quand on sait que Windows est le système d’exploitation pour ordinateurs fixes et portables le plus utilisé dans le monde…

            Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: BIND

              Posté par  . Évalué à 4.

              Windows est destiné à tout le monde. On s'attend à la force du marketing, de l'effet de groupe, etc.
              BIND est destiné à des pros ou amateurs éclairés. On s'attend à des choix éclairés (et peut-être que c'est le cas pour BIND, mais je trouve ça étrange).

              • [^] # Re: BIND

                Posté par  . Évalué à 1.

                BIND est destiné à des pros ou amateurs éclairés.

                Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: BIND

          Posté par  (site web personnel) . Évalué à 7.

          Bah, c'est un héritage. C'est un peu comme la syntaxe des Makefile dont on parlait il y a peu, ou le format des .mailfilter , ou les autoconf, ou la syntaxe de sh pour faire des expressions booléennes. C'est pourri mais on fait avec parce que c'est ce qui est disponible partout et par défaut.

          Après, aux autres de prendre la place. Apache n'est pas encore détroné mais a perdu beaucoup de terrain, le système d'init vénérable de Unix est aussi détroné, lilo est détroné. On se débarrasse de plein de vieilleries avec le temps…

          • [^] # Re: BIND

            Posté par  . Évalué à 1.

            Je n'ai pas entendu dire qu'Apache soit aussi mité que BIND…
            Ensuite, le côté "installé par défaut" a certainement un gros impact en effet.

          • [^] # Re: BIND

            Posté par  (site web personnel) . Évalué à 5.

            Le point commun entre les vieux systémes d'init et lilo, c'est qu'ils n'ont pas du tout évolué au niveau du design comme du code, tu peux pas vraiment comparer avec bind qui est maintenu, et qui s'adapte aux nouvelles RFCs.

            Le concept de serveur dns ne va pas vraiment bouger dans les années à venir je pense, donc je doute qu'un changement viennent de la.

        • [^] # Re: BIND

          Posté par  (site web personnel, Mastodon) . Évalué à 5.

          Mais quand même freebsd commence à ne plus vouloir de bind par défaut ( http://blog.des.no/2013/09/dns-in-freebsd-10/ ), on peut se dire que c'est pas non plus sans raison.

          Pour être complet, il faut lire la clarification : http://blog.des.no/2013/09/dns-again-a-clarification/

          Le point 5 (Python) est bloquant pour un logiciel du système de base.

Suivre le flux des commentaires

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