Ist Log4Shell ein Problem?

[ElektrOpa]

Da MedithekView ja Java verwendet, besteht bei Nutzung die Gefahr, dass man mit dem aktuellen Problem der Java Bibliothek Log4i, vor dem das BSI warnt, konfrontiert wird? Anders gefragt, kan man zur Zeit unter diesem Gesichtspunkt MediathekView bedenkenlos weiter nutzen?

[jkrieger]

Siehe z.B. heise

• Einfache Frage: Wo wird überall Log4j verwendet?

• Schwerere Frage: Ist da irgendwo ein (realistisches) Angriffsszenario zu konstruieren?
  Also z.B. nicht durch Angriff seitens der Sender…

[DerReisende77]

@jkrieger

Einfache Antwort: Überall innerhalb MediathekView client, da ich damit in das logfile schreibe (lokal).

Schwerere Antwort:

• Nein, IMHO gibt es kein realistisches Szenario. Nichtsdestotrotz wird in der nächsten Version (wie ich es auch davor schon immer gemacht habe) die jeweils aktuellste Version der Libraries verwendet. So wird auch die gepatchte Version dann genutzt und nicht die veralteten.
  Ausführlichere Antwort:
  Gemäß dieser Beschreibung werden folgende Voraussetzungen benötigt:

• A server with a vulnerable log4j version (listed above),
• an endpoint with any protocol (HTTP, TCP, etc) that allows an attacker to send the exploit string,
• and a log statement that logs out the string from that request.

• MediathekView ist ein Client, kein Server -> Punkt 1 nicht erfüllt
• MediathekView bietet nach außen keinen „endpoint“ um böse log strings zu empfangen -> Punkt 2 nicht erfüllt
• da ich keinen endpoint anbiete und somit nichts empfangen kann, kann ich auch nichts bösartiges schreiben.

Von daher sehe ich kein Risiko.

[jkrieger]

@derreisende77 sagte in Ist Log4Shell ein Problem?:

Einfache Antwort: Überall innerhalb MediathekView client, da ich damit in das logfile schreibe (lokal).

Schwerere Antwort:

• Nein, IMHO gibt es kein realistisches Szenario. Nichtsdestotrotz wird in der nächsten Version (wie ich es auch davor schon immer gemacht habe) die jeweils aktuellste Version der Libraries verwendet. So wird auch die gepatchte Version dann genutzt und nicht die veralteten.

Danke, das hilft sicher.

Gemäß dieser Beschreibung werden folgende Voraussetzungen benötigt:

• A server with a vulnerable log4j version (listed above),
• an endpoint with any protocol (HTTP, TCP, etc) that allows an attacker to send the exploit string,
• and a log statement that logs out the string from that request.

• MediathekView ist ein Client, kein Server -> Punkt 1 nicht erfüllt
• MediathekView bietet nach außen keinen „endpoint“ um böse log strings zu empfangen -> Punkt 2 nicht erfüllt
• da ich keinen endpoint anbiete und somit nichts empfangen kann, kann ich auch nichts bösartiges schreiben.

Von daher sehe ich kein Risiko.

Leider glaube ich, dass Klienten durchaus auch anfällig sind, wenn sie nur einen Server benutzen, der kompromittiert sein könnte, und von diesem Server Daten loggen.

Im (nicht-debug-)MV-Log sehe ich allerdings nichts außer Titeln und URLs aus den MV-Server-Daten. Solange also weder die MV-Server noch die öffentlich-rechtlichen kompromittiert sind, sollte nichts passieren.

<OT> Die Voreinstellung von Log4j, die zu protokollierenden Daten für (evtl. entfernte) Formatierung zu verwenden, halte ich allerdings für völlig bekloppt. Ähnlich klug war es früher, bei printf die (externen) Daten als Formatstring zu verwenden… </OT>

[DerReisende77]

@jkrieger wenn jemand die offiziellen downloads mit Java 17 verwendet sollte es kein Risiko geben (siehe dazu Hier. Manchmal hat es auch Vorteile im Gegensatz zu kommerziellen Anbietern mal state of the art zu nutzen. Aber es wird wie gesagt aktualisiert werden.

[styroll]

@elektropa sagte:Anders gefragt, kan man zur Zeit unter diesem Gesichtspunkt MediathekView bedenkenlos weiter nutzen?

Oder auch anders gefragt, könnte man nicht wenigstens die Überschriften der letzten 2 Threads lesen, bevor man selbst einen neuen eröffnet?

EDIT:
So ergibt das Merging von Posts natürlich keinen Sinn, wenn die chronologische Abfolge nicht mehr stimmt. Das wäre ja mal ein Thread gewesen, denn man sperren hätte können, da es in selber Sache schon einen Thread gibt. Dafür werden wieder andere Threads grund- und wahllos gesperrt. Okay, nichts Neues hier im Forum, aber ein konsistentes (und kompetentes) Vorgehen wäre ja schon mal schön, so nach bald 5 Jahren, seit es dieses Forum gibt.

[hufnala]

Hallo zusammen,

ja ich habe das hier bisher auch so verstanden,
@derreisende77 sagte in Ist Log4Shell ein Problem?:

MediathekView ist ein Client, kein Server -> Punkt 1 nicht erfüllt

aber auch das hier über https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 gefunden:
https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/
“Targets: Servers and clients that run Java and also log anything using the log4j framework - primarily a server-side concern, but any vulnerable endpoint could be a target or a pivot point
Downstream projects: until proven otherwise, assume anything that includes log4j - including Elasticsearch, Apache Struts / Solr / Druid / Flink, etc. - is affected in a way that requires mitigation; see below”

Die 1. Quelle wird auch hier https://www.lsi.bayern.de/aktuelles/meldungen/20211213_log4j/ zitiert, ordne ich also erst mal als sinnvoll ein.

Es gibt zumindest eine Öffentliche Organisation (Sorry Insiderwissen - daher hier keine Details) die hat heute FF auf einem VirtualDesktop für die Nutzer mit dem Verweis auf log4j gesperrt.
Ein anderer Browser blieb wohl verfügbar.

Braucht es wirklich einen Server, oder sind da driveby Downloads auch im normalen Stream denkbar die über den Browser aufschlagen, wenn Java/log4j dort laufen dort ankommen und die ganze Chose dann im Browser / User Kontext weiterläuft?

Habe da vorhin mal versucht weiterzudenken, was das z.B. für die Daten auf meinem gerade gemappten DAVFS-Nextcloud Drive bedeutet wenn mein Broswer (mit meinen User-Rechten) irgendwas zu verschlüsseln - der Schaden wäre schnell unübersichtlich / aufwändig zu beheben - backups hin oder her

Und ja, mir ist selber nicht wohl bei der Frage, Alu-Hut besitze ich keinen…

//hufnala

[DerReisende77]

@hufnala Log4Shell ist mit 13.8.1 definitiv kein Problem mehr.
Und für Version 13.8.1 und kleiner ist es esoterik darüber zu philosophieren ob MV betroffen ist oder nicht. Ich habe hierzu meine Punkte geäußert und das Thema ist für mich erledigt. Wir haben ein Szenario gefunden wo log4shell aktiviert hätte werden können. Dies setzte aber voraus das der User am Rechner den String in ein Textfeld kopiert. Wer das mutwillig macht braucht kein log4shell, der hat den Touristen schon vor Ort um Dinge zu erledigen

Und zum Thema öffentliche Institutionen: Auch ich kenne eine die heute ihre WLAN-Router wegen log4shell deaktiviert hat -> weil auf denen in der Regel auch ein Java läuft…ohne Worte.

[DerReisende77]

@hufnala sagte in Ist Log4Shell ein Problem?:

Es gibt zumindest eine Öffentliche Organisation (Sorry Insiderwissen - daher hier keine Details) die hat heute FF auf einem VirtualDesktop für die Nutzer mit dem Verweis auf log4j gesperrt.
Ein anderer Browser blieb wohl verfügbar.

Lass mich raten: Internet Explorer 11 wird als Alternative angeboten?

[hufnala]

@derreisende77

Hi, ich wollte niemandem zu nahe treten, oder irgendwas bzgl. mv herbeireden, sondern habe nur gefragt. Und nein es war edge, nicht IE…, soweit ich weiß aktuell gepatcht. Über MS kann man ja denken was man will, verbreitet ist das, und die Paarung hätte ich auch anders herum nicht verstanden - außer dass der Client einen Einfluss hat. Bei mir im log taucht auch curl auf, was sich wohl mehr oder minder als http endpunkt beschreiben lassen dürfte, oder?

BTW: ich nutze “nur” den Kodi client, hoffe mal der ist auch aktuell oder anders aufgebaut…

Also nochmal danke!
//hufnala

[DerReisende77]

@hufnala zum kodi plugin kann @codingPF was sagen, das ist nicht meine Baustelle

[codingPF]

@derreisende77 …Kodi ist C und Python…ist mir nicht ganz klar wo das relevant ist…

[hufnala]

@codingpf
Für mich dann nicht - Danke!

//hufnala

[DerReisende77]

@codingpf naja mir war das schon klar, aber eine Antwort aus berufenem Munde hierzu ist doch immer schön 🤪