Journal Vulnérabilités sérieuses dans des dizaines d'applis utilisant TLS (ex-SSL)

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
33
8
déc.
2012

The Most Dangerous Code in the World : Validating SSL Certificates in Non-Browser Software par Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh et Vitaly Shmatikov

Une excellente étude sur les vulnérabilités des applications utilisant TLS (autrefois nommé SSL), à l’exclusion des navigateurs Web. Des tas d’applications parfois peu connues et discrètes (par exemple pour réaliser la mise à jour des logiciels d’un système) utilisent, comme les navigateurs Web, TLS pour se protéger contre un méchant qui essaierait de détourner le trafic vers un autre serveur que celui visé. Mais, contrairement aux navigateurs Web, ces applications, souvent critiques (paiement entre cyber-marchands, par exemple) n’ont guère été étudiées et ont des vulnérabiités souvent énormes, permettant à un attaquant de se faire passer pour le serveur légitime, malgré TLS.

Pour ne donner qu’un exemple (mais un des plus beaux), la bibliothèque cURL, très utilisée par d’innombrables applications, a un paramètre CURLOPT_SSL_VERIFYHOST. La documentation dit bien qu’il doit être mis à 2 (sa valeur par défaut) pour que le nom soit vérifié et à 1 pour couper la vérification. Bien des programmes écrits dans des langages sans typage fort (comme PHP), mettent ce paramètre à « true », donc à 1, coupant ainsi la validation…

Les auteurs de l’article, après avoir cassé la sécurité de TLS dans des dizaines d’applications, suggèrent des API mieux documentées, plus claires et de plus haut niveau, pour diminuer le risque que les programmeurs se trompent.

http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

  • # cURL

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

    Bien des programmes écrits dans des langages sans typage fort (comme PHP), mettent ce paramètre à « true », donc à 1, coupant ainsi la validation…

    En même temps, tout les languages avec typage fort que je connais convertisse automatiquement true à 1.

    Par ailleurs, la documentation de cURL: http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTSSLVERIFYHOST

    When the value is 1, libcurl will return a failure. It was previously (in 7.28.0 and earlier) a debug option of some sorts, but it is no longer supported due to frequently leading to programmer mistakes.

    Donc cURL a été corrigé, et mettre la valeur à 1 ne désactive plus la vérification.

    • [^] # Re: cURL

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

      Euh, non, Go, Ada ou Java, pour ne prendre que trois exemples de langages typés, n'accepteraient pas un booléen là où on attend un entier. (A fortiori, ils ne le convertiraient pas.)

      Les vulnérabilités citées dans l'article ont évidemment été signalées aux auteurs de logiciels avant la publication de l'article et plusieurs sont donc aujourd'hui corrigées.

      • [^] # Re: cURL

        Posté par  . Évalué à 3.

        Les vulnérabilités citées dans l'article ont évidemment été signalées aux auteurs de logiciels avant la publication de l'article

        C'est faux.

        • [^] # Re: cURL

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

          Désolé, mais c'est vrai. Les auteurs de libcurl n'ont pas été contactés tout simplement parce qu'il n'y a pas à proprement parler de faille dans libcurl, juste une API dangereuse.

    • [^] # Re: cURL

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

      C++ ne compte pas comme un langage avec typage fort.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: cURL

        Posté par  . Évalué à 4.

        C++ ne compte pas comme un langage avec typage fort.

        Bah, le "typage fort" ce n'est pas un booléan vrai/faux, c'est une échelle de 0 à 10.
        Je mettrais le C++ à 8 personellement (les conversion automatiques signés/non-signés, entier/booléen affaiblissent le typage).

  • # Sensationnel

    Posté par  . Évalué à 10.

    Bien des programmes écrits dans des langages sans typage fort (comme PHP), mettent ce paramètre à « true », donc à 1, coupant ainsi la validation…

    Le problème n'est donc pas dans cURL, mais bien chez les développeurs qui ne lisent pas les documentations (et celle de libcurl est particulièrement claire). Et qu'on ne me parle pas d'une API qui soit là pour assister les incompétents (la documentation dit de passer 0, 1 ou 2, si l'on passe true, on est incompétent).

    Par ailleurs, Daniel Stenberg (l'auteur principal de cURL) signale que ceux qui ont écrit ce "papier" (qui à mon avis cherchent à faire du sensationnel plein de superlatifs) n'ont même pas contacté les auteurs des bibliothèques qu'ils "accusent".

    • [^] # Re: Sensationnel

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

      Le problème est que l'API de cURL n'était pas bonne.
      Tous les documents sur comment réaliser une API précise que une bonne API est « consistent » (cohérente) et « hard to misuse » (difficile à utiliser incorrectement) [1] [2] [3] [4]

      Or ici l'API n'est pas cohérente puisque CURLOPT_SSL_VERIFYPEER est un boolean et CURLOPT_SSL_VERIFYHOST un entier. Et elle induit les gens en erreur, ce qui est le contraire de « hard to misuse »

      • [^] # Re: Sensationnel

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

        Plus précisement (parce que Stenberg nie bêtement le problème, en jouant sur les mots et en prétendant qu'il n'y a pas de paramètres booléens dans libcurl), le paramètre est un long (libcurl n'utilise effectivement pas bool) mais qui prend deux valeurs, 0 pour "non" et 1 pour "oui". C'est donc un quasi-booléen et l'erreur des programmeurs qui ont passé "true" à une autre fonction de libcurl est tout à fait excusable (même si BFG les prend de haut).

      • [^] # Re: Sensationnel

        Posté par  . Évalué à 2.

        Je te rejoins, surtout que le développeur parle d'un choix pour verifyhost.
        Il aurait été peut-être plus pertinent de faire:

        CURLOPT_SSL_VERIFYPEER ( boolean )
CURLOPT_SSL_VERIFYHOST ( boolean )
CURLOPT_SSL_VERIFYHOST_TYPE ( int )

        Au moins, on est sûr de pas se gourer.

    • [^] # Re: Sensationnel

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

      Non, Stenberg ne dit pas ça du tout. Il dit que lui n'a pas été contacté (rappelons que libcurl n'avait pas de faille).

    • [^] # Re: Sensationnel

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

      Le problème n'est donc pas dans cURL, mais bien chez les développeurs qui ne lisent pas les documentations

      Avec une telle mentalité, on aura encore des failles de sécurité pendant longtemps. Peut-être que les abonnés à LinuxFr ne mettent jamais de bogues dans leurs programmes mais, dans le monde réel, avec les contraintes de délai et le PHB qui demande qu'on livre le code avant-hier, les bogues arrivent. Comme le rappelle très justement Gof dans son commentaire, le rôle d'une API n'est pas de tendre des pièges subtils, pour pouvoir ricaner ensuite de l'incompétence des programmeurs qui sont tombés dedans, c'est de rendre l'erreur difficile.

      qui à mon avis cherchent à faire du sensationnel plein de superlatifs

      Je ne sais pas ce qu'il vous faut : des dizaines de programmes vulnérables à une attaque triviale (et pas des petits scripts PHP écrits par Jean-Kevin Boulet dans son coin pour son usage personnel, non des codes utilisés par des dizaines de milliers de gens pour des usages critiques, par exemple du paiement en ligne), et ça ne vous suffit pas ?

      C'est un obstacle qu'on rencontre souvent dans le monde du logiciel privateur, le vendeur qui nie les failles de sécurité parce que cela le gonfle de corriger. Apparemment, ce mal frappe aussi le logiciel libre.

Suivre le flux des commentaires

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