Coucou nal (zut, ça marche pas)
Cette nuit, Google a révélé par son « Project Zero » une faille de sécurité chez CloudFlare, qui pourrait bien mériter le prix de faille de l’année.
Depuis le 22 septembre 2016, avec une aggravation depuis le 30 janvier, jusqu’au 18 février, certaines pages HTML mal formées permettaient, après traitement par CloudFlare, de participer à une magnifique loterie : lors d’un accès à la page, on obtenait la page et en cadeau Bonux un bout de mémoire vive du proxy de CloudFlare, contenant donc des données potentiellement sensibles de n’importe quel site passant par CloudFlare.
Les ingénieurs de Google ont trouvé ainsi des bouts de conversation sur des sites de rencontre ou de chat, du contenu pornographique, des mots de passe, etc., le tout dans le cache Google, sinon ce n’était pas drôle.
La réponse de CloudFlare est exemplaire en minimisation de l’impact de la faille : https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/.
Le message de Google étant plus précis sur l’impact donc : https://bugs.chromium.org/p/project-zero/issues/detail?id=1139.
J’adore l’Internet centralisé et les entreprises qui vendent du « man in the middle »…
# Et le cache des autres
Posté par Glandos . Évalué à 4.
Il n'y a pas que le cache de Google, il y a tous les autres moteurs de recherche.
Le plus embêtant, c'est que les utilisateurs n'ont pas beaucoup de moyen de savoir que leur site préféré utilise CloudFlare. Et qu'il leur faut donc changer leur mot de passe…
[^] # Re: Et le cache des autres
Posté par laurentb (site web personnel) . Évalué à 2.
Il y a https://github.com/cloudflare/claire pour Chrome
[^] # Re: Et le cache des autres
Posté par syntaxerror . Évalué à 7.
si si
http://www.doesitusecloudflare.com/?url=linuxfr.org
[^] # Re: Et le cache des autres
Posté par losynix . Évalué à 5.
Une liste non exhaustive des sites potentiellement affectés est disponible ici
# Exemplarité
Posté par Anonyme . Évalué à 10. Dernière modification le 24 février 2017 à 11:36.
Elle est très complète techniquement et elle ne minimise pas la gravité de la faille outre mesure.
Ils disent clairement que c’est très grave, mais de courte durée (activation le 13/02, découverte et correction le 18/02) et sur des sites pour lesquels les administrateurs ont activé un certain set de fonctionnalités (donc une faible proportion de requêtes, même si potentiellement les données de n’importe lequel de leur client ont pu être accessible).
Compare avec ce qui se fait ailleurs, notamment en France (il y a des exemples récents).
[^] # Re: Exemplarité
Posté par Pinaraf . Évalué à 9.
Ho je sais qu'il est possible de faire bien pire que ce que fait CloudFlare, mais ils mettent tellement bien en forme que des collègues n'ont pas compris l'impact de la faille tout de suite.
Accessoirement, la courte durée reste théorique, ils disent eux-même «The earliest date memory could have leaked is 2016-09-22.» (mais c'est dans les détails, dans le préambule ils s'abstiennent bien de faire peur).
Leur réponse est parfaite techniquement, mais la section «External impact and cache clearing» devrait être la première section de l'article, et surtout elle ne précise pas assez clairement que chaque mot de passe d'un site utilisant cloudflare a pu potentiellement fuiter dans la loterie. Rien non plus sur l'impact pour des données privées telles que celles qu'a pu récupérer le chercheur de Google (extraits de conversations notamment).
D'ailleurs, quand on donne «0.00003% of requests», je sais pas pour toi, mais je ne trouve pas sur internet le nombre de requêtes traitées par jour par CloudFlare, et donc ce chiffre est inexploitable…
[^] # Re: Exemplarité
Posté par bunam . Évalué à 5.
Quand tu vois le nombre de DC
https://www.cloudflarestatus.com
et :
https://blog.cloudflare.com/the-porcupine-attack-investigating-millions-of-junk-requests/
dans une partie du post
"The spikes were large in scale - 500k to 1M HTTP requests per second. Something very strange was going on."
Je pense que le nombre de request est monstrueux et du coup les 0.00003% peuvent devenir significatifs.
[^] # Re: Exemplarité
Posté par Zenitram (site web personnel) . Évalué à -10.
0.00003% sur 1 Milliard ou 0.00003% sur 1 Trillard reste 0.00003% non significatif.
La valeur absolue n'a d’intérêt que pour ceux qui veulent trouver quelque chose de significatif en tordant la réalité.
Juste pour relativiser : 0.00003%, c'est 1000x moins que, par exemple, le pourcentage de femmes qui meurent en accouchant, le truc bien naturel, en France (et vu le nombre d'accouchements, ça en fait des mortes dans l'année, on ne dit pas pour autant que c'est significatif en absolu car on s’intéresse toujours au pourcentage pour ça; perso je dirai juste que pour ce cas de mon exemple, 0.03% est significatif, je ne dirai pas "10 est significatif" car c'est le même problème de signification qu'on parle de la ville, le pays ou la planète)
J'avoue ne pas comprendre pourquoi vous voulez parler de nombres absolus qui n’apportent rien pour savoir si c'est significatif dans le flux. Question idiote : à partir de quel nombre absolu ça serait significatif? Est-ce que votre choix de nombre serait différent si c'est comparé à 1 milliard, 1 trilliard, 1 trilliard de trilliard?
[^] # Re: Exemplarité
Posté par StyMaar . Évalué à 10. Dernière modification le 25 février 2017 à 19:49.
Ce raisonnement est assez bête en fait, ce qui importe ce n'est ni le nombre total de requête affecté ni le ratio, ce qui compte c'est le nombre (ou le ratio) de personnes affecté. Comme très peu de françaises accouchent plus de 10 fois, la probabilité de mourir d'un accouchement dans sa vie est du même ordre de grandeur que la probabilité de mourir lors d'un accouchement en particulier.
Dans le cas d'HTTP la situation est bien différente: si je vais sur https://korben.info, mon navigateur fait une centaine de requête vers ce domaine par page chargée, admettons que j'aille 1 fois par jour sur ce site et que j'ouvre en moyenne 2 page, ça fait 200 requêtes effectuée par jours sur ce domaine. En 5 mois d'existence de la faille, ça fait donc 30 000 requêtes effectuées vers ce domaine. Là, d'un coup la probabilité qu'une de mes requêtes se soit retrouvée dans la nature avec un cookie d’authentification valide s'approche de 1%.
Bon OK pour Korben.info je m'en tape un peu. Si je regarde la liste des sites potentiellement affectés je vois des sites un peu moins anodins tels que transferwise.com, uber.com ou encore okcupid.com. OK les gens passent plus de temps à glander sur le net qu'à transférer de l'argent ou à commander des VTC, mais en 5 mois à raison de 2 courses en uber par semaine, ça fait encore plus d'une chance sur mille, et cela pour chacun des sites affectés : c'est clairement loin d'être négligeable.
Il y a donc bien un problème et il vient du fait que le nombre de requête effectuées par chaque personne est monstrueux.
[^] # Re: Exemplarité
Posté par Anonyme . Évalué à 4.
Qu’on se comprenne bien, je ne défends pas CloudFlare en tant que tel, seulement leur communication sur cet incident et je trouve que tu n’es pas honnête en disant qu’elle est mauvaise.
Dès le second paragraphe, ils précisent le type de faille et le type de données qui a pu fuiter :
Le ciquième paragraphe commence par « c’est un problème d’une grande gravité » :
Sur ce point, je suis d’accord.
[^] # Re: Exemplarité
Posté par Pinaraf . Évalué à 5.
Il manque dans ce paragraphe, tout comme dans l'intégralité de la première partie de leur article, un élément crucial qui est certes implicite quand on comprend leur fonctionnement technique, mais qui peut échapper à une personne légèrement moins intéressée : «other sensitive data from any website served previously on this edge server». Ils n'écrivent pas explicitement que le site pentagon.gov peut avoir fourni des données de petitchat.com… (ou l'inverse)
Mais effectivement, mon journal est peut-être mal formulé sur ce point, c'est une minimisation par utilisation de l'implicite plutôt que l'explicite, et le fait de «noyer» dans la technique des points clés du problème. Peut-être qu'une annonce plus officielle, plus corporate, viendra régler cet aspect, mais ça m'étonnerait…
# le tweet du vendredi 16h00
Posté par Anonyme . Évalué à 5.
le genre de tweet dont tu te passerais bien. Après une journée a mouler sur slashdot :'D
Could someone from cloudflare security urgently contact me.
from : Vulnerability researcher at Google
tentative de traduction : quelqu'un de l'equipe de sécurité cloudfare peut'il me contacter immédiatement.
[^] # Re: le tweet du vendredi 16h00
Posté par Pinaraf . Évalué à 10.
Ouais il abuse le mec de Google, il aurait pu passer par le programme de rapport de failles de CloudFlare et gagner un TeeShirt…
# Petit sondage : pensez-vous que CloudFlare va de faire Dawinizer ?
Posté par bunam . Évalué à -10. Dernière modification le 24 février 2017 à 13:45.
ps : Dawinizer : néologisme signifiant qu'une entité va mourir, car elle n'était pas adaptée à son milieu.
[^] # Re: Petit sondage : pensez-vous que CloudFlare va de faire Dawinizer ?
Posté par windu.2b . Évalué à 4.
Je suppose que tu voulais dire "darwiniser" (avec un 'r') ?
[^] # Re: Petit sondage : pensez-vous que CloudFlare va de faire Dawinizer ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6.
non, il voulait dire "brownsonisé" (avec un 'z')
[^] # Re: Petit sondage : pensez-vous que CloudFlare va de faire Dawinizer ?
Posté par Meku (site web personnel) . Évalué à 2. Dernière modification le 24 février 2017 à 19:28.
« Bonsonizer » plutôt, non ?
[^] # Re: Petit sondage : pensez-vous que CloudFlare va de faire Dawinizer ?
Posté par bunam . Évalué à -1.
Darwiniser oui ! ;) mais en fait ça ne correspond pas à ce que je voulais exprimer cf : https://fr.wiktionary.org/wiki/darwiniser
Je cherchais un mot combiné de Darwin + bronsoniser (https://fr.wiktionary.org/wiki/bronsoniser) pour exprimer l'implaquable sélection naturelle… https://fr.wikipedia.org/wiki/Sélection_naturelle
bref raté
# La réponse officielle de CF pour les clients, pour infos.
Posté par lince . Évalué à 3.
Dear Cloudflare Customer:
Thursday afternoon, we published a blog post describing a memory leak caused by a serious bug that impacted Cloudflare's systems. If you haven't yet, I encourage you to read that post on the bug:
https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/
While we resolved the bug within hours of it being reported to us, there was an ongoing risk that some of our customers' sensitive information could still be available through third party caches, such as the Google search cache.
Over the last week, we've worked with these caches to discover what customers may have had sensitive information exposed and ensure that the caches are purged. We waited to disclose the bug publicly until after these caches could be cleared in order to mitigate the ability of malicious individuals to exploit any exposed data.
In our review of these third party caches, we discovered data that had been exposed from approximately 150 of Cloudflare's customers across our Free, Pro, Business, and Enterprise plans. We have reached out to these customers directly to provide them with a copy of the data that was exposed, help them understand its impact, and help them mitigate that impact.
Fortunately, your domain is not one of the domains where we have discovered exposed data in any third party caches. The bug has been patched so it is no longer leaking data. However, we continue to work with these caches to review their records and help them purge any exposed data we find. If we discover any data leaked about your domains during this search, we will reach out to you directly and provide you full details of what we have found.
To date, we have yet to find any instance of the bug being exploited, but we recommend if you are concerned that you invalidate and reissue any persistent secrets, such as long lived session identifiers, tokens or keys. Due to the nature of the bug, customer SSL keys were not exposed and do not need to be rotated.
Again, if we discover new information that impacts you, we will reach out to you directly. In the meantime, if you have any questions or concerns, please don’t hesitate to reach out.
Matthew Prince
Cloudflare, Inc.
Co-founder and CEO
[^] # Re: La réponse officielle de CF pour les clients, pour infos.
Posté par Anonyme . Évalué à 10.
oh put*n j'ai cru un instant que le pdg de clouflare etait sur linuxfr !
[^] # Re: La réponse officielle de CF pour les clients, pour infos.
Posté par lince . Évalué à 1.
J'avais commencé à virée la signature, mais je me suis dit… étant une citation du mail…. mettre le pavé en entier me semblait plus cohérent (surtout pour voir la provenance).
[^] # Re: La réponse officielle de CF pour les clients, pour infos.
Posté par Pinaraf . Évalué à 4.
Ouais, t'as de la chance, tu aurais pu recevoir « You are receiving this email because you are one of the customers where our team was able to identify data that was leaked due to the bug and stored in one of these third party caches.»
Beaucoup moins fun…
[^] # Re: La réponse officielle de CF pour les clients, pour infos.
Posté par Pinaraf . Évalué à 10.
Tu veux rire un peu ? Regarde ton mail en texte brut, ils ont fait une erreur à l'envoi (en tout cas sur celui que j'ai eu)
Le même mail :
- en texte brut : « You are receiving this email because you are one of the customers where our team was able to identify data that was leaked due to the bug and stored in one of these third party caches. »
- en HTML : « Your domain is not one of the domains where we have discovered exposed data in any third party caches. »
Donc les plus barbus avec mutt et cie (ou avec un lecteur de mail configuré pour le texte brut) vont paniquer, pour les autres c'est bon rien de grave…
[^] # Re: La réponse officielle de CF pour les clients, pour infos.
Posté par lince . Évalué à 0.
J'ai regardé en affichant la source et il semble qu'ils aient corrigés depuis, ou en tout cas ça apparait pas sur le mien :')
[^] # Re: La réponse officielle de CF pour les clients, pour infos.
Posté par bunam . Évalué à -1.
Qui n'est pas chez CF ici ?? ;p
(email correct ici aussi)
# cloudfl..what?
Posté par Katyucha (site web personnel) . Évalué à 6.
J'ai jamais compris à quoi servait ce service …
[^] # Re: cloudfl..what?
Posté par Sufflope (site web personnel) . Évalué à -3.
Crée une boite avec un succès fulgurant qui génère des milliards de pages vues par jour sur toute la planète et qui n'a pas envie de se transformer en OVH parce que c'est pas son métier, et tu auras une meilleure idée.
[^] # Re: cloudfl..what?
Posté par Katyucha (site web personnel) . Évalué à 9.
Oh excusez moi, je ne savais pas que les questions sérieuses étaient interdites dans les commentaires
[^] # Re: cloudfl..what?
Posté par bunam . Évalué à 10.
www.cloudflare.com c'est essentiellement un frontal web (reverse proxy) pour un site web, il faut absolument confier les DNS à cloudflare. L'interface d'admin des DNS est superbe !
Ensuite on a 2 possibilités soit on l'utilise gratuitement :
- l'IP de son serveur est masquée par leurs IPs
- on dispose d'un CDN, les pages de ton site qui peuvent être mises en cache le sont sur l'ensemble de leurs serveurs réparti géographiquement
- un certificat SSL peut être activé entre les internautes et leurs serveurs CDN
- une protection DDOS
Pour les offres payantes, il y a des options que je n'ai pas mises en œuvre…
https://www.cloudflare.com/fr/plans/
l'offre gratuite permet d'améliorer leur détection des DDOS, on fait partie de l'ensemble de leur réseau et on augmente leur surface de détection. J'en suis conscient.
www.cloudflare.com me semble assez facile à mettre en œuvre…
J'ai un gros client (1er dans leur domaine en France et en au Royaume-Uni, avec une DSI au Royaume-Uni) qui a choisi https://www.incapsula.com un concurrent de https://www.cloudflare.com.
Ensuite on peut citer ceux-ci, et ils me semblent plus difficiles à mettre en œuvre :
https://www.akamai.com
https://www.cachefly.com
https://www.maxcdn.com.
Plus d'infos ici :
https://en.wikipedia.org/wiki/Content_delivery_network
En fait, il serait difficile pour certains sites d'exister et être consultable dans de bonnes conditions, sans ces CDNs. Apple et Microsoft utilisent Akamai. Pour Apple, elle est entrain de ce construire son propre CDN et se détache d'Akamai. Elle à même fiancé les début d'Akamai et lâché l'affaire quand Microsoft est devenu cliente.
[^] # Re: cloudfl..what?
Posté par damsos . Évalué à 3.
Il existe aussi une petite société francaise spécialisée dans la revente de solutions CDNs avec des prix compétitifs http://www.atanar.net ils sont à fond open source.
[^] # Re: cloudfl..what?
Posté par steph1978 . Évalué à 3.
On est d'accord sur l'usage.
Après, en terme d'exposition des données privées de ses clients, à leur insu, c'est presque intolérable.
[^] # Re: cloudfl..what?
Posté par Tangi Colin . Évalué à 1.
Niveau technologie, je sais que cachefly repose sur du TCP anycast, quelqu'un sait si les autres CDN sont sur le même type de techno ? C'est plutôt standardisé (via des RFC par exemple) ou chacun à sa solution custom ?
[^] # Re: cloudfl..what?
Posté par gouttegd . Évalué à 4.
Il y a un groupe de travail à l’IETF sur la question (le groupe Content Delivery Networks Interconnection, CDNI) qui a déjà produit plusieurs RFCs (par exemple les 6707, 6770, 7337, …) visant à promouvoir l’interopérabilité entre CDN.
Je ne sais pas si ça a été suivi d’effets chez les fournisseurs concernés.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.