Viren, Spyware, Datenschutz 11.032 Themen, 91.321 Beiträge

News: Fehler passieren!

Fatale Sicherheitslücke von Apple bei SSL

xafford / 20 Antworten / Baumansicht Nickles

Bei Apple-Produkten gibt es aktuell einen ziemlich fatalen Fehler bei der Umsetzung von SSL - verschiedene Seiten haben bereits darüber berichtet. Mittlerweile gibt es für IOS bereits ein Update, welches aktuell ausgeliefert wird. Allerdings ist auch OSX betroffen, für welches es zum jetzigen Zeitpunkt jedoch noch kein Update gibt.

Um die Tragweite dieser Lücke abschätzen zu können muss man wissen, was SSL macht. Genau genommen macht SSL zwei Dinge:

  • Per SSL wird eine Verbindung verschlüsselt, damit der Inhalt des Datenaustausches zweier Systeme im Netz nicht durch Dritte unberechtigt gelesen werden kann.
  • Zudem soll SSL garantieren, dass das andere System mit dem sich der eigene Computer unterhält auch das ist, wofür es sich ausgibt.

Bei der aktuellen Lücke patzt Apple beim zweiten Punkt, denn die Prüfung des Zertifikates des anderen Systems findet nicht statt - jedes System kann also behaupten beispielsweise www.sparkasse.de zu sein. Dadurch ist natürlich auch die Verschlüsselung der Verbindung nichts mehr wert, denn ein böswilliger Nutzer kann, wenn er sich im gleichen Netz wie der Apple-Nutzer befindet, dessen Anfragen unbemerkt auf einen eignen Server umlenken und so sensible Daten abgreifen oder manipulieren.

Quelle: opensource.apple.com

xafford meint:

Doch was ist das genaue Problem? Hierzu ein Screenshot des betreffenden Codes mit Hervorhebung der schuldigen Code-Zeile und einer Erklärung dazu:

Die verantwortliche Zeile im Code ist grau hinterlegt.

Der Fehler ist recht banal, denn eine Anweisung zum Sprung auf eine andere Code-Stelle wurde versehentlich(?) doppelt eingefügt. Dass hierdurch ein so fatales Problem entsteht ist aber erst dadurch möglich, dass der Programmierer hier wohl Tipp-Arbeit sparen wollte. Das will ich genauer erläutern.

Sogenannte If-Abfragen kann man unterschiedlich formulieren, zum Beispiel so:

if ( a = b ) {
    do_something();
}

oder so wie in obigem Code:

if ( a = b )
    do_something();

Im letzten Fall gibt es jedoch eine Besonderheit: lässt man die geschweiften Klammern weg, so gilt die Abfrage nur für die nächste Anweisung, der fehlerhafte Code hat also in Wirklichkeit folgende Bedeutung:

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) {
    goto fail;
}

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) {
    goto fail;
}

goto fail;

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) {
    goto fail;
}

Die Zeile in der das Zertifikat wirklich geprüft wird wurde also nie erreicht, denn "goto fail" wird immer vorher ausgeführt. Dies bedeutet, dass die Ausführung an dieser Stelle unterbrocken wird und an der Stelle weiter ausgeführt wird, wo "fail" definiert ist - der Code nach diesem Goto kommt nicht zur Ausführung.

Hierzu kommt noch, dass die Variable err, die einen Fehler signalisieren und als Rückgabewert dient an der betreffenden Stelle im Normalfall den Wert 0 (Null) hat, die Funktion also immer zurück gibt, dass kein Fehler aufgetreten ist.

Der Fehler ist so banal wie fatal - jeder betroffene Nutzer sollte schnellstmöglich das Update einspielen.

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
PaoloP xafford

„Fatale Sicherheitslücke von Apple bei SSL“

Optionen

Diese Art Fehler entsteht besonders dann häufig wenn man Codezeilen kopiert.
Ich denke hier hat der Entwickler das if statement mit SSLHashSHA1.final einmal geschrieben, 1x kopiert und 3x eingefügt. Dann noch schnell schnell rumgewurschtelt und dann passiert sowas. Ist mir selbst auch schon passiert. (Allerdings nicht mit goto, das zumindest in modernen Hochsprachen längst als depricated gilt. In den 90ern mit C oder VB habe ich die fehlersprungmarke immer hell genannt, 'goto hell' rockt!) Die geschweiften Klammern sind aus meiner Sicht nicht wirklich der Kern des Problems, es hängt halt davon ab ob die schliessende Klammer nach der ersten oder zweiten goto Anweisung auftritt. Passieren kann sowas immer und ein paar einfache Unit Tests hätten das aufgedeckt.

btw: was ist das hier? python?

Jedes mal wenn jemand "Cloud" sagt, verliert ein Engel seine Flügel.
bei Antwort benachrichtigen
xafford PaoloP

„Diese Art Fehler entsteht besonders dann häufig wenn man ...“

Optionen
btw: was ist das hier? python?

Ich würde mal auf Objective C oder einfach normales C tippen

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
the_mic PaoloP

„Diese Art Fehler entsteht besonders dann häufig wenn man ...“

Optionen
btw: was ist das hier? python?

Definitiv nicht. In Python müssen if-Anweisungen o.ä. mit einem Doppelpunkt abgeschlossen werden. Zuweisungen in der Anweisung sind nicht legal wegen der Gefahr sich zwischen = und == zu vertippen. Runde Klammern um die Auswertung wären zwar korrekt, sind aber unnötig und daher aufgrund zusätzlicher Tipparbeit verpönt. goto in Python gibt es, ist allerdings ein Aprilscherz ;-)

err = SSLHashSHA1.update(&hashCtx, &serverRandom)
if err != 0:
    goto fail

wäre korrekte Python-Syntax (ich hoffe, der Editor behält die Leerzeichen bei ;-) )

cat /dev/brain > /dev/null
bei Antwort benachrichtigen
PaoloP the_mic

„Definitiv nicht. In Python müssen if-Anweisungen o.ä. mit ...“

Optionen

Danke für die Aufklärung. Ich wollte sogar erst C schreiben aber das schien mir zu naheliegened.

Das mit der zusätzlichen Tipparbeit ist bei hochmodernen IDE's so eine Sache da sie dir auf Wunsch das jeweilige Konstrukt(if/foreach/switch aka select, etc) bereits hinschreiben. Das Zuweisungen in If Anweisungen bei Python nicht erlaubt sind empfinde ich als (gutgemeinte) Einschränkung.

Jedes mal wenn jemand "Cloud" sagt, verliert ein Engel seine Flügel.
bei Antwort benachrichtigen
the_mic xafford

„Fatale Sicherheitslücke von Apple bei SSL“

Optionen

Danke, Xafford, für die ausführliche Erklärung!

btw, etwas am Thema vorbei aber sollte in dem Zusammenhang dennoch erwähnt werden: Goto Statement Considered Harmful :-)

cat /dev/brain > /dev/null
bei Antwort benachrichtigen
xafford the_mic

„Danke, Xafford, für die ausführliche Erklärung! btw, ...“

Optionen

Goto ist eines der ungeliebten Kinder der IT. Wenn ich an die alten Zeiten zurück denke (alle unter 30 jährigen, bitte überlesen), als man am C64 programmiere war man dankbar dafür, aber in einer Hochsprache ist goto eigentlich ein eher überflüssiges Kontrukt, weil es einfach verdammt fehleranfällig und wenig elegant ist. Ich kann mich noch an die Häme erinnern, als die Diskussion los ging es in PHP auf zu nehmen.

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
Michael Nickles xafford

„Goto ist eines der ungeliebten Kinder der IT. Wenn ich an ...“

Optionen

Du hast wohl noch nie mit "Microsoft BASIC" auf einem PET2001 mit 7168 Byte RAM rumprogrammiert. Da gab es halt noch kein "select case", "else if", "do loop" oder so was! Siehe meine großartige Programmierleistung hier: http://www.nickles.de/thread_cache/538980947.html#c

Prost,
Mike

bei Antwort benachrichtigen
xafford Michael Nickles

„Du hast wohl noch nie mit Microsoft BASIC auf einem PET2001 ...“

Optionen

Nein, das nicht - dafür hab ich auf so etwas angefangen zu programmieren:

http://de.wikipedia.org/wiki/Commodore_VC_20

dem F*ck 20, wie der Volksmund ihn nannte (nicht ganz zu Unrecht) :)

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
Michael Nickles xafford

„Nein, das nicht - dafür hab ich auf so etwas angefangen zu ...“

Optionen

Ja der gute VC20. Der war gegenüber dem PET2001 ein besonders grausamer Rückschritt, weil er nur 22 × 23 Zeichen Textdarstellung hatte. Da waren die 25 x 40 vom PET 2001 schon ein Geschenk des Himmels dagegen. Ich habe übrigens nie kapiert, welcher Irre diese 23 Zeichen pro Zeile ausgedacht hat oder welchen irren technischen Hintergrund das vielleicht hatte.

bei Antwort benachrichtigen
xafford Michael Nickles

„Ja der gute VC20. Der war gegenüber dem PET2001 ein ...“

Optionen
oder welchen irren technischen Hintergrund das vielleicht hatte.

Speicher war wohl der Hintergrund. Commodore wollte damals überschüssige Speichermodule los werden, aber so großzügig waren sie dann doch nicht.

Was ich übrigens viel übler fand (nicht nur auf dem VC-20) waren die Zeilennummern - ein Horror, wenn man ein Programm überarbeiten wollte:

10 GOTO 20

20 GOTO 10

And hell broke loose...

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
Michael Nickles xafford

„Speicher war wohl der Hintergrund. Commodore wollte damals ...“

Optionen

Die Programmierer des Atari VCS mussten viel mehr leiden!

bei Antwort benachrichtigen
xafford Michael Nickles

„Die Programmierer des Atari VCS mussten viel mehr leiden!“

Optionen

Atari war nicht meine Welt - was war denn deren Strafe?

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
Michael Nickles xafford

„Atari war nicht meine Welt - was war denn deren Strafe?“

Optionen

Die mussten sich bei 128 Byte (BYTE!) RAM keine Gedanken über Zeilennummern machen. Sowas wie Grafikspeicher gab es gar nicht, die CPU musste den "Rasterstrahl" des Fernsehers quasi live versorgen. Extrem sehenswert:

www.youtube.com/watch?v=MBT1OK6VAIU

Die haben damals überirdisch Irres geleistet.

bei Antwort benachrichtigen
xafford Michael Nickles

„Die mussten sich bei 128 Byte BYTE! RAM keine Gedanken über ...“

Optionen

Also wenn Du glaubst, dass ich eine Stunde lang diesem Herren lausche, dann musst Du denken, dass ich nichts zu tun habe :)

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
Olaf19 xafford

„Speicher war wohl der Hintergrund. Commodore wollte damals ...“

Optionen

Ich hatte ab 1987 erst den Atari 1040 ST/F, später den Mega ST4. Hauptmotivation der Anschaffung, immerhin für satte 2.000 DM: ich wollte Basic programmieren lernen.

Damals war das GFA Basic äußerst populär; ich hatte mich aber für Omikron entschieden, da ich das von einem befreundeten Kommilitonen kannte, der damit astronomische Berechnungen mit 19-stelliger Genauigkeit durchführen wollte [mein Username Olaf19 ist damit leider nicht erklärt - die 19 war immer schon eine Lieblingszahl von mir, warum auch immer].

Beide Basic-Dialekte hatten gemeinsam, dass man auf den bereits damals verpönten GOTO-Befehl praktisch komplett verzichten konnte. Es ließen sich eigene Prozeduren und Funktionen definieren, inkl. Parameterübergabe, und am Ende solcher Subroutinen wurde mit RETURN wieder an die Stelle zurückgesprungen, wo die Prozedur aufgerufen worden war (vorzeitiges Abbrechen mit EXIT, oder noch schlimmer: EXIT 2 oder gar EXIT 3, wenn um mehr als 1 Strukturebene zurückgesprungen werden sollte, war möglich, galt aber als äußerst unfein).

Pascal-Fans haben trotz aller Möglichkeiten, auch in Basic gut strukturiert zu programmieren, eifrig die Nase gerümpft über GFA und Omikron. C-Programmierung war damals auch schon populär (das Code-Beispiel von oben sieht sehr nach C aus, die Struktur mit den geschweiften Klammern ist typisch für C), und die ganz Harten - wie mein Kommilitone! - haben sich sogar an Assembler herangewagt.

10 GOTO 20
20 GOTO 10

Das erinnert mich spontan an die Musiksoftware Emagic Logic (heute: Apple Logic Pro oder Express). Die hängte sich dann und wann einfach so auf und brachte dann immer eine Alertbox auf den Schirm, mit der Meldung:

Circular structure... pls. report to Emagic how you managed to do this

:-)

Greetz
Olaf

Ein Ziel ist ein Traum mit Termin. (unbekannt)
bei Antwort benachrichtigen
floytt xafford

„Fatale Sicherheitslücke von Apple bei SSL“

Optionen
Sogenannte If-Abfragen kann man unterschiedlich formulieren, zum Beispiel so: if ( a = b ) { do_something(); }

Genau so darf man es nämlich _nicht_ formulieren.

Der geneigte Leser möge selber herausfinden, was an dem Beispiel falsch ist.

Der Fehler ist nämlich genauso so banal wie fatal :-)

bei Antwort benachrichtigen
the_mic floytt

„Genau so darf man es nämlich _nicht_ formulieren. Der ...“

Optionen

Genau darum ist das z.B. in Python auch nicht erlaubt (siehe meine Diskussion mit PaoloP)

cat /dev/brain > /dev/null
bei Antwort benachrichtigen
xafford floytt

„Genau so darf man es nämlich _nicht_ formulieren. Der ...“

Optionen

Doch, darf man und kann man - sollte man nur nicht.

Der geneigte Leser möge selber herausfinden, was an dem Beispiel falsch ist.

Der geneigte Leser hat sich bestimmt den Screenshot aus dem Original-Quelltext angesehen und weiß deswegen, warum in meinem Beispiel eine Zuweisung und kein Vergleich statt findet ;)

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
floytt xafford

„Doch, darf man und kann man - sollte man nur nicht. Der ...“

Optionen

Im Original-Quelltext wird Vergleich und Zuweisung nicht gleichzeitig gemacht. Die Zuweisung an err ist in der inneren Klammer und danach wird ein Vergleich gemacht. Wenn schon Haare spalten, dann richtig :-)

bei Antwort benachrichtigen
xafford floytt

„Im Original-Quelltext wird Vergleich und Zuweisung nicht ...“

Optionen
Im Original-Quelltext wird Vergleich und Zuweisung nicht gleichzeitig gemacht. Die Zuweisung an err ist in der inneren Klammer und danach wird ein Vergleich gemacht.

Nur dass das ziemlich egal ist in meinem Beispiel, da ist nämlich nur eine Zuweisung drinnen - der Vergleich ist nur implizit. Aber wo Du es jetzt erwähnst fällt mir selbst auf, dass mein Beispiel nicht wirklich 100% zu dem Problem passt.

Wenn schon Haare spalten, dann richtig :-)

Beim Haare spalten zieh ich leider den Kürzeren - es sei denn Brusthaare zählen auch :)

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen