OTOBO und Spooky SSL

Viele Softwareprojekte sind von den 2022 aufgedeckten OpenSSL-Lücken CVE-2022-3602 und CVE-2022-3786 betroffen, die unter dem Spitznamen Spooky SSL bekannt geworden sind. Wir nehmen dies zum Anlass, den aktuellen Stand in OTOBO zu beschreiben.

Docker-Umgebungen

In der aktuellen Standard-Konfiguration verwendet OTOBO als Datenbank MariaDB in der Version 10.5. Die Standard-Datenbank kann über die Einstellung OTOBO_IMAGE_DB in docker_compose geändert werden.

Das MariaDB 10.5 Image verwendet als Basis Ubuntu Focal, also die 20.04 LTS Version, die bis April 2025 regelmäßig mit Sicherheitsupdates versorgt wird.

In Ubuntu Focal wird die Version 1.1.1 von OpenSSL eingesetzt. Diese ist laut SSL nicht verwundbar (siehe hier unter Canonical / Ubuntu / focal (20.04 LTS).

In der Image Vulnerability Database wird darauf hingewiesen, dass die Verwundbarkeit durch die verwendeten Abhängigkeiten entsteht:

“Based on information currently available the following products – through their usage or dependency to OpenSSL 3.x – will be vulnerable:

Debian 12 (bookworm) and unstable
Ubuntu 22.04 and 22.10
RedHat Enterprise Linux 9
Alpine 3.15, 3.16 and edge
Node.js 18 and 19″

Demnach ist für die von uns derzeit als Standard verwendete MariaDB keine Verwundbarkeit bezüglich der OpenSSL Lücken CVE-2022-3602 und CVE-2022-3786 vorhanden.

Wir empfehlen trotzdem allen Nutzern zu prüfen, ob Sie wirklich die aktuelle Fassung des Images in Betrieb haben.

OTOBO ohne Docker

Wenn Sie OTOBO ohne Docker verwenden, ist es wichtig, eine aktuelle Distribution einzusetzen, für die regelmäßig Sicherheitsupdates zur Verfügung gestellt werden.

Achten Sie darauf, diese automatisch oder mindestens regelmäßig zu installieren.

Die großen Distributionen haben die OpenSSL Lücke zügig gefixt und entsprechende Updates bereitgestellt.

Um zu prüfen, ob die bei Ihnen installierte MariaDB-Version eine verwundbare Fassung der Bibliothek verwendet, können Sie den Befehl ‘ldd’ verwenden:

$ ldd /usr/bin/mariadb | grep ssl

In der Ausgabe sehen Sie, dass die Version 1.1 der libssl Bibliothek verwendet wird, die nicht von dieser Lücke betroffen ist:

libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fb8b53d0000)

In Debian und Ubuntu können Sie den Befehl ‘dpkg’ verwenden, um sich die aktuell installierte Version des Paketes anzeigen zu lassen:

$ dpkg -s libssl1.1 | grep Version

Die Ausgabe weist auch hier auf eine nicht betroffene Version hin:
Version: 1.1.1f-1ubuntu2.13

Grundsätzlich möchten wir Ihnen empfehlen, mittelfristig auf die Docker-Variante zu migrieren, da dies unter anderem mehr Betriebssicherheit verspricht. Wir unterstützen Sie gerne dabei.

Bei Rückfragen wenden Sie sich gerne an unseren Support.