Eine interessante Lektüre zum Thema Open-Source-Security liefert Google in einem aktuellen Blogeintrag. Das Unternehmen beschreibt das Stopfen der “Mad Gadget Vulnerability” von 2015, einer der schädlichsten Sicherheitslücken, die man im Unternehmen je gesehen habe.
Um die Lücke in den Worten des Google-Mitarbeiters Justine Tunney zu beschreiben: Sie funktioniere in etwa so, als würde man den Kassierer einer Bank dazu ausbilden, freundlich darum bittenden Kunden sämtliches Geld aus dem Safe auszuhändigen. Konkret steckte die Lücke in den Gadget-Klassen der Apache Commons Collections, die als Java-Unterbau für zahlreiche andere Projekte fungieren. Der zugehörige Code deserialisiere Objekte für den kompletten JVM-Prozess, Turing-komplett und mit einer Exec-Funktion.
Das perfide an der Lücke lag in ihrer Unauffälligkeit, wie ein Blogpost von Foxglove Security im November 2015 schrieb. Da gab es bereits seit neun Monaten Proof-of-Concept-Code für die Lücke. Doch weder war die Java-Bibliothek geflickt, noch gab es Patches für die zahlreichen (kommerziellen) Anwendungen, die auf dem dazugehörigen Code aufsetzten, etwa Weblogic, Websphere, Jboss, Jenkins oder Open NMS.
Immerhin schreckte der Blogeintrag die Branche auf, Oracle, Cisco, Red Hat, Jenkins, VMWare und andere gaben Sicherheitswarnungen heraus. Bei vielen Open-Source-Projekten kamen diese allerdings nicht an, was einer weiteren Google-Mitarbeiterin fünf Monate nach der Ankündigung von Foxglove Security auffiel. Im März 2016 fingen sie und weitere Mitarbeiter von Google damit an, Pull Requests an die betroffenen Open-Source-Projekte zu schicken.
Dabei wurde ihnen klar, dass das Problem größer war, als ursprünglich angenommen. Buildsysteme wie Maven entfernen alte Versionen nicht automatisch, über Abhängigkeiten konnten sich auch die gepatchten Projekte die Sicherheitslücke wieder zuziehen. Also begann Google, die fehlerhaften Versionen der Apache Commons Collections zu entfernen. Das geschah über einen SQL-Query auf die öffentlichen Github Repositories, wobei man 2600 Projekte entdeckte, die auf die fehlerhafte Version referierten.
Github bringt jedoch kein Tool mit, um viele Projekte auf einen Schlag zu patchen, also stellte Google noch mehr Mitarbeiter ab, um alle Lücken zu schließen, in Handarbeit. Das Projekt Rosehub, von dem der Blogeintrag handelt, dauerte einige Wochen, in denen Mitarbeiter Patches an alle möglichen Projekte schickte, um die Lücke zu schließen.
Das Eingreifen von Googles Mitarbeitern verhinderte womöglich zahlreiche Security-Zwischenfälle in der Zukunft, allerdings nicht alle: So nutzten Ende 2016 Hacker die Lücke offenbar, um in das Netzwerk von San Franciscos Verkehrsbetrieben einzudringen und das Ticketsystem lahmzulegen. Außerdem wurden sensible Daten gestohlen und gedroht, diese nur gegen einen Bitcoin-Betrag wieder freizugeben. Die Stadt ging nicht darauf ein.
Wäre die Software der Verkehrsbetriebe Open Source gewesen, so schließt der Blogpost, hätte man womöglich auch hier einen Fix anbringen können. Auch ein Tool für Github, um zentral die Sicherheitslücken zu schließen, hätte die Arbeit vermutlich einfacher gestaltet. Zugleich wirft der Eintrag ein Licht auf die Schattenseiten der Popularität von Open-Source-Projekten.
