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.

Naja - es wäre mal interessant wie der TO denn irgendwas entwickeln würde wenn er "persönlich" haftbar wäre. Ich persönlich würde nämlich meine Software direkt abschalten. Nicht weil ICH ggf. Lücken drin hab (und ich bin mir sicher auch meine SW hat lücken und fehler, sonst sollte ich deutlich den Job wechseln ;) ) - ich nutze halt div. Frameworks, externe Schnittstellen,... Und gut - ich habe keine "Kunden" in der Form (ich programmiere das für mich und nen paar Kollegen um den Job zu vereinfachen - also eher "just for fun"), aber ich würde keine Verantwortung dafür übernehmen wollen was eben in den entsprechenden "Addons" verbaut wurde. Noch viel weniger würde ich dafür verantwortung übernehmen wollen was der Compiler ausm Java-Sourcecode zur JAR macht, was danach die JRE ausführt,..

Also lieber TO: Karten aufm Tisch, wieviele (reale) Software hast du schon programmiert und aktiv in Benutzung? Und ja - ich stimme dir durchaus in einem Punkt zu: Die QUALITÄT der Software hat (wie auch in vielen anderen Bereichen) nachgelassen, das liegt ua. auch daran das eben heute das übersetzen zum Test nur noch "sekunden" dauert und somit es schon verlockend ist "ich mach mal schnell und schau obs läuft" statt "ich überlege erst und mache dann" weils übersetzen eben mal kurz im besten Fall 5 min, im dümmsten Fall nen paar Stunden dauert. Denn das was du schreibst ist eben zwar für nen Stammtisch ne gute Theorie, in der Praxis jedoch so nicht machbar. Mir würde nämlich nur eine Anwendung einfallen bei der nen Hersteller diese Verantwortlichkeit übernehmen könnte - im Bereich der millitärischen Raketensteuerung... hier is es nämlich eh nur nen "one-time-use"...

Ich stimme dir vollkommen zu, dass es Verantwortung und bessere Qualität braucht. Bei kommerzieller Software wird das einkalkuliert. Sieht man alleine am Niveau, welches Microsoft & co. tagtäglich liefern: Schwere Sicherheitslücken werden immer wieder nicht mal als solche anerkannt und wenigstens im Nachgang korrigiert. Wenn doch, liefert man die Nutzer unverantwortlich lange ans Messer.

Die Liste könne man noch erweitern, der Punkt ist: Es geht gar nicht darum, die qualitativ beste (sicherste) Software zu entwickeln. Sondern um die billigste (und damit schlechteste), die gerade noch reicht, um maximalen Profit damit zu erwirtschaften. Aus BWL Sicht gibt es null Anreiz, mehr Geld in Sicherheit zu investieren - im Gegenteil, für die ist das unnötig = Verschwendung.

CVE abzuschaffen, halte ich trotzdem für falsch. Durch einen Umkehr zur technisch maximal möglichen Qualität/Sicherheit würde die Zahl der Sicherheitsmängel stark sinken. Dennoch kann es selbst bei einem wirklichen (nicht PR wie bei Microsoft, CrowdStrike & co!) Fokus auf Sicherheit zu Fehlern kommen. Für diesen Rest brauchen wir ein System zur Erfassung & Diskussion. Mit einer CVE ist eine Lücke eindeutig identifizierbar.

Was wir allerdings brauchen, ist ein Umdenken: Wenn ein Unternehmen wie MS regelmäßig eine große Zahl an Sicherheitslücken fixt, darf das nicht grundsätzlich als positiv gesehen werden. Würden wir bei einem Handwerker auch nicht tun, falls der nach Abschluss der Arbeiten ständig wieder kommen muss, um was nachzubessern. Das kann mal passieren, andauernd ist jedoch eher ein Zeichen für Schlamperei.

Analog ein paar Beispiele dafür bei Software:
- Hersteller nutzt externe Bibliotheken und patcht die verspätet
- Bereits bestehende Sicherheitslücke wird wieder aufgerissen
- Gefixte Sicherheitslücke ist Trivial und ließe sich einfach verhindern (z.B. SQL Injection)

Derzeit wird ein Schlamperladen, der aus Faulheit oder Unfähigkeit 2025 z.B. noch immer keine prepared statements & co. in seinen DB nutzt, gleich behandelt wie jemand, der alle Grundlagen übertrifft, Code Reviews mit 4 Augen Prinzip macht usw und nach längerer hoher Qualität doch einmal ein menschlicher Fehler passiert. Die gleiche Schieflage, wie Unternehmen, die pauschal (z.B. nach Abschluss) bezahlen: Wer sich den Hintern aufreißt, bekommt nicht mehr Geld wie der Kollege, der alles entspannt angeht. Folglich gibt es in beiden Fällen kaum Anreize dafür. So lange sich das nicht ändert, wird es auch nicht wesentlich besser werden.