Hätte ein Unittest den Heartbleedbug verhindern können?
-
Die Frage stelle ich mir gerade.
Im Prinzip ist es ja so, dass dieser Unittest dann bewusst Falscheingaben an das Programm übermitteln hätte müssen, damit der Bug aufgefallen wäre.
Im konkreten Fall hätte also ein Unittest eine größere Längenangabe an das Programm übergeben müssen, als die Payload groß war.Aber, wer kommt auf solche Ideen?
Die Frage ist nämlich, kann man alle Arten von möglichen Falscheingaben durch Unittests überhaupt abdecken?Und ob das aufgefallen wäre, ist auch wieder fraglich, denn wenn OpenSSL dann eine größere Payload zurückgeliefert hätte, dann hätte man das ja auch wieder überprüfen müssen.
-
-
Sobald man sich für das Heartbleed-Codestück fragt "was für Fehleingaben könnten vorkommen?" findet man den Bug. Ob man sich die Frage routinemässig stellt oder weil man einen Unittest schreiben möchte, ist egal. Hauptsache, man schaut nochmal genau drüber.
-
Bei so schlechtem Code hätte ein Test auch nicht mehr geholfen.
Modultest schrieb:
Die Frage ist nämlich, kann man alle Arten von möglichen Falscheingaben durch Unittests überhaupt abdecken?
Hängt von der getesteten Funktionalität ab. Endliche Automaten kann man zum Beispiel vollständig abdecken. Turingmaschinen kann man nicht vollständig abdecken. Da TLS wohl kaum turingvollständig ist, müsste das relativ gut testbar sein.
denkeschon schrieb:
Sobald man sich für das Heartbleed-Codestück fragt "was für Fehleingaben könnten vorkommen?" findet man den Bug.
Das Problem ist, dass es in OpenSSL fast überall so schlimm aussieht. Das zu lesen will sich anscheinend niemand antun.
-
Modultest schrieb:
Und ob das aufgefallen wäre, ist auch wieder fraglich, denn wenn OpenSSL dann eine größere Payload zurückgeliefert hätte, dann hätte man das ja auch wieder überprüfen müssen.
Wenn das Protokoll vorschreibt dass die Längenangabe nicht grösser sein darf als die mitgeschickte Payload, dann kann man jede Antwort auf ein solches Paket als Fehler werten. Dann wäre das natürlich aufgefallen.
Bzw. wenn das Protokoll es nicht explizit verbietet, aber nicht definiert was dann zu passieren hat, dann kann man daraus mMn. ein implizites Verbot herleiten, und das ist dann auch gut genug.Wobei man sich dann gleich die Frage hätte stellen können: wozu überhaupt eine Payload-Längenangabe im Paket? (Weil man sich die ja sowieso aus der Paketlänge ausrechnen kann. Bzw. wozu überhaupt eine Payload?)
Dann hätte man anstatt so einen Unit-Test zu schreiben die Längenangabe weglassen können (bzw. gleich die ganze Payload), und es hätte auch kein Problem gegeben.
-
hustbaer schrieb:
Bzw. wenn das Protokoll es nicht explizit verbietet, aber nicht definiert was dann zu passieren hat, dann kann man daraus mMn. ein implizites Verbot herleiten, und das ist dann auch gut genug.
Für so eine implizierte Herleitung wurde ich mal an meiner Hochschule vom Dozenten kritisiert.
Seine Begründung:
Kein Teil der Spezifikation.Dabei habe ich damit nur einen potentiellen Fehler abgefangen.
Auch da ging es um eine Funktion, die Parameter entgegen nimmt und wenn der übermittelte Parameter eben außerhalb der Spezifikation war, dann hätte das Programm, so wie es der Dozent haben wollte, mit falschen Werten weitergerechnet. Bei meiner Lösung wäre dies nicht passiert.Ich bin heute noch der Meinung, dass mein Dozent hier damals nicht Recht hatte.
Aber wenn man an Hochschulen schon gelehrt bekommt, nur streng nach der Spezifikation zu arbeiten, wobei hier der Ersteller der Spezifikation ja einen Fehler übersehen hätte können, dann wundert mich das nicht, wenn solche Bugs wie der Heartbleed Bug entstehen.
PS:
Meine Lösung hätte die Spezifikation übrigens nicht verletzt, da das, was ich abgefangen hätte, in der Spezifikation gar nicht definiert war.
-
NSA loves Heartbleed schrieb:
Ich bin heute noch der Meinung, dass mein Dozent hier damals nicht Recht hatte.
Aber wenn man an Hochschulen schon gelehrt bekommt, nur streng nach der Spezifikation...Meiner schwor auf sowas wie "Pfadüberdeckungstest".
http://de.wikipedia.org/wiki/Kontrollflussorientierte_Testverfahren#Bewertung_2
Der hätte hier auch nicht gegriffen.
