Discussion:
Über den Nutzen geschweifter Klammern bei bedingten statements
(zu alt für eine Antwort)
Georg Bauhaus
2014-02-24 08:21:18 UTC
Permalink
Auszug aus http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c:

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
{
...

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)
...
fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;

}


Die Folge soll eine Sicherheitslücke sein, die Datenkommunikation
im selben WLAN mitlesbar macht. Interessanterweise ist an vergleichbaren
Stellen eine Leerzeile zu sehen. Hätte hier ein verbessertes release
management etwas ändern können, sofern es damit zu tun hat?
(Im neulich diskutierten Beispiel von Hellmut Schellong war so etwas als
mögliche Ursache ins Gespräch gebracht worden.)
Stefan Ram
2014-02-24 11:37:42 UTC
Permalink
Post by Georg Bauhaus
Die Folge soll eine Sicherheitslücke sein, die Datenkommunikation
Ich weiß ja nun gar nicht, was überhaupt der Fehler war.

Ich sehe zwar das unbedingte Goto, aber ich kann ja nicht wissen,
ob das richtig oder falsch ist. Dahinter ist unerreichbarer Code,
aber das könnte ja so richtig sein. Unerreichbarer Code ist zwar
erklärungsbedürftig, aber sein Vorhandensein ist nicht unbedingt
immer ein Fehler. Ob die Semantik der Funktion richtig ist, kann
ich mangels Kenntnis ihrer Anforderungsspezifikation ja nicht wissen.

In Java bricht der Compiler das Programm mit einer Fehlermeldung
ab, falls er erkennt, daß bestimmte Code-Teile nicht erreichbar sind.

Ich kann leider UTF-8 im Subject nicht lesen. Aus Sicherheitsgründen
möchte ich keine Subject-Zeile verwenden, von der ich gar nicht weiß,
wie sie lautet. Daher mußte ich die Subject-Zeile leider ändern.
G.B.
2014-02-24 12:29:35 UTC
Permalink
Post by Stefan Ram
Post by Georg Bauhaus
Die Folge soll eine Sicherheitslücke sein, die Datenkommunikation
Ich weiß ja nun gar nicht, was überhaupt der Fehler war.
Die Analyse erwähnt einen Angriff über einen man in the middle.
Möglich wird der Angriff durch den Vorwärts-Sprung und Rückgabe
bei err == 0, augenscheinlich deswegen, weil das nicht geklammerte
goto die Zertifikatsüberprüfung überspringt.
Post by Stefan Ram
Ich kann leider UTF-8 im Subject nicht lesen. Aus Sicherheitsgründen
möchte ich keine Subject-Zeile verwenden, von der ich gar nicht weiß,
wie sie lautet. Daher mußte ich die Subject-Zeile leider ändern.
Mehrdeutige Kodierungen von Einzel-Oktetten sind besser und sind
sicherer als längenbeschränkte, unzweideutige Kodierungen mit
mehreren Oktetten und Bitmusterprüfung? Könnte sein, dass es
dafür Beispiele gibt.

F'up.
Stefan Ram
2014-02-24 12:39:36 UTC
Permalink
Post by Stefan Ram
In Java bricht der Compiler das Programm mit einer Fehlermeldung
ab, falls er erkennt, daß bestimmte Code-Teile nicht erreichbar sind.
Das kann man in C natürlich auch haben: Mit Lint-ähnlichen statischen
Werkzeugen. Und als Außenstehender denkt man natürlich, daß bei
sicherheitskritischer Software so etwas auch tatsächlich eingesetzt wird,
neben Code-Reviews und dynamischeren Werkzeugen wie valgrind.
Marcel Müller
2014-02-24 13:09:41 UTC
Permalink
Hallo,
Post by Stefan Ram
Post by Stefan Ram
In Java bricht der Compiler das Programm mit einer Fehlermeldung
ab, falls er erkennt, daß bestimmte Code-Teile nicht erreichbar sind.
Das kann man in C natürlich auch haben: Mit Lint-ähnlichen statischen
Werkzeugen. Und als Außenstehender denkt man natürlich, daß bei
sicherheitskritischer Software so etwas auch tatsächlich eingesetzt wird,
neben Code-Reviews und dynamischeren Werkzeugen wie valgrind.
bei 100-Produkten, wird das bestimmt alles gemacht - ganz bestimmt!


Marcel
Marcel Müller
2014-02-24 21:02:24 UTC
Permalink
Post by Marcel Müller
bei 100-Produkten, wird das bestimmt alles gemacht - ganz bestimmt!
^
hier fehlt ein €

Rainer Weikusat
2014-02-24 13:55:38 UTC
Permalink
Post by Georg Bauhaus
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
{
...
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)
...
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;
}
Die Folge soll eine Sicherheitslücke sein, die Datenkommunikation
im selben WLAN mitlesbar macht. Interessanterweise ist an vergleichbaren
Stellen eine Leerzeile zu sehen. Hätte hier ein verbessertes release
management etwas ändern können, sofern es damit zu tun hat?
Das ist aus einer Bibliothek und hier haetten 'unit testing' oder ein
verbindlicher Code-review geholfen, den "copy'n'mispaste"-Fehler zu finden.

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

haette sich hoechswahrscheinlich gar nichts erst uebersetzen lassen,
aber darauf, das Textmodificationsnachlaessigkeiten zu syntaktischen und
nicht semantischen Fehlern fuehren, sollte man sich meiner Ansicht nach
lieber nicht verlassen.
Loading...