Money Tree Browser mit Chromium-Bug-Bounties

Einführung in den Chromium Money Tree Browser

• Der Chromium Money Tree Browser ist eine Website, die Belohnungen aus dem Chrome VRP (Bug-Bounty-Programm) mit Änderungen (Fixes) an bestimmten Dateien verknüpft.
• Die Website ist sehr einfach aufgebaut, und man sollte weder eine ausgefeilte Benutzererfahrung noch eine hohe Datengenauigkeit erwarten.
• Die Bug-Bounties werden auf einzelne Dateien aufgeteilt: Wenn zum Beispiel ein Bug im Wert von 1000 $ behoben wurde und dabei 5 Dateien geändert wurden, werden jeder Datei 200 $ zugewiesen.
• Die Daten basieren auf Informationen bis Anfang November 2023.

Meinung von GN⁺

• Der Chromium Money Tree Browser ist ein interessantes Tool, das Entwicklern und Sicherheitsforschern visuell zeigt, welche Dateien im Chrome-Bug-Bounty-Programm geändert wurden und wie die entsprechenden Belohnungen verteilt wurden.
• Die Website bietet Einblicke darin, wie Belohnungen für Bugfixes berechnet werden, und kann dabei helfen, in der Security-Community nützliche Informationen zu teilen.
• Zwar sollte man die Erwartungen an Benutzererfahrung und Datengenauigkeit niedrig halten, doch die Website kann dazu beitragen, das Bewusstsein für Sicherheitslücken in Open-Source-Projekten zu erhöhen und Entwickler zu motivieren, Sicherheit stärker zu priorisieren.

[GN⁺]

Hacker-News-Kommentare

• Interesse an etwas, das einer Funktion ähnelt, die ein Entwickler schon lange bauen wollte

  • Überlegungen zur Nützlichkeit einer Methode, die auf Basis vergangener Änderungen in einer Datei oder in bestimmten Teilen einer Datei berechnet, wie wahrscheinlich es ist, dass eine gegebene Änderung Probleme verursacht.
  • Für jede Änderung einen Risiko-Score vergeben und diesen Score mit einem PR (Pull Request) verknüpfen, um Code-Reviewer auf Code hinzuweisen, der zusätzliche Aufmerksamkeit erfordert, und ihn bei Deployments als Signal zur Hervorhebung riskanter Änderungen zu nutzen.
  • Es ist schwierig, denselben Codeteil zu verfolgen, wenn er sich durch Einfügungen/Löschungen nach oben oder unten verschiebt. Ein Algorithmus, der nur auf Zeilennummern basiert, kann problematisch sein.
  • Der Hinweis, dass schon Arbeit auf Dateiebene ausreichend nützlich sein könnte.

• Hinweis darauf, dass Korrekturen in bestimmten Third-Party-Bibliotheken fehlen

  • Einige Korrekturen in Third-Party-Bibliotheken (z. B. ffmpeg) scheinen zu fehlen. Solche Fixes werden oft zuerst Upstream bearbeitet und lassen sich dadurch schwer nachverfolgen.

• Beim Blick auf viele Bugs in der Chrome-Browser-UI Gedanken über use-after-free-Probleme bei Daten, für die die Performance manueller Speicherverwaltung nicht wichtig ist

  • Beobachtungen zu use-after-free-Problemen in Code wie dem Lebenszyklus des Dialogs zur Dateiauswahl, obwohl die Performance manueller Speicherverwaltung dort nicht entscheidend ist.
  • Der Hinweis, dass es in solchem Code möglicherweise besser wäre, immer intelligentere und langsamere Pointer zu verwenden.
  • Der Verweis darauf, dass Typen wie raw_ptr<T> offenbar genau dabei helfen sollen und möglicherweise tatsächlich erfolgreich den in [2] aufgetretenen Crash abgewehrt haben.
  • Bedauern darüber, dass es im Projekt keine Möglichkeit gibt, zwischen verschiedenen Dialekten für performancekritischen Code und Code, bei dem Performance weit weniger wichtig ist, zu wechseln.
  • Überlegungen dazu, ob es fast den Aufwand wert wäre, zwei verschiedene Sprachen zu mischen, um klar zwischen performancekritischen Bereichen und Teilen mit viel asynchronem Zustand, in denen leicht Fehler entstehen können, zu unterscheiden.

• Lob für die Wirksamkeit der Visualisierung und ein Hinweis auf die CPU-Auslastung

  • Eine sehr saubere Visualisierung, mit dem Hinweis, dass die CPU-Auslastung beim Erweitern von Bereichen etwas hoch ist.
  • Die Erwartung, dass das Chrome-Team intern ein ähnliches Tool verwenden dürfte, und die Meinung, dass es nützlich wäre, um die Angriffsfläche zu verstehen.

• Lob für Idee und Umsetzung sowie eine Nachfrage zu den Rohdaten

  • Lob dafür, dass die Idee großartig ist und die Umsetzung gelungen.
  • Die Frage, ob es Zugang zu den Rohdaten gibt, sowie der Hinweis, dass ein Versuch mit Sunburst oder Tree Map lohnenswert sein könnte.

• Vorschlag, bestimmte Dateitypen nicht einzubeziehen

  • Ein detaillierter Hinweis, DEPS-, AUTHORS- und BUILD.gn-Dateien nicht einzubeziehen.

• Vorschlag zur Gewichtung anhand der Anzahl geänderter Codezeilen

  • Die Meinung, dass es interessant wäre, das dem Bug zugewiesene „Geld“ nach der Anzahl geänderter Codezeilen zu gewichten.
  • Der Vorschlag, dass, wenn 10 Zeilen in Datei A und 1 Zeile in Datei B geändert wurden, Datei A 1/11 des „Geldes“ zugewiesen bekommen sollte, weil sie den Großteil des Bugs ausmachte.

• Anfrage nach einer Funktion zur Anzeige der durchschnittlichen Belohnung pro Datei

  • Der Wunsch nach einer Funktion, die für jeden Knoten die durchschnittliche Belohnung pro Datei anzeigt.

• Idee für eine normalisierte Anzeige des Betrags anhand der Anzahl der Codezeilen

  • Ein Vorschlag für eine Version, die den Betrag normalisiert nach der Anzahl der Codezeilen anzeigt.

• Lob für die visuelle Einsicht, auf welche Bereiche man die Anstrengungen konzentrieren sollte

  • Die Bewertung, dass es sehr großartig ist, visuelle Einsichten dazu zu liefern, worauf man die Anstrengungen konzentrieren sollte.