Kritische Zero-Day-Lücke in Log4j gefährdet zahlreiche Server und Apps

[shiraz]

https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0095490

[CarstenH]

Stand 15.12.2021 - 6. Update: https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0095516

TLDR:

Aktuell sind nur bestimmte Versionen eines Produkts betroffen (siehe nachfolgende Liste).

The following product IS affected:

AppDev Pack versions 1.0.5 - 1.0.10

Im Folgenden werden (mehr oder weniger) alphabetisch alle bereits getesteten und nicht betroffenen Produkte aus der N/D Produktreihe aufgeführt:

Testing is still ongoing for all products for vulnerability to Log4Shell. HCL will update this bulletin as the situation progresses if any additional actions are required.
The following products are NOT affected:

Companion for iOS
Domino Administrator
Domino Designer and XPages
Domino Server
Domino Volt
Enterprise Integrator (HEI)
iNotes
Lotus Workflow
Nomad for web browsers
Nomad Mobile for iOS and Android
Notes Client
SafeLinx
Sametime Mobile for iOS and Android
ToDo for iOS
Traveler
Traveler for Microsoft Outlook (HTMO)
Verse
Verse Mobile for iOS and Android
AppDev Pack versions <1.0.5 and >1.0.10
Client Application Access (CAA)

The product list will be updated as soon as new information is found.

HTH
Carsten

[mind1]

Hallo zusammen,

ich habe mich schon gewundert, das das hier so ruhig ist heute und daraus geschlossen, dass es Domino nach jetzigem Wissensstand nicht betrifft.

HCL schreibt ja nur über BigFix Produkte:

https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0095486

Ich bin mir aber nicht ganz sicher, ob das auch gilt, wenn man diesen Apache (ihs) auf dem Server laufen hat.

[stoeps]

Log4j ist eine Java Bibliothek, der Apache HTTP Server (oder IBM HTTP Server) haben kein Java. Die werden "nur" von Apache gehostet/entwickelt. Der IHS ist ein rebrandeter Apache httpd  Also keine Gefahr, auch alle Apache 2.0 lizensierten Produkte haben nicht zwingend log4j an Board.

Die Advisories sind raus, für Connections gibt es Fixes von HCL und IBM. Domino ist nicht betroffen, Sametime weiss ich nicht, aber jitsi hat wohl log4j in der stats Komponente.

[CarstenH]

Ich habe obige Liste mal auf den neuesten Stand gebracht, aktuell scheint nur das AppDev Pack in den Version 1.0.5 - 1.0.10 betroffen zu sein. Update auf Version 1.0.11 schafft Abhilfe.

HTH
Carsten

[AxelSchmidt]

Hallo zusammen...

HCL gibt hier keine Versionen an.
Daher gehe ich mal dvon aus, dass die Aussage nur auf die aktuellen Versionen bezieht, oder?

Wie sieht es denn mit den älteren Domino/Traveler Versionen aus?
9.0 oder sogar 8.5
weiß jemand ob diese von der Sicherheitslücke betroffen sind?

Gruß
Axel

[eknori]

Hallo zusammen...

HCL gibt hier keine Versionen an.
Daher gehe ich mal dvon aus, dass die Aussage nur auf die aktuellen Versionen bezieht, oder?

Wie sieht es denn mit den älteren Domino/Traveler Versionen aus?
9.0 oder sogar 8.5
weiß jemand ob diese von der Sicherheitslücke betroffen sind?

Gruß
Axel

Kein offizielles Statement von meiner Seite; lediglich meine eigene Einschätzung.

Domino ist NICHT Java basiert; Domino ist C/C++. Von daher sehe ich nicht, wo da log4j ins Spiel kommt.
 
Traveler verwendet java.util.logging via SLF4J.

SLF4J ist lediglich eine API zur Ansteuerung unterschiedlicher logging frameworks, und daher nicht von log4shell betroffen http://slf4j.org/log4shell.html

Daher sehe ich auch hier kein Problem.

[Agrion]

Hallo zusammen,
ich mach mir doch etwas Sorgen. Wir haben den IBM Notes-Client 9.0.1 installiert und im Verzeichnis
  C:\Program Files (x86)\IBM\Notes\framework\shared\eclipse\plugins
finde ich die Datei
  org.apache.log4j_1.2.13.v200806030600.jar
Zur Zeit wird überlegt vom Standard-Client (mit Eclipse) auf den Basic-Client (ohne Eclipse) zurüch zu setzen.
Ist das übertrieben? Was denkt ihr?

LG
Ragna

[eknori]

Das ist die Version 1.x, die nicht betroffen ist, weil sie schlicht und ergreifend die angreifbaren Komponenten nicht enthält.

Ich glaube, ihr habt das Szenario auch nicht wirklich verstanden. Ziel ist es doch einen Zugang auf ein Rechnersystem zu bekommen. Das macht man vorzugsweise von ausserhalb der Organisation. Wenn ich dazu den Notes Client benutze, muss ich als Hacker schon ziemlich hackedicht sein. Ich bin ja schon auf dem Rechner in der Organisation …

ja, euer Vorgehen ist übertrieben und blinder Aktionismus.

[Tode]

Nur um das nochmal klarzumachen @Agrion: Die Log4j- Lücke kann dazu verwendet werden, remote- Code auszuführen, indem man einen Protokoll- Eintrag generiert, der bestimmte Tags enthält.

Dieser Angriff ergibt nur Sinn, wenn ich einen Service habe, den ich erreichen kann, und den ich über ein Eingabefeld oder irgendeine andere Eingabemöglichkeit Text unterschiebe, der durch Log4J protokolliert wird und dabei interpretiert wird und den Remote- Code nachlädt mit dem dann böse Dinge gemacht werden.

Warum ist also das Vorhandensein einer log4j.jar im Notes- Client per se kein Problem:

1. Der Client bietet keinerlei von außen ansprechbaren Service an... um an den Client zu kommen, muss ich schon auf der Maschine sein, und dann habe ich sicher bessere Angriffsvektoren, als den Client dazu zu bringen von irgendwo Remote Code runterzuladen...
2. Selbst WENN der Client einen Service (z.B. den lokalen http Task) anbieten würde, dann müsste erstmal eine darüber ansprechbare Funktion die LOG4J- Schnittstelle BENUTZEN, und diese müsste auch noch in irgendeiner Form Benutzerinput entgegennehmen und protokollieren, nicht jede Benutzung von Log4J ist automatisch gefährlich....

ALSO: vollkommen übertrieben, der Notes- Client ist für diesen Exploit definitiv kein lohnendes Ziel (und wegen der falschen Version eben gar kein Ziel)

[Agrion]

Hallo,
@Tode, @eknori
danke für eure Hinweise.
Eure Erläuterungen haben mir dann doch sehr geholfen