[English]Mitte August 2023 hatte Sicherheitsforscher Jaroslav Lobacevski vier Schwachstellen (CVE-2023-40031, CVE-2023-40036, CVE-2023-40164, CVE-2023-40166) im Editor Notepad ++ für Windows öffentlich gemacht. Die Einstufung der Schwachstellen reicht von mittel bis hoch. Der Entwickler hat diese Schwachstellen, nachdem ihm diese seit Monaten bekannt sind, nun mit dem Update auf Notepad++ v8.5.7 beseitigt.
Anzeige
Rückblick: Die Schwachstellen
Sicherheitsforscher Jaroslav Lobacevski insgesamt vier Schwachstellen (CVE-2023-40031, CVE-2023-40036, CVE-2023-40164, CVE-2023-40166) im Editor Notepad ++ für Windows gefunden und dem Entwickler des Programms bereits zum 28. April 2023 gemeldet. Aber es passierte nichts, der Entwickler gab kontinuierlich neue Notepad+++ Versionen heraus, ohne sich mit den Schwachstellen zu befassen.
Darauf hin beschloss Jaroslav Lobacevski an die Öffentlichkeit zu gehen und veröffentlichte zum 21. August 2023 die Details auf seiner GitHub Security-Seite. Ich hatte im Blog-Beitrag Schwachstellen in Notepad ++ (Sept. 2023) mehr Details zum Vorgang und zu den Schwachstellen zusammen getragen. Eine der Schwachstellen (CVE-2023-40031) kann einen Buffer-Overflow auslösen, wenn die Unicode-Darstellung vom Benutzer UTF16 zu UTF8 konvertiert wird.
Notepad++ v8.5.7 freigegeben
Ein anonymer Blog-Leser hat nun darauf hingewiesen, dass die Version 8.5.7 von Notepad++ erschienen ist. Auf der Download-Seite heißt es in den dort einsehbaren Hinweisen zu den Korrekturen, dass die Schwachstellen CVE-2023-40031, CVE-2023-40036, CVE-2023-40164 und CVE-2023-40166 behoben wurden.
Anzeige
Zudem schreibt der Autor, dass er eine weitere Sicherheitsverbesserung durchgeführt habe, in dem der Uninstaller jetzt wohl auch signiert wurde. Weiterhin entnehme ich dem Changelog, dass ein weiteres mögliches Speicherleck beim Lesen von Utf8-16-Dateien beseitigt wurde. Der Changelog weist eine Reihe weiterer Fehlerkorrekturen auf, die sich auf der Webseite hier nachlesen lassen.
Anzeige
Dann kann ich jetzt die Applocker-Sperre für NP++ wieder aufheben, Alternativen werden erstmal nicht mehr gebraucht.
Tragweite der "Schwachstellen" beim reflexartigen Sperren nicht verstanden, Check.
Doch, natürlich.
Hier genauso: auf Grundlage unserer IT-Compliance bzw. interner Richtlinien hatten wir Notepad++ auch per Applocker vorerst gesperrt.
Den Einwand von Anonymous kann auch ich nicht nachvollziehen, wobei ich zugegeben nicht weiß, ob er Privatanwender oder IT-Admin eines Unternehmens oder Behörde ist.
Wer kein technisches Verständnis für spezifische Probleme hat und entspr. darauf basierende Risikobewertung durchführen kann, dem bleibt nur reflexartiges Sperren. So jemand sollte aber für IT Sicherheit nicht wirklich verantwortlich sein.
ok, ich gebe zu, dass mir (uns) die Fachkenntnisse in der Analyse und Bewertung der CVE Scores die Fachkenntnisse fehlen.
Muss ich das, vielleicht ja, aber dagegen sprechen zeitliche und personelle Gründe.
Wenn ich (wir) für unsere Anwendungen bzw. unseren Software-Zoo für jede bekannte Schwachstellen und Anfälligkeiten bzw. jedes CVE eine Risikobewertung durchführen müssten,
dann wäre dass ein Fulltime-Job für eine Person.
Wir orientieren uns (siehe auch Beitrag von Tom) an den CVE Score von Cert Bund:
https://wid.cert-bund.de/portal/wid/securityadvisory?uuid=e1bf1aec-8a7d-4152-972c-49508d2a7844
Dieser lag bei hoch und deshalb haben wir Notebook++ per Applocker gesperrt.
Ansonsten:
Wenn Du in Deinem Job die Zeit für eine genaue Risikobewertung hast, dann herzlichen Glückwunsch.
Zu:
"reflexartiges Sperren" und "So jemand sollte aber für IT Sicherheit nicht wirklich verantwortlich sein."
Mag sein, aber bitte an dieser Stelle keine pauschalen Vorwürfe.
Danke!!!
Der CVE Score ist leider überhaupt nicht als Qualitätskriterium verwendbar.
Sehr lesenswert sind dazu die Vorgänge und Einstufung eines trivialen Bugs mit Score 9.8 bei curl…
https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-everything-that-is-wrong-with-cves/
Bedauerlicherweise haben die in größeren Unternehmen verantwortlichen CISOs oftmals wenig technisches Hintergrundwissen – Es wäre gut wenn die CERTs die für solche Einstufungen verantwortlich sind sich tatsächlich mit den technischen Hintergründen beschäftigen. – Eine Bewertung ohne, dass Problem verstanden zu haben ist sinnfrei.
Sollte man differenziert sehen – Daniel hat einen speziellen Fall aufgegriffen, der dumm gelaufen ist. Der Fall betraf aber die Curl-Entwickler.
Stingray hat es auf den Punkt gebracht, wenn die Info über eine Schwachstelle aufkommt, sollten Admins reagieren und die Auswirkungen grob abschätzen. Ein niedriger CVE-Score wäre ein Indiz, dass ein noch nicht brennt – wobei es Fälle gab, wo der Score später hochgestuft wurde.
Einen höheren CVE-Score sollte man da schon als ein Indiz sehen, da mal genauer hinzuschauen. Gibt es einen Patch, steht man vor der Frage, diesen zeitnah einzuspielen. Ist der Patch ohne Nebenwirkungen, dürfte die Entscheidung klar sein. Gibt es Probleme mit dem Patch, bleibt nur eine Folgenabschätzung und ggf. Mitigation.
Man möge sich aber vor vorschnellen "ist nicht relevant"-Einstufungen hüten – es sind durchaus Fälle hier im Blog behandelt worden, wo Schwachstellen durch Microsoft tageweise im CVE-Wert hochgestuft wurden. Wenn ich nicht sofort patchen kann, heißt es den Sachverhalt im Auge zu behalten.
Korrekt. Wer nicht in der Lage ist ein im CVE beschriebenes Problem bei Bedarf technisch nachzuvollziehen und dessen Tragweite abschätzen zu können, sollte keine Verantwortlichkeit im IT-Security Bereich haben.
@Bernie
ich würde sagen, völlig korrekte Vorgehensweise, man muss in unserem Job auch die Prioritäten sehen.
Lohnt sich der Aufwand, um hier explizit nachzuvollziehen, ob oder weshalb ein CVSS Score von einer hochqualifizierteren Stelle (als man selbst im Unternehmen hat) vergeben wurde oder nutzt man diese Zeit für andere, produktivere Maßnahmen?….
Naja, die IT in größeren Firmen hat im Normalfall irgendwelche Compliance Regeln. z.B. das ab einem bestimmten CVE Score vorher definierte Maßnahmen ergriffen werden müssen und je nach CVE Score eben auch x-Tage zur Behebung der Sicherheitslücke eingehalten werden müssen.
Der CVE Score war in dem Fall relativ hoch und wenn dann nicht in einer angemessenen Zeit ein Patch zur Verfügung steht, wird die App eben vorübergehend gesperrt.
Das mag aber natürlich in irgendwelchen kleineren Unternehmen anders gehandhabt werden.
Stimme dem zu: Installation erfolgreich!
Notepad++ v8.5.7 bug-fixes and new features:
1. Fix 4 security issues CVE-2023-40031, CVE-2023-40036, CVE-2023-40164 & CVE-2023-40166.
2. Security enhancement: Sign uninstall.exe.
3. Change the slogan in installer.
4. Fix eventual memory leak while reading Utf8-16 files.
5. Fix dragging tab performance issue while Document List is displayed.
6. Add supperss 2GB file warning option for x64.
7. Fix cloned document disassociated issue after Notepad++ being relaunched.
8. Fix session file saving problem if it's read-only.
9. Fix activating wrong file(s) issue after loading session file.
10. Fix wrong product version value displayed in file's properties.
Nicht wundern das Selbstupdate wird bei Notepad++ immer erst ein paar Tage später für neue Versionen freigeschaltet.
Zum Glück läuft das bei uns auf der Arbeit automatisch über das Patch-Management. Heute Nacht um 4 Uhr wurden bereits die ersten NP++ Installationen mit dem Patch versehen. Diese Autoupdate Funktionen in den Programmen selbst sind ja ganz nett, aber in der Firma würde ich mich nicht drauf verlassen, dass die Updates auch immer funktionieren. Auch fehlt eine Rückmeldung an zentraler Stelle über den Patchstand der Gesamtumgebung.
Klar, der Hinweis war jetzt auch eher für Privatanwender gedacht.