Sonstiges > Offtopic

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

<< < (2/3) > >>

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 (retired):

--- Zitat von: AxelSchmidt am 16.12.21 - 08:17:28 ---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

--- Ende Zitat ---

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 (retired):
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)

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete