Frage zu Log4J Problem

[Lemmy]

Servus,

wenn ich ein Jar habe, das "nur" auf meinem Rechner liegt, das jar aber nicht aktiv ausgeführt wird. Dort ist aber definitiv eine alte Log4J drin, dann kann doch diese Lücke nur dann ausgenutzt werden, wenn ich auf meinem Rechner ein Programm ausführe, das dann nach angreifbaren jar sucht. Wobei dann müsste das Programm ja noch die Jar ausführen?!?

Oder kann das Programm dann "lediglich" das kaputte Log4J aus dem Jar aktivieren und ausnutzen?

Grüße

P.s: mir ist klar, dass ich schon dann ein Problem habe, wenn ich ein unerwünschtes Programm auf meiner Kiste ausführe....

[himitsu]

Das ist egal.

Wenn das "böse" Programm bereits auf deinem Rechner läuft und Rechte hat diese Datei im Java auszuführen, dann braucht es diese Sicherheitslücke nicht mehr, weil es dann auch gleich direkt auf alles Zugriff haben würde,
bzw. es könnte auch seinen eigenen Code für Log4J mitbringen und braucht deine Datei garnicht.

[mjustin]

Zitat:

Zitat von Lemmy (Beitrag 1499226)

Servus,

wenn ich ein Jar habe, das "nur" auf meinem Rechner liegt, das jar aber nicht aktiv ausgeführt wird. Dort ist aber definitiv eine alte Log4J drin, dann kann doch diese Lücke nur dann ausgenutzt werden, wenn ich auf meinem Rechner ein Programm ausführe, das dann nach angreifbaren jar sucht.

Der passende Vergleich wäre ein Virus (in der Biologie): solange ein Virus nur so herumliegt, ist es ungefährlich. Erst wenn es in einer Umgebung ist in der sein DNA oder RNA Code 'ausgeführt' wird, kann es sich in seinem Wirt vermehren. (Also ja.)

[Phoenix]

Dazu kommt, das das Problem ja nur auftritt, wenn bestimmte Texte in den Platzhaltern der Lognachrichten mittels log4j gelogged werden.
Konkret: Loggt das Java-Programm nur statische Texte mit z.B. Datum und Zahlen, hast Du kein Problem. Nur wenn das Ding externe Eingaben loggt, und jemand so einen {jndi:ldap://url} - Text ins das Log reinbringt, DANN wird der Code hinter der Adresse nachgeladen und ausgeführt.

[Lemmy]

Danke für die Antworten.
Das Problem ist: Das teil ist nicht von mir, keinen Plan was das Ding so treibt und was wohin geschrieben wird.
Allerdings haben "wir" das halt an unsere Kunden ausgeliefert (ausliefern müssen) und jetzt stelle ich mir die Frage ob es nicht schlauer wäre, das Zeugs von den Kundenrechnern zu putzen, wenn wir die aktuelle Version ausliefern....

[sakura]

Zitat:

Zitat von Lemmy (Beitrag 1499234)

das Zeugs von den Kundenrechnern zu putzen, wenn wir die aktuelle Version ausliefern....

Definitiv, und mit einem Flammenwerfer hinterher alles reinigen.

...:cat:...

[hoika]

Hallo,
von der KBV gibt es mittlerweile neue Versionen vom Prüfmodul und Kryptomodul.
Falls es darum geht ...

[Rollo62]

Zitat:

Zitat von Lemmy (Beitrag 1499234)

... das Zeugs von den Kundenrechnern zu putzen, wenn wir die aktuelle Version ausliefern....

Gute Frage: Wie findet und bereinigt man das Log4J Problem am Besten und Einfachsten ?
Durch einfache Filesuche, oder gibt es von MS oder anderso schon Scanner ?
Wie findet und beseitigt das auf Apache-Servern und/oder NAS-Systemen ?

[Bernhard Geyer]

Zitat:

Zitat von sakura (Beitrag 1499243)

Zitat:

Zitat von Lemmy (Beitrag 1499234)

das Zeugs von den Kundenrechnern zu putzen, wenn wir die aktuelle Version ausliefern....

Definitiv, und mit einem Flammenwerfer hinterher alles reinigen.

...:cat:...

Wenn man von einem erfolgreichen Angriff ausgeht, wäre der Rechner neu aufzusetzen.
Also das "putzen" als ersten Schritt unnötig.

[Lemmy]

Zitat:

Zitat von hoika (Beitrag 1499245)

Hallo,
von der KBV gibt es mittlerweile neue Versionen vom Prüfmodul und Kryptomodul.
Falls es darum geht ...

ähm.. Ja.. aber halt "nur" für Q1-2022 und glaube Q4-2021. Aber der Rest halt nicht :-) Und die KBV empfiehlt inzwischen selbst die Entfernung bzw. die Ausführung in einer sicheren Umgebung...

https://update.kbv.de/ita-update/Ank..._Log4j_FAQ.pdf