Vom Umgang mit Fehlern

By patru

Leider, wir wissen es alle, ist Software nicht perfekt. Dieser Satz bleibt für mich selbst dann so stehen wenn ein Stück Software "mathematisch bewiesen" wurde. Damit kann man nämlich mitnichten eine "abstrakte Korrektheit" der Software beweisen, sondern nur, dass ein Stück real existierender Software eine mathematisch formulierte "Spezifikation" korrekt implementiert. Das ist zwar im Normalfall schon sehr viel mehr als das was wir über Software sonst so beweisen, aber letztlich haben wir damit nur ein schwieriges Problem (die Verifikation eines Stücks Software) auf ein noch schwierigeres Problem (die vollständige mathematische Beschreibung von realen Abläufen) zurück geführt.

Wir stehen also selbst dann noch vor einem grossen Problem wenn wir ein Stück Software mathematisch bewiesen haben, denn eigentlich müssten wir anschliessend zeigen, dass die mathematisch formulierte Spezifikation den Wunsch des Auftraggebers vollständig und abschliessend abbildet. Dies ist in den meisten Fällen ein Ding der Unmöglichkeit. In sehr eingeschränkten Bereichen mag dies möglich erscheinen, etwa wenn man möchte, dass ein Atomkraftwerk in allen denkbaren Fällen immer einen sicheren Zustand annimmt. Leider gibt es aber auch dann noch Erdbeben (Fukushima) und menschliche Dummheit (Tschernobyl) die den "Rahmen der denkbaren Fälle" sprengen. In diesem Moment sind die Rahmenbedingungen unserer mathematischen Spezifikation nicht mehr gegeben und selbst ein vollständig korrekt geschriebenes Stück Software kann in einen unvorhergesehenen Zustand übergehen (siehe auch "Fehlgeschlagener Erstflug" in Ariane 5). Diese Art von Fehlern können wir nicht restlos verhindern da wir nicht immer verhindern können, dass die Welt sich ändert. Wir können nur versuchen, sie so gut wie möglich zu vermeiden.

Fehler werden der Software erhalten bleiben.

So lange wir also nicht unbegrenzte Ressourcen zur Verfügung haben (was schon aus zeitlichen Gründen unmöglich ist) wird es immer Fälle geben in denen Software fehlerhaft reagiert. Die Anzahl der abgefangenen Fehler in einem Stück Software ist nicht zuletzt auch eine Frage des Preises den man dafür zu zahlen bereit ist, denn auch der Fehlerbehandlungscode muss ja geschrieben werden. Interessanterweise finden sich jedoch in Open Source Software Projekten etwa gleich viele Fehler wie in Closed Source Projekten, obwohl man Open Source Projekte meist gratis verwenden darf. Dies scheint auf den ersten Blick der Aussage über den Aufwand zu widersprechen, für Open Source Projekte arbeitet jedoch die Tatsache, dass man als Programmierer damit die eigene Arbeit ausstellt und deshalb bereit ist einigen zusätzlichen Aufwand zu investieren, auch wenn er sich im Moment vielleicht noch nicht rechtfertigen lässt.

Wenn sich also Fehler nicht vermeiden lassen, so müssen wir wohl einen Weg finden damit umzugehen. In den letzten Monaten hat es dazu einiges Anschauungsmaterial gegeben, hatten doch sowohl die Rubi-on-Rails- als auch die Java-Community mit einigen Fehlern zu kämpfen.

Schlechte Presse für Ruby on Rails

Leider gab es in den letzten Monaten auch einiges an schlechter Presse für Ruhy on Rails. Am gravierendsten war für mich der Fehler CVE-2013-0156 der am 8. Januar 2013 bekannt wurde. Dieser betraf alle bisherigen Rails-Versionen und erlaubte über einen obskuren Weg (den eigentlich kaum jemand verwenden wollte) die Einschleusung von beliebigem Code auf dem Server. Über diesen Fehler und die Gründe dafür wurde viel geschrieben, das soll an dieser Stelle nicht ausgerollt werden. Interessant ist hingegen der Umgang der Rails-Community mit diesem Problem. Der Fehler wurde im Rails Sourcecode am 8. Januar 2013 korrigiert, damit wurde implizit auch bekannt, dass der Fehler zuvor existiert hatte. Darauf fanden sich rasch Exploits im Netz die zeigten wie einfach man die Lücke ausnützen konnte. Für alle supporteten Rails-Versionen war aber zu diesem Zeitpunkt bereits ein Update verfügbar welches die Lücke schloss. Für Leute die nicht updaten wollte (oder konnten) gab es Patches um die "gefährliche" Funktionalität auszuschalten, was für die meisten Rails-Server problemlos war.

Danach ging ein Rauschen durch den Blog- und E-Mail-Wald, jeder Blog der über eine gewisse Reichweite verfügte meldete die Lücke und verlinkte die verfügbaren Lösungen. Ich selber las am Mittwoch Abend von dem Problem und konnte für alle unsere Server am Donnerstag ein Update machen welches das Problem ausschaltete. 

Spätestens mit der Veröffentlichung des entsprechenden Metasploit Moduls am 10. Januar 2013 hätte dann auch dem letzten klar sein sollen, dass es sich um ein ernsthaftes Problem handelt. Die meisten öffentlichen Rails-Applikationen wurden umgehend auf den neuesten Stand gebracht und es wurden nur wenige effektive Hacks bekannt, dies aber leider auch noch viel später, als es schon längst nicht mehr nötig gewesen wäre.

Obwohl es nicht immer leicht zu beurteilen ist weshalb eine Applikation nicht upgedatet wurde, im Internet sind 4 Monate ohne ein Update eine zu lange Zeit.

Aber alles in allem glaube ich doch sagen zu dürfen, dass die Rails Community rasch und mit adäquaten Mitteln auf dieses Problem reagiert hat. Dies hatte wohl auch damit zu tun, dass die Schwachstelle in einem kaum genutzten Teil von Rails auftrat, dadurch konnte man sie eliminieren indem man das Feature ganz weg liess. Auch das ist wiederum kein Zufall, denn in einem häufig verwendeten Programmteil wäre das Problem wahrscheinlich früher aufgefallen.

Schlechte Presse für Java

Seit Sun von Oracle übernommen wurde verhält sich die Java-Community eher zugeknöpfter als sie dies vorher schon war. Betrachten wir exemplarisch den Fehler CVE-2013-0422 der ebenfalls im Januar auftrat. Nach einem ersten Blog Posts von Anfang Januar wurde die Lücke bereits seit dem 2. Januar aktiv ausgenutzt bevor Oracle am 13. Januar die Patch-Version 11 von Java 7 veröffentlichte. Obwohl diese Lücke ebenfalls sehr kritisch war (und in diesem Fall auch einfache Windows-Rechner mit Java-Plugin betroffen waren) dauerte es also deutlich länger bis das Problem behoben war.

Auch hier gingen wieder Warnungen durch die Presse, das war auch dringend nötig, denn zum Zeitpunkt als das Problem bekannt wurde gab es nur die Lösung, Java im Browser ganz zu verbieten um einen Angriff zuverlässig ausschliessen zu können. Das Problem betraf zwar nur die neuste Version von Java, dafür direkt den Endbenutzer der sich darüber nicht so oft Gedanken macht wie der Systemadministrator einer Server-Maschine.

Leider waren solche Sicherheitsproblem im Java-Umfeld in den letzten Monaten sehr häufig und auch der Umgang damit hat sich kaum verbessert.

Vergleich

Es ist zwar notorisch schwierig zu sagen wie lange ein Hersteller schon von einem Problem weiss, es deutet aber einiges darauf hin, dass die beiden Probleme etwa zum gleichen Zeitpunkt entdeckt wurden. Die Rails-Entwickler reagierten deutlich schneller und in meiner Einschätzung auch entschiedener auf das Problem. Kann sein, dass es in Rails einfach weniger Sicherheitslücken gibt, dass die Lücke in Rails einfach leichter zu korrigieren war, oder dass die Probleme einfach ernster genommen wurden, alle Gründe würden an dieser Stelle für die Open Source Community sprechen.

Auch die Kommunikation über das Problem hielt ich für umfassender und vernünftiger, so kamen noch am Tag des Korrektur-Commits Blog Posts mit detaillierten Erklärungen heraus. Dies wurde zwar vereinzelt kritisiert, im allgemeinen war die Reaktion auf die Veröffentlichungen aber sehr positiv und auch wir haben den offenen Umgang mit dem Problem geschätzt. Dies bedeutete zwar etwas Arbeit für jede unserer Seiten, diese ist aber auf zentralisierten Systemen leichter zu erledigen als wenn jeder Anwender selber gefordert ist sich ein neues JRE zu installieren.