Überraschende Software-Schwachstellen oder Exploits?

Question

Welches sind die seltsamsten/raffiniertesten/überraschendsten/tiefsten versteckten Software-Schwachstellen oder Exploits, die Sie je gesehen haben? Stellen im Code, von denen Sie dachten, dass sich dort keine Gefahr verbirgt, aber falsch lagen?

[Zur Klarstellung: Jeder kennt SQL-Injektionen, XSS oder Pufferüberläufe - Fehler, die oft durch unvorsichtige Kodierung entstehen. Aber Dinge wie Ken Thompsons versteckter Trojaner (Reflections on Trusting Trust: http://cm.bell-labs.com/who/ken/trust.html ), die jüngste NULL-Dereferenz-Schwachstelle im Linux-Kernel ( http://isc.sans.org/diary.html?storyid=6820 ), oder ein komplexer Angriff auf RNG mit Denial of Service ( http://news.ycombinator.com/item?id=639976 ) haben mich sehr beunruhigt].

Update: Vielen Dank für alle Antworten, sie waren großartig. Ich hatte die Qual der Wahl. Letztendlich habe ich mich entschieden, das Kopfgeld für den Seitenkanal-/Stromüberwachungsangriff zu zahlen. Nichtsdestotrotz zeigen all eure Antworten zusammen, dass ich mehr über Sicherheit lernen muss, da es ein wirklich tiefes Thema ist :).

Answer 1

Das fragt man sich doch die ganze Zeit, nicht wahr? Die diesjährigen "Can't be real ... but wow" waren Parameterverschmutzung und Schnüffeln in Ihrem Verlauf ohne JavaScript .

Ich entscheide mich für Letzteres, weil es sowohl verblüffend einfach ist (ich denke, jeder wird diesen Moment haben, in dem ihm klar wird, dass er selbst auf diese Idee hätte kommen können... nein, kommen müssen.), als auch die Bandbreitenoptimierung des Browsers nutzt, die sicherstellt, dass ein Hintergrundbild nur dann geladen wird, wenn es benötigt wird.

Ich mag es.

Und das lässt sich nicht so einfach abmildern, ohne ein paar Dinge kaputt zu machen. Eigentlich bin ich hier falsch, man könnte "unsichtbare" iframes im Browser verhindern. Ich weiß nicht, ob das wirklich jemand will.

Answer 2

Auf der "anspruchsvollen" Skala Dowds Angriff auf die ActionScript-VM ist unübertroffen. Siehe dieses Schreiben für eine unterhaltsame Zusammenfassung des Papiers.

Answer 3

Das Beste, was ich bisher gesehen habe, war der Kommentar in der Zeile mrand.c in den Debian-SSL-Paketen, weil purify sich über die Verwendung von nicht initialisierten Daten beschwerte. Dies war kein Code-Fehler an sich, sondern eher ein Refactoring-Fehler, der von einem Maintener durch das Auskommentieren einer Code-Zeile eingeführt wurde. Die auskommentierte Zeile war ein Aufruf einer Funktion, die dazu diente, Entropie für die Schlüsselerzeugung bereitzustellen, aber weil sie dafür nicht initialisierte Daten verwendete, beschwerte sich valgrind.

Der Betreuer fragte in einer E-Mail an die SSL-Mailingliste, ob es in Ordnung sei, diese Zeile auszukommentieren, da sie nur einige zufällige Daten hinzufüge.

Dies dauerte mehrere Jahre und wurde erst entdeckt, als Luciano Bello versehentlich Hunderte von Schlüsseln für ein Hochschulprojekt erstellte und dabei mehrere Schlüsselkollisionen bemerkte.

Diese Bugs sind die eigentliche Bedrohung, sie halten seit Jahren an, und wie testet man, dass ein PRNG wirklich zufällig ist?
_{(Quelle: <a href="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/2000/300/2318/2318.strip.gif" rel="nofollow noreferrer">dilbert.de </a>)}

Der genaue Wortlaut war:

md_rand.c

MD_Update(&m,buf,j); /* purify complains */

Sie können alles über diesen erstaunlichen Käfer hier nachlesen: Linktext

Answer 4

Meine Favoriten sind eine Klasse von recht speziellen Angriffen, die als Format String Attack . Sie nutzen die printf-ähnlichen Formatierungs-Tags aus, um Daten im Stack zu überschreiben. Einige von ihnen verwenden obskure Token wie %n, die zwar recht selten zu finden sind, aber in den Code eingeschleust werden können, wenn der Programmierer unvorsichtig genug ist, um zuzulassen, dass eine ungefilterte Eingabe die Formatierungszeichenfolge erreicht.

Obwohl sie Pufferüberläufen scheinbar nicht unähnlich sind, bringen sie zusätzliche Komplexität mit sich: Bei einem Pufferüberlauf überschreiben Sie einfach die Rücksprungadresse auf dem Stack. Bei der Format-String-Attacke müssen Sie Ihren Angriff sorgfältig anpassen, um den Ausführungsfluss umzuleiten, ohne einen Absturz zu verursachen, so dass die Entwicklung wesentlich komplexer ist.

Ein weiterer interessanter Angriff ist die ausnahmsweise Fehler. Auch dies ist nicht leicht auszunutzen, aber durchaus machbar.

Answer 5

Hyper-Threading-Schwachstelle :

Diese Schwachstelle ermöglicht lokale Informationen Offenlegung lokaler Informationen, die es einem unprivilegierten Benutzer, einen RSA privaten Schlüssel zu stehlen, der auf demselben Maschine verwendet wird.