Original-URL des Artikels: https://www.golem.de/news/linuxtag-keynote-lehren-aus-heartbleed-und-ein-schluessel-von-cisco-1405-106379.html    Veröffentlicht: 10.05.2014 15:34    Kurz-URL: https://glm.io/106379

Linuxtag-Keynote

Lehren aus Heartbleed und ein Schlüssel von Cisco

Felix 'FX' Lindner und Gregor Kopf von Recurity Labs blicken zurück auf Heartbleed und andere Sicherheitslücken in Verschlüsselungssoftware - und veröffentlichen nebenbei einen fest eingestellten Schlüssel von zahlreichen Cisco-Produkten.

"Das ist nicht lustig (auch wenn's so aussieht). Das ist Crypto!!! Die brauchen wir noch" - mit dieser Nachricht auf den Folien begrüßten Felix 'FX' Lindner und sein Kollege Gregor Kopf von der IT-Sicherheitsfirma Recurity Labs die Besucher des Linuxtages.

Lindner und Kopf wagten einen Rückblick auf Heartbleed, die Goto-Fail-Lücke von Apple und zahlreiche andere Sicherheitsprobleme der vergangenen Monate. Außerdem zogen sie einige Schlussfolgerungen für die künftige Entwicklung von Verschlüsselungssoftware. Wie schwer es ist, Kryptographie korrekt zu implementieren, werde häufig unterschätzt, sagte Lindner. Deshalb sei für die meisten auch der wichtigste Hinweis, dass sie Kryptographiecode überhaupt nicht selbst schreiben sollen.

Der Heartbleed-Bug in OpenSSL ist für Lindner ein gutes Beispiel dafür, dass die kritischsten Sicherheitskomponenten oft am schlechtesten finanziert sind. Erst nach dem Heartbleed-Bug hatten sich einige Größen der IT-Branche dazu durchgerungen, die Entwicklung von OpenSSL in großem Maßstab mitzufinanzieren.

Allerdings, so Lindner, fingen die Probleme von Verschlüsselungssoftware bereits bei den Standards an. Die Zertifikatsinfrastruktur von TLS beispielsweise basiert auf einem Protokoll namens X.509, welches wiederum eine Codierung namens ASN.1 nutzt. ASN.1 selbst ist schon ein extrem komplexes Protokoll, das darauf aufbauende X.509 hat das Problem, dass es an manchen Stellen nicht eindeutig spezifiziert ist. Beide Protokolle stammen aus den 80er Jahren und wurden von der ITU (International Telecommunication Union) spezifiziert.

Auch in den Programmiersprachen C und C++ sehen Lindner und Kopf ein grundsätzliches Problem. C-Code ohne Buffer Overflows oder andere Fehler in der Speicherverwaltung zu schreiben, sei fast unmöglich. Deswegen solle sicherheitskritischer Code in Programmiersprachen geschrieben werden, die derartige Speicherprobleme von vornherein verhindern.

Zudem wiesen beide darauf hin, dass gravierende Fehler in Kryptographiesoftware kein Problem quelloffener Software seien. Seit mehreren Jahren versuche er, Cisco auf ein Problem in ihren Enterprise-Produkten hinzuweisen, sagte Lindner. Diese hätten zum Teil statische AES-Schlüssel und Initialisierungsvektoren, die in allen Devices dieselben sind. Cisco hat schon mehrfach fälschlicherweise behauptet, dass das Problem behoben sei. Zum Abschluss des Talks präsentierten Lindner und Kopf daher den privaten Schlüssel, der beispielsweise in den Cisco Nexus 1000v Switches fest einprogrammiert ist.  (hab)


Verwandte Artikel:
Enlightenment: Von zwölf Jahren zu drei Monaten Entwicklungzyklus   
(08.05.2014, https://glm.io/106343 )
Kollaborationssoftware: IBM ersetzt E-Mails durch Slack   
(26.02.2018, https://glm.io/132990 )
TANs der Citibank angeblich unsicher   
(04.10.2006, https://glm.io/48155 )
Git und Co: Bösartige Code-Repositories können Client angreifen   
(11.08.2017, https://glm.io/129441 )
Anton Zeilinger: Wissenschaftler kommunizieren quantenverschlüsselt   
(30.09.2017, https://glm.io/130370 )

© 1997–2021 Golem.de, https://www.golem.de/