Fehlerhafte Daten bringen eine Anwendung zum Absturz? Den Verursacher der Daten will man nicht öffentlich benennen? So etwas passiert aber nur ganz selten?

Welcher DV-Laie hat denn so etwas verzapft? NATS benötigt wohl wenigstens einen neuen DV-und PR-Chef.
Mit einer angedeuteten Rufmordkampanie kann man sich nicht reinwaschen!


Dieser Beitrag wurde am 30.08.2023 11:46 Uhr bearbeitet.

Fehlerhafte Daten bringen eine Anwendung zum Absturz?

Ja, wie überall sonst auch...

Den Verursacher der Daten will man nicht öffentlich benennen? So etwas passiert aber nur ganz selten?

Welcher DV-Laien hat denn so etwas verzapft?

Eher Profis, ganz ohne Ironie.
Wenn der Fehler so noch nie vorkam, war er auch bisher nicht notwendigerweise Teil der Testcases.

Eine Abschalt-Reaktion auf Fehler ist allerdings in sicherheitskritischen Anwendungen oft so implementiert. Die Idee dahinter: Bevor der Computer was Blödes macht, soll er besser gar nichts machen.
Ist ja auch keine schlechte Idee :)

Dieser Beitrag wurde am 30.08.2023 11:50 Uhr bearbeitet.

Die Software ist nicht abgestürzt, so wie ich das interpretiere, sondern sie hat die Verarbeitung eingestellt, so zumindestens der Text.

Es ist übrigens ein beliebter Gedanke, das ein Systemabsturz an sich eine schlechte Sache ist. Der Systemabsturz (Bluescreen bei Windows, Kernel Panic anderswo) hat aber einen sehr sinnvollen Zweck. Es ist ein Mechanismus um zu verhindern (oder es zumindestens zu versuchen), wenn das Betriebsystem in einem nicht ordnungsgemässen Zustand ist, dieser Zustand auf nicht-flüchtigen Speicher geschrieben wird und man damit den Fehler auch in die Situation nach einem Neustart des Systems fortführt. Sobald das System feststellt, hier stimmt etwas nicht, bringt es nichts, das System herunterzufahren, weil dann alles was noch hätte geschrieben werden sollen, eben auf nichtflüchtigen Speicher geschrieben wird und einen nichtflüchtigen inkonsistenten Zustand beim nächsten Neustart bereitstelt. Man will, das nichts mehr passiert, nur noch das Betriebsystem neu starten.

Gleiches gilt, wenn sich eine Applikation crashed, weil irgendetwas nicht stimmt. Man will nicht, das die Applikation in diesem noch Zustand irgendwas an den Datenbankfiles, Word-File, Graphikfiles schreibt, sondern man will, das zumindestens der letzte konsistente Zustand noch erhalten bleibt und schreibt höchstens noch an eine ganz andere Stelle den möglicherweise inkonsistenten Zustand, damit sich ein Mensch angucken kann, was man damit noch anfangen kann (Mir haben die Autorecovery-Files bspw. von Word sehr oft den Hintern gerettet). Durch ein abruptes Beenden des Prozesses, ohne das die Applikation noch was macht, kann das sehr oft sichergestellt werden, das man danach wieder am letzten intakten Zustand weiterarbeiten kann.

Und vermutlich muss man die Situation, die dort beschrieben wird ähnlich Denken.

Szenario 1: Das System verarbeitet den defekten Datensatz und arbeitet weiter. Dann werden offensichtlich fehlerhafte Daten im System. Das System ist einem nicht die Realität abbildenden Zustand, da die Daten falsch sind.

Szenario 2: Das System verwirft den defekten Datensatz und arbeitet weiter. Dann fehlt offensichtlich zu einem Flugzeug für die Flugsicherung notwendige Daten. Das System ist einem nicht die Realität abbildenden Zustand, da die Daten fehlen.

Szenario 3: Das System erkennt den defekten Datensatz, korrigiert diesen auf Basis von Annahmen und arbeitet weiter. Es ist unbekannt, ob die Reparaturannahmen korrekt sind. Es ist unbekannt, ob die Daten korrekt sind. Sie könnten korrekt sein, sie könnten aber auch falsch sein.

Szenario 4: Der Datensatz ist gar nicht defekt, sondern die Verarbeitung ist unter ganz bestimmten Umständen fehlerhaft. Bis zur Diagnose des Fehlers und der Feststellung des Root-Cause des Fehlers muss angenommen werden, das möglicherweise alle Daten im System fehlerhaft verarbeitet worden sind.

Ich möchte annehmen, das es ein Konsens ist, das auch Fluglotsen jederzeit ein Gesamtbild haben müssen, das wirklich der Realität entspricht und jederzeit vor allem Dingen Vertrauen haben müssen, das dies so ist, damit sie nicht anfangen die Angaben des System in Frage zu stellen, und damit noch mehr Probleme erzeugen.

Unter keinem der vier Szenarien kann man dem System erlauben, einfach so weiterzuarbeiten

Insofern ist es wahrscheinlich die richtige Vorgehensweise, die automatische Verarbeitung einzustellen, bis die Korrektheit wieder sichergestellt werden kann und auf ein Notverfahren umzusteigen, das gegebenfalls zwar langsamer arbeitet, aber sicherstellt, das der Zustand der Abbildung der Realität, die den Fluglotsen bereit gestellt wird, auch der Realität entspricht.

Dieser Beitrag wurde am 30.08.2023 12:26 Uhr bearbeitet.

Entsprechend dieser Logik wäre also Progoschins Abgang neulich der Versuch eines Neuanfangs? Höchstens, wenn er bei den Wiedertäufern gewesen wäre.

Im Ernst: Auch in der Datenverarbeitung fängt man Fehler, deren Eintretenswahrscheinlichkeit groß genug ist, selbstverständlich immer ab und nur wenige bis gar keine Daten des Teilprozesses sind dann verloren, aber nicht gleich die ganze Datenbank inkonsistent und schon gar nicht das Programm außer Gefecht.

Problematisch wird's einzig nur, wenn man einen Fehler erst gar nicht erwartet und deshalb auch nicht abfängt. Ein Bluescreen ist immer die Folge eines solchen ungeplanten Exitus und nie ein Wegbegleiter der Schadensbegrenzung. Wenn ein Bluescreen auftaucht hat das Programm bereits jegliche Kontrolle an das Betriebssystem abgegeben.

Wobei vor einigen Windows-Versionen übrigens damit mal geworben wurde, daß mit der neuen Version jetzt Programme weniger abstürzen würden. Windows hat eben manchmal nur keinen Bluescreen mehr angezeigt und fast so weitergemacht, als wäre nix geschehen. Die User hat's gefreut.

Entsprechend dieser Logik wäre also Progoschins Abgang neulich der Versuch eines Neuanfangs?

Nein, das russische Betriebssystem wollte erst mal nur sicherstellen, dass er keinen weitern Blödsinn macht. Was funktioniert zu haben scheint.

Die Idee dahinter: Bevor der Computer was Blödes macht, soll er besser gar nichts machen.

Die Ã"hnlichkeit der Logik ist bestechend, oder?
:)

Ein Neuanfang ist allerdings nur bei rebootfähiger Hardware möglich.

@EricM.
wenn man von einem externen System Daten bekommt, werden sie vollständig überprüft.
Wenn sie akzeptiert werden, dann sind sie korrekt oder das empfangende System arbeitet fehlerhaft bzw. wurde fehlerhaft entwickelt.
Man definiert ein System an Hand von gültigen Daten. Alle anderen Daten werden nicht akzeptiert.

Eine Anwendung - heute mit Datenbanken - mit vielen Anwendern kann man nicht einfach so abstellen. Die Konsistenz der Daten muss gewährleistet sein (roll back!). Die Anwender müssen wissen, welche Daten vollständig verarbeitet wurden und welche nochmals eingegeben werden (manuell oder batch).
Ein Absturz ohne roll back der offenen Transaktionen führt zu sehr sehr viel Stress und Arbeit...
Typischerweise wird ein Beenden einer Anwendung vorher angekündigt.

@cOtOdOsO,

wenn es drei- oder viermal innerhalb eines Monats während der normalen Betriebszeit zu einem Systemabsturz kommt, kann sich ein DV-Chef in einem grösseren Unternehmen einen neuen Job suchen.
Da dann der normale roll back der Datenback nicht funktionieren kann, dürfen einige Duzend MA Däumchen drehen.... Die Aufräumarbeiten kosten Zeit und ggf. externe Kräfte!

@EricM.
wenn man von einem externen System Daten bekommt, werden sie vollständig überprüft.
Wenn sie akzeptiert werden, dann sind sie korrekt oder das empfangende System arbeitet fehlerhaft bzw. wurde fehlerhaft entwickelt.

Sollte man meinen - aber Sie können davon ausgehen, dass *jedes* in Betrieb befindliche halbwegs komplexe Programm nach dieser Definition fehlerhaft arbeitet, d.h. bei bestimmten Eingaben oder Zuständen entweder:
- abstürzt bzw. die Verarbeitung einstellt
- oder eben "Blödsinn" macht.

@c0t0d0s0 hat das gut beschrieben.

Und gerade Software, die nicht abstürzt, sondern falsch weiterläuft ist gefährlich.
Reihenweise große Firmen und Einrichtungen, die trotz Firewalls und Antivirus Verschlüsselungstrojanern zum Opfer fallen, sind ein Zeichen für nicht abstürzende Software, die Blödsinn macht.

 https://xkcd.com/2030

Und gerade Software, die nicht abstürzt, sondern falsch weiterläuft ist gefährlich.
Reihenweise große Firmen und Einrichtungen, die trotz Firewalls und Antivirus Verschlüsselungstrojanern zum Opfer fallen, sind ein Zeichen für nicht abstürzende Software, die Blödsinn macht.

Würde ein Trojaner abstürzen, könnte er ja nicht verschlüsseln. Insofern sind Trojaner genau das Gegenteil für Abstürze, sie sind perfekt funktionierende Software, die sogar unter widrigsten Umständen läuft und läuft und läuft...

Und eine Software, die läuft, aber wegen fehlender/verschlüsselter Daten nichts zustande bringt, ist auch nicht abgestürzt, sondern immer noch voll funktionsfähig. So wie ein Auto, das aus der Kurve fliegt und im Acker steht noch immer ein funktionierendes Fahrzeug nur halt ohne aktuelle Geschäftsgrundlage ist.

Und gerade Software, die nicht abstürzt, sondern falsch weiterläuft ist gefährlich.
Reihenweise große Firmen und Einrichtungen, die trotz Firewalls und Antivirus Verschlüsselungstrojanern zum Opfer fallen, sind ein Zeichen für nicht abstürzende Software, die Blödsinn macht.

Würde ein Trojaner abstürzen, könnte er ja nicht verschlüsseln. Insofern sind Trojaner genau das Gegenteil für Abstürze, sie sind perfekt funktionierende Software, die sogar unter widrigsten Umständen läuft und läuft und läuft...

... ich meinte die Sicherheitssoftware in den Mail- und Internet-Gateways und den Arbeitsplatzrechnern dieser Firmen, die "sicherheitskritisch" ist bis zum gehtnichtmehr - und trotzdem macht Outlook "Blödsinn" und läßt den Trojaner innerhalb der Firma loslaufen statt ein Dokument oder Bild anzuzeigen.

Denn den meisten Anwendern wäre in der Situation im Nachhinein wohl ein Bluescreen lieber gewsen als eine Infektion.
Also: Im Zweifelsfall lieber Absturz :)

Dieser Beitrag wurde am 01.09.2023 08:36 Uhr bearbeitet.

@EricM,
Daten werden erst dann gefährlich, wenn sie ein beliebiges Programm starten dürfen.
Wenn Sie z. B. eine unbekannte Excel-Tabelle laden und diese Tabelle Makros enthält, die beim Laden auch ausgeführt werden dürfen, dann kann einiges passieren.
Das dürfte aber bei den Daten aus Frankreich nicht der Fall sein.

@EricM,
Daten werden erst dann gefährlich, wenn sie ein beliebiges Programm starten dürfen.

Das ist tatsächlich nicht richtig.
Daten können auch dann gefährlich sein, wenn sie die Verarbeitung eines Programms so beeinflussen, dass es falsche Ergebnisse liefert.
Dabei muss diese Beeinflussung nicht einmal absichtlich erfolgen.

Wenn Sie z. B. eine unbekannte Excel-Tabelle laden und diese Tabelle Makros enthält, die beim Laden auch ausgeführt werden dürfen, dann kann einiges passieren.
Das dürfte aber bei den Daten aus Frankreich nicht der Fall sein.

Eher nicht, das stimmt :)
Ich wollte aber den Punkt illustrieren, dass es bisweilen besser ist, ein Programm gar nichts mehr statt falsche Sachen tun zu lassen.

Nah,
zunächst wird immer die Gültigkeit der Daten(elemente) etc. überprüft. Zu jeder Verarbeitung gibt es doch Vorgaben, wie die Datei auszusehen hat.
Wenn ein Programm eine Endlosschleife zulässt, ist es falsch programmiert. Die Zeiten, in den man mit einem Tabellenüberlauf Programmteile überschreiben oder gar manipulieren, sollten an sich vorbei sein.
Natürlich gab/gibt es noch Programmiersprachen die Erzeugung oder Ã"nderung von Programmcode zur Laufzeit zulassen. So etwas lässt man aber nicht zu.

Nah,
zunächst wird immer die Gültigkeit der Daten(elemente) etc. überprüft. Zu jeder Verarbeitung gibt es doch Vorgaben, wie die Datei auszusehen hat.

Und jede Menge Annahmen, die falsch sein können

Wenn ein Programm eine Endlosschleife zulässt, ist es falsch programmiert.

Ja :)

Die Zeiten, in den man mit einem Tabellenüberlauf Programmteile überschreiben oder gar manipulieren, sollten an sich vorbei sein.

Sind sie defintiv nicht. Darüber passiert ein Großteil der Sicherheitsvorfälle.

Natürlich gab/gibt es noch Programmiersprachen die Erzeugung oder Ã"nderung von Programmcode zur Laufzeit zulassen. So etwas lässt man aber nicht zu.

Wer ist "man"?
Reflection bzw dynamischer Code ist großflächig kommerziell im Einsatz.

Sie scheinen generell ein ziemlich idealisiertes Bild kommerzieller Software_Entwicklung zu haben.
So wie ich mir gerne vorstelle, dass man bei Boeing jede Schraube 3 x umdreht und prüft, bevor man sie festzieht - das stimmt halt auch nicht, sonst würden nach dem Zusammenbau keine Leitern im Leitwerk rumklappern..

Wenn Ihre Vorstellungen richtig wären - wie bringen Sie das mit der aktuellen Nachrichtenlage zum Thema IT Sicherheit in Unternehmen und Verwaltung überein?

Hier nur mal die Liste der öffentlich bekannt gewordenen Vorfälle aus Deutschland
 https://www.csoonline.com/de/a/diese-unternehmen-hat-s-schon-erwischt,3674038



Dieser Beitrag wurde am 01.09.2023 21:42 Uhr bearbeitet.

Wenn man für die Softwareentwicklung kein Geld ausgibt, kann es man Ende teuer werden.
Manche Programme wurden länger eingesetzt als erwartet - siehe Jahrtausendwechsel.
Bei objektorientierter Programmierung hofft man auf eine "eierlegende Wollmilchsau" - aber auch sie ist nur für den Augenblick konzipiert. Wartung und Pflege wird zur Strafarbeit. Der Testaufwand iat am Ende schwer zu kalkulieren. Aber man will modern sein und macht überhaupt keine Fehler.
Hierbei ist das Nachladen von Programmcode sehr begrenzt. Man kann den Programmcode natürlich auch mit den Daten einlesen usw....Auch schon erlebt.

Vor Angriffe kann man sich nicht schützen, wohl aber vor den vom Angreifer erhofften Ergebnis.
Das Schwarmkonzept ist hierbei - aus Sicht des Angreifers - wohl zum ersten Male erfolgreich umgesetzt worden. Die Massnahmen zum Schutz der eigenen Daten sind bekannt. Man muss sie nur wirklich umsetzen.

Dieser Beitrag wurde am 02.09.2023 00:08 Uhr bearbeitet.