Bullying in Open Source: Eine neue Form des Angriffs?

Seit dem bekannt gewordenen Angriff auf die xz-Bibliothek mehren sich die Erfahrungsberichte und Diskussionen über die Sicherheit von Open Source-Projekten. Auch wenn sich noch keine akute Krise für quelloffene Softwareprojekte abzeichnet, bedarf das Thema nochmal einer allgemeineren Aufbereitung. In diesem Sinne soll einmal die Verbindung zwischen Open Source und Sicherheit aufgezeigt werden – und auch, auf welchen verhältnismäßig neueren Angriffsvektor sich die Landschaft der IT-Sicherheit potenziell einstellen sollte.

Kerckhoff’s Prinzip für beständige Sicherheitsmechanismen

Wer sich öfter mit IT-Sicherheit und seinen Grundlagen beschäftigt, wird dabei sicher auch einmal auf unterschiedliche Designprinzipien gestoßen sein. Mit am bekanntesten ist hierbei sicher Kerckhoff’s Prinzip. Das besagt: ein Sicherheitsmechanismus darf seine Sicherheit nicht aus einem unbekannten Mechanismus ziehen. Anders formuliert: Wenn das Konzept allen bekannt sein darf, aber ein Angreifer mit diesem Wissen dennoch nicht auf die für ihn nötige Lösung kommt, hält das Verfahren stand. Im weiteren Sinne lässt sich dies als „Open Design“ auch für Mechanismen außerhalb reiner Verschlüsselungsverfahren in Betracht ziehen. Hierbei gilt, dass verschleierte Teilmechanismen oder Inhalte keinesfalls verboten sein müssen. Sie sollen nach Kerckhoff nur nicht den Kernpunkt eines Verfahrens darstellen.

Dies soll sicherstellen, dass wirklich der Mechanismus selbst die Sicherheit garantieren kann. Dann basiert diese nicht allein darauf, dass der Angreifer nicht weiß, wogegen er kämpft. Erfahrungsgemäß hat dieses Prinzip auch seine Richtigkeit. Denn früher hat sich schon oft gezeigt, dass z.B. Verschlüsselungstechniken, die primär auf Geheimhaltung basierten, früher oder später gebrochen und anschließend fast völlig unbrauchbar wurden.

Das „Open Design“ in Open Source Projekten

Doch selbst wenn Sicherheitsexperten das Konzept des Open Designs hochhalten, lässt sich das Konzept leider nicht uneingeschränkt auf Open Source Software übertragen. Denn wie nicht zuletzt der Fall der xz-Bibliothek zeigte, bietet die Möglichkeit, dass grundsätzlich jeder bei Open Source mitmachen kann, auch Einfallstore für Angreifer – oder schlicht das Risiko von nicht ausreichend durchdachten und überprüften Änderungswünschen.

Dabei ist das Thema der IT-Sicherheit in Open Source durchaus von Relevanz. Das auch aus gleich mehreren Gründen: Einerseits werden gerade größere Projekte von einer Vielzahl an bekannten – dann auch mitunter proprietären – Softwarelösungen als Abhängigkeit mitverwendet. Weiterhin bieten sie aber oft Alternativlösungen zu ebensolchen proprietären Formaten. Und nicht selten bieten sie dann auch selbst Ersatz für sicherheitskritische Funktionalitäten – wie beispielsweise OpenSSL. Dabei werden die Open Source-Projekte mehrheitlich ehrenamtlich betrieben.

Leider ist die Bedrohung der xz-Bibliothek derzeit auch kein Einzelfall. In letzter Zeit werden immer häufiger Fälle bekannt, in denen Betreuer ähnliche Erfahrungen gemacht haben. Jüngst unter anderem so geschehen in mindestens drei größeren Javascript-Projekten. Und nicht zuletzt wurde vor kurzer Zeit auch Docker-Hub als „unterwandert“ festgestellt. Zwar weniger durch eine gezielte Attacke auf einzelne Akteure, sondern durch ein kontinuierliches Einfügen von schadhaften Metadaten in öffentliche Projekte. Ein Angriff auf quelloffene Projekte bleibt es somit trotzdem.

Alte Idee neu verpackt – „Bullying“ als Angriffsvektor

Für diese zurzeit vermehrt auftretenden Angriffsstrategie etabliert sich offenbar der Begriff des „Bullying in Open Source“. So bezeichnet man das kontinuierliche Ausüben von Druck und durchgängige Beschwerden, welche Betreuer einer Software dazu bringen sollen, Änderungen zeitnah und möglichst unsauber geprüft durchzulassen. Alternativ soll dadurch dafür gesorgt werden, dass zusätzliche Betreuer zur Unterstützung eingetragen werden. Wenn es sich hier nun jedoch um eingeschleuste Angreifer handelt, implementieren diese dann den Schadcode.

Dies ist, gerade zum derzeitigen Zeitpunkt, aus vielen Gründen eine Gefahr für öffentlich gepflegte Softwareentwicklung:

• Die ohnehin schon oftmals unter Zeitmangel leidenden Betreuer werden – wie geplant – noch stärker unter Druck gesetzt. Neben eventuell zu schlecht geprüften Änderungen kann dies auch zur Folge haben, dass noch mehr Projekte an Entwicklern verlieren.
• Sie unterscheiden sich kaum von tatsächlich engagierten Unterstützern – im Fall von Jia T. (xz Backdoor) engagierte dieser sich bereits jahrelang im Voraus, um sich Vertrauen zu erarbeiten.
• Oft entzieht die benötigte Prüfung den Betreuern deutlich mehr Zeit, als der Angreifer vermutlich ursprünglich aufwenden muss. Diese Zeit fehlt wiederum auch für andere Änderungen von legitimen Nutzern. Es könnte zunehmend schwieriger für Betreuer werden, sich solchen Beiträgen entgegenzusetzen.

Der Umgang mit dem Open Source Bullying

Muss Sicherheit in Open Source also nun aufgegeben werden? Soweit muss man nicht gehen. Erst einmal ist es – wenn auch wenig überraschend – wichtig, anzumerken, dass solche Angriffe voraussichtlich eher zunehmen als abnehmen dürften. Unter Umständen sind sogar bereits einige Angriffe erfolgreich gewesen oder gerade aktiv in Planung. Doch gerade der Umstand, dass selbst so subtile Versuche wie bei der xz-Bibliothek bereits recht früh erkannt wurden, sollte Grund genug sein, die Hoffnung nicht aufzugeben. Es war zwar irgendwo ein glücklicher Zufall, dass dem betreffenden Spezialist die geringe Latenzveränderung überhaupt auffiel – doch der Willen, dieser Problematik nachzugehen, hat uns vor größerem Schaden bewahrt.

Die Effektivität von Open Source steht und fällt – noch mehr als früher – mit der Anzahl an Mitwirkenden. Denn wo Angreifer versuchen, subtil offene Projekte zu unterwandern, müssen noch mehr Experten ihr Auge auf Änderungen haben. Ob es an dieser Stelle nun sinnvoll wäre, Verifizierungen für neue Betreuer zu implementieren, sei an dieser Stelle dahingestellt. Jedoch müssen wir uns erneut in Erinnerung rufen, dass wir es der – teils freiwilligen – Arbeit vieler IT(-Sicherheits)-Experten verdanken, die sich um diese Angelegenheiten kümmern.

Leider bleibt natürlich die Frage, wie mit einer eventuellen Flut solcher Anfragen umzugehen ist. Doch so abgedroschen es klingen mag – es mag sicher bereits helfen, wenn mehr Entwickler von diesem Angriffsvektor Kenntnis erlangen. Wer den Versuch, Druck zu erzeugen, früher und treffender einordnen kann, läuft weniger schnell Gefahr, darauf auch einzugehen. So, wie man heutzutage mit dem vermeintlich verursachten Druck von Phishing als Experte meist gut umgehen kann, muss man also auch lernen, dem Druck vermeintlich gut gewillter Mitprogrammierer standzuhalten.

Was wird die Zukunft bringen?

Vielleicht mag dadurch dann leider der ein oder andere ernst gemeinten Vorschlag abgeschmettert oder aufgeschoben werden. Aber gerade in größeren Projekten, die von vielen anderen mitverwendet werden, muss der Fokus – möglichst – auf der Sicherheit liegen. Perfide Angriffe wie die von Jia Tan werden dadurch natürlich nicht gleich im Handumdrehen aufgedeckt, wenn sie erst einmal implementiert sind. Jedoch hätte man an erster Stelle seine Beteiligung bereits verhindern können.

Allerdings ist man im Nachhinein natürlich immer schlauer. Und damit wir es hoffentlich auch in Zukunft sein können, bleibt uns nur: uns der immer neuen Strategien bewusst sein – und vielleicht auch darüber hinaus noch einen Beitrag zur öffentlichen Sicherheit und Projektkultur leisten.