Gerade habe ich mir ein wenig die Hintergründe zum SSL/TLS-Bug durchgelesen, der Apple diese Woche ereilt hat.

Wer grad nicht weiß, wovon ich spreche, hier ein paar Links:

Heise.de: “Ein Sicherheitsdesaster”: Hintergründe zu Apples schwerwiegendem SSL-Problem
Golem.de: iOS erhält SSL-Bugfix, OS X bald auch
Spiegel.de: Sicherheitslücke: Apples furchtbarer Fehler

Interessant dabei ist, daß dieser Bug nur auf eine einzige Code-Zeile hinausläuft. Er wäre einfach zu verhindern gewesen, hätte man die grundlegenden Regeln von “Clean Code” befolgt.

Hier der Code-Auszug, der den Fehler beinhaltet. Ich habe ihn von Apple selbst, da der entsprechende Code unter einer OpenSource-Lizenz steht (siehe hier).

hashOut.data = hashes + SSL_MD5_DIGEST_LEN;
hashOut.length = SSL_SHA1_DIGEST_LEN;
if ((err = SSLFreeBuffer(&hashCtx)) != 0)
goto fail;


if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
goto fail;
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;

Warum ist nun aber genau dieser Code problematisch?

Schon gesehen?

Ich gebe zu, auch bei mir hat es ein wenig gedauert. Ich versuche es mal zu erklären:

Normalerweise ist es in der Programmiersprache C (in der dieser Code geschrieben ist) der Brauch, Anweisungen nach einem “If”-Statement in geschweifte Klammern zu setzen. In etwa so:

if (bedingung) {
Anweisung 1;
Anweisung 2;
Anweisung 3;
...
}

Es gibt jedoch die Möglichkeit, auf die geschweifte Klammer zu verzichten, wenn hinter der Bedingung nur eine einzige Anweisung folgt.

Also so:

if (bedingung)
Anweisung 1;

In diesem, zweiten Stil, sind auch alle “If”-Statements aus dem Code-Auszug von Apple geschrieben. Der Programmierer wollte sich so wohl einige Zeichen Tip-Arbeit sparen. Dummerweise hat sich aber nun ein kleiner Fehler eingeschlichen: Nach dem rot markierten If-Statement steht nicht eine, sondern 2 Anweisungen.

Was passiert nun in so einem Fall?

Nun, der Compiler wertet die Regel strikt aus: Steht hinter einem If-Statement keine Klammer, so folgt genau 1 Anweisung: Die erste Anweisung (in diesem Fall “goto fail;”) gehört also noch zum If-Statement. Die zweite Anweisung gehört für den Compiler jedoch nicht mehr zum If-Statement. Sie wird daher in jedem Fall ausgeführt. Ganz so, als sähe der Quellcode so aus:

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

goto fail;

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

Das zweite “goto fail;” wird daher in jedem Fall ausgeführt, und damit die Textmarke “fail” bereits angesprungen, bevor das letzte, blau hinterlegte if-Statement ausgeführt werden kann.

Was hat das nun aber mit Clean Code zu tun?

Aus meiner Sicht ist es kein guter Stil, in if-Statements auf die geschweifte Klammern zu verzichten. Zu welch schwerwiegenden Problemen das führen kann, sieht man z.B. genau mit diesem Beispiel hier. Besser ist es, man verwendet geschweifte Klammern, dann ist es auch eindeutig, was ausgeführt wird und was nicht. Wahrscheinlich hätte hier dann sogar der Compiler davor gewarnt, dass das zweite “goto fail;” nicht erreicht werden kann (“Dead Code”), und damit überflüssig ist.

So jedoch hatte der Compiler keine Chance. Auch die ganzen Tools zur statischen Quellcodeanalyse, die Apple sicherlich im Hintergrund anwendet, laufen hier ins Leere. Und die Wahrscheinlichkeit, daß ein anderer Programmierer das zufällig entdeckt, wenn er drüberschaut, ist ebenfalls nicht allzu hoch: Der Fehler ist gut versteckt. Man muß schon mehrmals hinsehen, um ihn zu entdecken.

Was kann man nun dagegen machen?

Die einfachste Methode ist es, sich solche “besseren” Schreibweisen gar nicht erst anzugewöhnen, sondern beim Standard zu bleiben. Die meisten IDEs bieten dafür sogar Regeln an, die man hinterlegen kann. Dadurch werden entsprechende Code-Stellen als Warnung oder sogar als Fehler hinterlegt. Rutscht doch einmal eins durch, so wird es bei der automatischen Code-Formatierung (dessen Tastenkombination man während der Entwicklung ständig drückt) wieder in die Standard-Schreibweise aufgelöst.

Es ist eine gute Idee, einmal einen kompletten Satz solcher Code-Formatierungsregeln zu definieren, und dann anschliessend an alle Teammitglieder zu verteilen.

Man kann dies sogar so einstellen, daß es automatisch an alle verteilt wird, die das Projekt aus dem Versionsverwaltungssystem auschecken. Z.B. indem man etwa projektspezifische Regeln anlegt, und diese in ein Verzeichnis innerhalb des Projekts legt.

Sollten Sie das bisher noch nicht gemacht haben, so ist es eine gute Idee, nun damit anzufangen.

Ich kann mir vorstellen, bei Apple sind sie gerade voll dabei  8-)

bfi

Bernhard Findeiss
Mittwoch, der 6. November 2013

PM-Forum 2013: Ein persönliches Fazit

Nach 1 Jahr Abstinenz war ich Anfang der Woche wieder in Nürnberg auf dem PM-Forum. Zeit, ein Fazit zu ziehen.

PMO-Tag

Die 3-tägige Konferenz beginnt mit einem Tag zum Thema “PMO”. Alle Vorträge drehen sich um genau dieses Thema. Bis auf eine Ausnahme waren die Vorträge dieses Tages mäßig bis durchschnittlich interessant.

Spannend fand ich dabei vor allem, aus den Inhalten der Vorträge Rückschlüsse auf die jeweilige Firmenkultur zu ziehen. Besonders aufschlussreich war hier z.B. der Bericht über das Projekt-Portfoliomanagement (mit ca. 1000 Projekten) eines global tätigen Unternehmens aus der Verkehrsbranche. Hier scheint die Projektkultur vor allem auf der Angst vor einem (karrierelimitierenden) externen Audit zu basieren, dem sich Projekte im Status gelb oder rot unterziehen müssen.

mehr »

Ende letzter Woche war ich auf der Konferenz “interPM“. Diese stand unter dem Leitthema “IT-Projektmanagement 2012+ im Spagat zwischen Industrialisierung und Agilität?”.

Was mir dort aufgefallen ist: Vielen Menschen, ich selbst eingeschlossen, ist gar nicht richtig klar, was “agiles” Projektmanagement eigentlich kennzeichnet, und inwiefern es sich vom “klassischen” Projektmanagement unterscheidet. Das wird noch verstärkt dadurch, daß es eigentlich auch keine vernünftige Definition für “klassisches” Projektmanagement gibt.

Eine Abgrenzung ist daher schwierig. Nichtsdestotrotz möchte ich es trotzdem versuchen. Hier also meine ganz persönliche Meinung, was “Agilität” im Kern eigentlich ausmacht:

mehr »

Vor einiger Zeit habe ich hier auf dem Blog eine kurze Einführung in das Thema “Agiles Schätzen und Planen” gegeben und als Beispiel das aus vielen agilen “Standardwerken” bekannte Planning Poker verwendet (siehe hier (Teil 2) und hier (Teil 3)).

Doch in der letzten Zeit hat sich, zumindest für mich, gezeigt, daß sogar diese scheinbar einfache Methode in der Realität für mich oftmals zu schwergewichtig ist und somit nicht die erste Wahl darstellt. Deswegen möchte ich heute noch eine zweite Schätzmethode vorstellen, die ich in letzter Zeit immer häufiger in meinem täglichen Alltag verwende:

Das Schätzen in T-Shirt-Grössen.

mehr »

Bernhard Findeiss
Mittwoch, der 26. Oktober 2011

PM-Forum – Ein persönliches Fazit *Update*

Der letzte Vortrag des diesjährigen PM-Forums läuft gerade. Zeit, ein Fazit zu ziehen.
mehr »

Bernhard Findeiss
Dienstag, der 25. Oktober 2011

Handwerklich gut gemachte Software – für viele ein zu hoher Anspruch?

In den letzten Monaten habe ich mich zusehends mit Software Craftsmanship beschäftigt.  Eine der spannendsten Thesen darin ist die Forderung:

“Not only working software, but also well-crafted software” (siehe hier).

Hinter diesem so einfach klingenden Satz verbirgt sich für mich ein Thema mit einigem Diskussionspotential. Natürlich ist eine funktionierende Software immer besser als ein Schrank voller Ordner mit Spezifikationsdokumenten auf totem Baum.

Jedoch gehen bereits die Vorstellungen darüber, was man unter “funktionierender Software” zu verstehen hat, teils weit auseinander: Der einfachsten Definition nach würde es bereits ausreichen, einen kompilierfähigen Quellcode zu haben. Doch reicht das schon? Besser wäre es, den Quellcode vor der Auslieferung nicht nur zu kompilieren, sondern auch tatsächlich mal laufen zu lassen. Zudem besteht zumindest die entfernte Möglichkeit, daß die allererste Version der Software evtl. nicht der ganz große Wurf ist. Insofern wäre es auch nicht schlecht, sich zumindest im Grundsatz schon mal Gedanken zu den Themen Lesbarkeit, Wartbarkeit und Erweiterbarkeit zu machen.

mehr »

Bernhard Findeiss
Donnerstag, der 8. September 2011

Der Software Craftsman auf Wanderschaft *Update*

In meinem letzten Artikel habe ich ja angedeutet, daß hinter dem Thema “Software Craftsmanship” ein eher mittelalterlich inspiriertes Verständnis von Handwerk steht.

Zu einer Handwerksausbildung im Mittelalter gehörte in vielen Berufen auch eine Verpflichtung zur Wanderschaft (schön beschrieben z.B. auf Wikipedia). Gesellen mussten teils für mehrere Jahre auf Wanderschaft gehen, bevor sie sich für die Prüfung zum Handwerksmeister einschreiben konnten. Meistens waren daran auch noch strenge Auflagen geknüpft. So wurde z.B. ein “Sperrgebiet” um den Heimatort vorgeschrieben, und ein Abbruch der Wanderschaft war nur in genau festgelegten Ausnahmefällen möglich. Im Gegenzug waren viele Zünfte dazu verpflichtet, Gesellen auf Wanderschaft aufzunehmen und ihnen Arbeit zu geben.

mehr »

Bernhard Findeiss
Freitag, der 2. September 2011

Software Craftsmanship – Was soll das eigentlich?

Aus gegebenem Anlass (die SoCraTes 2011 ist gerade in vollem Gange) möchte ich gerne mit dem Thema “Software Craftsmanship” beschäftigen: Was ist das? Was steht dahinter? Warum ist dieses Thema wichtig?

Dazu möchte ich ein klein wenig ausholen und einen Ausflug ins “echte” Handwerk machen:

Im Mittelalter war die Produktion von Gütern noch in Manufakturen organisiert. Meistens mit sehr wenigen Mitarbeitern. Geleitet wurde die Manufaktur üblicherweise von einem Meister, der in langjähriger Ausbildung alles über sein Handwerk gelernt hat. Die Qualität der von der Manufaktur gefertigten Waren hing damit auch direkt mit den Qualitäten und Fähigkeiten des Meisters zusammen.

Dann kam die Industrialisierung. Die komplexen Produktionsprozesse der Manufakturen wurden nun in ganz viele Einzelschritte aufgeteilt. Am besten so klein, daß sie auch von Menschen ohne grosse Ausbildung durchgeführt werden können. Meistens waren es tatsächlich nur wenige Handgriffe, die man in relativ kurzer Zeit lernen konnte.

mehr »

Wie mittlerweile garantiert auch der letzte Fussballmuffel mitbekommen hat, findet zur Zeit in Südafrika wieder die Fussball-WM statt. Neben der Möglichkeit, viele mehr oder weniger spannende und interessante Fussballspiele in einem kurzen Zeitraum zu sehen, bietet sie auch wieder die passende Gelegenheit, die Arbeitsweise verschiedener Teams zu vergleichen und gegenüber zustellen.

Fussballmannschaften sind ja selbstorganisierende Teams im besten Sinne: Alle Teammitglieder arbeiten auf ein gemeinsames Ziel hin (dem Gewinn des Spiels bzw. des Turniers), und es gibt einen Coach, bzw. (im Falle einer Nationalmannschaft) einen ganzen Trainerstab.

Dieser Coach sorgt dafür, daß das Team die Regeln des zugrunde liegenden Prozesses – hier natürlich ein Fussballspiel – versteht und alles dafür tut, sich stetig zu verbessern. Eine ganz ähnliche Aufgabe also wie ein ScrumMaster hat.

mehr »

Bernhard Findeiss
Mittwoch, der 21. April 2010

Gestrandet…

Nun hat die Aschewolke aus Island also auch uns erwischt.

Dabei war der Plan eigentlich ganz einfach:

Meine Frau und ich wollten zum Ende meines auf 2,5 Wochen angesetzten Urlaubs noch für 1 Woche in den Badeurlaub fahren. Ganz egal wohin. Hauptsache warm und nicht allzuweit weg (d.h. nicht mehr als 2-3 Stunden Flugzeit).

Im Unterschied zu sonst wollten wir dieses Mal aber nicht schon ewig im Voraus buchen, sondern kurzentschlossen, also “Last Minute”, uns ein gutes Angebot schnappen. Das erste Mal nach fast 10 Jahren Individualtourismus also wieder eine Pauschalreise.

mehr »