1 points par GN⁺ 2025-08-12 | 1 commentaires | Partager sur WhatsApp
  • Le jury de récompenses VRP de Chrome a récemment décidé une récompense de 250 000 dollars pour un signalement de vulnérabilité de sécurité.
  • La vulnérabilité signalée est un bogue du composant ipcz ; le renderer peut dupliquer un handle du processus du navigateur, ce qui permet une possible sortie de sandbox.
  • Le dossier concerne la zone Chromium > Internals > Mojo > Core.
  • Cette vulnérabilité peut augmenter la menace pour la sécurité des utilisateurs.
  • Ce problème est en cours de correctif via des changements de code.

Aperçu des principaux points

  • Une vulnérabilité de sécurité extrêmement sérieuse a été signalée récemment dans le projet Chromium.
  • Il s’agit d’un défaut du composant ipcz qui donne à un renderer, qui devrait rester dans la sandbox, la possibilité de dupliquer un handle du processus navigateur et de sortir de l’isolation de sécurité.
  • Cette action constitue une menace fondamentale pour la structure de la sandbox du navigateur.

Décision et portée de la récompense Chrome VRP

  • Le panel du Chrome Vulnerability Reward Program (programme de récompense) a décidé une récompense de 250 000 dollars pour ce signalement de vulnérabilité.
  • Cette décision reflète la gravité de la vulnérabilité ainsi que sa difficulté de découverte et son impact.
  • C’est un cas qui montre une volonté d’encourager activement les signalements de vulnérabilités de sécurité importantes.

Gestion interne

  • Cette issue est traitée dans les catégories Internals>Mojo>Core et Internals>Mojo.
  • Plusieurs changements de code connexes sont nécessaires, avec notamment certains commits de code sur Gerrit.
  • Les revues formelles, y compris la revue des documents de conception, sont également en cours.

Patch et impact

  • Ce problème est actuellement en cours de patch via des modifications de code.
  • Le problème affecte plusieurs jalons de release de Chromium et la priorité des mises à jour de sécurité est élevée.
  • Il existe un risque que ce bogue permette de neutraliser les barrières de sécurité des systèmes des utilisateurs.

Points connexes et réponse du système

  • Un enregistrement IRM (Incident Response Management) a également été créé pour ce problème.
  • Les détails de ce bogue sont suivis et soumis à un contrôle d’accès via divers systèmes de gestion internes, y compris les changements de code générés automatiquement, les problèmes de sécurité associés, la revue de conception et la gestion des releases.
  • Une distribution et une communication rapides et efficaces d’un patch de sécurité auprès de la communauté et des utilisateurs sont nécessaires.

1 commentaires

 
GN⁺ 2025-08-12
Avis de Hacker News
  • Il dit qu’il a eu un exploit assez fiable sur le navigateur le plus utilisé, et pense que s’il l’avait vendu sur le marché noir, il aurait gagné bien plus sans payer d’impôts. Les outils de sécurité comme l’EDR (Endpoint Detection and Response) sont désormais largement déployés, donc les exploits sont plus susceptibles d’être repérés rapidement, mais certains services de renseignement de régimes autoritaires peuvent quand même juger ce type de piratage intéressant.
    • On se demande pourtant si l’on peut vraiment gagner plus sans impôts sur le marché noir, et surtout où et comment trouver des criminels fiables. Les échanges reposent sur l’anonymat et la confiance ; même si tu es payé, d’autres risques (comme le chantage) peuvent surgir, et il n’est pas facile de dissimuler une grosse somme, d’où la question : comment vendre un exploit en toute sécurité ? En gagnant ainsi, tu ne peux pas non plus publier sur ton blog ni te faire connaître de chercheurs ou de recruteurs, ce qui pourrait nuire à ta carrière et à ta réputation.
  • Vendre sur le marché noir ne signifie pas que l’argent arrive automatiquement sans impôts ; c’est même souvent l’inverse. Si un gros montant finit sur un compte bancaire, il sera tôt ou tard surveillé ; il faut donc, comme avec l’impôt, blanchir l’argent, et payer une commission au blanchisseur, ce qui finit par revenir comme une taxation en double. La cryptomonnaie n’est pas une solution simple non plus, car on peut aussi t’exiger une preuve de minage.
  • Beaucoup se concentrent uniquement sur l’argent ; certains proposent de viser une approche plus "correcte". C’est un vrai sujet d’ouvrir la porte à de nombreux criminels pouvant nuire à des millions de personnes pour un profit potentiel.
    • On rappelle aussi qu’il n’est pas certain de gagner plus en vendant sans impôt sur le marché noir. Dans Chrome, une présentation indique officiellement que l’on peut obtenir jusqu’à 200 000 $ pour une sandbox escape ou son contournement (diapositive 72). Le dépôt de la présentation est sur GitHub ; comme GitHub est actuellement down, le lien reddit est également partagé.
    • Ce type de vulnérabilité est l’un des rares cas où existe un marché de revente. Ces bugs peuvent être revendus plusieurs fois, et il existe même des entreprises spécialisées qui les vendent à des services de renseignement ou à des autorités d’application de la loi à l’échelle nationale.
  • Pour une sandbox escape et un rapport de haute qualité dans Chrome, la récompense est de 250 000 $. Mozilla ne donne que 20 000 $ pour une vulnérabilité équivalente, selon le programme officiel, le lien Mozilla bug bounty.
    • Selon Wikipédia, ce montant représente 0,012 % du bénéfice net de Mozilla. Les commentaires disent que ce type de comparaison n’est pas adapté, mais en pourcentage cela revient à environ 50 fois celui de Google, donc “assez”. (Le calcul initial était faux ; il corrige en précisant que c’est bien 0,012 % : 20 000 $ représentent 0,012 % de 157 000 000 $, donc 50 fois le pourcentage de Google.)
    • Chrome a 15 à 20 fois plus d’utilisateurs que Firefox, donc les vulnérabilités y sont aussi beaucoup plus chères sur le marché noir. Safari peut être encore plus cher, parce que l’utilisateur moyen est plus aisé et moins attentif à la sécurité.
    • En regardant la santé financière des deux sociétés, Google gagne bien plus d’argent que Mozilla.
    • Quelqu’un voudrait faire la parodie du “si tu étais le CEO de Mozilla sur HN, dis ce que tu veux” : imaginer chacun plaidant sérieusement au bureau en faveur de sa politique préférée (protection de la vie privée, renforcement des standards web, amélioration des performances, hausse des récompenses bug bounty, etc.), tandis qu’en arrière-plan une courbe rouge de baisse du chiffre d’affaires tombe continuellement en slow-motion.
    • Même sur un marché gris, la récompense liée aux vulnérabilités Firefox est bien plus faible, côté demande comme côté offre.
  • En voyant la phrase “ouverture de l’incident cinq jours avant pour ne le divulguer que cette semaine”, un commentaire prend cela comme un clin d’œil à DEFCON.
  • En rappelant, ce bug est une question de logique/de timing ; le fait qu’il soit écrit en Rust n’en fait pas une classe de vulnérabilité qu’on pourrait bloquer.
  • Quelqu’un demande s’il existe des explications claires pour comprendre précisément ce qu’est une sandbox escape quand on ne maîtrise pas bien les notions de “renderer”, “native API” et “sandbox” dans les navigateurs.
    • Premièrement, compromettre le processus renderer grâce à un bug du moteur JavaScript, etc., c’est l’étape 1, et dans ce cas le renderer reste enfermé dans la sandbox. Le bug de ce post concerne l’étape 2, la sandbox escape. Le patch.diff publié est décrit comme un patch de simulation d’un processus renderer déjà compromis.
  • Le commentaire sur la récompense est disponible ici.
  • Une récompense de ce niveau, capable de changer une vie, donne le vertige — et c’est agréable d’en voir une aussi élevée.
    • Au Danemark où je vis, même sans impôts cette somme ne suffit pas pour acheter un appartement d’une seule pièce. Quand j’ai reçu mon premier bonus de 240 000 $, je croyais que ma vie changerait, mais 100 000 $ sont partis en impôts. Après avoir payé 20 000 $ pour une voiture, il ne restait pas grand-chose à faire. C’était nettement insuffisant pour les prix immobiliers à LA/SF/NYC, et pas de quoi lancer non plus une startup. J’aurais peut-être pu vivre 2 à 3 ans comme un étudiant, mais j’avais déjà 34 ans, revenir à un mode étudiant était difficile. Finalement, ça n’a pas vraiment changé ma vie ; bien sûr, c’est génial d’avoir reçu une telle somme, mais mon existence ne s’est pas transformée comme je l’espérais. Il y a 25 ans, et encore aujourd’hui, même 1 million de dollars (600 000 $ net) ne suffit pas pour changer la vie où que ce soit dans ces trois villes. Le mieux que l’on puisse faire, c’est peut-être payer l’apport d’achat d’un logement ou les frais d’université d’un enfant, mais je n’ai pas ressenti la liberté à laquelle je m’attendais.
    • La valeur dépend de l’endroit où l’on vit. Même dans les pays développés, 250 000 $ ne suffit généralement pas à “changer une vie”, plutôt à “souffler un peu”. Une fois l’impôt payé, c’est souvent insuffisant pour acheter un logement.
  • C’est impressionnant de trouver des bugs dans un projet de cette taille ; on dirait une aiguille dans une botte de foin.
    • Un projet plus grand et plus complexe a plus de code et donc potentiellement plus de bugs, donc il peut être plus facile de détecter des anomalies qu’un petit projet. Mais pour des bugs critiques type Sandbox Escape, la difficulté est réelle, car la politique de primes de Google attire déjà énormément de gens en analyses manuelles et automatiques (y compris fuzzing), rendant la découverte ardue. En 2014, il a découvert par hasard un bug dans Chrome (pas en cherchant, en écrivant juste du JS), l’a signalé, et Google lui a versé 1 500 $. Il dit que cela lui avait pris environ 30 minutes. Lien concerné
    • Inversement, un gros projet peut être plus facile à explorer justement à cause des interactions étranges entre composants. Il faut cibler les frontières de sécurité (ici la communication entre renderer et broker) et creuser les cas limites. Google paie pour ce type de bug, donc la récompense est importante en cas de découverte. Cela dit, il faut bien admettre qu’il faut être un chercheur très compétent pour en trouver.
  • La vitesse de paiement de la récompense impressionne aussi. La prime est arrivée en environ 4 semaines, alors que beaucoup d’entreprises mettent des mois à seulement reconnaître un rapport de bug.
  • S’il y avait une nouvelle ownership après qu’un démantèlement de Chrome soit imposé par le DOJ, il exprime des doutes sur la pérennité de bug bounties à ce niveau.