8 Comments

  1. Eine EAL4 Zertifizierung ist mitnichten eine Bescheinigung der Fehlerfreiheit durch einen Auditor. Der Quellcode wird dabei garnicht betrachtet. (Semi)formale Verifikation erfolgt auch erst auf höheren Stufen. Von daher ist eine solche Zertifizierung zwar lobenswert, würde aber vor Programmierfehlern wie dem buffer-overread nicht schützen.

    Ich wage zu prophezeien dass sich HOB keine Freunde gemacht hat, und der Fehdehandschuh wird dankend aufgenommen werden.

  2. Tobias Knoth

    Ich musste ganz schön stutzen als ich die Anzeige in der ZEIT gesehen habe. Vielen Dank, dass Sie die Thematik aufarbeiten. Die angesprochene Anzeige ist dreist.

  3. David von Oheimb

    @Bernd Eckenfels: bei einer Common Criteria EAL 4(+) Zertifizierung wird sehr wohl auch der Quelltext mit betrachtet. Allerdings nicht systematisch, und eine formale Code-Verifikation findet erst bei EAL 7 statt. Es wird allerdings schon recht genau die Dokumentation der Interfaces analysiert und als Grundlage für Tests verwendet. Ein ordentlich arbeitender Evaluator hätte Heartbleed also durchaus finden können.

    Nebenbei etwas allgemeiner zu dem Thema – was viele Leute nicht wissen/beachten:
    * Die fehlerhaft implementierte Heartbeat-Funktionalität ist bei normalem TLS (über TCP) ziemlich unnötig. Erster grober Fehler der community (wie auch von vielen anderen Entwicklern): die trusted base ist viel zu groß und damit entsprechend unübersichtlich und fehlerträchtig.
    * Ein mindestens genauso schwerer Fehler steckt schon im Design des Heartbeat (RFC 6520): statt eines variablen Feldes, das bis zu 64 KByte groß sein kann, hätte ein wenige Bytes langes Feld mit fester Länge völlig gereicht (und wäre nicht nur Heartbleed-sicher, sondern auch effizienter). Da muss man sich schon fragen, was diesen Uni-Mitarbeiter geritten hat, das so zu spezifizieren – und dann auch noch selbst falsch umzusetzen.
    * Der fehlerhafte Code wurde an zwei Stellen eingebaut und, der Fehler ist beim offiziellen Review nicht aufgefallen, obwohl die Verwendung von ‚memcpy‘ und fehlende input validation als potentielle Schwachstellen gerade bei Security-Spezialisten hinlänglich bekannt sind. Für eine so weit verbreitete sicherheitskritische SW-Komponente ist die (nicht) vorhandene Qualitätssicherung ziemlich mau.
    * Das Schadenspotential von Heartbleed ist nicht so katastrophal wie von Sicherheitsexperten wie z.B. Bruce Schneier anfangs behauptet wurde: Auch durch vielfaches gezieltes Ausnutzen der Lücke kann man in Prinzip zwar alle möglichen Werte aus dem Speicher auslesen, insbesondere oftmals eigentlich verschlüsselt übertragene Daten wie z.B. Yahoo-Passwörter. Aber aufgrund der typischen Speicher-Organisation ist es recht unwahrscheinlich, dabei zufällig an die besonders kritischen privaten Schlüssel des Servers (bzw. Clients) zu gelangen.

      • David von Oheimb

        Ich kenne diese Challenge und ihre Ergebnisse. Dass bei einem bestimmten Testserver der private Schlüssel herausgefunden wurde, sagt erst mal noch recht wenig darüber aus, auf wie vielen der hunderttausenden anderen verwundbaren Server das ebenfalls möglich ist. Dazu sind genauere Analysen nötig, wie die Server bestückt sind und ihre Arbeitsspeicher SW-seitig organisiert sind.
        Wenn die Private Keys in ganz anderen (etwa: statischen) Speicherbereichen als die für den Heartbeat verwendeten Puffer stehen, hilft auch eine noch so große Masse von Anfragen nichts, diese auszulesen.

Schreibe einen Kommentar zu David von Oheimb Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert