Überraschenderweise erhalten wir in den letzten Tagen tatsächlich Anfragen, inwieweit convert4print von der Sicherheitslücke CVE-2021-44228, gemeinhin als Log4Shell bekannt, betroffen ist. Insbesondere die Warnung des Bundesamts für Sicherheit in der Informationstechnik hat wohl einige Anwender aufgeschreckt.

Zunächst einmal ist festzustellen, dass das Kernsystem von convert4print komplett in den Programmiersprachen C und C++ realisiert ist. Das ist alleine aus Gründen der Performance so entschieden worden. Uns als Hersteller des Produkts convert4print ist die Verantwortung beim Schreiben von Services, die innerhalb des Betriebssystems unter dem Systemkonto ohne Benutzerschnittstelle ausgeführt werden, sehr bewusst.

Von daher verwenden wir auch ausser den Laufzeitbibliotheken der Fa. Microsoft nur selbstgeschriebene Bibliotheken, oder solche, deren Quellen wir haben, und die wir selbst kompilieren können.

Von daher ist festzuhalten: convert4print selbst enthält keinerlei Java-Code.

Die genannte Sicherheitslücke CVE-2021-44228 ist für das Kernsystem daher bedeutungslos.

Eine kleine Einschränkung ist allerdings anzumerken: da die SPE Systemhaus GmbH in vielen Fällen keine Informationen darüber hat, für welche Aufgaben convert4print-Gateways eingesetzt werden, und wie diese Aufgaben realisiert werden, mag es sein, dass ein Gateway ein Java-Programm aufruft.

Ist das der Fall, muss natürlich dieses Programm auf die Sicherheitslücke CVE-2021-44228 hin geprüft werden.

Das gilt selbstverständlich auch in den Fällen, in denen das vom Gateway aufgerufene Skript selbst zwar in Perl oder PHP geschrieben ist, aber für die Erledigung seiner Aufgabe Web-Services nutzt.

Auch die Software Management Console ist ein Service, der unter dem Systemkonto des Betriebssystems ausgeführt wird. Auch dieser Service ist in den Programmiersprachen C und C++ realisiert.

Im Falle der NET-Version wird eine abgehende (!) Netzwerkverbindung zu einem von drei Lizenz-Servern der SPE System­haus GmbH genutzt, über die zumindest theoretisch ein Angriff auf die Kunden-Installation von aussen her denkbar wäre.

Die aktuellen Installer der Software Management Console setzen aber sehr restriktive Firewall-Regeln, die ausschliesslich abgehenden Netzwerkverkehr zu den festen IP-Adressen der drei Lizenz-Server erlauben. Von daher wäre also ein Angriff von aussen lediglich von einem der Lizenz-Server aus möglich.

Aller Programm-Code der Console als auch der auf Seiten der Lizenz-Server ist proprietärer Code, der keinerlei Standard­schnittstellen nutzt. Insofern ist der Angriffsvektor der CVE-2021-44228 prinzipiell gar nicht nutzbar. Zudem können unsere Kunden davon ausgehen, dass wir keinerlei Interesse haben, ihre Systeme anzugreifen - im Gegenteil wir tun alles, um die Kunden-Systeme zu schützen.

Zuletzt sei noch angemerkt, dass auf keinem der drei Lizenz-Server eine Java-Laufzeitumgebung konfiguriert ist, und daher auch kein Java-Code ausgeführt werden kann.

Es sind also keine Massnahmen erforderlich.

Im Falle der USB-Version der Software Management Console ist wegen der komplett fehlenden Verbindung ins Internet keine Grundlage für einen Angriff gegeben.

Im Normalfall wird convert4print so konfiguriert sein, dass alle Netzwerkverbindungen zu den physischen Druckern unternehmensintern im lokalen Netzwerk sind. Sollte das im Einzelfall nicht so sein, bestände theoretisch auch hier die Möglichkeit eines Angriffs von aussen.

Da aber der Rückkanal eines Druckers in convert4print nur PJL-Kommandos erkennt, ist ein Nachladen von Code über LDAP prinzipiell unmöglich.

Ob der Drucker selbst angegriffen werden kann, wäre im Einzelfall zu prüfen, da einige Drucker-Hersteller auch neue Firmware für ihre Geräte aus dem Netz nachladen.

Auch die jetzt neu aufgetauchten Angriffsszenarien, in denen über eine Web-Socket-Verbindung auch Rechner angegriffen werden können, die keine direkte Verbindung ins Internet haben, sind mit convert4print nicht nutzbar. Es gibt keine Komponente, die Web-Sockets nutzt.

Eine Einschränkung dieser Aussage gilt natürlich für die von Gateways gestarteten Skripte. Siehe oben.