VW hat seinerzeit im Abgasskandal auch ordentlich betrogen und die sind trotz hoher Milliardenstrafen immer noch nicht pleite. Ob eine Firma wie CrowdStrike sowas in der Größenordnung überleben würde, bezweifle ich allerdings...
Weltweite Computerstörung legt Systeme lahm
-
-
Ich kann da jetzt nicht wirklich eine „Häufung von Unzulänglichkeiten“ entdecken. Eine fehlerhafte Zeile im Code und die Testabdeckung und/oder Qualitätssicherung hat es übersehen.
Fehler in der Programmierung, automatisierte Tests haben es nicht entdeckt, im Review durch einen Menschen wurde es übersehen. Das ist das Normalste der Welt
Der Test, der darin bestanden hätte, es einmal durchlaufen zu lassen, ist ja augenscheinlich gar nicht gemacht worden. Wenn so was passiert, dann ist das mehr als ein "übersehen". Dann ist der ganze Prozess sinnlos. Hier geht es ja um ein Ausrollen einer Änderung ohne jegliche Kontrolle in die Produktion des Kunden. So was darf nicht passieren! Hier geht es um Prozesse, Kontrollen und interne Strukturen, die nicht funktioniert haben. Das ist ein tiefgreifenderes Problem, als nur zu sagen 'fehlerhafter Code und QS hat es übersehen.' Nochmal: es geht darum, dass man überhaupt keinen Test gemacht hat, sonst wäre es sofort aufgefallen. Das ist nicht das "Normalste der Welt"!
Das ist in C++ einfach gefährlich und wenn da mal nicht die volle Konzentration da ist, übersieht man das leicht.
Das wäre in C++ nicht gefährlicher als in anderen Sprachen, wenn man die Programme wie gesagt in C++ schreiben würde und die std-Bibliothek nutzt und nicht nur in der Untermenge 'C' einen Pointer dereferenziert, ohne ihn vorher auf NULL getestet zu haben, wie es wohl in diesem Fall passiert ist.
Hier geht es es nicht in erster Linie um den Programmierfehler. So was passiert natürlich immer wieder. Hier geht es darum, dass laut eigener Aussage von CrowdStrike gegen die eigenen strengen Vorgaben der Firma verstoßen wurde. Hier geht es auch darum, dass CrowdStrike und die Kunden die "automatisierten" Updates hinterfragen müssen, weil auch der auslösende Fehler in einer Definitionsdatei stecken kann (welch neue Erkenntnis). Für mich ist das genug um zu sagen, dass da einiges im Argen liegt. Darfst du gerne anders sehen...
-
Der Test, der darin bestanden hätte, es einmal durchlaufen zu lassen, ist ja augenscheinlich gar nicht gemacht worden. […] Nochmal: es geht darum, dass man überhaupt keinen Test gemacht hat
Ich wäre vorsichtig mit Aussagen darüber, was offensichtlich passiert ist oder nicht passiert ist. Das wissen wir nicht. Menschliche Code-Reviews schließen im Übrigen nicht zwingend die Ausführung von Code ein, dazu kann auch einfach nur der Code gelesen werden. Die Ausführung erfolgt dann eher im Rahmen der sogenannten Continuos Integration (CI). Aber da kann es auch vorkommen, dass ein bestimmter Fall nicht abgedeckt ist. Oder abgedeckt ist, aber der Test fehlerhaft ist und ein falsches Ergebnis liefert. Oder die Testumgebung verhält sich anders als das Gerät des Entwicklers. Das kommt in der realen Welt alles vor. Da wird dir auch Mozilla ein Lied von singen können.
So was darf nicht passieren!
Das bestreitet doch überhaupt niemand. Im Gegenteil, ich schrieb das sogar selbst, dass das nicht passieren darf. Aber zwischen „darf nicht passieren“ und „es gab möglicherweise eine vorsätzliche Manipulation“ liegt ein himmelweiter Unterschied.
Das wäre in C++ nicht gefährlicher als in anderen Sprachen, wenn man die Programme wie gesagt in C++ schreiben würde und die std-Bibliothek nutzt und nicht nur in der Untermenge 'C' einen Pointer dereferenziert, ohne ihn vorher auf NULL getestet zu haben, wie es wohl in diesem Fall passiert ist.
Für eine Beurteilung, welche Bibliotheken eingesetzt oder nicht eingesetzt werden sollten, benötigt man ein bisschen mehr Kenntnis über das Gesamtprojekt und Entscheidungen, die in dessen Rahmen getroffen worden sind. Dazu kann ein Außenstehender keine qualifizierte Aussage treffen. Du hast jetzt Kenntnis über einen konkreten Bug. Und da ist es immer leicht, hinterher schlau daherzureden, wie leicht man den Bug doch hätte vermeiden können. Tatsache ist: Entwickler sind auch nur Menschen und machen Fehler. Und das betrifft ausnahmslos jeden Entwickler. Den perfekten und fehlerfreien Entwickler gibt es nicht.
Was den Punkt betrifft, das sei in C++ nicht gefährlicher als in anderen Sprachen: Wie gesagt, in Rust wäre ein solcher Fehler nicht möglich gewesen. Also doch, diese konkrete Situation ist in C++ gefährlicher. Natürlich folgt daraus nicht, dass es besser wäre, jetzt die gesamte Anwendung in Rust neu zu schreiben. Es ging bei dieser Aussage darum, dass das in C++ einfach eine typische Situation ist, in die vermutlich die meisten C++-Entwickler schon mindestens einmal gekommen sind. Vermutlich eher selten mit solch dramatischen Auswirkungen. Aber das war ja nicht der Punkt.
Für mich ist das genug um zu sagen, dass da einiges im Argen liegt
Ja. In der Qualitätssicherung wurde versagt, hier muss nachgebessert werden. Das hat wie gesagt niemand bestritten. Es ging in meinem Beitrag einzig und alleine um deine Andeutung von Vorsatz. Das sehe ich beim bisherigen Kenntnisstand nicht. Ich habe dargestellt, dass wir hier von einem einfachen Programmierfehler sprechen, der dann durch die Qualitätssicherung gerutscht ist, was nicht passieren darf, aber leichter passieren kann, als man meint. Dass der Fehler keine internen Änderungen zur Folge haben müsste, war nicht meine Aussage. Selbstverständlich muss das Unternehmen alles daran setzen, dass so etwas nie wieder passiert.
-
"Friendly fire"
sozusagen.
Gut dass das bei den "Guten" passiert ist und nicht beim "Feind". Wohlgemerkt, ein amerikanisches Unternehmen hat den ultimativen "Kill Switch" gefahren. Ganz großes Kino.
Wird es da eigentlich Verantwortliche geben die in die Pflicht genommen werden? Wie sieht es mit Regressforderungen aus? Ist der Schaden bezifferbar oder "too big too pay"? -
Ich wäre vorsichtig mit Aussagen darüber, was offensichtlich passiert ist oder nicht passiert ist. Das wissen wir nicht.
Doch das wissen wir sehr genau und alle Firmenkunden des Unternehmens wissen das mittlerweile auch: es wurde kein (Integrations-)Test für dieses Update durchgeführt. Weder automatisch, noch händisch. Ein andere logische Erklärung (außer eben "Manipulation") gibt es nicht.
Menschliche Code-Reviews schließen im Übrigen nicht zwingend die Ausführung von Code ein, dazu kann auch einfach nur der Code gelesen werden.
Ein Treiberupdate (auch die Änderung einer Konfigurationsdatei ist ein Treiberupdate) welches im Kernel eines OS residiert wird sicher nicht getestet, indem ich nur den "Code lese". Der eigentlich verursachende Agent, welcher den Fehler enthielt, wurde als Herzstück der Endpunkt-Überwachung vermutlich vorher schon etliche Male Code-gereviewed . Dass man da so einen Fehler noch nicht findet, ist etwas, was wirklich häufiger passiert und "normal" gewesen wäre, da hier ja viele Komponenten auf den Zielrechnern zusammenspielen müssen. Bei der Änderung an der Definitionsdatei sehe ich ja auch nur einen geänderten Datensatz.
Die Ausführung erfolgt dann eher im Rahmen der sogenannten Continuos Integration (CI). Aber da kann es auch vorkommen, dass ein bestimmter Fall nicht abgedeckt ist. Oder abgedeckt ist, aber der Test fehlerhaft ist und ein falsches Ergebnis liefert. Oder die Testumgebung verhält sich anders als das Gerät des Entwicklers. Das kommt in der realen Welt alles vor.
Auch da sind Tests zwingend vorgeschrieben. Welcher Fall soll denn da nicht abgedeckt worden sein? Man erwartet als absolutes Minimum bei einem Rollout eines Treiber(!)-Updates, dass dieses Update wenigstens einmal auf einem Windows-Testrechner eingespielt und durchgeführt wird. Also auf einem dieser stinknormalen Windows-Rechner, die CrowdStrike dann millionenfach stillgelegt hat. Da ist der Rechner des Entwicklers absolut nebensächlich...
Das bestreitet doch überhaupt niemand. Im Gegenteil, ich schrieb das sogar selbst, dass das nicht passieren darf. Aber zwischen „darf nicht passieren“ und „es gab möglicherweise eine vorsätzliche Manipulation“ liegt ein himmelweiter Unterschied.
Ich habe nur im letzten Satz geäußert, dass der Verdacht bei so etwas entstehen kann, wenn man bei dem Versuch einer Erklärung nur zwei Möglichkeiten hat: Extreme "Stümperei"(m.M.n. zu 99% wahrscheinlich) oder eben Vorsatz. Ich habe meine Argumentation nicht daran aufgehängt.
Für eine Beurteilung, welche Bibliotheken eingesetzt oder nicht eingesetzt werden sollten, benötigt man ein bisschen mehr Kenntnis über das Gesamtprojekt und Entscheidungen, die in dessen Rahmen getroffen worden sind. Dazu kann ein Außenstehender keine qualifizierte Aussage treffen.
Die std-Bibliothek (früher STL) ist, wie der Name schon sagt, standardmäßig integriert. Mit den entsprechenden Headern und dem Auswählen des std:: Namensraums bzw. using habe ich Zugriff darauf. Ja, welche Funktionen und was konkret davon benutzt wurde, weiß momentan niemand. Ich hatte auch nur das wiedergegeben, was bekannt ist und extra dazugeschrieben:
Nur Vermutungen meinerseits ...
Ich nehme mir halt das Recht heraus in einem Off-Topic Beitrag auch Vermutungen zu formulieren, so wie du es in diesem Thread auch schon getan hast. Hier hatte ich das sogar explizit dazugeschrieben. Und wenn ich bei dieser expliziten Vermutung meine Meinung äußere, wie man Fehlerquellen minimieren (nicht gänzlich ausschließen!) kann, so wird einem das gleich als Klugscheißerei ausgelegt?!
Ja. In der Qualitätssicherung wurde versagt, hier muss nachgebessert werden.
Gut, da sind wir uns ja immerhin einig.
-
Der erste von der Störung Betroffene prüft Schadenersatzansprüche von Crowdstrike, sofern der Bericht so richtig ist....
-
Um auf deine Anzahl Neustarts zurückzukommen. Heute lag eine Meldung von IT in der Mail, wonach Crowdstrike eine Lösung präsentiert, Rechner mit BSOD bis zu 20 Mal starten zu lassen. Es stand nicht weiter bei, was im Hintergrund passiert, ob ein Update geladen wird mit rudimentärem Web-Zugriff, oder der Treiber sich zurücksetzt, whatever. Ansonsten muss da manuell jemand eingreifen, dann geht's leider nicht.
PS und zur Klage des UKSH gibt es auch wieder etliche dumme Kommentare. Wundert es?
