Findet Apples Sicherheits-Bug

  • Das schaut auf den ersten Blick schon recht absichtlich aus. Andererseits braucht man nur ein bissl rummurksen (ala "oh da fehlt noch ein if, weil Fall xyz ist noch nicht abgedeckt *kopiert if mit fail hin* - ach, bin ich blöd.. steht ja eh da.. *löscht nur if aber das fail nicht mehr"). Wenn ich darane denke, was für abstruse Fehler mir teilweise schon unterlaufen sind.. ^^
    Was mich viel mehr verstört ist, dass die scheinbar keinerlei automatische Tests drüber laufen haben lassen. Bei nem simplen Unit-Test hätte das doch schon failen müssen.. oO

  • Das mit den Unit Tests war auch mein erster Gedanke

    "The quieter you become, the more you are able to hear."
    -------------------------------------------------------------------------------------

  • evtl. verdrückt und unabsichtlich den Shortcut für aktuelle-Zeile-kopieren erwischt? (passiert mir öfters..)
    Aber normalerweise schaut man sich den diff ja an bevor man committed...

    und dass dieser Fehler so lange unentdeckt blieb... is auch komisch
    bzgl: Unit Tests: vmtl habens eh welche, nur diesen Testfall habens halt vergessen

    oder die NSA is an allem schuld

  • Hmm, das Ding ist überhaupt recht wild..
    dachte zuerst: "na, wenn das eh in jedem Fall failed, dann dürfte ja zumindestens die Sicherheitslücke nicht entstehen".

    Bis ich dann gesehen habe, dass das fail-label in jedem Fall durchlaufen wird.
    Was von der Benennung hier etwas verwirrend ist.. und ja, man sieht ja wozu das dann führt...
    wäre "fail" wirklich ein "fail", dann wäre dieses doppelte goto schneller aufgefallen.

  • Ja und er gibt ja err zurück und da err kein err ist, läuft es nicht schief ;)
    Hab irgendwo mal bei den Comments gelesen, dass XCode keinen Shortcut für Zeile kopieren/einfügen hat. Auch wäre es unlogisch bei der Änderung diese Zeile anzunavigieren.

    "The quieter you become, the more you are able to hear."
    -------------------------------------------------------------------------------------

  • Sind "go to" Befehle wirklich so schlimm wie alle sagen? ;) Da ich noch nichts mit C programmiert habe, hatte ich auch noch nichts mit go to zu tun. Die Leute scheinen schockiert zu sein, dass sowas (bei Apple) benutzt wird.

    That awkward moment when you realize everyone on this board knows more about a test/homework than you do.

  • Sind "go to" Befehle wirklich so schlimm wie alle sagen? ;) Da ich noch nichts mit C programmiert habe, hatte ich auch noch nichts mit go to zu tun. Die Leute scheinen schockiert zu sein, dass sowas (bei Apple) benutzt wird.

    Naja, darüber kann man wohl streiten.. der Programmfluss wird halt schwieriger überschaubar, wenn man wild umherspringt.
    Zum Error-Handling wird es ja schon öfters mal noch verwendet.

    Was in der Situation wohl die beste Lösung wäre?
    Würde mich interessieren, was ihr dazu meint.
    (abgesehen von {} IMMER verwenden :) )

    - Die Variante mit den tausend verschachtelten ifs erhöht auch nicht unbedingt die Lesbarkeit.

    - Im error case sofort returnen bricht diese "one way in, one way out"-Regel, hätte hier das cleanup-Problem und hätte nichts gerettet, wenn stattdessen das return doppelt dringewesen wäre.

    - Return-Wert OK/NOK und Error-Number extra speichern hätte das Problem die Sicherheitslücke hier verhindert (wenn "return NOK" fälschlicherweise kopiert worden wäre).
    Da ist halt dann wieder die Frage: einen zusätzlichen unschönen Parameter per Pointer mitgeben für den Error-Value? Oder die "get_last_error"-Variante die aber ihre Probleme mit Parallelität hat, und die Funktion recht "unpure" werden lassen würde (was z.B. für Parallelisierung nicht gerade förderlich wäre).

    - Wenn man das goto beibehalten möchte: den eigenen Return Wert vom Return-Wert der aufgerufenen Funktionen trennen.
    Also z.B. anfangs OK = 0 und dann direkt VOR dem fail-label OK = 1 nur dann wenn wirklich alles durchlaufen wurde. Der bissl eigenartige Fall ist dann halt, wenn OK und "err" dann nicht übereinstimmen.

  • Zitat

    - Return-Wert OK/NOK und Error-Number extra speichern hätte das Problem die Sicherheitslücke hier verhindert (wenn "return NOK" fälschlicherweise kopiert worden wäre).
    Da ist halt dann wieder die Frage: einen zusätzlichen unschönen Parameter per Pointer mitgeben für den Error-Value? Oder die "get_last_error"-Variante die aber ihre Probleme mit Parallelität hat, und die Funktion recht "unpure" werden lassen würde (was z.B. für Parallelisierung nicht gerade förderlich wäre).

    Das ist grundsätzlich der Weg, den ich bei "ähnlichen Problemen" gehe. Mag vllt. unschön sein, aber in Punkto Nachvollziehbarkeit sicher leichter zu finden und verstehen.

    Was ist eigentlich der Unterschied zwischen goto xyz und xyz() als stinknormaler Methodenaufruf?

    That awkward moment when you realize everyone on this board knows more about a test/homework than you do.

  • Sind "go to" Befehle wirklich so schlimm wie alle sagen? ;)


    Kommt drauf an wohin man springt. Vorwärtssprünge aus Schleifen oder Bedingungen hinaus (also sowas wie verallgemeinertes break) sind nicht so schlimm wie wenn du wild zurück und in Schleifen hinein springst.

    Zitat

    Die Leute scheinen schockiert zu sein, dass sowas (bei Apple) benutzt wird.


    Welche Leute? Dieses Idiom mit Sachen testen und wenn was schiefgeht zum clean up code am Ende der Funktion springen ist in der Systemprogrammierung recht akzeptiert. Der Python-Interpreter verwendets intern auch. Linux auch, glaub ich.


    Was in der Situation wohl die beste Lösung wäre?
    Würde mich interessieren, was ihr dazu meint.
    [...]
    - Die Variante mit den tausend verschachtelten ifs erhöht auch nicht unbedingt die Lesbarkeit.


    Ein großes großes Oder hätte hier auch gereicht. Aber ja, das ist auch nicht unbedingt super.

    In Wirklichkeit gehören die ganzen Überprüfungen hier in eine eigene Funktion ausgelagert. Nur geht dann etwas Kohäsion verloren. Verschachtelte Funktionen wären der Hit, gibts aber in C nicht.

    Was ist eigentlich der Unterschied zwischen goto xyz und xyz() als stinknormaler Methodenaufruf?


    Ein Aufruf schiebt die Rücksprungadresse auf den Stack, damit man zurückspringen kann. Bei goto ist das nicht vorgesehen.

    *plantsch*

  • Danke für die Aufklärung :)

    Zitat

    Welche Leute?

    Bekannte, Leute aus dem Standardforum und auch bei Stackoverflow hab ich einen Link gefunden, wo erklärt wird, dass gotos böse sind. (http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF)

    Zitat

    Dieses Idiom mit Sachen testen und wenn was schiefgeht zum clean up code am Ende der Funktion springen ist in der Systemprogrammierung recht akzeptiert. Der Python-Interpreter verwendets intern auch. Linux auch, glaub ich.

    Hängt dann vermutlich stark mit dem Anwendungszweck zusammen, obs gut oder böse ist. Wahrscheinlich wissen auch viele Leute gar nicht wo goto überall verwendet wird :)

    That awkward moment when you realize everyone on this board knows more about a test/homework than you do.

    Einmal editiert, zuletzt von Cr0w3 (24. Februar 2014 um 16:01)

  • Und das, Kinder, ist der Grund warum ihr immer geschwungene Klammern verwenden sollt.

    tja, die frage ist ob man es auch tut. natürlich hab ichs in OSUE immer brav den studenten vorgebetet, aber privat hab ich bemerkt dass ich zusehends drauf verzichte... und dann gibt es natürlich auch noch coding guidelines die sagen man darf nicht klammern. linux kernel zb. openbsd (man style) läßt es offen.

    Was mich viel mehr verstört ist, dass die scheinbar keinerlei automatische Tests drüber laufen haben lassen. Bei nem simplen Unit-Test hätte das doch schon failen müssen.. oO

    Zitat von https://www.imperialviolet.org/2014/02/22/applebug.html

    A test case could have caught this, but it's difficult because it's so deep into the handshake. One needs to write a completely separate TLS stack, with lots of options for sending invalid handshakes.

    [edit]zeit für ein neues t-shirt: http://teespring.com/goto-fail-goto-fail[/edit]

    Willfähriges Mitglied des Fefe-Zeitbinder-Botnets und der Open Source Tea Party.

    Einmal editiert, zuletzt von Kampi (3. März 2014 um 11:12)

  • Hey, ich hab den Fred erst jetzt gesehen. Dankeschön für den Link, hehe. Zum Glück komm ich so gut wie nie dazu, goto zu verwenden. Und klammern tu ich eigentlich auch immer.

    In einen FBO rendern ist wie eine Schachtel Pralinen - man weiß nie, was man kriegt.

  • Und klammern tu ich eigentlich auch immer.

    Hier könnte vielleicht ein Beziehungspsychologe weiterhelfen. #badPunDay #doILookLikeAnIdiotUsingHashtagsHereOhMyICertainlyDoSorry #EspeciallyIfTheForumAutoseperatesEm

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!