Skip to content

Stellungnahme zur Videoüberwachung als Hörspiel

Posted by Jens Kubieziel on

Stellungnahmen zu Gesetzentwürfen sind üblicherweise große Papierberge. Die Mitglieder der Ausschüsse müssen diese lesen und interpretieren. Die Initiative Freiheitsfoo ist einen anderen Weg gegangen. Sie bekamen eine Anfrage des Wirtschaftsausschusses des Landes Schleswig-Holstein, in der es um die lückenlose Überwachung in Zügen ging. Freiheitsfoo entwickelte ein Hörspiel und stellte es den Abgeordneten zur Verfügung. Es steht mittlerweile allen zur Verfügung. Hört rein: 201402freiheitsfoo-an-LT-SH-zu-VUE-OEPNV.mp

via Patrick Breyer: Videoüberwachung im ÖPNV: Landtag erhält Hörspiel als Stellungnahme

Ist Open Source besser als Closed Source?

Posted by Jens Kubieziel on

Die operative Hektik angesichts der Heartbleed-Lücke bei OpenSSL legt sich langsam. Ein Großteil der Server scheint gepatcht zu sein und diverse Zeitungen wie andere Medien bringen zur Prime-Time Warnungen an die Nutzer. Jetzt beginnt die Zeit der Spekulation, woher der Bug kommt, ob der absichtlich eingebaut wurde und es wird auch die Frage diskutiert, ob Open Source sicherer bzw. besser als Closed Source ist.

Auf der einen Seite steht u.a. Linus’ Law als Argument. Der Erschaffer von GNU/Linux wird mit dem Spruch »Given enough eyeballs, all bugs are shallow« zitiert. Das heißt, wenn nur genügend Leute einen Blick in den Quellcode werfen, so wird jeder Bug gefunden und am Ende ist die Software »rein«. Am Beispiel des Linuxkernel ist zu sehen, wie gut das Modell funktioniert. Allerdings gibt es eine Reihe von anderer Open-Source-Software, wo offensichtlich niemand einen Blick in den Quellcode wirft. Dort bleiben dann zahlreiche Fehler unentdeckt. Das ist dann auch gleich das Argument der Befürworter von Closed Source. Denn dort bekommt niemand den Code zu sehen und kann daher auch keine Fehler finden. So lautet die etwas vereinfachte Argumentation.

Forscher vom Lehrstuhl für Betriebssysteme der TU Dresden haben sich dieser Frage im Jahr 2010 genähert. Für ihre Veröffentlichung The Mathematics of Obscurity: On the Trustworthiness of Open Source schufen sie ein Modell, in dem verschiedene Personen versuchen, Schwachstellen in Code zu finden. Wenn die Verteidiger zuerst sind, können sie die Lücke schließen. Die Angreifer haben auf der anderen Seite eine Lücke, über die sie ins System eindringen können.

Das Modell widerspricht dem obigen Gesetz von Linus Torvalds. Das Modell erbringt die Aussage, dass die Angreifer bei Open Source immer leicht im Vorteil sind. So nehmen die Forscher an, dass bei einem Open-Source-Projekt die Verteidiger in 6 von 10 Fällen einen Fehler vor dem Angreifer finden. Je nach den weiteren Modellannahmen braucht das Projekt mehr als Tausend oder gar mehr als Zehntausend Mitwirkende. Für den Fall, dass sogar in 9 von 10 Fällen der Fehler von den Verteidigern gefunden wird, können die Forscher zeigen, dass dies unmöglich ist. Alles in allem erscheint Closed-Source-Software besser aufgestellt zu sein.

Jedoch sagen die Forscher weiter, dass sie hier einen eingegrenzten Aspekt betrachten. In der Realität beheben die Hersteller von Closed Source die Fehler nicht sofort. Außerdem gibt es dort wirtschaftlichen Druck, Programme zu einem festen Datum herauszubringen. Dies führt dann dazu, dass die Programme nicht getestet sind. Alldies bringt die Forscher zu der Meinung, dass Open Source in der Gesamtschau vermutlich doch Vorteile mit sich bringt. Letztlich bringt gerade Freie Software die Vier Freiheiten mit.

Alles in allem kann ich nur nochmal den Aufruf aus meinem letzten Eintrag wiederholen. Nutzt Freie Software, schaut in den Quellcode oder versucht anderweitig zu der Software beizutragen. Damit helft ihr allen!

Wie funktioniert eigentlich Heartbleed

Posted by Jens Kubieziel on

Lest ihr regelmäßig Bugreports oder Meldungen über Schwachstellen bei SSL/TLS? Wie fühlt ihr euch so? Zur Erinnerung:

SSL added and removed here!
Ausschnitt aus einer Folie aus dem MUSCULAR-Programm der NSA

Das heißt, drei Monate in Folge gab es schwere Sicherheitslücken in Software zur Verschlüsselung. Ganz unwillkürlich fühlt man sich an die Folien aus dem NSA-Programm MUSCULAR erinnert.

Die letztgenannte Schwachstelle ist vermutlich die bislang schwerste. Denn damit ist es möglich, den Arbeitsspeicher eines Computers auszulesen. Dies funktioniert sowohl auf der Seite des Servers wie auch beim Clientprogramm. Dazu ist es notwendig, dass das Programm OpenSSL verwendet und eine Erweiterung von SSL namens Heartbeat aktiviert hat. Dies ist beispielsweise bei Android in der Version 4.1.1 der Fall. Mozilla Firefox hingegen nutzt die NSS-Bibliothek und ist nicht betroffen. Die Webserver nutzen hingegen recht oft die OpenSSL-Bibliothek und sind damit betroffen, falls die Version 1.0.1 bis 1.0.1f von OpenSSL verwendet wird. Sollte jemand von euch die Software nutzen, so upgraded auf mindestens 1.0.1g oder deaktiviert Heartbeat in OpenSSL. Gerade letzteres kann man aus meiner Sicht problemlos tun. Denn bisher fand ich keinen sinnvollen Anwendungsfall für Heartbeat.

Doch wie funktioniert diese Lücke eigentlich? Heartbeat (RFC 6520) ist eine Erweiterung für TLS. Ein Teilnehmer einer Verbindung sendet beliebige Daten an den Empfänger. Dieser antwortet mit einer Kopie dieser Daten und zeigt somit, dass die Verbindung noch steht und alles in Ordnung ist. Das Problem dabei ist, dass in einer Anfrage zwei Längenfelder vorhanden sind. Ein Angreifer sendet einfach ein Byte Daten und behauptet, er hätte 64 kB gesendet. OpenSSL liest nun die 64 kB aus dem eigenen Puffer und sendet die Daten zurück an den Angreifer. Der Angreifer kann den Angriff immer und immer wieder starten und erhält so eventuell immer wieder ein neues Stück Arbeitsspeicher (siehe Kommentar von Florian Diesch). Bruce Schneier hat mit seinen Worten vollkommen recht:

Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.
https://www.schneier.com/blog/archives/2014/04/heartbleed.html

Ich hatte in meinem 30C3-Vortrag schon ein OpenSSL-Beispiel reingenommen. Das sollte zeigen, wie kompliziert es sein kann, mit der Software sicheren Code zu schreiben. Auch andere sind, über die Codequalität gestolpert. Daher sind Leute gefragt, die einen detaillierten Blick auf OpenSSL werfen und die Software verbessern. Dazu zählt auch die bessere Lesbarkeit des Codes oder gute Dokumentation.

Wenn ihr wissen wollt, ob ihr betroffen seit, schaut lokal auf die OpenSSL-Version, nutzt die Zeile openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep ‘server extension “heartbeat” (id=15)’ || echo safe oder verwendet den Testservice von Lutz Donnerhacke oder Filippo Valsorda.

Weiterlesen:

Passwort und Nutzername im Dump der Daten von Yahoo! Mail

cronjob