Log4j-sårbarhed – Er Log4j 1.2.17 sårbar (kunne ikke finde nogen JNDI-kode i kilden)?

Med hensyn til Log4j JNDI fjernudførelsessårbarheden, der er blevet identificeret CVE-2021-44228 – (se også referencer) – spekulerede jeg på, om Log4j-v1.2 også var påvirket, men det tætteste jeg kom fra kildekodegennemgang er JMS. -Tillæg.

Spørgsmålet er, at selvom indlæggene på internettet indikerer, at Log4j 1.2 også er sårbart, kan jeg ikke finde den relevante kildekode til det.

Går jeg glip af noget, som andre har identificeret?

Log4j 1.2 ser ud til at have en sårbarhed i socket-server-klassen, men min forståelse er, at den skal aktiveres i første omgang for at den kan anvendes, og er derfor ikke en passiv trussel i modsætning til JNDI-opslagssårbarheden, som den identificerede synes at være.

Er min forståelse - at Log4j v1.2 - ikke er sårbar over for udførelsesfejlen jndi-remote-code korrekt?

Referencer

• Sikkerhedssårbarheder i Apache Log4j

• Zero-day i allestedsnærværende Log4j-værktøj udgør en alvorlig trussel mod internettet

• Værste Apache Log4j RCE Zero day faldt på internettet

• 'Log4Shell'-sårbarhed udgør en kritisk trussel mod applikationer, der bruger 'allestedsnærværende' Java-logningspakke Apache Log4j

Dette blogindlæg fra Cloudflare indikerer også det samme punkt som fra AKX...at det blev introduceret fra Log4j 2!

Opdatering #1 – En fork af den (nu pensionerede) apache-log4j-1.2.x med rettelser til nogle få sårbarheder identificeret i det ældre bibliotek er nu tilgængelig (fra den originale log4j-forfatter). Siden er https://reload4j.qos.ch/. Fra 21. januar 2022 er version 1.2.18.2 blevet frigivet. Sårbarheder behandlet til dato omfatter dem, der vedrører JMSAppender, SocketServer og Chainsaw sårbarheder. Bemærk, at jeg blot videregiver disse oplysninger. Har ikke verificeret rettelserne fra min side. Se linket for yderligere detaljer.

Svar

JNDI-funktionen blev tilføjet til Log4j 2.0-beta9.

Log4j 1.x har således ikke den sårbare kode.