CVE - der Fluch

Moin,

Sehe ich wie @DivideByZero
Nehmen wir mal Windows (Server) als OS
Du musst dein OS für jede mögliche Konstellation absichern:
BareMetal auf HP, Dell, Lenovo, Fujitsu, …
Dann nochmals mittels Hypervisoren im Unterbau. HyperV wäre noch Easy. Aber dann kommt VMware, Proxmox, KVM/ Qemu, XenSever, Redhat, …
Dann hast du CPUs von Intel oder AMD in unterschiedlichen Generationen.
Dann gibt es Hardware wie NIC, FC HBAs, RAM, Mainboards,… alles von unterschiedlichsten Herstellern
Jetzt kommen die User noch auf die Idee, weitere Hardware anzubinden: Drucker, Webcams, Headsets, …
Das ist jetzt nur die eine einfache Übersicht.
Aber wie willst du das alles Fehlerfrei implementieren? Richtig, geht nur mit allgemeinen Schnittstellen. Und je allgemeiner die sind desto anfälliger werden die. Denn eine Intel-NIC will mit seinen Features ja genauso im OS mitspielen, wie eine Mellanox NIC. Gut, das geht mit Treibern die entweder vom Hersteller oder von Microsoft kommen und dann die Schnittstellen des OS ansprechen.


Anderes Beispiel: IBMs Power10. Das OS (SLES mal ausgenommen) kommt von IBM, die CPU kommt von IBM und bei den NICs bist du auf Intel/ QLogic eingeschränkt. Da ist es für einen OS-Hersteller leichter, alles zu härten. Gut - Windows ist deutlich mehr verbreitet als AIX oder auch DB2 (als OS in der aktuellen V7.4). Da ist Windows als Angriffsziel lukrativer (und leichter anzugreifen).


Und ich bin mir sicher, deine Powershell-Skripte haben auch Schwachstellen (solltest du welche atabliert haben). Oder hast du jeden erdenklichen Fehler und jede erdenkliche Falscheingabe angefangen?
Und als Hersteller denkst du anders, als einer, der versucht, deine Schwachstellen mit aller Macht zu finden.

Ganz einfach - der To hat bewiesen das er/sie/es keine Ahnung von SW-Entwicklung hat. Genau 0... Also ggf. mal nen "Hello World" unfallfrei durchn Compiler bekommen, aber das wars schon...

a) Jede nicht-triviale Software enthält Fehler. Dabei muss es nicht mal immer schlechte Programmierung sein - unklare Anforderungen, falsches Verständnis der Aufgabe oder sogar ne falsche Anwendung des Programmes können Fehler erzeugen, selbst wenn der Code selbst wirklich fehlerfrei wäre. Wer wäre denn zB. bei dem Kampfjet verantwortlich bei dem der Autopilot den Vogel aufm Rücken gedreht hat weil jemand dachte es wäre ne gute Idee die Steuerung einer Rakete wiederzuverwenden? Der CODE hat für seine Anwendung schließlich richtig gearbeitet, nur dummerweise war die Anwendung dann falsch.

b) Selbst wenn die Aufgabe richtig verstanden wurde, der Code fehlerfrei ist,... - kaum eine Software wird heute noch komplett selbst erzeugt. Da sind Abhängigkeiten drin - sei es das der Entwickler Frameworks nutzt, sei es das der Compiler ja auch noch nen paar Importe macht. Was bringt es also wenn der eigene Code super ist? Recht prominent ist ja zB. Log4j gewesen - von vielen Projekten eingesetzt weils das Logging stark vereinfacht. Blöd nur das es dann da nen Fehler drin gab...

c) Und selbst wenn man jetzt sagt "Ok, die Entwicklerfirma muss sowas ja auch aufm Schirm haben" - wer ist verantwortlich wenn der Kunde eben das Update nicht einspielt? Was ist mit der Software die irgendwo auf nem Chip läuft... Da müsste man somit direkt nen Killswitch einbauen - sorry, gab nen Fehler, die Hardware is jetzt leider Müll. Und es gibt auch nebenbei Systeme die man eben nicht einfach mal eben aktuallisieren kann - ich glaube kaum einer wäre zB. beim Urlaubsflug begeistert wenn der Pilot mal durchsagt "Tja, leider geht gleich das Entertainment aus, wir machen kurz nen vollständiges Systemupdate... aber keine Sorge, normalerweise kommt die Steuerung auch in 5 Min zurück". Und irgendwie will ich auch selbst bei meinem Auto nich während der Fahrt lesen "Steuergerät wird aktuallisiert weil der Hersteller nen Fehler gefunden hat und das Update jetzt machen möchte"...

Von daher hat der TO ggf. nen bisserl Stammtisch-Rhethorik, aber von Software-Entwicklung einfach mal so keine Ahnung... Natürlich ist da einiges aufm Markt was so hätte gar nich raus dürfen - aber das hat idR. auch tiefergehende Gründe... Im EINFACHEN Fall wars halt der Zeitdruck weil irgendwann das Produkt nunmal verkauft werden muss, im komplexeren Fall hat man sowas wie Windows wo es millionen von möglichen Hardware-Kombinationen gibt, man den Herstellern vorab schon was liefern muss damit die Treiber usw. entwickeln können UND bei dem jeder der nen Rechner einschalten kann auch im System rumfummelt... Komisch wenns da dann noch einige Problempunkte mehr gibt.

Der TO ist wahrscheinlich bisher nie mit Linux in Kontakt gekommen.
Dort gibt es Bibliotheken, die zentral installiert sind und von vielen Programmen verwendet werden – nehmen wir mal "libtiff".
Wenn da jetzt eine Sicherheitslücke auftaucht, lädt man nicht einfach die neue Version herunter, man aktualisiert die Bibliothek über das Paketmanagement der Distribution.
Und genau hierfür brauche ich eine eindeutige Möglichkeit, einzelne Sicherheitslücken adressieren zu können – denn bei vielen Distributionen (die nicht rolling-release sind) kann ich es an den Versionsnummern der Bibliothek nicht festmachen, da die Versionsnummern von den Distributionen verwaltet werden.
Ich kann dann nur sehen, ob durch eine neue Version des Pakets eine bestimmte, im Moment mit CVE-Nummer adressierte, Sicherheitslücke gefixed wird. Da geht es nicht um "verwalten" sondern um "ich möchte eine eindeutige Information haben, ob mein System tatsächlich gegen diese Lücke abgesichert ist wenn ich das Update installiere, oder ob ich weiterhin angreifbar wäre".

Und wer meint, dass Sicherheitslücken ja im Prinzip zu 100% vermeidbar wären wenn Leute dafür haften, soll bitte seinen eigenen Code irgendwo öffentlich bereitstellen, wir auditieren den dann gerne.

Ok - und wo haftet der Autohersteller zB. wenn du bei deinem PKW irgendwelche (ggf. nicht mal zugelassenen) Reifen aufziehst? Wo haftet der Hersteller wenn du ohne Führerschein fährst und die Karre an die Wand semmelst? Und wenn du an der Tanke statt Benzin mal Diesel reinhaust is auch eher wenig mit Haftung... Du merkst wo es drauf rausläuft - der haftet genau für SEINEN Bereich (wie es auch Software-Hersteller idR tun - dafür bekommst du nämlich Updates, Patches,...). Aber soweit es irgendwie ein Fremdsystem berührt sagt auch dein Autohersteller "nee, lass ma mit Garantie, da hab ich keinen Einfluss drauf".

Und du hast auch bei Software bei entsprechenden Fehlern natürlich allein schon den gesetzlichen Anspruch auf Nachbesserung/Rückgabe - sofern der Hersteller denn in DE oder zumindest erreichbar sitzt. Wie eben dein PKW-Hersteller auch - und nach einer gewissen Zeit sagt auch der dir "du, is nix mit Ersatzteilen, die Produktion ist eingestellt...". Da KANNST du dann Glück haben und irgendein China-Händler bietet das an - was du dann aber eben wieder auf eigenes Risiko machen kannst...

Der grosse Unterschied ist doch nur das beim Fahrzeug bekannt ist wer welches Fahrzeug hat - und ein Rückruf somit addressiert werden kann. Bei SOFTWARE ist das eben nicht bekannt wo die installiert bzw. verwendet wurde. Damit bleiben nur Datenbanken wo die Hersteller / Kunden sich selbst schlau machen können. Die alternative wäre das jedes Modul praktisch ne art Popup-Funktion bekommt und sich beim Hersteller permanent meldet. Unabhängig davon das nicht jeder das lustig finden würde dürfte dir das auch viele lustige Fenster geben...

Und nur mal ganz nebenbei - auch in den "nicht-software"-Bereichen wird heute eher auf "Wegwerf-Produkte" gesetzt (vgl. Mobiltelefon-Markt wo es ganz extrem ist). Ob da jetzt die Qualität wirklich steigt wenn die Hersteller oft schon damit rechnen das du das Produkt eh nur nen paar Jahre nutzt? Und hier darfst du auch gerne nochmal deine Fahrzeuge nehmen - da ist nämlich die Garantie oft genug auf den erst-besitzer limitiert.

Aber träum mal schön davon das du nur in der SW-Welt sowas hast und die anderen Bereiche alle toll sind...

Wir haben solche Datenbanken doch auch bei anderen Produkten oder Dienstleistungen.
Seien es unsichere Produkte im Allgemeinen oder Lebensmittelproduzenten im Speziellen.
Produktrückrufe von Lebensmitteln wegen gefährlicher Keime sind damit ja komplett sinnlos, die dürfte es ja überhaupt nicht geben. Diese Datenbanken sind alle sinnlos, da macht irgendwer nur Geld mit!!1!

Und weil es gerade auf der Startseite ist: Ein Autohersteller, der seine Fahrzeuge in die Werkstatt zurückrufen muss weil es ein Sicherheitsproblem gibt, haftet damit bereits für dieses Problem und behebt es.
Gleiches tut ein Softwarehersteller aber auch, der ein Update bereitstellt.

Eine Schadensersatzpflicht entsteht daraus aber nicht. Denn dann kommen wir schnell in den Bereich, ob du die Software in dem Bereich hättest einsetzen dürfen und ob du überhaupt selbst genug unternommen hast, um eventuelle Auswirkungen durch Sicherheitslücken zu begrenzen.
Ich als Hersteller einer Software würde z.B. jede Verantwortung zurückweisen, wenn du die Software entgegen jeder gängigen Praxis mit höchsten Privilegien laufen lässt. Genau wie ein Autohersteller nicht Schuld ist, wenn du bei Nässe mit über 180 km/h über die Autobahn fährst und in der Leitplanke wieder aufwachst.
Denn es ist selten eindeutig klar, über welche Sicherheitslücke ein Angreifer in ein System gelangt ist.
Und dann könnte es sogar noch sein, dass die Lücke nicht im Code der Software sondern im genutzten Compiler ist.
Außerdem würden damit viele "KRITIS" OpenSource-Projekte wie OpenSSL, sämtliche Dateiformat-Bibliotheken und letztlich sogar Interpreter wie Python, PHP, Perl u.s.w. eigentlich unmöglich werden. Die haben weder die Kapazitäten noch das Geld sich um solchen juristischen Kram zu kümmern.

Wie nicht nur von mir gesagt, klingt das alles so, als hättest du nur theoretisch Ahnung von der Materie, aber noch nie selber ernsthaft programmiert.
Und mein Angebot steht: Zeig mir deinen Code, ich zeige dir die Sicherheitslücken darin. Und dann reden wir nochmal darüber, ob du dafür wirklich persönlich haften willst.

Hmm, wieso nur ein kleiner Teil? Wohl eher auf den Kern Deines Beitrags.

Eine persönliche Haftung, die Du forderst, ist das aber nicht. Auch da gilt: wohl niemand würde einen Herzschrittmacher bauen, wenn er dafür persönlich haftet. Das potentielle Risiko wäre de facto untragbar. Gleichwohl bemüht sich jeder seriöse Anbieter in diesem Bereich um Qualität, so, wie man das seriösen Softwareherstellern auch "unterstellen" darf. Denn sie sind alle an nachhaltigem Geschäft interessiert, was torpediert wird, wenn man (ggf. sogar bewusst) schrottreife Software auf den Kunden los lässt.

Dass so richtig schlechte Software massive Auswirkungen auf das Geschäft hat, auch ohne persönliche Haftung, kann man bei Sonos und deren katastrophal schlechter App sehen, wo Köpfe gerollt sind, die Umsätze eingebrochen sind und seit 1 Jahr versucht wird, überhaupt den Featurestand der alten App zu erreichen.