Wir brauchen eine Sprache und Prozesse, die Bugs verarbeitet.
Nicht "Security-Bugs."
Sondern alle Bugs, und ihre Schwere und die Mitigationskosten im Kontext UNSERER ORGANISATION kontextualisiert.
"Toll, log4j wurde gefunden und auf einer Konferenz präsentiert." Und ignoriert. Ein Haufen Minecraft Server gehen runter, Jahre später. Der Bug bekommt eine CVE-Nummer.
Hilft Dir das?
Es beantwortet nicht, ob es Dich betrifft, welche Software es betrifft, wie viele unterschiedlich versionierte Versionen von log4j in diesem Binary sind und was Du statt Subsonic einsetzt, das betroffen ist aber das seit 5 Jahren keine Commits mehr hat.
Software Supply Chain Management hatte geholfen und weitaus früher, weil das schon geklingelt hätte, wenn ein Projekt einschläft, ohne daß Bugs vorliegen.
Nur eine sinnvoll gemanagte Supply Chain kann so was. Aber die ist für alle Bugs.
Oder auch:
Wenn eine CVE-Nummer so wichtig ist, wieso haben manche Bugs dann Namen?
CVE (Common Vulnerabilities and Exposures) sind eine Liste von "gemeldeten Security Bugs". Der Bug bekommt eine Nummer der Form CVE-Jahreszahl-Folgenummer.
Mit der CVE gibt es in der Regel eine aussagelose Beschreibung und eine "Bewertung" in Form einer dimensionslosen Zahl und einem String, der die Art des Bugs so beschreibt, wie im Internet Sex-Geschichten nach Art der Kinks kategorisiert werden.
Das Zeug wird dann in der National Vulnerability Database vor sich hin verwaltet (mit Nation ist hier selbstverständlich Trumpistan gemeint).
Wie haben hier also die Kinks "Attack Vector: Network", "Attack Complexity: Low", "Privileges: None", "User Interaction: None", "Scope: Unchanged", "Confidientiality: High", "Integrity: High" und "Availability: High" und einen Total Score von 9.8/10.
Was das genau bedeutet muß man sich aus dem Beipackzettel zur NVD raus klauben.
Die Beschreibung dann
In Progress® Telerik® UI for WinForms, versions prior to 2025 Q1 (2025.1.211), using the improper limitation of a target path can lead to decompressing an archive's content into a restricted directory.
und ein Link zur OWASP bzw. CWE:
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Ist das ein schlimmer Bug?
Das weißt Du nicht. Du weißt nicht, ob ihr die Software einsetzt, wie sie exponiert wird, welche Version ihr einsetzt, ob und wie das durch Eure Konfiguration beeinflußt wird und ob eine Mitigation mehr Schaden anrichten würde als der Bug.
Wie der Score bei Euch ist, oder ob der Score irgendeinen Sinn bei der Mehrzahl der Deployments hat – unklar.
Das heißt, wir bekommen im wesentlichen eine Nummer, eine Beschreibung und einen Link zur Bug-Database des Herstellers.
CVE haben sich für eine Reihe von Leuten als Item in ihrem Lebenslauf entwickelt, das CV in CVE steht dann für CV.
"Entdecker von CVE-2019-..., CVE-2020-... und fünf weiteren in 2021, alle mit einem CVSS:3.1 Score von 8 oder mehr." "Oh, toll! Den stellen wir ein! Dann sind wir sicher!"
Wir machen das mit den CVE-Nummern also für bestimmte Bugs, "Security Bugs", aber nicht für andere Bugs – alle anderen.
Ein Freund sagt:
Die CVEs sind Bookkeeping. Das ist wichtig und sinnvoll, aber es rettet Deine Cybersecurity nicht. Es erleichtert aber, darüber zu reden.
und in derselben Discord Message einen Absatz weiter unten
Von allen kritischen Lücken der letzten Jahre hatte ich erfahren, bevor der CVE raus war.
Ich fasse ihn zusammen:
Du hast von den CVE erfahren, bevor sie CVE waren und ohne den CVE Prozess. Der ist also nicht entscheidend gewesen für für Informationsverbreitung und nicht für die Bewertung und nicht für das Handeln.
Der CVE gibt Dir also eine Bugnummer. Das ist alles. Man könnte auch den Bug im Bugtracker des jeweiligen Projektes referenzieren, jedenfalls bei der Software, die OSS ist – das Problem sind eher die unsichtbaren Bugtracker von propietärer Software.
Der Linux Kernel hat nicht ohne Grund bei dem ganzen CVE Zeug nicht mitgemacht und sich auch geweigert, “Security” bugs anders als andere bugs zu behandeln. Das hat gut funktioniert.
Dann haben Leute an denen vorbei CVE Nummern für Kernel Bugs bestellt, und das hat totales Chaos verursacht.
Die Reaktion der Kernel-Leute war, sich zur CNA machen zu lassen, also selbst CVE-Nummern zu vergeben und dann diese Macht zu nutzen, um CVE-Nummern zu produzieren. Das war dann auch nicht recht, "weil es den Prozess in unserer Organisation überlastet hat."
Je nun.
Wenn Du nicht Linux einsetzt, sondern RedHat, dann lies halt deren Bulletins und halte Dich nicht mit CVE-Nummern auf.
CVE sind ein System zur Verarbeitung von Bugs, das an allen Software Supply Chain und Fehlerbearbeitungen vorbei läuft und Prozesse belastet. Das wäre eventuell okay in Notfällen, aber meist sind es halt keine.
"Meist" as in "weitaus überwiegend."
Das Problem ist, daß "Deine Organisation" kein sinnvolles Software Supply Chain Management hat für Software und ihre Fehler. Deine Org ignoriert das meist, und wenn das nicht geht, dann verwendet sie die CVE um Supply Chain Management zu simulieren.
@Zettelhexer Wieso kann kann die nur einmal verwarnen?
Ich habe in Kiel Dauerparker im Parkverbot gesehen, die für drei Wochen Urlaub 21 Zettel am Scheibenwischer hatten (Knooper Weg, um die Ecke ist die Wache Gartenstraße und jeden Morgen um 8:00 gab es den nächsten Zettel).
Bij „Low Code” (programmeren in een dialect uit de Lage Landen) gaat het zo: iemand schrijft de broncode in het Nederlandse taal, een compiler of interpreter (die bij de programmeertaal hoort) verwerkt dat en levert het resultaat op. Als gewone computergebruiker zie je meestal alleen het resultaat – en dat is genoeg.
This ends up being a call to execl() to a binary without a path, and a sh with interpolation inbetween. It should be a call to execve() with a clean env, and a path to a binary, sans sh.
If this is run as root in a suid binary, it would be not good.