Si la liste des vulnérabilités, dont 88 sont dites critiques, n’est pas encore publique, la société Coverity a annoncé son intention de la divulguer soixante jours après l’annonce. Un bien étrange cadeau de bonne année lorsqu’on sait que, dans le passé, les bogues qu’elle découvrait dans du code open source étaient remontés aux développeurs sans être divulgués.

Ce changement de méthode rappelle aux fabricants de terminaux qu’un code open source n’est pas forcément exempt de vulnérabilités, et que les outils Coverity ne sont pas réservés au code propriétaire. On pourra taxer la société d’opportunisme à un moment où la part de code libre contenue dans les produits grand public croît très rapidement, comme le montre l’évolution de la part de marché d’Android, mais cette annonce permet avant tout de poser un certain nombre de questions pratiques.

Où se situent les responsabilités ?

Tout d’abord, qui a la responsabilité des vulnérabilités contenues dans du code open source utilisé par un vendeur d’appareils grand public comme, ici, un fabricant de téléphones mobiles ? Si la réponse de l’utilisateur final semble évidente, la réalité est plus compliquée. La responsabilité du fabricant pour le code spécifique à ses produits, comme les pilotes matériels, est évidente.

Mais quid du reste du code ? Dans le processus normal de divulgation, le découvreur remonte d’abord le problème au responsable du code et, éventuellement, propose une correction. Or, dans le cas présent, et vu le nombre d’entreprises utilisant l’outil, le risque est grand de voir chaque fabricant intégrer ses propres corrections. L’effet pervers en est le coût de maintien de ces corrections, sans aucune valeur ajoutée ni pour l’industrie, ni pour les utilisateurs.

Des outils puissants d'analyse

Il semble donc naturel de suivre le chemin habituel et de remonter aux mainteneurs du code de manière centralisée (kernel.org, Google…). On peut aussi penser que c’est à Google, considéré comme fournisseur de l’OS Android, de garantir un niveau de qualité minimal et de fournir des correctifs, tout comme le feraient des fournisseurs de systèmes propriétaires. On peut enfin imaginer que l’Open Handset Alliance, qui regroupe l’écosystème Android, centralise la gestion de ces corrections et la mise en place de bonnes pratiques avec les communautés de développeurs de code utilisé par Android.

Enfin, la disponibilité de puissants outils d’analyse de code dans le monde libre, tel Frama-C, ouvre la porte à une utilisation très large de ces outils pour le code open source ; reste à trouver comment généraliser leur usage dans le monde du libre, dans un contexte de diffusion des logiciels où la responsabilité vis-à-vis des vulnérabilités est moins évidente.

On notera enfin avec soulagement que, faute de réponse claire à ces questions, les auteurs du rapport semblent renoncer à maintenir une date ferme pour la divulgation des vulnérabilités découvertes dans la distribution Android. Ils auront au moins eu le mérite de faire réfléchir l’industrie à ses responsabilités lorsqu’elle embrasse le monde du libre pour, en général, baisser ses coûts.

Auteur : Hervé Sibert, pour 01net
Spécialiste et architecte chargé de la technologie Sécurité chez ST-Ericsson, Hervé Sibert a obtenu son doctorat en mathématiques en 2003, après sa sortie de Polytechnique. Avant de rejoindre NXP (fabricant de chipstets pour terminaux mobiles devenu ST-Ericsson) en 2006, il passe trois ans au département de recherche et développement de France Télécom en tant qu’ingénieur et chercheur en cryptographie et sécurité des réseaux.