Tavis Ormandy, un employé de Project Zero, l’équipe parfois controversée de chasseurs de vulnérabilités de sécurité de Google, a découvert la semaine dernière un problème d’une grande ampleur chez Cloudflare, alors qu’il travaillait sur un projet annexe.
Dans certaines pages Web mises en cache par le moteur de recherche de Google, il remarquait que de grandes portions de données confidentielles, comme des clés d’interfaces de programmation, des mots de passe ou des cookies, apparaissaient dans le cache.
Après des recherches avec ses collègues, il comprend que ces données sont des pages de données de mémoire non initialisée, mélangées avec des données valides. Rapidement, il est établi que ces données pourraient provenir de serveurs de proxy inverse de Cloudflare, l’un des plus grands CDN au monde.
Cloudflare est une entreprise spécialisée dans l’accélération des sites Web et des fichiers de ses clients. À l’aide de son réseau de distribution de contenu (CDN), et de ses fermes de serveurs partout dans le monde, elle place au plus près des utilisateurs les sites Web, images, vidéos et autres contenus, pour une vitesse optimum.
Elle propose également des options additionnelles d’accélération, et des options de sécurité. Ses services sont utilisés par des très grosses entreprises internationales comme Uber ou Fitbit.
Une personne surfant le site de Fitbit pouvait ainsi recevoir une page HTML comprenant également des données confidentielles du service Uber de 1Password ou du site de rencontre OK cupid. Fort heureusement ces données étaient invisibles pour l’utilisateur lambda. Malheureusement, elles étaient exploitables par toute organisation ayant remarqué le bogue.
Quelque temps plus tard, l’équipe de Project Zero réussit à reproduire le problème.
Ormandy contacte alors immédiatement Cloudflare,
En moins d’une heure, Cloudflare confirme le problème, découvre qu’il est lié, dans des circonstances inhabituelles, au service d’obfuscation des adresses de courriel, et réduit les risques en désactivant le service.
Six heures plus tard, Cloudflare découvre l’origine du problème, un bogue dans l’analyseur syntaxique HTML, qui est utilisé par plusieurs services pour optimiser le HTML du client.
Cloudflare identifie également deux services de plus occasionnant le bogue: les inclusions côté serveur (server side includes), et la réécriture automatique HTTPS, qui consiste à remplacer les hyperliens HTTP par des hyperliens HTTPS.
Le bogue est classique, il s’agit de la mauvaise gestion des limites d’une variable, avec débordement de mémoire tampon, causant le renvoi par une fonction de la variable de sortie plus une certaine quantité de mémoire la suivant. Ce qui donne envie à certains d’appeler la vulnérabilité Cloudbleed, en référence à Heartbleed.
Dans le code autogéré de l’analyseur syntaxique, un pointeur incrémenté est comparé au pointeur de fin du tampon.
Au lieu d’utiliser une comparaison supérieur ou égal, une comparaison égal à fut générée, ce qui au bout d’un moment, occasionne la fuite d’informations:
Code C généré (p = pointeur, pe = pointeur sur la fin du tampon
/* #line 877 "ngx_http_email_filter_parser.rl" */
{ dd("script consume_attr failed");
{goto st1266;} }
goto st0;
[...]
st1266:
if ( ++p == pe )
goto _test_eof1266;
Heureusement, il fallait des conditions inhabituelles pour que le bogue ait des conséquences : il devait retourner un script ou un tag img mal formé d’une taille inférieure à 4 kilo octets (sans quoi le serveur Web Nginx crash), et les trois services fautifs devaient être utilisés conjointement.
Malheureusement, le nouvel analyseur syntaxique est utilisé depuis le 22 septembre 2016. D’après les journaux de Cloudflare, la plupart des incidents se sont toutefois produits entre le 13 et le 18 février.
Les moteurs de recherche ont coopéré, et vidé leurs caches.