{"id":8118,"date":"2021-12-17T20:04:11","date_gmt":"2021-12-17T18:04:11","guid":{"rendered":"https:\/\/u-labs.de\/portal\/?p=8118"},"modified":"2022-12-12T18:23:21","modified_gmt":"2022-12-12T16:23:21","slug":"zwei-weitere-sicherheitsluecke-in-log4j-was-ihr-zu-version-2-16-und-1-2-wissen-muesst-update-1","status":"publish","type":"post","link":"https:\/\/u-labs.de\/portal\/zwei-weitere-sicherheitsluecke-in-log4j-was-ihr-zu-version-2-16-und-1-2-wissen-muesst-update-1\/","title":{"rendered":"Zwei weitere L\u00fcckenin log4j: Was ihr zu Version 2.16 und 1.2 wissen m\u00fcsst (Update 1: CVE-2021-45046 und CVE-2021-4104)"},"content":{"rendered":"

Vor einigen Tagen habe ich \u00fcber „Log4Shell“ berichtet<\/a>, eine schwere Sicherheitsl\u00fccke in der Bibliothek Log4j. Als Reaktion darauf wurde Log4j in Version 2.15 ver\u00f6ffentlicht. Seit kurzem gibt es jedoch eine weitere Version 2.16: Sie soll neue Fehler korrigieren, die inzwischen bekannt geworden sind. In diesem Beitrag schauen wir uns an, welche dies sind und wir ihr darauf reagieren solltet.<\/p>\n

Mithilfe der CVE-Nummern k\u00f6nnen wir die L\u00fccken zuordnen und Klarheit schaffen. Zur Erinnerung: CVE-2021-44228<\/strong> war die als Log4Shell bekannte schwere Sicherheitsl\u00fccke, bei der per JDNI beliebig Schadcode auf dem System ausgef\u00fchrt werden konnte. CVE-2021-44228 wurde in Log4j Version 2.15 behoben.<\/p>\n

CVE-2021-45046: Die erste neue L\u00fccke<\/h2>\n

Unter der Nummer CVE-2021-45046<\/strong> wurde eine zweite Schwachstelle bekannt: Sie verwendet ebenfalls JNDI-Aufrufe, allerdings f\u00fcr DoS<\/strong>-Angriffe. DoS <\/strong>steht f\u00fcr D<\/strong>enial o<\/strong>f S<\/em>ervice und bedeutet, dass man das Zielsystem lahm legt. Etwa mit vielen Anfragen, wodurch es zur \u00dcberlastung kommt. F\u00fcr Nutzer steht der Dienst dann nicht zur Verf\u00fcgung. Auf einem Minecraft-Server kann keiner Spielen, eine Internetseite ist nicht erreichbar und so weiter. <\/p>\n

Im Gegensatz zu CVE-2021-44228 von Log4Shell kann CVE-2021-45046 nicht daf\u00fcr missbraucht werden, um beliebig Schadcode auf dem Zielsystem auszuf\u00fchren. Diese neue L\u00fccke ist daher sicherheitstechnisch deutlich weniger kritisch, wenngleich Updates nat\u00fcrlich auch hier zu empfehlen sind. Sie betrifft alle Versionen bis einschlie\u00dflich 2.15, nur 2.16 ist nicht betroffen.<\/p>\n

Der Hintergrund ist: In Log4j 2.15 wurde JDNI auf lokale Adressen (localhost) limitiert, um die unkontrollierte Ausf\u00fchrung von Code zu verhindern. Aktiv ist JDNI damit aber weiterhin. In Version 2.16 hat man sich dazu entschieden, JDNI komplett zu deaktivieren – sicherheitstechnisch in meinen Augen eine sinnvolle Entscheidung.<\/p>\n

Wichtig<\/strong>: Der im vorherigen Beitrag empfohlene Workaround log4j2.noFormatMsgLookup=True<\/strong> hilft nur <\/strong>gegen die alte Log4Shell Sicherheitsl\u00fccke (CVE-2021-44228). Gegen die neue DoS-L\u00fccke CVE-2021-45046 bietet er keinen Schutz!<\/strong> Hier hilft nur zu aktualisieren. Oder wenn dies nicht m\u00f6glich ist, weil es sich um (propriet\u00e4re) Drittanbieter-Software handelt: Auf den Hersteller der Software zu warten bzw. bei der entsprechenden Stelle Druck zu machen, damit ein Update bereitgestellt wird.<\/p>\n

CVE-2021-4104: Eine neue Sicherheitsl\u00fccke in log4j 1.2<\/h2>\n

Die zweite L\u00fccke ist dagegen sicherheitskritischer: Sie erlaubt das Ausf\u00fchren von Code aus der Ferne, \u00e4hnlich gef\u00e4hrlich wie Log4Shell. Allerdings betrifft sie nur Log4j 1.2. Diese Version ist seit 2015 durch Version 2 abgel\u00f6st worden, erh\u00e4lt also keine Aktualisierungen mehr. Leider haben sich nicht alle Entwickler\/Hersteller um die Pflege ihrer Abh\u00e4ngigkeiten gek\u00fcmmert, sodass auch heute noch die alte 1.x Versionen eingesetzt werden.<\/p>\n

Im Gegensatz zu Log4Shell kann CVE-2021-4104 aber nur ausgenutzt werden, wenn der JMSAppender aktiviert ist. Zwar lassen sich auch hier JDNI-Anfragen missbrauchen. Doch JMSAppender ist standardm\u00e4\u00dfig nicht aktiv. Dadurch sind weit weniger betroffen, als bei Log4Shell.<\/p>\n

Fazit: Mehr Arbeit wegen fehlendem Sicherheitsbewusstsein<\/h2>\n

Die zwei neuen L\u00fccken sind vom Schadpotenzial her beide deutlich weniger gravierend, als Log4Shell. Dennoch macht es Sinn, m\u00f6glichst auf die neueste Version 2.16 zu aktualisieren. Zwar kann ein DoS-Angriff einen Server nicht kompromittieren. Dennoch ist es \u00e4rgerlich, wenn durch Ausnutzung dieser L\u00fccke Dienste nicht erreichbar sind. <\/p>\n

Dass CVE-2021-4104 in Log4j auch 6 Jahre nach dem Wechsel auf Version 2 teils immer noch ein Thema ist, unterstreicht die Problematik, welche ich im vorherigen Beitrag gegen Ende angesprochen habe: Viele ziehen sich Abh\u00e4ngigkeiten nicht nur ungepr\u00fcft in ihre Projekte, sondern k\u00fcmmern sich zudem nicht ausreichend um deren Pflege. <\/p>\n

Wenn in dieser Hinsicht bei den Entwicklern und vor allem Unternehmen kein Umdenken stattfindet, wird Log4Shell nicht die einzige Sicherheitsl\u00fccke bleiben, die einen Gro\u00dfteil des Internets bedroht – bis hin zu Top-Unternehmen wie Amazon oder Apple, wo jeder iPhone-Benutzer durch das Einf\u00fcgen einer Zeichenkette im Name seines iPhones theoretisch Vollzugriff auf Apples Systeme erhalten konnte. Selbstverst\u00e4ndlich ist das nur ein Beispiel von vielen. Es sind nicht nur zahlreiche weitere Unternehmen betroffen, sondern auch Geheimdienste wie die NSA. Und zwar jene, die Massen\u00fcberwachung nahezu weltweit betreiben und kein Problem damit haben, Sicherheitsl\u00fccken auf dem Schwarzmarkt zur eigenen Ausnutzung zu kaufen.<\/p>\n

Weiterf\u00fchrende Links und Quellen<\/h2>\n