Am 17. Dezember, 2021 in ihrem Blog erklärte das Google Open Source Insights Team die gesamte beobachtete Situation bezüglich der Apache Log4j-Sicherheitslücke. Sie beschrieben die weit verbreitete Schwachstelle und die aktuellen Fortschritte bei der Behebung des Open-Source-JVM-Ökosystems. Außerdem teilte das Team seine Gedanken dazu mit, wie lange es möglicherweise dauern wird, bis diese Schwachstelle im gesamten Ökosystem behoben ist und worauf man sich als nächstes konzentrieren sollte.
Am 9. Dezember erfuhr das Informationssicherheits-Ökosystem von der Existenz der Schwachstelle, die einen hohen Schweregrad und weitreichende Auswirkungen hat. Zehntausende Softwarepakete (Artefakte im Java-Ökosystem) und Projekte verwenden ein beliebtes Protokollierungstool, log4j, bei dem sich herausstellte, dass die Schwachstellen diskutiert wurden. Wie Spezialisten erklären, ermöglichen diese Schwachstellen die Remotecodeausführung, indem sie die zurückhaltende JNDI-Lookups-Funktion ausnutzen, die von der Protokollierungsbibliothek log4j offengelegt wird. In vielen Versionen der Bibliothek war die ausgenutzte Funktion standardmäßig vorhanden.
Die Behebung der Apache Log4j-Sicherheitslücke wird eine Weile dauern
Vor nicht allzu langer Zeit haben die offengelegten log4j-Schwachstellen mehr als berührt 35,000 Java-Pakete, Nummerierung zu über 8% des Maven Central-Repositorys. Da das Repository das bedeutendste Repository für Java-Pakete ist, hat es ein umfassendes Ergebnis für die Softwareindustrie verursacht. Spezialisten weisen darauf hin 8% ist ein riesiges Ergebnis für das Ökosystem-Ergebnis, während die durchschnittliche Zahl für das Ergebnis der Maven Central-Advisories damit einhergeht 2% und der Median kleiner als 0.1%. Obwohl die genannten Nummern nicht alle Java-Pakete umfassen, zum Beispiel direkt verteilte Binärdateien.
Zum Zeitpunkt der Veröffentlichung wurden fast fünftausend der fraglichen Artefakte repariert. Und über 30,000 Artefakte, viele hängen von einem anderen Artefakt ab, warte immer noch darauf gepatcht zu werden. Das Team erwähnt, dass es ein Artefakt als behoben gewertet hat, wenn das Artefakt mindestens eine betroffene Version hatte und eine größere, nicht betroffene stabile Version veröffentlicht hat (das entspricht der semantischen Versionierung). Im Fall von log4j gilt ein Artefakt als behoben, wenn es auf aktualisiert wurde 2.16.0 oder hat keine Abhängigkeit mehr von log4j.
Zwei wesentliche Probleme behindern den Reparaturprozess
Obwohl die Situationen im Allgemeinen als klar definiert werden können, die Spezialisten weisen auf zwei wesentliche Befestigungsprobleme hin. Das erste Ziel, das sie definieren, ist die Tatsache, dass viele Artefakte indirekt von log4j abhängen. Diejenigen der direkten Abhängigkeiten machen etwa 7,000 der betroffenen Artefakte. In einem solchen Fall hängt jede seiner Versionen von einer betroffenen Version von log4j-core oder log4j-api . ab, in den CVEs beschrieben. Die indirekte Abhängigkeit oder transitive Abhängigkeit bezeichnet die Abhängigkeiten der eigenen Abhängigkeiten.
Das gesamte Personal dieser Abhängigkeit schafft erhebliche Hindernisse bei der Behebung, wenn man es mit Abhängigkeitsketten betrachtet. Hier bleibt alles ganz klar: Je tiefer die Verletzlichkeit fällt runter, desto mehr Schritte sollte man gehen, um es zu beheben. Laut den Verbraucherabhängigkeitsdiagrammen des Teams zeigten die Histogrammergebnisse große Zahlen. In mehr als 80% der Pakete Sicherheitslücke ist mehr als eine Ebene tief. In den meisten Fällen sind es fünf Stufen tiefer und in einigen neun Stufen tiefer. Der Prozess der Behebung erfordert, dass zuerst die tiefsten Abhängigkeiten und danach alle Bäume behandelt werden.
Offene Bereiche bietet die Möglichkeit, die zuletzt veröffentlichte Version auszuwählen
Eine weitere Schwierigkeit liegt in den Entscheidungen auf Ökosystemebene im Algorithmus zur Abhängigkeitsauflösung und in den Konventionen der Anforderungsspezifikation. Die Praxis unterscheidet sich von solchen wie npm, wo sie routinemäßig offene Bereiche für Abhängigkeitsanforderungen angeben. Offene Bereiche bieten die Möglichkeit, die zuletzt veröffentlichte Version auszuwählen, die die Abhängigkeitsanforderungen erfüllt. Und es zieht anschließend neue Fixes ein. Benutzer erhalten eine gepatchte Version beim nächsten Build nach der Verfügbarkeit des Patches. Es generiert die Abhängigkeiten schneller.
„Im Java-Ökosystem, Es ist gängige Praxis, „weiche“ Versionsanforderungen anzugeben – genaue Versionen, die vom Auflösungsalgorithmus verwendet werden, wenn keine andere Version desselben Pakets früher im Abhängigkeitsdiagramm auftaucht. Die Verbreitung eines Fixes erfordert oft explizite Maßnahmen der Betreuer, um die Abhängigkeitsanforderungen auf eine gepatchte Version zu aktualisieren,“ Open Source Insights-Team schrieb zu diesem zweiten Problem.
Mit diesen rät das Team der Open-Source-Community, automatisierte Abhängigkeitsupdates zu ermöglichen und Sicherheitsmaßnahmen hinzuzufügen. Sie stellten auch eine Liste mit 500 betroffene Pakete mit der höchsten transitiven Nutzung. Nach Ansicht der Experten wird die Priorisierung dieser Pakete die Reparaturbemühungen erleichtern und in der Folge mehr von der Community entsperren. Das Team bedankte sich bei den Open-Source-Betreuern und Verbrauchern, die ihre Versionen von log4j aktualisiert haben.
Auf die Frage, wie lange es dauern würde, alles vollständig zu reparieren, äußerte das Team eine vage Meinung. Sie sagen, es ist schwer zu wissen. Wenn es sich um alle öffentlich bekannt gegebenen kritischen Hinweise handelt, die Maven-Pakete betreffen, kann der Vorgang eine Weile dauern. Sie sagen weniger als die Hälfte (48%) der Artefakte, die von einer Schwachstelle betroffen sind, wurden behoben. Aber an der log4j-Front scheinen die Dinge mit ungefähr vielversprechend zu sein 13% das wurde behoben.
