Conversation

Notices

1. Embed this notice
   Kris (isotopp@infosec.exchange)'s status on Wednesday, 16-Apr-2025 17:02:37 JST Kris

   Das muß alles noch viel mehr weh tun.
   Vulnerabilities sind nicht zum Managen da.

   • Embed this notice
     Kris (isotopp@infosec.exchange)'s status on Wednesday, 16-Apr-2025 17:02:36 JST Kris

     in reply to

     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.

     Das geht nun nicht mehr.

     Ich seh das als Chance.

     GreenSkyOverMe (Monika) repeated this.
   • Embed this notice
     Kris (isotopp@infosec.exchange)'s status on Wednesday, 16-Apr-2025 17:02:36 JST Kris

     in reply to

     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!"

     Does anyone here speak l335?
     j0.

     https://megatokyo.com/strip/9

     GreenSkyOverMe (Monika) repeated this.
   • Embed this notice
     Kris (isotopp@infosec.exchange)'s status on Wednesday, 16-Apr-2025 17:02:37 JST Kris

     in reply to

     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).

     Als Beispiel

     https://nvd.nist.gov/vuln/detail/CVE-2025-0332

     CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

     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.

   • Embed this notice
     Kris (isotopp@infosec.exchange)'s status on Wednesday, 16-Apr-2025 18:43:05 JST Kris

     in reply to

     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?
     GreenSkyOverMe (Monika) repeated this.
   • Embed this notice
     Kris (isotopp@infosec.exchange)'s status on Wednesday, 16-Apr-2025 18:43:16 JST Kris

     in reply to

     https://social.bund.de/@bsi/114346473404284835

     Good News! Hier ist auch der EU Fork: EUVD. Wie üblich, wenn EU und BSI involviert sind, in Monaten.

     Aber dann haben Eure wichtigen Security-Bugs halt zwei Namen, USVD, und EUVD. Sehr gut, dann sieht man gleich was Phase ist.

     GreenSkyOverMe (Monika) repeated this.
   • Embed this notice
     Kris (isotopp@infosec.exchange)'s status on Wednesday, 16-Apr-2025 18:43:17 JST Kris

     in reply to

     Ok, wie kriegen also den ersten Fork des CVE-Projektes.

     https://chaos.social/@danimo/114346693129070641

     https://www.thecvefoundation.org/

     Amerikanisch natürlich. Es fehlt jetzt noch ein europäischer Fork und ein chinesischer.

     So sieht Fortschritt aus.

     GreenSkyOverMe (Monika) repeated this.
   • Embed this notice
     Stefan Schmidt (zaphodb@twitter.resolvt.net)'s status on Wednesday, 16-Apr-2025 18:43:31 JST Stefan Schmidt

     in reply to

     @isotopp

     Bei Namen kann es Kollisionen geben. Deine Organisation ist nicht die Welt und macht es auch nicht für die Welt. Ob es dich betrifft kannst ohnehin nur du beantworten. Du weisst das eigentlich.

     edit: PS: es muessen natuerlich nicht unbedingt die USA oder MITRE sein die eindeutige IDs zu Schwachstellen bereitstellen, aber naja UN waere wohl auch nicht die Loesung. Daher ist meine Meinung: Besser haben als nicht haben.

   • Embed this notice
     Janek Bevendorff (phoerious@mastodon.social)'s status on Wednesday, 16-Apr-2025 18:43:47 JST Janek Bevendorff

     in reply to

     @isotopp CVEs sind auch für Downstream-Projekte anstrengend, weil sie jedes Projekt, das eine Dependency nutzt, zwingen, sofort ein neues Release zu schnüren, auch wenn die Software gar nicht in einer Art und Weise genutzt wird, die angreifbar wäre. Macht man das nicht, hat man den Bugtracker voll von Leuten, deren CVE-Scanner die alte DLL-Version gefunden hat.

     Ich bekomme auch regelmäßig vom CERT Meldungen wegen alter "vulnerabler" OpenSSH-Versionen, weil Ubuntu lieber backportet als upgradet.

   • Embed this notice
     Stefan Schmidt (zaphodb@twitter.resolvt.net)'s status on Wednesday, 16-Apr-2025 18:43:58 JST Stefan Schmidt

     in reply to

     @isotopp Fortschritt wohl kaum aber ganz vielleicht schaffen sie ja die Wiederherstellung des status quo.

   • Embed this notice
     Daniel Molkentin (danimo@chaos.social)'s status on Wednesday, 16-Apr-2025 18:44:19 JST Daniel Molkentin

     in reply to

     @isotopp Je nachdem, wie diese Foundation aussieht und wer sich da engagiert, wäre ich da jetzt nicht so pessimistisch. Irgendwo müssen sie halt sitzen und dass das in den USA jetzt kurze Dienstwege geht.. naja.

   • Embed this notice
     Daniel Molkentin (danimo@chaos.social)'s status on Wednesday, 16-Apr-2025 18:44:26 JST Daniel Molkentin

     in reply to

     @isotopp So wie ich das sehe ist das ist kein Fork, sondern ein Enrichment-Service. Gibts AFAIK überall, auf nationaler und Großkonzernebene. Als ob bei der EU oder beim BSI auf Prozessebene irgendwer so schnell wäre...