Überraschenderweise erhalten wir in den letzten Tagen tatsächlich Anfragen, inwieweit print2forms 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 print2forms 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 print2forms 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: print2forms 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 print2forms-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 externe Web-Services nutzt.

Wird im print2forms-Router die BC-XOM-Schnittstelle zu einem SAP-System genutzt, gibt es eine Besonderheit zu beachten.

Um unabhängig von der Betriebssystem-Umgebung des SAP-Systems zu sein, hat sich die SPE Systemhaus GmbH entschieden, die auf Seiten des SAP-Systems notwendigen Programmteile zur Unterstützung des BC-XOM-Protokolls tatsächlich in Java zu realisieren.

Dieser Java-Code wird auf dem SAP-System ausgeführt!

Das Java-Programm enthält - gemäss unserer internen Sicherheitsphilosophie - eine selbstgeschriebne Logger-Klasse, die lediglich im Falle der Fehlersuche auf dem SAP-System eine Textdatei (!) mit reinen Textnachrichten (die definitiv kein JSON enthalten) erstellt. In der Regel ist das Logging im Produktivbetrieb abgestellt.

Das Java-Programm baut eine Netzwerkverbindung zum print2forms-Router auf. Im Normalfall ist davon auszugehen, dass dies eine Netzwerkverbindung im lokalen Netz des Kunden ist. Da BC-XOM in der Regel manuell nachinstalliert wird, ist nicht immer klar, ob für diese Netzwerkverbindung limitierende Firewall-Regeln definiert sind. Gegebenenfalls kann hier nochmals kontrolliert und die Angreifbarkeit dieser internen (!) Verbindung verringert werden.

Da die Laufzeit des Java-Programms im SAP-System im Bereich weniger Millisekunden ist, und für jeden Aufruf eine eigene Laufzeitumgebung initiert wird, ist ein Angriff generell sehr schwierig.

Fazit: die von der Bibliothek log4j bereitgestellte Logger-Klasse wird nicht (!) benutzt!

Unseres Erachtens sind hier keine Massnahmen erforderlich.

Die vom print2forms-Service gegebenenfalls gestarteten Web-Server sind ebenfalls in C und C++ realisierter proprietärer Code, der somit keinerlei Java-Code nutzt. Da diese Web-Server zudem aus Sicherheitsgründen keinerlei Backend-Scripting zulassen, ist es nach unserem aktuellem Kenntnisstand auch nicht möglich, hier von aussen Code einzuschleussen.

Eine möglicherweise existierende Gefahr besteht allerdings darin, dass wir die HTML-Verzeichnisse dieser Web-Server nicht auf Integrität prüfen und überwachen. Von daher mag es sein, dass vielleicht durch Modifikation dieser Verzeichnisse tatsächlich Java-Code ausgeführt wird.

Das mag von Kundenseite selbst oder von einem seiner Dienstleiter so konfiguriert worden sein. Das gilt es aktiv zu prüfen, wenn der Web-Server produktiv genutzt wird.

Die iOS- und Android-Apps der SPE Systemhaus GmbH nutzen zwangsweise Java-Code. Aber auch hier kommen eigene Logger-Klassen zum Einsatz. Die Bibliothek log4j wird nicht (!) genutzt.

Inwieweit das Gerät, auf dem unsere Apps ausgeführt werden, von der CVE-2021-44228 betroffen sind, können wir nicht beurteilen.

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 print2forms 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 print2forms 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 print2forms nicht nutzbar. Die einzige Komponente, die Web-Sockets nutzt, ist der Web-Server, der eventuell vom p2fService gestartet wird.

Da dieser Web-Server aber weder in Java geschrieben ist und nur reine Text-Dateien als Log schreibt, ist kein Angriff in der beschriebenen Form möglich.

Einschränkungen dieser Aussage gelten natürlich - siehe oben - falls das HTML-Verzeichnis des Web-Servers gegenüber unserem Lieferstand verändert wurde.

Eine weitere Einschränkung gilt ebenso für die von Gateways gestarteten Skripte. Siehe oben.