Zum Inhalt springen.
Sympa Menü

sg-presse - 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

sg-presse@lists.piratenpartei.de

Betreff: Mailingliste der SG Bundes-PR

Listenarchiv

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


Chronologisch Thread 
  • From: Anita Möllering <anita.moellering@googlemail.com>
  • To: Florian Stascheck <florian.stascheck@junge-piraten.de>
  • Cc: sg-socialmedia <sg-socialmedia@lists.piratenpartei.de>, SG Onlineredaktion <SG-Onlineredaktion@lists.piratenpartei.de>, SG Presse <sg-presse@lists.piratenpartei.de>, Julia Reda <julia.reda@piratenpartei.de>
  • Subject: 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
  • Date: Wed, 9 Apr 2014 16:18:25 +0200
  • List-archive: <https://service.piratenpartei.de/pipermail/sg-presse>
  • List-id: Mailingliste der SG Presse - Diskussion <sg-presse.lists.piratenpartei.de>

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





Archiv bereitgestellt durch MHonArc 2.6.19.

Seitenanfang