IBM hat mehrere kritische #Sicherheitslücken im Datenbanksystem IBM Db2 veröffentlicht, die unter bestimmten Umständen lokale Angreifer in die Lage versetzen können, ihre Rechte auszuweiten – im schlimmsten Fall bis hin zu Root‑Rechten. Laut heise sind derzeit über 17 Schwachstellen bekannt, darunter zwei mit hoher Kritikalität, die es Angreifern mit Dateisystemzugriff ermöglichen, privilegierte Operationen auszuführen oder Root‑Zugriff zu erlangen. [heise.de]
Was genau ist betroffen?
Die Schwachstellen betreffen verschiedene Db2‑Versionen, inklusive älterer Releases, die nicht mehr im Support stehen und somit keine Sicherheitsupdates mehr erhalten. Für unterstützte Versionen wie Db2 11.5.9 stehen spezielle Patches (z. B. Special Build #66394) zur Verfügung. Diese beheben insbesondere Privilege‑Escalation‑Lücken sowie diverse Denial-of-Service‑Probleme, die durch manipulierte SQL‑Abfragen ausgelöst werden können.
Bin ich betroffen, wenn Db2 nur im internen LAN läuft?
Viele Unternehmen setzen Db2 ohne externe Erreichbarkeit und ausschließlich intern ein – zum Beispiel als Datenbank für d.3 / d.velop documents Version 8. Die gute Nachricht: Wenn der Db2‑Server nicht aus dem Internet erreichbar ist, sinkt das Risiko deutlich.
Allerdings gilt: Die kritischsten Lücken erfordern lokalen Zugriff auf den Server. Das bedeutet, dass ein Angreifer bereits im internen Netz oder auf dem System aktiv sein müsste, um die Schwachstellen auszunutzen. Das schützt zwar vor externen Angriffen, aber nicht vor:
- infizierten Arbeitsplätzen im LAN.
- kompromittierten Dienstkonten.
- internen Angreifern.
- Malware, die sich lateral im Netzwerk bewegt.
Kurz gesagt: Nicht aus dem Internet erreichbar bedeutet nicht automatisch sicher.
Was bedeutet das für d.3‑Systeme mit IBM Db2?
Ein wichtiger Punkt: d.velop hat angekündigt, die Unterstützung für IBM Db2 ab 2026 vollständig einzustellen. Bereits heute steht Db2 für Neuinstallationen nicht mehr zur Verfügung, und Bestandskunden erhalten nur noch bis Ende 2026 Support. Eine Migration auf Microsoft SQL‑Server wird ausdrücklich empfohlen. [Wichtige N….dok – GWS]
Damit ergibt sich ein doppelter Handlungsdruck:
- Aktuelle Sicherheitslücken beheben
- Frühzeitig die Migration auf SQL‑Server planen, da Db2 perspektivisch nicht mehr unterstützt wird
Wie hoch ist das Risiko für meine bestehende d.3‑Installation?
Bewertung für typische d.3‑Umgebungen im LAN:
Du bist wahrscheinlich betroffen, wenn:
- Du eine ungepatchte oder ältere Db2‑Version einsetzt.
- Dein d.3‑System weiterhin auf Db2 basiert (Version 8 ist häufig betroffen).
- Dienstkonten oder Anwendungen mit zu hohen Rechten laufen.
- es potenzielle interne Angriffswege gibt (z. B. über RDP, SMB, Schwachstellen in Drittsoftware).
Du bist weniger betroffen, wenn:
- Deine Db2‑Version gepatcht und im Support ist.
- Der Server gehärtet ist und nach Prinzip „Least Privilege“ betrieben wird.
- Das System vollständig isoliert ist.
- Du bereits auf Microsoft SQL‑Server migriert hast.
Klare Empfehlung
Kurzfristig
- Prüfen, welche Db2‑Version eingesetzt wird.
- Verfügbare Sicherheitsupdates umgehend installieren.
- Dienst‑ und Systemkonten prüfen und bereinigen.
- Serverhärtung durchführen (Firewall, AV, lokale Richtlinien).
Mittelfristig
- Migration von Db2 auf SQL‑Server planen, da der Hersteller‑Support endet
- Prüfen, welche d.3‑Komponenten bereits SQL‑Server voraussetzen
Langfristig
- Moderne Web‑Technologien (z. B. d.3 One) nutzen.
- Abhängigkeit von abgekündigten Technologien vermeiden.
- Sicherheitsrisiken reduzieren, die durch veraltete Datenbanksysteme entstehen.
Fazit
Auch wenn dein d.3‑System auf Basis von IBM Db2 nur intern im LAN betrieben wird, kann eine lokale Angriffsfläche bestehen bleiben – besonders, wenn ältere oder ungepatchte Versionen im Einsatz sind. Die aktuelle Entwicklung sowie das bevorstehende Supportende von Db2 bei d.velop machen klar: Eine Migration auf SQL‑Server ist nicht nur sicherer, sondern perspektivisch zwingend notwendig.
Kommentare