MediathekView Logo

    MediathekView-Forum

    • Registrieren
    • Anmelden
    • Suche
    • Kategorien
    • Aktuell
    • Tags
    • Beliebt
    • Benutzer
    • Gruppen

    Ist Log4Shell ein Problem?

    Entwicklerforum
    6
    14
    1107
    Lade mehr Beiträge
    • Älteste zuerst
    • Neuste zuerst
    • Meiste Stimmen
    Antworten
    • In einem neuen Thema antworten
    Anmelden zum Antworten
    Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
    • E
      ElektrOpa zuletzt editiert von MenchenSued

      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?

      styroll 1 Antwort Letzte Antwort Antworten Zitieren
      • jkrieger
        jkrieger zuletzt editiert von

        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…

        D 1 Antwort Letzte Antwort Antworten Zitieren
        • D
          DerReisende77 Entwickler @jkrieger zuletzt editiert von

          @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.

          Open source developers do NOT have to:

          • Make your issue a priority, just because you say so.
          • Give you any sort of "timetable", or explanation for why it´s "taking too long".

          Check your entitlement. Nobody owes you anything.

          jkrieger H 2 Antworten Letzte Antwort Antworten Zitieren
          • jkrieger
            jkrieger @DerReisende77 zuletzt editiert von

            @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>

            D 1 Antwort Letzte Antwort Antworten Zitieren
            • D
              DerReisende77 Entwickler @jkrieger zuletzt editiert von

              @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.

              Open source developers do NOT have to:

              • Make your issue a priority, just because you say so.
              • Give you any sort of "timetable", or explanation for why it´s "taking too long".

              Check your entitlement. Nobody owes you anything.

              1 Antwort Letzte Antwort Antworten Zitieren
              • styroll
                styroll @ElektrOpa zuletzt editiert von 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?

                Screenshot_ 2021-12-13 at 13.37.01.png

                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.

                1 Antwort Letzte Antwort Antworten Zitieren
                • Von Fragen verschoben durch  MenchenSued MenchenSued 
                • H
                  hufnala @DerReisende77 zuletzt editiert von

                  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

                  D 2 Antworten Letzte Antwort Antworten Zitieren
                  • D
                    DerReisende77 Entwickler @hufnala zuletzt editiert von

                    @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 :D

                    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.

                    Open source developers do NOT have to:

                    • Make your issue a priority, just because you say so.
                    • Give you any sort of "timetable", or explanation for why it´s "taking too long".

                    Check your entitlement. Nobody owes you anything.

                    1 Antwort Letzte Antwort Antworten Zitieren
                    • D
                      DerReisende77 Entwickler @hufnala zuletzt editiert von

                      @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? :D

                      Open source developers do NOT have to:

                      • Make your issue a priority, just because you say so.
                      • Give you any sort of "timetable", or explanation for why it´s "taking too long".

                      Check your entitlement. Nobody owes you anything.

                      H 1 Antwort Letzte Antwort Antworten Zitieren
                      • H
                        hufnala @DerReisende77 zuletzt editiert von

                        @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

                        D 1 Antwort Letzte Antwort Antworten Zitieren
                        • D
                          DerReisende77 Entwickler @hufnala zuletzt editiert von

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

                          Open source developers do NOT have to:

                          • Make your issue a priority, just because you say so.
                          • Give you any sort of "timetable", or explanation for why it´s "taking too long".

                          Check your entitlement. Nobody owes you anything.

                          codingPF 1 Antwort Letzte Antwort Antworten Zitieren
                          • codingPF
                            codingPF @DerReisende77 zuletzt editiert von

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

                            H D 2 Antworten Letzte Antwort Antworten Zitieren
                            • H
                              hufnala @codingPF zuletzt editiert von

                              @codingpf
                              Für mich dann nicht - Danke!

                              //hufnala

                              1 Antwort Letzte Antwort Antworten Zitieren
                              • D
                                DerReisende77 Entwickler @codingPF zuletzt editiert von

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

                                Open source developers do NOT have to:

                                • Make your issue a priority, just because you say so.
                                • Give you any sort of "timetable", or explanation for why it´s "taking too long".

                                Check your entitlement. Nobody owes you anything.

                                1 Antwort Letzte Antwort Antworten Zitieren
                                • 1 / 1
                                • Erster Beitrag
                                  Letzter Beitrag

                                59
                                Online

                                5.6k
                                Benutzer

                                5.1k
                                Themen

                                33.1k
                                Beiträge

                                Betrieben mit NodeBB - Impressum