Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03403.jsonl.gz/1595

Kryptographische Algorithmen benötigen oft Berechnungen mit großen Ganzzahlen. Immer wieder werden Fehler in den entsprechenden Bibliotheken gefunden. Diese können zu Sicherheitslücken werden.
Im Januar veröffentlichte OpenSSL ein Sicherheitsupdate, in dem ein Fehler in einer mathematischen Funktion behoben wurde. In sehr seltenen Fällen verrechnete sich OpenSSL beim Versuch, eine große Zahl zu quadrieren. Dieser Fehler in der Funktion BN_sqr() war Anlass für Ralph-Philipp Weinmann, mögliche Sicherheitslücken durch fehlerhafte Berechnungen in sogenannten Bignum-Funktionen zu untersuchen. Auf der Black-Hat-Konferenz in Las Vegasstellte er seine Ergebnisse vor.
Berechnungen mit großen Zahlen wichtig für Public-Key-Kryptographie
Insbesondere Public-Key-Algorithmen benötigen oft Berechnungen mit großen Ganzzahlen. So müssen etwa bei einer RSA-Verschlüsselung Zahlen mit mehreren Tausend Bit multipliziert und potenziert werden. Verschlüsselungsbibliotheken wie OpenSSL besitzen daher entsprechende Funktionen, um mit großen Zahlen zu rechnen.
Bereits 2008 veröffentlichten die Kryptographen Eli Biham, Yaniv Carmeli und Adi Shamir ein Paper, in dem sie der Frage nachgingen, wie Rechenfehler durch fehlerhafte Hardware zu Sicherheitslücken führen könnten. Das Paper betrachtete überwiegend theoretische Fehler, das einzige praxisrelevante Beispiel war der FDIV-Bug in Intel-Pentium-Prozessoren, der allerdings aus heutiger Sicht nur noch historische Bedeutung hat.
Bitcoin-Entwickler finden OpenSSL-Rechenfehler
Der oben bereits erwähnte Bug in OpenSSL wurde bei Tests der Bibliothek libsecp256k1 entdeckt, die von einigen Bitcoin-Implementierungen genutzt wird. Es handelt sich um einen Fehler beim Übertrag des Carry-Bits, der in einigen Spezialfällen auftritt. Zufällig finden kann man den Bug praktisch nicht, da der Rechenfehler nur in einem von 2^128 Fällen auftritt. Die OpenSSL-Entwickler untersuchten zahlreiche Möglichkeiten, wie der Fehler ausgenutzt werden könnte und schätzten das Risiko letztendlich als gering ein.
Bei der Berechnung von RSA wird die entsprechende Quadrier-Funktion nur unter wenigen Architekturen genutzt. Selbst dort, wo sie zum Einsatz kommt, sorgt das sogenannte RSA-Blinding dafür, dass die Eingabedaten durch einen Zufallswert beeinflusst werden und somit nicht durch einen Angreifer kontrolliert werden können. Beim Schlüsselaustausch mit elliptischen Kurven (ECDH) kann der Fehler zwar auftreten, allerdings nur bei der Verifikation von Kurvenpunkten, und es gibt keine praktikable Möglichkeit, derartige fehlerhafte Kurvenpunkte zu konstruieren. Die OpenSSL-Entwickler haben noch diverse weitere potenzielle Fehlerquellen untersucht, haben aber letztendlich alle als harmlos eingeschätzt.
Weinmann kann zwar den meisten Argumenten der OpenSSL-Entwickler folgen, er weist aber darauf hin, dass einige Szenarien dabei nicht beachtet wurden. Alle Argumente gelten nur dann, wenn die OpenSSL-eigenen Kryptofunktionen genutzt werden. Aber die Bignum-Berechnungsfunktionen können auch von anderen Bibliotheken genutzt werden. So nutzt beispielsweise die Java-Implementierung unter Android zur Verschlüsselung eine Bibliothek namens Spongy Castle, diese wiederum greift auf die Bignum-Funktionen von OpenSSL zurück.
Der Code für elliptische Kurven in OpenSSL wurde vor nicht allzu langer Zeit stark überarbeitet und durch eine optimierte Version ersetzt. Die Betrachtungen der OpenSSL-Entwickler gelten allerdings nur für den neuen Code, ältere Versionen – Weinmann nennt 1.0.1e – sind möglicherweise von ganz anderen Problemen betroffen.
Carry-Übertrag sehr fehleranfällig
Wie sich herausstellte, sind Fehler beim Carry-Übertrag extrem häufig, die überwiegende Zahl der Rechenfehler in Bignum-Bibliotheken tritt beim Carry-Übertrag auf. So behob die 2012 veröffentlichte Version 5.0.4 einen Rechenfehler bei bestimmten Multiplikationen mit dem Carry-Übertrag. Auch in der NaCl-Verschlüsselungsbibliothek wurde ein Fehler in der Implementierung von Ed25519-Signaturen gefunden, der ebenfalls mit dem Carry-Übertrag zusammenhing. Ein Sicherheitsproblem trat dort nicht auf, da der fehlerhafte Code lediglich bei der Schlüsselerzeugung und bei Signaturen genutzt wird und somit keine vom Angreifer kontrollierten Daten betroffen sind. Die Wahrscheinlichkeit für ein zufälliges Auftreten ist vernachlässigbar gering.
Das einzige Beispiel, in dem gezeigt werden konnte, dass ein Software-Rechenfehler auch ganz praktisch ausgenutzt werden kann, ist ein Paper aus dem Jahr 2011. Genutzt wurde dabei ein Fehler in der sehr alten OpenSSL-Version 0.9.8g. Mittels einiger gezielter Anfragen konnte damit der Schlüssel eines Schlüsselaustauschverfahrens mittels ECDH extrahiert werden.
Fehlerhafter Code an riskanter Stelle in GnuPG
Ein subtiler Fehler in der Bibliothek Libgcrypt, die unter anderem von GnuPG verwendet wird, führte dazu, dass in bestimmten Situationen Bitmanipulationen durch die Funktion mpi_set_bit() fehlerhaft arbeiteten. Der Fehler trat nur zufällig auf, und das lag am Speicherlayout. In der Funktion wurde uninitialisierter Speicher verwendet. Falls der Speicher schon vorher genutzt worden war, konnte das die Funktionsweise beeinflussen.
Weinmann suchte nach Codestellen, die die entsprechende Funktionmpi_set_bit() aufrufen. Ausgerechnet bei der Erstellung des k-Wertes von DSA-Signaturen in GnuPG fand sich ein entsprechender Funktionsaufruf. Der k-Wert von DSA ist besonders kritisch, da ein Fehler hier katastrophale Auswirkungen haben kann. Falls derselbe k-Wert zweimal verwendet wird oder falls der Wert einem Angreifer bekannt ist, kann dieser dadurch den privaten Schlüssel zu einer Signatur berechnen. Weinmann kam letztendlich zu dem Schluss, dass das Problem vermutlich nicht zu einer Sicherheitslücke führt, er rief aber explizit dazu auf, dass weitere Personen den Fehler untersuchen sollten.
Neben der Analyse von bekannten Fehlern ging Weinmann auch der Frage nach, wie man derartige Fehler finden könnte. Mittels sogenannter Symbolic Execution ist es theoretisch möglich, zumindest die Äquivalenz von verschiedenen Funktionen zu beweisen. Damit könnte man etwa die Implementierungen bestimmter Rechenvorgänge von verschiedenen Verschlüsselungsbibliotheken vergleichen. Ein Forscherteam der Universität Stanford hat hierfür eine Variante des Tools KLEE entwickelt. Zwar ist das entsprechende Tool nicht öffentlich verfügbar, mit geringfügigen Modifikationen sei dieser Ansatz jedoch laut Weinmann auch mit der Originalversion vonKLEE umsetzbar.
Symbolic Execution gerät an Grenzen
Allerdings gibt es dabei einige Hürden. KLEE arbeitet mit Hilfe des Compilerframeworks LLVM und nutzt dafür den Zwischencode, den LLVM erzeugt. Große Teile der Rechenfunktionen von Verschlüsselungsbibliotheken sind jedoch in Assembler geschrieben. Um diese zu verifizieren, muss der Code erst entsprechend zurückkonvertiert werden. Dafür gibt es einige experimentelle Tools. An komplexeren Funktionen scheitert die Methode der Symbolic Execution letztendlich, da es zu viele Zustände gibt, in die eine Funktion geraten kann. Für die meisten aufwendigeren Funktionen ist diese Methode daher – zumindest mit aktuellen Tools – nicht nutzbar.
Bestimmte Rechenfehler lassen sich auch innerhalb einer Bibliothek selbst testen. Den OpenSSL-Fehler in der Quadrierungsfunktion etwa könnte man finden, wenn man den entsprechenden Eingabewert einmal mit der Quadrierungsfunktion berechnet und anschließend die Zahl mit sich selbst multipliziert. Bei beiden Berechnungen müsste dasselbe Ergebnis herauskommen.
American Fuzzy Lop kann seltene Rechenfehler finden
Weinmann hatte ein kleines Programm geschrieben, das genau dies tut, und anschließend das Fuzzing-Tool American Fuzzy Lop darauf angewendet. Weinman sagte, er habe dabei gedacht, “das wird zwar bestimmt nicht funktionieren, aber ich sollte es zumindest ausprobieren”. Erstaunlicherweise hatte diese Methode jedoch Erfolg. Innerhalb von einer Stunde fand American Fuzzy Lop in einer verwundbaren OpenSSL-Version einen der seltenen Ausnahmefälle, in denen die Quadrierung fehlerhafte Ergebnisse liefert.
Quelle: golem.de