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

[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)