Feed auf
Postings
Kommentare

Sascha Lobo fordert in einer Spiegel-Kolumne über den Heartbleed-Bug, dass große Firmen, die Open Source nutzen, die Qualitätssicherung für diesen Code finanzieren und durchführen sollten. Er schreibt:

„Es fängt damit an, dass ein einzelner, freiwilliger Programmierer ein paar fehlerhafte Zeilen Open-Source-Code schreibt, also für ein offenes, nachvollziehbares Programm, das verwenden kann wer möchte. Dann aber wird dieser Fehler nicht entdeckt, und das Programm wird flächendeckend verwendet, für Milliardenumsätze und delikateste Daten. Internetkonzerne wie Google, Yahoo, Facebook, Amazon nutzten das kostenlose Programm. Bei einem Börsenwert allein dieser vier von über 600 Milliarden Dollar ist das keine Frage der Mittel. Stattdessen lässt sich eine grundlegende Fehlentwicklung erkennen. Die digitale Wirtschaft hängt substantiell von Open-Source-Entwicklungen ab, sie vertraut voll auf deren Funktionsfähigkeit – aber sie gibt offensichtlich nicht ausreichend Kapital, Arbeitskraft, Know-how zurück, um die notwendige Qualitätssicherung zu gewährleisten. Als würde Mercedes herumliegende, kostenlose Räder in seine Autos einbauen und dann zerknirscht dreinschauen, wenn die Reifen bei voller Fahrt platzen.“

Mal abgesehen davon, dass der letzte Satz eine Unverschämtheit und ein Schlag ins Gesicht aller Open-Source-Projekte ist, weil er unterstellt, dass deren Qualität grundsätztlich schlecht ist und mit herumliegendem Schrott verglichen werden kann, ist das auf den ersten Blick ein sinnvoller Ansatz. Große Internetfirmen mit viel Kapital nutzen freie Software und könnten so etwas zurückgeben. Oder?

Nein, kein sinnvoller Ansatz, wie ich finde. Denn wenn die Communities, die die freie Software entwickeln, den Code-Review in die Hände von großen Internetfirmen geben, die unbestritten ganz eigene Interessen verfolgen, besteht die Gefahr, dass diese Firmen den Review auch für ihre eigenen Interessen nutzen und die Funktionalität der Software, die sie eigentlich nur reviewen sollen, in ihrem Sinne – oder im Sinne bestimmter Auftraggeber – ein bisschen funktional erweitern.

Worum geht es also letztlich? Richtig, es geht um nichts anderes als um Vertrauen. Um den Code-Review an große Firmen wie „Google, Yahoo, Facebook, Amazon“ abzugeben, muss man diesen Konzernen vertrauen, dass beim Review alles mit rechten Dingen zugeht. Und dieses Vertrauen fehlt mir offen gestanden.

Ihr haltet mich für paranoid? Dann denkt nochmal drüber nach. Möchtet ihr den Code-Review von freier Software wirklich in die Hände von Firmen wie Google und Facebook geben, die mindestens im Verdacht stehen, mit der NSA zu kooperieren, und deren eigenes Datenschutzgebaren auch nicht grade die Unschuld vom Lande widerspiegelt, und dann diesem Review vertrauen? Meiner bescheidenen Meinung nach ist dieser „Closed-Source“-Review so gut, als hätte gar kein Review stattgefunden. Anders ausgedrückt: Weil man grade diesen Firmen nicht trauen kann, bräuchte es einen Review vom Review. Sinnvoll und ökonomisch geht anders.

Stattdessen sind die vielen Einzelpersonen aufgerufen, die eine freie Software nutzen und das Know-How haben, einen Code-Review durchzuführen, sich an diesem Prozess zu beteiligen. Natürlich ist das nicht ganz so einfach, da die Mitarbeit an diesen Projekten meist freiwillig geschieht. Wie könnte man die entsprechenden Menschen nun motivieren, sich an so einem Code-Review zu beteiligen? Ich hatte neulich zusammen mit Atari-Frosch die Idee, dass man einen „Month of Code Review“ ausrufen könnte, während dem sich Menschen, die den Code freier Software reviewen möchten, online oder an einem Ort zusammentun und gemeinsam freie Software reviewen. Aus einer „Week of Code Review“ könnte man auch ein Event machen, das ähnlich wie der Chaos Communication Congress oder ähnliche Veranstaltungen von Vorträgen begleitet wird.

Die Vorteile eines solchen öffentlichen und gemeinsamen Code-Reviews gegenüber dem geschlossenen Review innerhalb einer großen Firma sind offensichtlich. Unter derart offenen Bedingungen ist es für eine einzelne Person viel schwieriger, während des Reviews bösartigen Code einzuschleusen, da eine Kontrolle durch die anderen Reviewer gegeben ist. Das gilt natürlich auch für Fehler, die selbstverständlich auch während eines Reviews passieren können.

Große Firmen können dann natürlich gern im Sinne Lobos ein solches Event sponsern. Aber den Bock zum Gärtner zu machen, indem man ihnen den Code-Review vollständig überlässt, ist nicht die Lösung des Problems, sondern schafft vielmehr neue Probleme, die zu neuen Sicherheitslücken wie Heartbleed führen können.

Flattr this!

6 Kommentare auf “Heartbleed: Lösen Code-Reviews durch große Firmen das Problem?”

  1. Eberhard sagt:

    Es tut mir einerseits leid, daß Heartbleed jetzt offensichtlich zu einer Krise der Open-Source-Programmierer führt, weil die sicher mit sehr viel Herzblut (!) bei der Sache waren und sind.

    Andererseits verkaufe ich selbst kommerzielle Sicherheitssoftware und schließe mich daher der Überzeugung meines Kollegen (der diese programmiert) an: Open Source Software kann im Sicherheitsbereich nie so gut sein wie kommerzielle Software, deren Quellcode nicht offengelegt wird.

    Aus vielen Gründen, aber der meines Erachtens wichtigste Grund ist: gerade weil der Quellcode geheim ist, können Fehler, die er ggf. natürlich auch hat – die Idee absolut fehlerfreier Sofware ist eine Illusion – kaum entdeckt und mißbraucht werden. Zumindest nicht so leicht wie bei Open-Source-Software.

    Die Frage stellt sich mir auch grundsätzlich: wieso gibt es überhaupt noch so viel Open-Source-Software? Wäre es im Zeitalter von PayPal und anderer internationaler Micro-Payment-Systeme nicht ein leichtes, die Programmierer für ihre Arbeit zu bezahlen? Ich glaube nicht, daß diese Geld aus Prinzip verschmähen. Schließlich gehen auch die mal gerne ab und zu ein Eis essen …

  2. Alex Schestag sagt:

    Du sitzt hier einem weit verbreiteten Irrtum über Open Source und freie Software auf. Open Source und freie Software ist nicht gleich nicht kommerziell. Open-Source und auch freie Software ist keine Freeware, sondern darf – zumindest bei freier Software, denn nicht jede quelloffene Software ist frei – unter Beibehaltung der Lizenz, die jedem das Recht der uneingeschränkten Nutzung, Einsehbarkeit des Codes, Veränderung des Codes und der uneingeschränkten Weitergabe des Codes gibt, gegen Geld weitergegeben werden, und man darf für Support oder für individuelle Anpassungen des Codes Geld verlangen. Firmen wie Oracle, Automattic, die Firma, die WordPress herausbringt, und andere leben super von Open Source, inklusive zahlreicher Angestellter. Auch ich verdiene mein Geld ausschließlich mit freier Software, die natürlich auch quelloffen ist.

    Genauso falsch ist die Behauptung, geschlossene Sicherheitssoftware sei sicherer, weil Bugs darin nicht so leiht entdeckt würden. Das ist Security by Obscurity und brandgefährlich. Dass die Behauptung der Realität nicht standhält, sieht man an den zahlreichen 0-Days und Patchdays, die es bei Microsofts Software immer wieder gibt. Die Behauptung, „gerade weil der Quellcode geheim ist, können Fehler, die er ggf. natürlich auch hat kaum entdeckt und mißbraucht werden.“ ist schlicht falsch. Das Gegenteil ist der Fall. Grade bei Software, die Sicherheits- oder Kryptographiefunktionen zur Verfügung stellt, müssen alle Algorithmen und der Quellcode zwingend offenliegen, um Sicherheit zu gewährleisten. Das ist eine notwendige Bedingung für die Sicherheit von Sicherheitssoftware, die ein Herr Auguste Kerckhoff schon im Jahre 1883 formuliert hat und die sich Kerckhoffs Prinzip nennt. Kurz gesagt hat er damit ausgedrückt, dass gute Verschlüsselungsalgorithmen nicht durch die Geheimhaltung des Algorithmus sicher sind, sondern durch die Güte des Schlüssels. Ausführlicher habe ich das auf https://www.projekt.xxx/2013/08/11/warum-verschluesselung-quelloffen-sein-muss/ diskutiert.

  3. Eberhard sagt:

    Stimme Dir völlig zu, daß die Güte einer Verschlüsselung von der Güte des Schlüssels, und von der Qualität des Algorithmus abhängt. Der Algorithmus ist auch bei uns völlig offen, d.h. standardisiert (AES). Warum unsere Verschlüsselungssoftware dennoch nicht frei verfügbaren Quellcode hat, und wir das für absolut sicher und für vertrauenswürdig halten, kann ich Dir gerne bei Interesse privat erklären. Es kann bei uns systembedingt keine Backdoors geben, obwohl der Quellcode nicht offen ist. Dein Microsoft-Beispiel ist zwar richtig, aber in unserem speziellen Fall ist das kein Argument gegen geheimen Quellcode.

    Ich übersetze seit einigen Wochen das White Paper unserer Verschlüsselungssoftware ins Deutsche; sobald es fertig ist, findest Du es (wie auch heute schon die englische Originalversion) auf http://www.sha-3.de – der Quellcode ist deswegen nicht offen, weil wir mit dessen Lizenzierung unser täglich Brot verdienen.

  4. Alex Schestag sagt:

    Es kann bei uns systembedingt keine Backdoors geben, obwohl der Quellcode nicht offen ist.

    Diese Aussage setzt Vertrauen in einen Code voraus, den man nicht einsehen kann. Einhellige Meinung unter Sicherheitsforschern ist, dass es keinen Grund gibt, dieses Vertrauen zu haben, aber eine Menge, es nicht zu haben.

    der Quellcode ist deswegen nicht offen, weil wir mit dessen Lizenzierung unser täglich Brot verdienen.

    Das ist teilweise nachvollziehbar. Aber für mich als User ist wichtiger, dass der Quellcode komplett offenliegt. Und auch so kann man Geld verdienen.

    Ich lese da im übrigen: „Vom NIST zertifiziert (Nummer 1141)“.

    Nun ja: http://www.scientificamerican.com/article/nsa-nist-encryption-scandal/.

    Kurz: NIST ist nicht vertrauenswürdig. Warum sollte ich dann eurem Code vertrauen, zumal wenn ich ihn nicht einsehen kann?

  5. Eberhard sagt:

    Du kannst unserem Code vertrauen, weil er zwar nicht quelloffen ist, Du aber bei einem COBOL-Programm selbst entscheidest, welche Ein- und Ausgabedateien Du auswählst. Das heißt, der Anwender hat volle Kontrolle darüber, was aus dem Programm rauskommt und wohin die verschlüsselten Daten gehen. Es ist ganz einfach technisch unmöglich, Daten per „Backdoor“ an die NSA oder wen auch immer abzuzweigen.

    Der Verschlüsselungsalgorithmus selbst, also AES, ist übrigens NSA-zertifiziert. Den folgenden Abschnitt im deutschen „White Paper“ habe ich dennoch entfernt, weil viele in Deutschland derzeit kalte Füsse bekommen, wenn sie auch nur das Wort NSA lesen.

    Dann wählte im Juni 2003 die National Security Agency (NSA) die AES-Verschlüsselung aus, mit dem Hinweis „alle Schlüssellängen des AES-Algorithmus (also 128, 192 und 256) sind ausreichend, um vertrauliche Informationen bis zur Stufe GEHEIM zu sichern“ und „STRENG GEHEIME Informationen müssen eine Schlüssellänge von 192 oder 256 verwenden“.

  6. […] Alex Schestag: Heartbleed: Lösen Code-Reviews durch große Firmen das Problem? (via Alex […]

Kommentar abgeben