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

[Julia Reda <julia.reda@piratenpartei.de>]

+1 Wenn wir uns überhaupt dazu äußern, dann doch lieber mit nem Augenzwinkern 
als Socialmediamotiv, "Zwischen OpenSSL und WideOpenSSL liegt nur ein 
Heartbleed", oder so. :P

Julia

Von unterwegs gesendet

> Am 09.04.2014 um 16:14 schrieb Florian Stascheck 
> <florian.stascheck@junge-piraten.de>:
> 
> Moin,
> 
> Ich halte es eher für eine untergute Idee, sich als Partei zu dem Thema zu 
> äußern. Software-Bugs passieren und sind – solange sie Bugs sind – nichts, 
> wo wir uns als politische Partei zu äußern müssen. Bis auf die 
> Verschwörungstheorie von Fefe gibt es zurzeit keinerlei Hinweise darauf, 
> dass das kein ganz normaler Bug ist, wie täglich tausende gefixt werden 
> (hier halt mit ein bisschen größeren Auswirkungen). Dass Fefe darüber 
> schreibt ist sowieso eher ein Grund, daraus keine PM zu machen als daraus 
> eine PM zu machen :)
> 
> -Florian
> 
> -- 
> Florian Stascheck
> Junge Piraten
> Jabber: levu@jabber.ccc.de
> Öffentliche Telefonnummer: 015122835597
> 
> Am 2014-04-09 15:03, schrieb Anita Möllering:
>> 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:
>> http://www.tagesschau.de/multimedia/video/video1385706.html
>> ..............
>> *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] <http://blog.fefe.de/?ts=adba343f> Wer hat eigentlich diesen
>>   OpenSSL-Code geschrieben, der alle eure Keys kompromittiert hat? Ein Typ
>>   namens Robin
>> Seggelmann<http://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug.html>.
>>   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<http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1>.
>>   Das ist aber nicht der Punkt hier gerade.
>>   Wo arbeitet der? Was meint ihr? Kommt ihr NIE
>> drauf<http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-prpolicies-01>
>>   !
>>      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<http://duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/Derivate-31696/dissertation.pdf>
>> 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<http://www.drh-consultancy.demon.co.uk/>,
>>   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)