Auch das noch!

Das Jahr 2021 meint es mit uns offenbar nicht so gut. Zuerst die - trotz diverser Versprechungen unserer politischen Repräsentanten - nicht endend wollende Geschichte um das Coronavirus. Dann, quasi um uns Weihnachten endgültig zu verderben, noch die Sache mit der Sicherheitslücke "Log4Shell" im extrem weitverbreiteten Loggingmodul "Log4j".

Die Lücke ist von der Grundidee her eigentlich eine grundsätzlich sehr praktische Sache für Entwickler, die im Loggingmodul (das für Anzeige, aber auch Protokollierung von Fehlern und Benutzerinformationen zuständig ist) quasi Variablen zulässt, die dann direkt vom Loggingmodul eingesetzt werden. Leider in dieser Konstellation aber genauso praktisch für böswillige Zeitgenossen, die damit von außen Schadcode einschleusen oder - im noch harmlosesten Fall - geheime Daten auslesen können.

Das große Problem ist, dass das "Log4j" praktisch in sehr vielen, wenn nicht gleich den allermeisten Systemen, die sich auf Java stützen, eingesetzt wird - und das aber oft nur als Komponente einer Komponente, die wieder in einer anderen Komponente steckt. So gesehen kein Wunder, dass viele Systemadministratoren gar nicht wissen, ob sie von diesem Problem betroffen sind oder nicht.

Natürlich ist das für unseren Schwerpunkt LIMS / Laborinformationssysteme auch durchaus ein Thema und wir wurden schon mehrfach gefragt, ob unser LIMS "uniLIME" davon betroffen ist.

uniLIME-User können aufatmen ...

Hier können wir glücklicherweise absolute Entwarnung geben - uniLIME hat nichts mit der Java-Welt zu tun und verwendet daher die genannte Komponente nicht. Für Laborinformationssysteme anderer Hersteller können wir leider natürlich nicht sprechen, hier gibt es durchaus einige LIMS, die sich auf Java stützen und möglicherweise von diesem Schreckensszenario betroffen sein können. Im Zweifelsfall also besser beim Entwickler nachfragen!

< Früherer Beitrag     Neuerer Beitrag >