Zum Inhalt springen.
Sympa Menü

sg-presse - [Sg-presse] [SG Presse und andere] OpenSSL- "Heartbleed-Bug" - Kritische Sicherheitslücke bei Verschlüsselungs-Software Bug - Programmierer T-Systems - Verdacht Backdoor

sg-presse@lists.piratenpartei.de

Betreff: Mailingliste der SG Bundes-PR

Listenarchiv

[Sg-presse] [SG Presse und andere] OpenSSL- "Heartbleed-Bug" - Kritische Sicherheitslücke bei Verschlüsselungs-Software Bug - Programmierer T-Systems - Verdacht Backdoor


Chronologisch Thread 
  • From: Anita Möllering <anita.moellering@googlemail.com>
  • To: SG Presse <sg-presse@lists.piratenpartei.de>, sg-socialmedia <sg-socialmedia@lists.piratenpartei.de>, SG Onlineredaktion <SG-Onlineredaktion@lists.piratenpartei.de>
  • Subject: [Sg-presse] [SG Presse und andere] OpenSSL- "Heartbleed-Bug" - Kritische Sicherheitslücke bei Verschlüsselungs-Software Bug - Programmierer T-Systems - Verdacht Backdoor
  • Date: Wed, 9 Apr 2014 15:03:21 +0200
  • List-archive: <https://service.piratenpartei.de/pipermail/sg-presse>
  • List-id: Mailingliste der SG Presse - Diskussion <sg-presse.lists.piratenpartei.de>

Hallo zusammen,

grad auf nen Post bei Fefe aufmerksam gemacht worden: http://blog.fefe.de/?ts=adba343f
Text unten

Nachricht zum Fehler selbst dazu gab schon gestern auf Heise: http://www.heise.de/newsticker/meldung/Der-GAU-fuer-Verschluesselung-im-Web-Horror-Bug-in-OpenSSL-2165517.html

Nachricht:


..............

Ein äußerst schwerwiegender Programmierfehler gefährdet offenbar Verschlüsselung, Schlüssel und Daten der mit OpenSSL gesicherten Verbindungen im Internet. Angesichts der Verbreitung der OpenSource-Bibliothek eine ziemliche Katastrophe.

Die Entwickler von OpenSSL veröffentlichen ein Update ihrer weit verbreiteten Verschlüsselungsbibliothek, das äußerst schlechte Nachrichten transportiert: Ein Programmierfehler erlaubt es jedem Kommunikationspartner, Speicher der Gegenstelle auszulesen. Konkret bedeutet das: Ein Angreifer kann Schlüssel, Passwörter und andere geheime Daten klauen.

..................

Was wir tun könnten:


Presse - Statement:
Sicherheitslücke in SSL gefährdet Endnutzer, da sensible Daten leicht ausgespäht und missbraucht werden können. nach ersten Recherchen wohl Telekom-Entwickler Urheber des Bugs. Erwarten Stellungnahme des Unternehmens. Dann Frage, ob das noch als Zufall gewertet werden kann oder hier von einem vorsätzlichen Programmieren einer Sicherheitslücke gesprochen werden muss.


Social Media & Web:
Zusätzlich: Wir könnten alle unsere Leser drauf aufmerksam machen "Hay, patcht mal OpenSSL und besorgt euch neue Zertifikate wegen Datenschutz etc."



Padlink für SG Presse hier:
https://sgpresse.piratenpad.de/2014-04-09-Statement-OpenSSL-Bug-T-Systems

......................

Wed Apr 9 2014

  • [l] Wer hat eigentlich diesen OpenSSL-Code geschrieben, der alle eure Keys kompromittiert hat? Ein Typ namens Robin Seggelmann. Kann mal passieren, ich will jetzt nicht mit dem Finger auf den zeigen. Aber es sollte vielleicht mal jemand den anderen Code auditieren, den der so geschrieben hat.

    Hier ist der git commit. Das ist aber nicht der Punkt hier gerade.

    Wo arbeitet der? Was meint ihr? Kommt ihr NIE drauf!

       Robin Seggelmann
       T-Systems International GmbH
       Fasanenweg 5
       70771 Leinfelden-Echterdingen
       DE
    

    Update: Eine Sache noch. Nehmen wir mal an, jemand würde mich bezahlen, eine Backdoor in OpenSSL einzubauen. Eine, die auf den ersten Blick harmlos aussieht, die aber ohne Exploit-Schwierigkeiten auf allen Plattformen tut und von den verschiedenen Mitigations nicht betroffen ist. Genau so würde die aussehen.

    Ich sehe in dem Code nicht mal den Versuch, die einkommenden Felder ordentlich zu validieren. Und auch protokolltechnisch ergibt das keinen Sinn, so eine Extension überhaupt zu definieren. TCP hat seit 30 Jahren keep-alive-Support. Es hätte also völlig gereicht, das für TLS über UDP zu definieren (und auch da würde ich die Sinnhaftigkeit bestreiten). Und wenn man ein Heartbeat baut, dann tut man da doch keinen Payload rein! Der Sinn von sowas ist doch, Timeouts in Proxy-Servern und NAT-Routern vom Zuschlagen abzuhalten. Da braucht man keinen Payload für. Und wenn man einen Payload nimmt, dann ist der doch nicht variabel lang und schon gar nicht schickt man die Daten aus dem Request zurück. Das ist auf jeder mir ersichtlichen Ebene völliger Bullshit, schon das RFC (das der Mann auch geschrieben hat), das ganze Protokoll, und die Implementation ja offensichtlich auch. Aus meiner Sicht riecht das wie eine Backdoor, es schmeckt wie eine Backdoor, es hat die Konsistenz einer Backdoor, und es sieht aus wie eine Backdoor. Und der Code kommt von jemandem, der bei einem Staatsunternehmen arbeitet, das für den BND den IP-Range betreut (jedenfalls vor ein paar Jahren, ob heute immer noch weiß ich nicht). Da muss man kein Adam Riese sein, um hier 1+1 zusammenzählen zu können.

    Update: Es stellt sich raus, dass der Mann damals noch an seiner Dissertation geschrieben hat und an der Uni war und erst später bei T-Systems anfing. In der Dissertation geht es unter anderem um die Heartbeat-Extension, die mit UDP begründet wird. In dem Text steht auch drin, dass man keine Payload braucht. Aber lasst uns das mal trotzdem so machen, weil ... Flexibilität und so!

    Update: Echte Verschwörungstheoretiker lassen sich natürlich von sowas nicht aufhalten. Der Job bei T-Systems war dann halt die Belohnung!1!! Und echte Verschwörungstheoretiker googeln auch dem Typen hinterher, der den Code auditiert und durchgewunken hat, damit der eingecheckt werden konnte. Ein Brite, der nur 100 Meilen von Cheltenham (GCHQ-Sitz) entfernt wohnt!!1! (Danke, Jürgen)


--
Anita Möllering AKA anuschka

Follow me
http://twitter.com/anuschka78
http://gplus.to/anuschka78 
http://www.facebook.com/anita.moellering





Archiv bereitgestellt durch MHonArc 2.6.19.

Seitenanfang