VonDoczuDoc.de

Hier die offizielle Bekanntmachung von Turbomed zum Thema: https://service.turbomed.de/home/00001713.html

aber bei der Benachrichtigung von TM wurde verlautbart, dass sich das update auf nächsten Montag verschiebt - wegen technischer Probleme (die man beim Durchlauf des github-scripts durchaus nachvollziehen kann). Das wären dann gut 10 Tage nach offizieller Bekanntgabe der Warnstufe ROT.
Dieses Verhalten als insuffizient zu sehen ist mehr als legitim, ist aber auf dem Weg der CGM nichs Neues.
Bin froh, bei T2Med eine zeitnahe Programmauffrischung erhalten zu haben (Freitag offzielles update, Samstag Sicherheitsupdate, nichtmal 1 Tag nach Veröffentlichung des exploits).
Lungert trotzdem noch so Einiges an javalogging auf der Festplatte rum, neben Turbomedresten das Laborprogramm und und und....

Hat jemand zufällig probiert, ob das manuelle austauschen der jeweils 3 log4j*.jar Dateien in den jeweiligen betroffenen Ordner (mit Version 2.16) funktioniert, wenn die Dateien mit der alten Versionsnummer (2.11) benannt werden?
Würde ja im Prinzip reichen, wenn Turbomed erstmal nicht abstürzt )

..also austausch von:

log4j-api-2.11.1.jar
log4j-core-2.11.1.jar
log4j-slf4j-impl-2.11.1.jar

mit:

log4j-api-2.16.0.jar
log4j-core-2.16.0.jar
log4j-slf4j-impl-2.16.0.jar

und dann wieder umbenennen in:

log4j-api-2.11.1.jar
log4j-core-2.11.1.jar
log4j-slf4j-impl-2.11.1.jar

(beim Smartupdatecenter Standalone scheint es zu funtionieren, da der Dienst sich nach dem Austausch wieder starten lässt)

Forti hat geschrieben:https://github.com/mergebase/log4j-detector

Code: Alles auswählen

c:\******>java -jar log4j-detector-2021.12.14.jar t:\turbomed > hitsTM.txt

Code: Alles auswählen

t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\Asthma\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\Brustkrebs\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\COPD\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\DM1\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\DM2\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\FEK\Bin\xpm-core-4.1.5.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\KHK\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eHKS\Q1\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eHKS\Q2\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eHKS\Q3\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eHKS\Q4\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK\bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK\bin\xpm-core-4.2.6.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_3\Bin\xpm-core-4.1.9.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
-- Problem t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_3\Bin\xpm-ldk-2.2.1.jar!/javafx-swt.jar - java.io.EOFException: Unexpected end of ZLIB input stream
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_4\Bin\xpm-core-4.1.15.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
-- Problem t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_4\Bin\xpm-ldk-2.3.2.jar!/javafx-swt.jar - java.io.EOFException: Unexpected end of ZLIB input stream
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_5\Bin\xpm-core-4.2.3.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_6\Bin\xpm-core-4.2.3.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_7\Bin\xpm-core-4.2.3.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KIM\Client Module\libs\common\log4j-core-2.11.2.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KIM\Kim Assist\data\KIM_Client-Modul\libs\common\log4j-core-2.11.2.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KIM - Kopie\Client Module!\libs\common\log4j-core-2.11.2.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KIM - Kopie\Kim Assist\data\KIM_Client-Modul\libs\common\log4j-core-2.11.2.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\IV_Verwaltung\data\Data\doku\IQTIG\DPP\datenpruefprogramm-4.2.0-jar-with-dependencies.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ SADSMILEY
t:\turbomed\IV_Verwaltung\data\Data\doku\IQTIG\packer\TPacker-4.2.5-jar-with-dependencies.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\IV_Verwaltung\data\Data\doku\IQTIG\packer\XPacker-4.2.5-jar-with-dependencies.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
-- Problem t:\turbomed\Programm\aWinS\secsigner\SecSigner.jar!/certStack.zip - java.io.EOFException: Unexpected end of ZLIB input stream
-- Problem t:\turbomed\Programm\aWinS\secsigner\SecSigner.jar!/scdriver.jar - java.io.EOFException: Unexpected end of ZLIB input stream
-- Problem t:\turbomed\Programm\communicator\lib\h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
t:\turbomed\Programm\communicator\lib\log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
-- Problem t:\turbomed\Programm\communicator\plugins\CubePlugin\lib\h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
-- Problem t:\turbomed\Programm\communicator\plugins\CubePlugin.jar!/lib/h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
-- Problem t:\turbomed\Programm\communicator\plugins\DaleUVCommunication\lib\h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
-- Problem t:\turbomed\Programm\communicator\plugins\DaleUVCommunication.jar!/lib/h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
t:\turbomed\Programm\communicator\plugins\EVaccinationCertificateService\lib\log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\Programm\communicator\plugins\EVaccinationCertificateService.jar!/lib/log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
-- Problem t:\turbomed\Programm\communicator\plugins\MedDataPlugin\lib\h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
-- Problem t:\turbomed\Programm\communicator\plugins\MedDataPlugin.jar!/lib/h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
-- Problem t:\turbomed\Programm\communicator\SmartUpdateStandalone\lib\h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
t:\turbomed\Programm\communicator\SmartUpdateStandalone\lib\log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\Programm\communicator\updater\lib\log4j-core-2.6.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ SADSMILEY

--> geht auch hiermit über die Kommandozeile nur nicht so schön
findstr /s /i /c:"JndiLookup.class" C:\*.jar

Lt. CGM ist ja da Programm TM selbst nicht betroffen.
Ich prüfe die Abrechnung per Prüfmodul aktuell auf einem Stand-alone-Rechner.
Weiß jemand, ob auch DALE-UV eine Gefährdung bringt?? Wir versenden aktuell die Berichte per Post.
Gruß

Heilberger hat geschrieben:Lt. CGM ist ja da Programm TM selbst nicht betroffen.
Ich prüfe die Abrechnung per Prüfmodul aktuell auf einem Stand-alone-Rechner.
Weiß jemand, ob auch DALE-UV eine Gefährdung bringt?? Wir versenden aktuell die Berichte per Post.
Gruß

TurboMed ist nicht betroffen.
CGM ASSIST ist ja was Eigenständiges *hust*

DALE-UV ist betroffen, weil es über CGM ASSIST angebastelt ist.

CGM Kim und CGM SmartUpdate (Standalone) sind ja auch betroffen.. prinzipiell würde ich auf Aussagen von CGM nicht all zu viel geben.

ich habe mit einer Batch Datei einfach alle potenziellen "log4j*2.XX*jar" gegen die 2.16 ausgetauscht (alte Dateibennung wie vorher). Zumindest läuft Turbomed scheinbar auch so und man kann besser Nachts schlafen.. das "Update" dauert doch wieder bis 23.12... und dann sind wieder hundert neue Fehler eingebaut.

APC Business Edition ist übrigens auch betroffen, das hat vielleicht der ein oder andere auch drauf (USV).

Hat noch jemand bekommen, jetzt setz ich mich glaub doch hin und tausch dateien von hand aus.....

Landarzt21 hat geschrieben:Hat noch jemand bekommen, jetzt setz ich mich glaub doch hin und tausch dateien von hand aus.....

Na ein Glück ist ja CGM Turbomed nicht betroffen *Ironie aus*…

evtl. sollte man alle Fernwartungsstools von CGM entfernen?

Schorsch hat geschrieben:CGM Kim und CGM SmartUpdate (Standalone) sind ja auch betroffen.. prinzipiell würde ich auf Aussagen von CGM nicht all zu viel geben.

ich habe mit einer Batch Datei einfach alle potenziellen "log4j*2.XX*jar" gegen die 2.16 ausgetauscht (alte Dateibennung wie vorher). Zumindest läuft Turbomed scheinbar auch so und man kann besser Nachts schlafen.. das "Update" dauert doch wieder bis 23.12... und dann sind wieder hundert neue Fehler eingebaut.

APC Business Edition ist übrigens auch betroffen, das hat vielleicht der ein oder andere auch drauf (USV).

.. ich präzisiere meine Aussage.. das Update kommt am 23.12.2022!

Info der KV Bayern: Abrechnung kann wie bisher übersandt werden. Module der KVB seien von log4j nicht betroffen. Der Dienst Telemed ist heute nicht verfügbar. wir versenden unsere D-Berichte per Post!
Schöne Weihnachten!

Klingt unglaubwürdig.
Das KBV-Prüfmodul ist lt. CGM anfällig.
Und die neue Version kommt erst mit dem - sich verspätenden - Update.

Aber entspannt: Das Modul läuft lokal über die .CON und holt sich nichts aus dem Netz nach.
Und die wird sicherlich nicht kompromittiert sein, wenn PC und das ausgebende TurboMed sauber sind.

TurboMed schreibt ja am 17.12.21 folgendes:
„Von einer Abrechnung von Q4/2021 mit bereits ausgelieferten Versionen von CGM TURBOMED raten wir ab, da uns keine Informationen vorliegen, inwieweit die log4j-Schwachstelle bereits ausgenutzt und schadhafter Code in betroffene Software-Module eingeschleust wurde!“

Wir haben bereits vorletzte Woche Probeabrechnungen laufen lassen. Da wusste man noch nichts von der Sicherheitslücke. Könnte dadurch etwas passiert sein? Und wie bekäme man sowas heraus??

Bin besorgt …

Wir finden auf dem Server viele Java-Altlasten, die z.T. out-of-life sind. Erschreckend, dass TurboMed-Updates hier keine Routine zur Bereinigung anbieten. Hier müsste doch mal aufgeräumt werden, oder?

Ang. sind von der Lücke nur die Java-Versionen 2.0 bis 2.14.1 betroffen. Wo finde ich die Java-Version?? Ggf. sind die von TM im Rahmen der updates gelieferten Versionen ja älter?? Meinungen??

Unten im Windows Suchfeld Java eingeben - Java Konfigurieren - Java- Ansicht

Heilberger hat geschrieben:Ang. sind von der Lücke nur die Java-Versionen 2.0 bis 2.14.1 betroffen. Wo finde ich die Java-Version?? Ggf. sind die von TM im Rahmen der updates gelieferten Versionen ja älter?? Meinungen??

Wobei man anmerken muss, dass gerade bei Java die älteren Versionen reich gespickt mit Schwachstellen sind.

Grüße

lcer

Dann halt mal mit v22.1.1.5285 versuchen.

Kommando zurück: nur der Patch enthält die korrigierten log4j-Module, nicht das v22.1-Update.