Hallo in die Runde... wie läufts bei euch mit dem stopfen der neuen Lücke/n ? Geh ich recht, das ElasticSearch log4j verwendet? Ausgehend von diesem Beitrag: Mitigate Log4j2 / Log4Shell in Elasticsearch und diesem: Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228 - ESA-2021-31 Kann man mit ES 6.x und 7.x wohl dennoch relativ entspannt sein. Korrekt?
Hier erklärt was man in Xenforo dagegen tun kann: PSA: Potential security vulnerability in Elasticsearch 5+ via Apache Log4j (Log4Shell)
Naja genau genomme ist es keine Lücke sondern es funktioniert wie es entworfen worden ist. Hier ist das schön nachzulesen.
Kümmert mich nicht. Hab kein Apache und der ES ist von aussen nicht erreichbar. Hatte auf der Arbeit genug damit zu tun.
Geloggt wird nur bei Bedarf, das erhöht die Laufzeit der SSDs und bringt Performance. Nutze kein ES, kein *Java* und war daher in der Sache auch ganz entspannt.
Magst Du das etwas näher erläutern? Ich verstehe es nämlich ehrlich gesagt nicht wirklich: Apache (also Apache Webserver) ist AFAIK eh nicht betroffen (da kein Java)? Dass ein ES nicht von außen erreichbar ist heißt ja noch lange nicht dass es nicht anfällig wäre. Ist zwar eher unwahrscheinlich, aber sollte es einem Angreifer z.B. durch eine Suche gelingen einen entsprechenden Log-Eintrag mit JNDI Lookup zu triggern, dann diese ES-Instanz ggf. angreifbar wenn diese entsprechende Verbindungen (LDAP im LAN o.ä.) aufbauen kann?
Puh, ich meinte bei den ganzen Infos die auf mich einprasselten auch den Apache Webserver gelesen zu haben. Ich kann mich aber auch täuschen. Das war echt viel am Montag morgen. Mein ES läuft auf einer eigenen Instanz in der AWS welche in einer Security Group mit dem Nginx läuft, und per Richtlinie nur von diesem über den einen Port angesprochen werden kann. Muss ich mal per Konsole drauf zugreifen, gebe ich ich für den Zeitraum meine IP für SSH frei. Selbst wenn man also den Server infiziert, wird es schwierig damit was anzustellen. Falls ich eine Lücke übersehe bin ich für einen Hinweis dankbar.
Hat sich mal einer - EINER , die Infos aus meinen Links oben durchgelesen? Da bezieht ja u.a. ES selbst Stellung und gibt zu die Bibliothek zu verwenden, aber die Art der Verwendung wird für sicher befunden. ES war übrigens das einzige wo ich log4j über die mir bisher bekannten Suchen entdecken konnte. Das System als solches wird freilich up to date gehalten.
Also ich glaub da hast Du etwas missverstanden bzw. verwechselt: Log4j steht unter der Apache-Lizenz, wird unter dem Dach der Apache Foundation entwickelt - aber nicht vom Apache Webserver genutzt. Ich wüsste ehrlich gesagt auch nicht wie da ohne größere Verrenkungen technisch überhaupt möglich sein sollte, denn der Apache Webserver ist ja nicht in JAVA geschrieben sondern in C. Bei z.B. Hadoop und Solar sieht das anders, die sind vmtl. anfällig. Es kommt für die Frage ob ein ES prinzipiell anfällig is ja nicht darauf an ob es direkt von außen erreichbar ist sondern ob der Prozess selbst eine Verbindung (LDAP, HTTP, etc.) zu einem vom Angreifer kontrollierten Server aufbauen kann. Wenn das möglich ist (und das dürfte es in vielen Fällen sein), dann ist eine Ausnutzung prinzipiell denkbar. Ich hab das (zum ersten mal) gelesen lange bevor Du den Thread überhaupt eröffnet hast, nämlich am 10.12.2021 gegen ca. 20h Und wie so oft: Es ist komplizierter als es auf den ersten Blick erscheint: ES < 5 ist nicht betroffen da es keine der betroffenen Log4j-Versionen nutzt ES 5 ist betroffen, sowohl für Leak als auch RCE ES 6 und 7 sind nach eigener Aussagen nicht für RCE anfällig auf Grund der Nutzung des Java SM Bei älteren JVM-Versionen (< 9) aber für Leak
Also würdest du erstmal deren Einschätzung teilen - ich nutze aktuell ES 7.16.2 ps. du machst das beruflich (nehme ich mal an) ich nur neben dem Hauptjob, der mich seit Wochen 7 Tage die Woche mit 12-14h am Tag fordert. Von daher hab ich das zwar im Radio mitbekommen, aber eine adäquate Recherche war erst in den Tagen danach möglich.
Ja, würde ich. Wer noch einen Schritt weitergehen will: Den ES Prozess (per iptables/nftables, SELinux, AppArmor, ...) daran hindern aktiv Verbindungen ("nach außen") aufzubauen - dann dürfte es reichlich schwierig werden Code von irgendwo nachzuladen (selbst wenn es da noch eine Lücke gäbe).
