Outra vulnerabilidade identificouse na biblioteca Log4j 2 (CVE-2021-45105), que, a diferenza dos dous problemas anteriores, está clasificada como perigosa, pero non crítica. O novo problema permítelle provocar unha denegación de servizo e maniféstase en forma de bucles e fallos ao procesar determinadas liñas. A vulnerabilidade foi corrixida na versión Log4j 2.17 publicada hai unhas horas. O perigo da vulnerabilidade vese mitigado polo feito de que o problema só aparece en sistemas con Java 8.
A vulnerabilidade afecta aos sistemas que usan consultas contextuais (Context Lookup), como ${ctx:var}, para determinar o formato de saída do rexistro. As versións de Log4j desde a 2.0-alpha1 ata a 2.16.0 carecían de protección contra a recursividade incontrolada, o que permitía a un atacante manipular o valor utilizado na substitución para provocar un bucle, o que provocou o esgotamento do espazo da pila e un fallo. En particular, o problema ocorreu ao substituír valores como "${${::-${::-$${::-j}}}}".
Ademais, pódese sinalar que os investigadores de Blumira propuxeron unha opción para atacar aplicacións Java vulnerables que non aceptan solicitudes de redes externas; por exemplo, os sistemas de desenvolvedores ou usuarios de aplicacións Java poden ser atacados deste xeito. A esencia do método é que se hai procesos Java vulnerables no sistema do usuario que aceptan conexións de rede só desde o host local ou procesan solicitudes RMI (Remote Method Invocation, porto 1099), o ataque pode levarse a cabo mediante código JavaScript executado. cando os usuarios abren unha páxina maliciosa no seu navegador. Para establecer unha conexión co porto de rede dunha aplicación Java durante un ataque deste tipo, utilízase a API WebSocket, á que, a diferenza das solicitudes HTTP, non se aplican restricións da mesma orixe (WebSocket tamén se pode usar para escanear portos de rede no local. host para determinar os controladores de rede dispoñibles).
Tamén son de interese os resultados publicados por Google de avaliación da vulnerabilidade das bibliotecas asociadas ás dependencias de Log4j. Segundo Google, o problema afecta ao 8% de todos os paquetes do repositorio de Maven Central. En particular, 35863 paquetes Java asociados con Log4j a través de dependencias directas e indirectas expuxéronse a vulnerabilidades. Ao mesmo tempo, Log4j emprégase como dependencia directa de primeiro nivel só no 17% dos casos, e no 83% dos paquetes afectados, a vinculación realízase a través de paquetes intermedios que dependen de Log4j, é dicir. adiccións de segundo e nivel superior (21% - segundo nivel, 12% - terceiro, 14% - cuarto, 26% - quinto, 6% - sexto). O ritmo de arranxo da vulnerabilidade aínda deixa moito que desexar; unha semana despois de identificar a vulnerabilidade, dos 35863 paquetes identificados, o problema solucionouse ata agora en só 4620, é dicir. nun 13%.
Mentres tanto, a Axencia de Protección de Infraestruturas e Ciberseguridade dos Estados Unidos emitiu unha directiva de emerxencia que esixe ás axencias federais que identifiquen os sistemas de información afectados pola vulnerabilidade Log4j e instalen actualizacións que bloqueen o problema antes do 23 de decembro. Ata o 28 de decembro, as organizacións están obrigadas a informar sobre o seu traballo. Para simplificar a identificación de sistemas problemáticos, elaborouse unha lista de produtos que se confirmou que presentan vulnerabilidades (a lista inclúe máis de 23 mil aplicacións).
Fonte: opennet.ru