News Sonntagsfrage: Eine Woche Log4Shell, was hat das für dich bedeutet?

[foo_1337]

Welcher Paketmanager upgraded das kaputte log4j Paket auf dem System?

Keiner auf dem System, es macht der maven build und danach die CI/CD Pipeline.
Leider hast du meine Frage noch nicht beantwortet bzw. völlig ignoriert. Wenn du dich im Software Development nicht so auskennst, ist das auch kein Problem. Aber dann mache keine unpraktikablen Vorschläge.
Ich weiß, du würdest das gerne irgendwie per deb, rpm etc. abfrühstücken. Aber das funktioniert so nicht.

 

[Moep89]

@poly123

Vielen Dank für die Info, aber das ist genau das, was für Nicht-Programmierer, Nicht-Sysadmins etc. weitestgehend Böhmische Dörfer sind. Mit Reverse-Proxies, Classes oder ähnlichem habe ich nichts zu tun bzw. keine Ahnung ob. Bei Software bin ich reiner Nutzer, bei Hardware sieht es anders aus.
Daher fehlt genau für diese, absolut größe, Nutzergruppe eine verständliche Vorgehensweise. In wie fern "normale" Software (Steam, Games, Office etc.) da betroffen sein könnte, entzieht sich völlig meiner Kenntnis. So'n paar Dinge wie der JDownloader kann ich mir noch vorstellen (er ist laut denen NICHT betroffen), aber beim Rest?

 

[wayne_757]

Wenn du dich im Software Development nicht so auskennst, ist das auch kein Problem. Aber dann mache keine unpraktikablen Vorschläge.

Kenne mich mit vielen Sprachen und deren Eigenheiten nicht aus, unter anderem Java.
Wenn ich aber um einen Bug in einer Basislib zu beheben, alle Pakete im Dependency Graph neu bauen muss, ja dann ist das einer der größten Designfalls die man sich so erlauben kann. Aber es passt auf jeden Fall gut in mein Bild von Java.

 

[kugel.]

Auf GitHub existiert eine Liste betroffener Anwendungen, die inzwischen über 100 Einträge zählt.

In der Liste sind offensichtlich nicht nur betroffene Anwendungen enthalten. Bspw. wird zwar 7zip genannt, aber wenn man dem Link folgt, dann landet man beim issue tracker, wo nach Nachfrage die Anfälligkeit explizit verneint wird, weil 7zip überhaupt keine Java-Bestandteile hat. Gleiches gilt für 1Password und Nextcloud.

Scheint mir eher ne Sammlung für Anwendungen zu sein, die schon abgeklopft wurden, unabhängig vom Ergebnis.

 

[poly123]

@Moep89 BSI im Auge behalten.

Allg. ganz nützlich: https://github.com/hillu/local-log4j-vuln-scanner

 

[foo_1337]

Wenn ich aber um einen Bug in einer Basislib zu beheben, alle Pakete im Dependency Graph neu bauen muss, ja dann ist das einer der größten Designfalls die man sich so erlauben kann.

Magst du es nicht verstehen? Das Prinzip von shared objects und dagegen zu Linken gibt es so nur bei C/C++. Du kannst das Prinzip nicht auf PHP, Javascript, Java, Rust und sonstwas anwenden. Es geht einfach nicht. Genau daher gibt es ant, maven, npm, composer, yarn usw. Das Paket- und Dependency Management findet beim Build statt.
Auf das Target werden dann alle Artefakte deployed. Idealerweise via Pipeline.

Was machst du denn, wenn jetzt z.B. jQuery (kennst du ja vielleicht, ist ja kein Java) eine Lücke hat? Alle Verzeichnisse und Dateien nach der potentiellen Nutzung von jQuery abgrasen? Oder hoffst du etwas, dass man jQuery via $DISTRO Paketmanager installiert, auf magische weise einbindet und dann updated? So läuft das nicht

 

[elgorro]

Ich bin nun wirklich kein DAU, aber mit Programmierung habe ich einfach nichts am Hut. Von daher ist es selbst für einen Nerd und IT-ler in meinem Fall völlig undurchsichtig OB mich das nun betrifft oder nicht. Ich habe beim Routerhersteller (AVM) geschaut und der sagt "Alles gut", der Hersteller meiner NAS-Systeme sagt ebenfalls "Bei uns ist nichts". Damit war's das für die offensichtlichen Dinge. Ob irgendwelche andere Software das nutzt? Keinen blassen Schimmer und trotz einiger Sucherei im Netz nach einfachen und klaren Hinweisen, weiß ich es nach wie vor nicht. Da fehlt mir wirklich die klare Ansage WAS genau da praktisch los ist (theoretisch weiß ich was das "Problem" ist), WO es relevant ist und WIE ich reagieren muss. Dafür, dass es anscheinend so dermaßen kritisch ist, gibt es erstaunlich wenige klare Ansagen, nur Geschwurbel und "Fragen Sie beim Hersteller Ihrer Software nach". Na klar, ich liste erstmal alle Software, Apps, Pakete etc. pp. auf, die ich irgendwo auf irgendwelchen Geräten im ganzen Haus habe und versuche dann deren Hersteller zu erreichen

Von daher fehlt mir auch ganz klar die Antwort: "Keine Ahnung, sagt Ihrs mir"

Was? In ungünstiger Konstellation einfach alles.
Wo? Da wo Log4j2 im Einsatz ist (bzw. war).
Wie? Da alles passieren kann, ist das keine einfache Antwort und es wird an Lösungen gearbeitet. Inwieweit Privat-Nutzer und -Systeme direkt kompromietiert werden, lässt sich nur schwer abschätzen. Indirekt in den Clouds läuft ja schon einiges - vorallem von Unternehmen.
https://www.wired.com/story/log4j-log4shell/ https://t3n.de/news/log4shell-problem-fuer-jahre-1437990/ Experten gehen von mehreren Jahren aus.

 

[fdsonne]

@fdsonne Es ging bei den Beispielen darum, dass eben viele tomcat servelets l4j nutzen, auch wenn es nicht der default ist. Das ist auch bei jira und confluence der Fall, auch wenn es bei denen Version 1.x ist. Bitbucket z.B. nutzt 2.x. Bei vmware meinte ich den vcd, der auch tomcat mit log4j (auch 1.x) nutzt.

Du, mir ist das bewusst, aber es wäre meiner Ansicht nach hilfreich die entsprechenden "Kinder" auch direkt beim Namen zu nennen. Vor allem wenn du dann weiter oben mit der Aussage kommst, dass dich Leute nerven, die einfach reinplatzen und meinen, dem zeig ichs jetzt... Wie in #127 beschreiben. Deine Aussagen sind halt in Teilen "angreifbar", weil sie eben sagen wir, missverständlich und in Teilen eben Interpretierbar sind. Dann hört das nämlich wahrscheinlich auch auf, dass da wer meint, das wäre alles falsch und man muss seinen Senf zu geben, weil wer das eben anders interpretiert.

Als konkretes Beispiel. Erst sagst du VMware, auf meine Nachfrage jetzt vCD. Der vCD Storage Extension ist halt trotzdem betroffen und wurde per Patch gefixt und vorher per Workaround umgangen.
Bei Atlassian ähnlich. Atlassian schreibt, der Bitbucket Server und die Datacenter Version dessen ist betroffen. Der Rest nutzt nen 1.2er Fork ist wäre nur betroffen von der 44228er Geschichte, wenn man die Settings manuell entsprechend verbiegt. Sowas taugt halt meiner Ansicht nach als gewichtiges Beispiel für ein Gegenargument nicht, wenn es dann wieder nur auf einen kleinen Teil zutrifft. Kein anderes Atlassian Produkt außer besagtem Bitbucket ist für 44228 anfällig, sofern ich das richtig sehe... Du/ihr kamt ja argumentativ davon, dass oben wer permanent meinte, dass seine Kunden das nicht haben das Problem - in so manchem Beispiel, trotz das da Log4J drin ist, ists halt dennoch zumindest in der Form dann doch nicht so wirklich ein Problem. Das hättet ihr euch komplett ersparen können mit der Diskussion, wenn ihr da konkret geworden wärt und nicht um den heißen Brei (Argumenten mit Herstellern oder Gruppen von irgendwas) gesprochen hättet

Aber das ist nur meine Ansicht - deinen Standpunkt unterschreibe ich zumindest bis auf das Detail quasi vollständig

Na klar, ich liste erstmal alle Software, Apps, Pakete etc. pp. auf, die ich irgendwo auf irgendwelchen Geräten im ganzen Haus habe und versuche dann deren Hersteller zu erreichen

Von daher fehlt mir auch ganz klar die Antwort: "Keine Ahnung, sagt Ihrs mir"

Auch wenn du es nicht hören willst - exakt das wäre das sinnigste. Privat wird dir keiner die Arbeit abnehmen. Das Motto ist da jetzt eher, entweder du vertraust auf Andere, die dir sagen was Phase ist oder du guckst selbst. Da aber Niemand garantiert weis, was du nutzt, welche Software, welche Hardware, ... -> da gibts quasi nur eine Antwort

Es gibt ein paar durchaus brauchbarer Github Projekte mit kleinen Scripten oder Tools, die den Spaß "suchen". Zumindest PCs und Geräte mit Zugriff auf das Filesystem bekommst du damit halbwegs verlässlich gescannt. Der Rest wird um längen schwieriger. Aber im Zweifel muss man halt einfach schauen. Wenn ich alles abziehe wo ich direkt oder indirekt Zugriff auf das Filesystem habe, bleibt nicht mehr soooo viel übrig. Das kann ich meiner Ansicht nach durchaus dann manuell über Herstelleranfragen bzw. Security Advisory Suche im Netz analysieren.

Ich für meinen Teil mache mir bei sowas halt viel eher Sorgen um den ganzen IoT Blödsinn. Irgendwelche Gerätschaften, die irgendwo in der Ecke liegen und irgendwas machen, Softwarestände von Anno Knips und wegen genau solchen Lücken Tür und Tor in interne Netze auf machen...

 

[ModellbahnerTT]

Natürlich wirds immer den einen Kunden geben, der da irgendwie nen Bogen um alle Sachen rumgemacht hat.

Der dafür aber in die nächste Falle tappt und sich etwas sicherer fühlt oder noch nicht erkannt hat das er auch betroffen ist.

 

[xexex]

Der dafür aber in die nächste Falle tappt und sich etwas sicherer fühlt oder noch nicht erkannt hat das er auch betroffen ist.

Kein Produkt ist vom Grundsatz her sicher. Das Problem bei der Java Lücke ist aber vor allem, wie Java normalerweise zum Einsatz kommt, da werden einfach mit irgendeinem Programm, diverse Komponenten irgendwo auf das System "hingerotzt". Hier mal am Beispiel "Megaraid Storage Manager":

Das Zeug pflegt niemand, aktualisiert niemand und daran denkt meist auch niemand. Ganz anders sieht es bei Software die zum Beispiel VC++ einsetzt, die Runtimes werden dann einfach über Windows Update gepflegt.

Zum Glück, wie ich bereits angemerkt habe, verzichten die Hersteller in der letzten Zeit allesamt auf Java. Das hilft aber natürlich bei alten Installationen wenig, wobei zum Glück solche Programme meist sowieso nicht aus dem Netz erreichbar sind und somit nur bedingt anfällig sind.

 

[Marflowah]

Es wurde zwar schon erwähnt, aber die "Liste der betroffenen Anwendungen" ist völlig für den Popo. Siehe Beitrag #164 von @kugel.

 

[Jesterfox]

Ich verstehe das Ganze nicht so ganz. Besteht für mich als User auf normalen Websiten da ein Risiko?

Die Möglichkeit dass die Webseite kompromittiert wurde und daher evtl. Schadcode ausliefert oder deine Daten die du dort hast abhanden kommen wurde ja schon genannt.

Ansonsten betrifft dich die Lücke wenn du Software nutzt die log4j verwendet, bekanntestes Beispiel dafür ist ja bisher Minecraft. Da ist wohl auch der Client betroffen, man kann also über die Lücke am Server auch alle Spieler angreifen.

Ergänzung (19. Dezember 2021)

Das Zeug pflegt niemand, aktualisiert niemand und daran denkt meist auch niemand. Ganz anders sieht es bei Software die zum Beispiel VC++ einsetzt, die Runtimes werden dann einfach über Windows Update gepflegt.

Aber auch nur die Runtime, was mit der JRE vergleichbar wäre. Wenn jemand irgend welche weiteren C++ Libs verwendet dann werden die nicht darüber gepflegt sondern liegen genauso im Programmverzeichnis.

 

[xexex]

Wenn jemand irgend welche weiteren C++ Libs verwendet dann werden die nicht darüber gepflegt sondern liegen genauso im Programmverzeichnis.

Das ist so nur halb korrekt, seit Windows Vista nutzt Windows WinSxS und hat Kenntnis über alle irgendwo im System verteilten und möglicherweise veralteten Komponenten.
https://docs.microsoft.com/de-de/wi...op/manage-the-component-store?view=windows-11

Der Punkt an dieser Stelle ist aber, dass zumindest die Software die ich kenne, bei der Installation die benötigten VC++ Runtimes installiert und nicht irgendwo in den Programmordner hinrotzt, bei Java Software war aber bis vor kurzem das Gegenteil der Fall. Erst mit den ganzen Änderungen an den Java Lizenzbedingungen und der Einstellung von Java Web Start, haben die Hersteller Java sterben lassen.

 

[wayne_757]

Magst du es nicht verstehen? Das Prinzip von shared objects und dagegen zu Linken gibt es so nur bei C/C++. Du kannst das Prinzip nicht auf PHP, Javascript, Java, Rust und sonstwas anwenden.

Rust kann shared objects erzeugen (https://doc.rust-lang.org/reference/linkage.html) also gehe ich mal davon aus, dass es auch selbst dagegen linken kann. In Python installiert man sich auch Pakete über pip und verwurstet nicht alles in sein Paket. Das man also shared dependencies transparent nur bei C oder C++ austauschen könnte stimmt so nicht.

Das Paket- und Dependency Management findet beim Build statt.
Auf das Target werden dann alle Artefakte deployed.

Sowas funktioniert dann noch halbwegs solange man die Hoheit über alle Pakete hat, aber wehe da wird was zugeliefert. Dann heißts:

Das Zeug pflegt niemand, aktualisiert niemand und daran denkt meist auch niemand. Ganz anders sieht es bei Software die zum Beispiel VC++ einsetzt, die Runtimes werden dann einfach über Windows Update gepflegt

 

[Jesterfox]

@xexex : nur bei Komponenten die tatsächlich als SxS Paket vorliegen. Ich hab jetzt einfach mal bei Qt geschaut weil mir das als erstes einfiel: das kann man entweder statisch linken oder shared Libs verwenden, die aber nicht im WinSxS landen...

 

[codengine]

Kenne mich mit vielen Sprachen und deren Eigenheiten nicht aus, unter anderem Java.
Wenn ich aber um einen Bug in einer Basislib zu beheben, alle Pakete im Dependency Graph neu bauen muss, ja dann ist das einer der größten Designfalls die man sich so erlauben kann. Aber es passt auf jeden Fall gut in mein Bild von Java.

Muss man nicht zwangsläufig, das ist nur bei Bundles (Fat JARs/WARs) der Fall.

Es gibt auch Konfigurationen bei denen die Dependencies über den Application Server bereit gestellt wird.

 

[foo_1337]

Rust kann shared objects erzeugen (https://doc.rust-lang.org/reference/linkage.html) also gehe ich mal davon aus, dass es auch selbst dagegen linken kann

Wie du siehst, geht es hier um crates. Rust eigene Pakete, wo wir wieder beim Thema npm & co sind.

In Python installiert man sich auch Pakete über pip und verwurstet nicht alles in sein Paket.

Schön, dass du es erwähnst: pip funktioniert quasi wie CPAN (perl). Das f*cked dir dein System komplett ab, wenn du damit anfängst und anderes via deb oder rpm nachinstalliert hast. Darüber hinaus funktioniert das ganze schon dann nicht mehr, sobald du 2 Apps hast, die jeweils andere Versionen wollen. Was macht man deshalb? Man benutzt venvs. Ein bescheuerter Workaround, der sein muss, weil das ganze damals leider völlig an der Realität vorbei designed wurde. Am Ende hat man dann unzählige Pfade auf der Kiste in der irgendwelche Pakete liegen. Was ist also die Lösung? Man nutzt container, damit man sich nicht in die Quere kommt und sicher stelle kann, dass man das richtig gebaute environment vorfindet.

Sowas funktioniert dann noch halbwegs solange man die Hoheit über alle Pakete hat, aber wehe da wird was zugeliefert.

Genau dafür habe ich doch den Paketmanager?

 

[Jonnni]

Ich betreibe Minecraft Server. Dort ging die Info unter Admins sehr schnell rum. Noch Donnerstag am 09.12. nachts, war es bei uns überall gefixt. Erschreckend, dass es bei einigen Firmen erst Freitag/Samstag oder teilweise erst Montag der Fall war. Noch erschreckender, das es teilweise bei einigen jetzt über 11 Tage später immer noch nicht gefixt ist

 

[dev/random]

joar wie nutzen noch Log4j 1.2 ... also nicht betroffen. 😅

log4j 1.2 ist genauso angreifbar, nur über eine andere remote code execution Schwachstelle (CVE-2019-17571). Wird auch nicht mehr gefixt werden, da end of life.

Ich frage mich imer noch, in wie weit man als Privatnutzer betroffen ist und wie dann eine Attacke erfolgen soll. Und was kann ich dagegen tun.

Z.B. falls Du einen Minecraft server betreibst. Oder auch nur mal Minecraft spielst.
Auch die letzte Minecraft client version 1.18.1 enthält noch eine verwundbare log4j v2.14.1. Und wenn man die Jndi Klasse entfernt, wird beim nächsten Minecraft Start gleich wieder eine vollständige log4j Kopie aus dem Netz installiert...

 

[fdsonne]

Das Zeug pflegt niemand, aktualisiert niemand und daran denkt meist auch niemand. Ganz anders sieht es bei Software die zum Beispiel VC++ einsetzt, die Runtimes werden dann einfach über Windows Update gepflegt.

Ehrlich gesagt verstehe ich deinen Einwand nicht.
A) der Nachfolger des MSM ist der LSA - wenn du, dein Admin, deine IT, deine whatever dafür zuständige Person das nicht updatet -> was kann da die Software für?
B) Ja, VC++ Redistributable Pakete werden per Windows Update bezogen. ABER:

Wenn man sich analog dem MSM nicht drum kümmert, ist das exakt gar kein Vorteil... Zumal die alte Kamelle natürlich auch lange nicht mehr geplegt wird und je nach genutzter Software, vor allem Games! sind da ein Problem, wird der Spaß dann gern auch einfach mal in Form einer Assbach Version mitinstalliert.

@xexex : nur bei Komponenten die tatsächlich als SxS Paket vorliegen.

Das ist doch eh eher ne Microsoft Eigenart. Wenn der Entwickler da sein Zeug mitliefern will, dann liefert er das mit. Außer MS, nutzt da wirklich groß wer die SxS Pakete?
Wir sind ja hier in einer Gaming Angehauchten Community - wenn ich mir anschaue wie das in den Games so ausschaut. Libs von Engines über x-verschiedenste Versionen werden mitgeschliffen. Oder auch sehr prominent - NVidias DLSS. Wenn sich die Gamer dann wie Schnitzel freuen, weil sie einen Weg gefunden haben, in einem Game durch simples Kopieren der Libs irgendwie ne Verbesserung zu bekommen usw. usf.
Es ist doch eher die gängige Praxis das was notwendig ist, auch mitzuliefern - mal von den absoluten Basics wie den VC++ Runtimes abgesehen.

Noch erschreckender, das es teilweise bei einigen jetzt über 11 Tage später immer noch nicht gefixt ist

Wieso erschreckend? Es gibt teilweise nichtmal verlässliche Aussagen der Hersteller. Da kannste natürlich auch dann nix beheben/fixen. Cisco bspw. hat nach ihrem Whitepaper erst gestern die letzten "under investigation" Produkte aus der Matrix rausgeputzt. Sprich da ist die Klarheit seit gestern.

Btw. weil ich das jüngst erst bei mir analysiert habe. Der erste Zugriffsversuch von Dritten mit irgendwas Bezogen auf die 44228er Lücke fand bei einem VPS Server von mir am 10.12.2021 gegen 15 Uhr statt. Seit dem WE (11-12.12.) häufen sich die Versuche, teilweise binnen weniger Minuten Unterschied. Selbst die privaten IP Bereiche der DSL Kunden werden gescannt. Ich hab auf meinem privaten Anschluss mehrere Versuche im Log stehen.