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

[Anita Möllering <anita.moellering@googlemail.com>]

Hi Levu,

Am 9. April 2014 16:25 schrieb Florian Stascheck <florian.stascheck@junge-piraten.de>:

Hm, also dieser IT-Security-Aufklärungs-Aspekt hat imho auch zu wenig mit unserer Parteipolitik zu tun als dass ich das primär bei Social-Media sehe.

Vielleicht hat stattdessen ja z.B. die Flaschenpost Interesse, dazu was zu machen, ich habe die mal mit in CC genommen.

Das sehe ich anders. Wir haben als Partei auch immer die Aufgabe, Bürger aufzuklären in unseren Kernthemengebieten. Es ist sogar politisch sinnvoll: Denn wie sollen Menschen sonst verstehen, dass das, worum wir uns politisch kümmern, wirklich wichtig ist? Die ganze NSA-Thematik zieht doch u.a. genau deshalb noch nicht umfassend: weil der Otto-Normal-Verbraucher gar nicht so genau weiß, was genau im Netz seine Daten sichert und was nicht.

Siehe Kryptoparties. Gutes Beispiel, dass das allgemein und für uns als Partei Sinn macht.

LG, Anita

 

-Florian

--
Florian Stascheck
Junge Piraten
Jabber: levu@jabber.ccc.de
Öffentliche Telefonnummer: 015122835597

Am 2014-04-09 16:18, schrieb Anita Möllering:

Ja, das ist gerade auch die Analyse im Pad. Der Bezug zu T-Systems ist
derzeit zu vage als dass wir den ziehen können. Und damit steht und fällt
eine Pm zu dem Thema. Also aktuell eher: Daumen runter.

Was wir für unsere Leser und Nutzer aber machen können & sollten:
Hilfestellungen geben, was man aktuell tun kann, um sich zu schpützen, Das
ist aber nix für PM, sondern eher für Website, Social Media etc.

LG, Anita




Am 9. April 2014 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)

--
Anita Möllering AKA anuschka

Follow me

http://twitter.com/anuschka78

http://gplus.to/anuschka78 

http://www.facebook.com/anita.moellering