Ein Kommentar von Alexander Benesch
Sicherheitsexperte Bruce Schneier erklärte, die als „Heartbleed“ bekannte Schwachstelle im Code der Sicherheitssoftware OpenSSL sei eine elf auf einer Gefährlichkeitsskala von eins bis zehn. Millionen Server weltweit waren oder sind noch betroffen. Angreifer mit Wissen von der Schwachstelle konnten meist spurenlos wieder und immer wieder Bruchstücke wichtiger Informationen abgreifen. Versucht man es oft genug, ist die Wahrscheinlichkeit hoch, sensible Passwörter und Schlüssel zu ergattern.
Hinweise in den Logs betroffener Server lassen darauf schließen, dass bereits seit Monaten, wenn nicht sogar seit noch viel längerer Zeit, irgendwelche Individuen oder Gruppen die Schwachstelle kannten und ausnutzten. Geheimdienste und Cyber-Mafia-Gruppen spezialisieren sich auf das Auffinden von solchen Code-Lücken, oft werden diese sogar meistbietend verkauft.
Auch die Möglichkeit einer bewussten Hintertür existiert. Im Jahr 2010 gab es eine Kontroverse um eine mögliche FBI-Hintertür in OpenBSD.
Verständlicherweise versucht man nun händeringend zu klären, wie es dazu kommen konnte. Verantwortlich für die Lücke in OpenSSL scheint ein Programmierer namens Robin S. Zur fraglichen Zeit arbeitete er an seiner Dissertation an einer deutschen Universität. Später ging er zu T-Systems International der Deutschen Telekom. Der Sicherheitsexperte Felix von Leitner kommentiert dazu:
„Und echte Verschwörungstheoretiker googeln auch dem Typen hinterher, der den Code auditiert und durchgewunken hat, damit der eingecheckt werden konnte. Ein Brite, der nur 100 Meilen von Cheltenham (GCHQ-Sitz) entfernt wohnt!“
Der Fehler, der nun als Heartbleed bekannt ist, scheint ungewöhnlich:
„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.“
Andererseits könnte der Bug auch einfach nur übersehen worden sein:
„Wenn jemand da den reinkommenden Code auditiert, guckt der nach den hochriskanten Bugs. Und nach der langläufigen Einschätzung, die so bei Entwicklern vertreten wird, ist out of bounds read halt viel weniger riskant als andere Bug-Klassen. Ich kann mir gut vorstellen, dass der Auditor einfach nicht nach der Art von Bug geguckt hat. Der hat memcpy gesehen, und hat dann kurz geprüft, dass vorher genug alloziert wurde und das keinen Buffer Overflow gibt, und dann hat der das durchgewunken.“
