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

[MADman_One]

Ich habe 10 Webanwendungen erst auf 2.15.0 gebracht und dann als sich rausstellte daß das nicht reicht, das gleiche nochmal für 2.16.0. Und da wir mit Change Management Prozessen arbeiten dürfte ich für jede einzelne Aktion einen eigenen Change erstellen, das hat fast länger gedauert als das updaten selber. Dazu Anfragen an 3rd Party Anbieter für Software die wir selbst im Einsatz haben sowie Absichern von Umgebungen die noch nicht gepatcht werden können...war ne ganze Menge Arbeit bisher schon. Und ich glaube nicht, daß 2.16.0 schon der letzte Patch für unsere Anwendungen war.

 

[mitch-dk]

Kurze Frage von der Client-Seite:
Hab jetzt inzwischen die privaten Systeme durch, nur das Minecraft von einigen Systemen hat seltsame Effekte, gibts hier schon neuere Erkenntnisse?

Minecraft <1.18.1 betroffen
c:\Users\userxyz\AppData\Roaming\.minecraft\libraries\org\apache\logging\log4j

[*] Found CVE-2021-44228 (log4j 2.x) vulnerability in c:\Users\userxyz\AppData\Roaming\.minecraft\libraries\org\apache\logging\log4j\log4j-core\2.14.1\log4j-core-2.14.1.jar, log4j 2.14.1

Da gibt es verschiedene Dateien von log4j die betroffen sind, selbst nach dem Update auf 1.18.1 und entfernen per Hand, werden die alten betroffenen Dateien von log4j nach dem starten wiederhergestellt. Keine neue Version davon trotz (v1.18.1). Ob die jetzt genutzt werden oder nicht ist erstmal zweitrangig..
Evtl. verhalten sich sonstige Java Anwendungen auch so, was ein Dauerhaftes Problem werden könnte?

Edit:
Falls jemand auch vor dem gleichen Problem steht, hab einige Aussagen von Reddit dazu gefunden, inwieweit die helfen oder stimmen - wir werden sehen (evtl. ist MS/Mojang immer noch in der Schadensbegrenzung und liefert aktuell nur "Workarounds"). Selbst nach einer Neuinstall sind die betroffenen Dateien wieder dabei..
https://www.reddit.com/r/admincraft/comments/reuq8j/any_way_to_verify_clientside_patch_of_log4j/

 

[jaegerschnitzel]

Auf den ComputerBase-Servern kommen Java und log4j ausschließlich für das Such-Backend Elasticsearch zum Einsatz, welches sowohl das CMS als auch die Forumsoftware XenForo nutzen. Die empfohlenen Maßnahmen gegen die Sicherheitslücke haben wir am frühen Samstagmorgen umgesetzt.

Es gibt keine Anzeichen dafür, dass die Sicherheitslücke auf ComputerBase ausgenutzt wurde. Wie es scheint, ist unser Setup ohnehin nicht verwundbar, weil Nutzer und somit auch ein potenzieller Angreifer auf Elasticsearch nicht direkt zugreifen können, sondern dies nur indirekt über das CMS oder XenForo geschieht (Ankündigung von XenForo).

Ich würde hier gerne nachfragen. Wenn im CMS oder im Forum gesucht wird, dann kommt die Anfrage doch im Backend an und dort nutzt ihr log4j. D.h. potenziell gefährliche Anfragen kommen an log4j heran, obwohl die Server nicht aus dem Internet erreichbar sind. Der gefährliche Code wird dort dann interpretiert und der Server kann sich dann beispielsweise weiteren Code oder direkt eine Malware aus dem Internet nachladen. Somit können auch Server die nicht aus dem Internet erreichbar sind, ganz leicht übernommen werden.

Die Aussage im letzten Abschnitt ist damit falsch, ihr wart bis zum Update verwundbar.

 

[BrollyLSSJ]

Ich habe mal für indirekt abgestimmt. Ich musste den Workaround in einigen vSphere Umgebungen umsetzen.

 

[abanev]

Ja, war indirekt betroffen da ich im IT Support für meine Firma tätig bin.
Prüfen mehrerer hundert Server und gut tausend Clients, beruhigen von Kollegen und planen und koordinieren der notwendigen Maßnahmen.

War ne stressige Woche.

 

[drachenpalme]

Wie selten siehst du Tomcat/Jetty/Jboss/Wildfly Webapps an?

Tomcat ist nicht betroffen, Wildfly (Full) ist nicht betroffen. Ich bezweifle, dass sie für Webapps ein eigenes Logsystem geschrieben haben. Jetty nutzt augenscheinlich Slf4j und da ist log4j nicht die Standard-Implementierung drunter.
Hast Du Nachweise dafür, dass auch nur eines der drei von Dir genannten Systeme im Standard auf log4j setzt? (JBoss ist die kommerzielle Ausgliederung von Wildfly)

Vielleicht ist ja der ein oder andere Entwickler anwesend, der ein real live Beispiel für solche lookups hat.

Ich bezweifle, dass Dir da jemand was sinnvolles nennen kann. Es gibt keinen Grund, beim Logging dynamisch irgendwelche Lookups zu machen oder sonstwie Code von extern reinzuladen.
Wenn man solche ausgefuchsten Anforderungen hat, dann macht man das hintenraus, zum Beispiel, indem man die Nachrichten mit Logstash nachbearbeiten lässt oder statt auf Platte nach Kafka transportiert oder einen andersgearteten zentralen Logserver benutzt.
Oberstes Prinzip bei Software Design ist "ein Tool, ein Job". Der Job der Fachanwendung ist es, fachliche Anforderungen abzudecken. Alles, was Du an Aufbereitung der Lognachrichten machen musst, machst Du nachgelagert.
Das ist nicht nur ne Frage bezüglich dieser Sicherheitslücke. Sagen wir, Dein Anwendungsfall braucht eine Nachbearbeitung mit dynamisch nachgeladenen Code. Per Default passiert (mit allen mir bekannten Frameworks) das Logging im selben Thread, in dem auch Deine Anwendung läuft. Wenn das Logging auf einen Fehler läuft, kann das Deine Fachanwendung töten. Das ist der worst case - eine "unwichtige" Sekundärfunktion reißt Deine Anwendung in den Abgrund. Das ist so das Niveau:
"Entschuldigen Sie bitte, Amazon ist derzeit nicht verfügbar, weil eine Funktion zur hübscheren Formattierung von Zahlen grade nicht zur Verfügung steht. Kommen Sie in einer Stunde nochmal vorbei"
Jeder, der beim Implementieren halbwegs seine Sinne beisammen hat, macht im fachlichen Prozess nichts, was in die Grütze gehen kann und nicht unmittelbar zwingend notwendig ist. Pretty-Printing kann man immer ex-Post machen.

 

[foo_1337]

Tomcat ist nicht betroffen, Wildfly (Full) ist nicht betroffen. Ich bezweifle, dass sie für Webapps ein eigenes Logsystem geschrieben haben. Jetty nutzt augenscheinlich Slf4j und da ist log4j nicht die Standard-Implementierung drunter.
Hast Du Nachweise dafür, dass auch nur eines der drei von Dir genannten Systeme im Standard auf log4j setzt? (JBoss ist die kommerzielle Ausgliederung von Wildfly)

Es ist überhaupt kein Problem bei Tomcat, Wildfly, Jetty & Co log4j zu nutzen. Im Gegenteil, es wird sogar sehr oft gemacht. Wir hatten jedenfalls genug Applikationen, bei denen das der Fall war.
Magst du ein prominentes Beispiel haben? Atlassian. Ein weiteres? Vmware. Noch mehr?

Aber klar, der Ansatz "Wir nutzen zwar Tomcat, aber der ist ja eh nicht betroffen" ist sicher ein guter. Nicht.

Es nervt mich langsam wirklich, wie einem hier teilweise die Worte im Mund rumgedreht werden, frei nach dem Motto "Ha! Dem zeig ichs, der hat unrecht!!". Augenscheinlich dann genau von den Leuten, die sich mit der Thematik hier offensichtlich kein bißchen beschäftigt haben.

 

[[wege]mini]

Zum Glück, habe ich mit diesen Dingen wenig zu tun.

Kein Smartphone, keine Dienste wie Whatsapp oder Facebook, kein Onlinebanking, nur Avatare im Internet und selbst die nachgelagerte Person im Reallife stellt nur genau das dar, was die anderen sehen sollen.

Trotzdem bin ich dankbar für viel Lesestoff und sehr viel Wissen, wie bestimmte Dinge im hier und jetzt von den "Normalos" angegangen werden.

Mein Mitleid für Softwareheinis hält sich aber in Grenzen. Wenn ich etwas überhaupt nicht machen würde wollen, dann für wenig Geld aber dafür viel Kaffee und Pizza, dann aber wieder wenig Anerkennung dauerhaft irgend welche Codes zu schreiben, und immer der Arsch zu sein.

Das bekommt von mir viel Anerkennung. Machen, würde ich es aber trotzdem nicht, auch wenn ich es könnte.

mfg

 

[Snowi]

Tomcat ist nicht betroffen, Wildfly (Full) ist nicht betroffen. Ich bezweifle, dass sie für Webapps ein eigenes Logsystem geschrieben haben.

Bei uns hat so ziemlich jede Anwendung die auf Tomcat oder Jboss läuft ihr eigenes Logging, das meistens auf Log4j basiert hat. Die meisten waren traurigerweise nur nicht direkt betroffen, weil sie Version 1.irgendwas genutzt haben. Das wird jetzt bei uns alles gepatcht, weil es für die 1er auch einen schönen CVE gibt.

 

[foo_1337]

Danke Snowi, das deckt sich genau mit meiner Erfahrung in diesem Kontext Ich habe fast keinen Tomcat gefunden, in dem die Applikation nicht log4j genutzt hat.

 

[Tamron]

Erschreckend was man hier so liest wie "früh" einige auf die Lücke reagiert haben.
Kein Wunder, dass ich immer Arbeit habe

 

[poly123]

@jaegerschnitzel primär betroffen sind unmittelbar erreichbare Syteme, mittelbar aber auch Backend-Syteme. Der Payload in dem ersten Request, egal in welchem Header Parameter reicht aus (scheiße an ner WAF zu filtern, hilft nur hart ^\$\{.\} Edit: und da reden wir noch nicht einmal vom Payload, also den Request-Body Inhalten..), um Cobalt Strike Beacons etc. mit erstem Request zu laden. LDAP Requests sind ein Angriffsvektor, DNS-Callbacks und RMI sind im kommen …

PS: OTRS nutzt elasticsearch 😂

Edit: Juniper Link ergänzt.

 

[Scythe1988]

Ich habe 10 Webanwendungen erst auf 2.15.0 gebracht und dann als sich rausstellte daß das nicht reicht, das gleiche nochmal für 2.16.0. Und da wir mit Change Management Prozessen arbeiten dürfte ich für jede einzelne Aktion einen eigenen Change erstellen, das hat fast länger gedauert als das updaten selber. Dazu Anfragen an 3rd Party Anbieter für Software die wir selbst im Einsatz haben sowie Absichern von Umgebungen die noch nicht gepatcht werden können...war ne ganze Menge Arbeit bisher schon. Und ich glaube nicht, daß 2.16.0 schon der letzte Patch für unsere Anwendungen war.

Arbeitest du bei uns (Versicherer in Hannover)? Kommt mir sehr bekannt vor

 

[Snowi]

Arbeitest du bei uns (Versicherer in Hannover)? Kommt mir sehr bekannt vor

Kommt mir auch bekannt vor, denke aber eher das liegt an der Branche

 

[MADman_One]

Arbeitest du bei uns (Versicherer in Hannover)? Kommt mir sehr bekannt vor

Haha nope Aber ich bin mir sicher das ich da in guter Gesellschaft bin, ich kenne selbst mindestens zwei Bekannte bei anderen Unternehmen die genau das gleiche machen mussten Sowohl patchen als auch Change Management Und letzteres ist diesmal zumindest bei uns nicht typisch deutsch, mein Arbeitgeber ist ein US Unternehmen und die wollen das so

 

[Enurian]

Ich musste mittels Skript für den Jenkins Server prüfen, ob irgendein Plugin den Bumms benutzt. Taten sie nicht (1 Minute copy&paste). Ansonsten nur einem Kunden vermitteln, dass unsere Produkte nicht betroffen sind - insofern mal "nicht betroffen" angekreuzt.

 

[ShiftyBro]

https://log4jmemes.com/

🤷🏻‍♂️

Danke, nach dem Betrachten der ersten 30 Memes hab ich nun ein deutlich besseres Bild von der allgemeinen Lage.

 

[kim88]

Dann mal für dich die Frage, was habe ich mit möglichen Sicherheitslücken bei irgendwelchen Webhostern zu tun?

Du persönlich? Naja vielleicht liegen ja irgendwelche Daten von dir auf einem diesen Webhostern. Vielleicht nur harmloses wie Adresse, Name oder Telefonnummer.
Vielleicht aber auch Impfanmeldungen oder deinen Pornhub Suchverlauf wer weiss das schon.

Clouddienste? Womöglich! Inwiefern ist das ein Risiko für interne Kundennetzwerke? Ich schrieb von Software die bei Kunden läuft, die deren Netzwerk angreifbar machen machen würde und da ist alles relevante längst weg von Java.

Also in meinem Umfeld ist "Software" die beim Kunden läuft in der Regel auch immer Software die über gewise Schnittstellen nach aussen telefonieren kann. Ist doch inzwischen alles irgendwie vernetzt.

Am meisten nervt eigentlich, dass es nun noch eine Version (2.17) braucht, die dann hoffentlich mal endgültige Abhilfe schafft - kopflos mit einem Workaround der nicht funktioniert hat und mit einer Version 2.16, bei der man die Lookup Funktion versucht hat rauszuschmeißen, wirbt man auch nicht für Vertrauen - das nervt.

Wie viel Geld hat eure Firma den Entwicklern gespendet? Oder habt ihr ein paar Stellenprozente reserviert die in an dieser Libary mitarbeiten?
Wenn du beide Fragen mit Nein beantwortest und ihr dennoch ihre Software nutzt sollte man sich nicht über die Entwickler ärgern. Sondern etwas ändern.

 

[poly123]

@kim88 die Frage könnte man jedem bei Verwendung von FOSS stellen.

Besagte Funktion war (zwischen pull und commit) nach 23h integriert - sauberer Review, würd ich sagen.

 

[wayne_757]

Was schlägst du als bessere Alternative vor?

Er leidet unter dem NIH Syndrom und geht davon aus alles besser zu machen zu können

Das Problem sind nicht die Paketabhängigkeiten an sich, sondern, dass es als statische Abhängigkeit reinverwurstet wird. Das ist genauso eine schlechte Idee wie der Containerquatsch wo praktisch das Gleiche gemacht wird.

Als shared object würde man einmal die betroffene Bibliothek aktualisieren und dann die abhängigen Dienste neu starten.

Das ist auf jeden Fall entspannter als dieses Abenteuer.