{"id":102661,"date":"2021-12-19T03:36:43","date_gmt":"2021-12-19T01:36:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov"},"modified":"2021-12-19T03:36:43","modified_gmt":"2021-12-19T01:36:45","slug":"eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov","title":{"rendered":"Mais uma vulnerabilidade no Log4j 2. Os problemas no Log4j afetam 8% dos pacotes Maven","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Na biblioteca Log4j 2 foi identificada mais uma vulnerabilidade (CVE-2021-45105), que, diferentemente dos dois problemas anteriores, foi classificada como perigosa, mas n\u00e3o cr\u00edtica. O novo problema permite causar uma interrup\u00e7\u00e3o no servi\u00e7o e se manifesta como um loop infinito e falhas ao processar determinadas strings. A vulnerabilidade foi corrigida na vers\u00e3o do Log4j 2.17 lan\u00e7ada h\u00e1 algumas horas. O risco da vulnerabilidade \u00e9 reduzido pelo fato de que o problema ocorre apenas em sistemas com Java 8. <\/p>\n
As vulnerabilidades afetam sistemas que utilizam consultas contextuais (Context Lookup) na determina\u00e7\u00e3o do formato de sa\u00edda de logs, como ${ctx:var}. Nas vers\u00f5es do Log4j, desde a 2.0-alpha1 at\u00e9 a 2.16.0, n\u00e3o havia prote\u00e7\u00e3o contra recurs\u00e3o n\u00e3o controlada, o que permitia que um invasor manipulasse o valor utilizado na substitui\u00e7\u00e3o, resultando em um loop que esgotava o espa\u00e7o na pilha e causava a finaliza\u00e7\u00e3o do processo. Especificamente, o problema ocorria ao substituir valores como «${${::-${::-$${::-j}}}}». <\/p>\n
Al\u00e9m disso, pesquisadores da Blumira sugeriram uma variante de ataque a aplicativos Java vulner\u00e1veis que n\u00e3o aceitam requisi\u00e7\u00f5es de rede externas; por exemplo, sistemas de desenvolvedores ou usu\u00e1rios de aplicativos Java podem ser atacados dessa forma. A ess\u00eancia do m\u00e9todo \u00e9 que, com processos Java vulner\u00e1veis no sistema do usu\u00e1rio que aceitam conex\u00f5es de rede apenas do host local (localhost) ou que processam requisi\u00e7\u00f5es RMI (Remote Method Invocation, porta 1099), um ataque pode ser realizado com c\u00f3digo JavaScript executado ao abrir uma p\u00e1gina maliciosa no navegador dos usu\u00e1rios. Para estabelecer a conex\u00e3o com a porta de rede do aplicativo Java durante um ataque desse tipo, utiliza-se a API WebSocket, que, ao contr\u00e1rio das requisi\u00e7\u00f5es HTTP, n\u00e3o aplica as restri\u00e7\u00f5es de same-origin (WebSocket tamb\u00e9m pode ser utilizado para escanear portas de rede no host local, a fim de identificar manipuladores de rede dispon\u00edveis).
<\/center> <\/p>\n
Os resultados da avalia\u00e7\u00e3o de vulnerabilidades de bibliotecas relacionadas ao Log4j, publicados pela Google, tamb\u00e9m s\u00e3o de interesse. De acordo com a Google, o problema afeta 8% de todos os pacotes no reposit\u00f3rio Maven Central. Em particular, 35.863 pacotes Java relacionados ao Log4j apresentaram vulnerabilidades, tanto por depend\u00eancias diretas quanto indiretas. O Log4j \u00e9 utilizado como uma depend\u00eancia direta de primeiro n\u00edvel em apenas 17% dos casos, enquanto em 83% dos pacotes afetados, a liga\u00e7\u00e3o ocorre atrav\u00e9s de pacotes intermedi\u00e1rios que dependem do Log4j, ou seja, depend\u00eancias de segundo n\u00edvel ou superiores (21% - de segundo n\u00edvel, 12% - de terceiro, 14% - de quarto, 26% - de quinto, 6% - de sexto). A velocidade de corre\u00e7\u00e3o das vulnerabilidades ainda deixa a desejar; uma semana ap\u00f3s a detec\u00e7\u00e3o da vulnerabilidade, o problema foi corrigido apenas em 4.620 dos 35.863 pacotes identificados, ou seja, apenas 13%.
<\/center> <\/p>\n
Enquanto isso, a Ag\u00eancia de Ciberseguran\u00e7a e Prote\u00e7\u00e3o de Infraestrutura dos EUA publicou uma diretiva de emerg\u00eancia, exigindo que as ag\u00eancias federais identifiquem os sistemas de informa\u00e7\u00e3o vulner\u00e1veis ao Log4j e, at\u00e9 23 de dezembro, instalem atualiza\u00e7\u00f5es que bloqueiem o problema. At\u00e9 28 de dezembro, as organiza\u00e7\u00f5es devem relatar as atividades realizadas. Para facilitar a identifica\u00e7\u00e3o dos sistemas problem\u00e1ticos, foi preparado uma lista de produtos em que a vulnerabilidade foi confirmada (a lista cont\u00e9m mais de 23 mil aplicativos). \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Mais](\"\/wp-content\/uploads\/2021\/12\/811931e8c3ae3f3f3c2e81db361034e6.jpg\")
<\/center> <\/p>\n![\"Mais](\"\/wp-content\/uploads\/2021\/12\/1e61b09923c7e055fa635545f1b3de6b.jpg\")
<\/center> <\/p>\n