{"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\/fr\/blog\/news\/eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov","title":{"rendered":"Une nouvelle vuln\u00e9rabilit\u00e9 dans Log4j 2. Les probl\u00e8mes dans Log4j touchent 8 % des packages Maven","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Une nouvelle vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 identifi\u00e9e dans la biblioth\u00e8que Log4j 2 (CVE-2021-45105), qui, contrairement aux deux probl\u00e8mes pr\u00e9c\u00e9dents, est class\u00e9e comme dangereuse mais non critique. Ce nouveau probl\u00e8me permet de provoquer un d\u00e9ni de service et se manifeste par des boucles infinies et des arr\u00eats soudains lors du traitement de certaines cha\u00eenes. La vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 corrig\u00e9e dans la version r\u00e9cemment publi\u00e9e de Log4j 2.17. Le risque de cette vuln\u00e9rabilit\u00e9 est att\u00e9nu\u00e9 par le fait que le probl\u00e8me ne se manifeste que sur des syst\u00e8mes utilisant Java 8. <\/p>\n
Les syst\u00e8mes vuln\u00e9rables utilisent des requ\u00eates contextuelles (Context Lookup) pour d\u00e9terminer le format de sortie dans les journaux, telles que ${ctx:var}. Dans les versions de Log4j, de 2.0-alpha1 \u00e0 2.16.0, il n'y avait pas de protection contre la r\u00e9cursion non contr\u00f4l\u00e9e, permettant \u00e0 un attaquant, par manipulation de la valeur utilis\u00e9e lors de l'insertion, d'entra\u00eener un bouclage, conduisant \u00e0 un \u00e9puisement de l'espace de la pile et \u00e0 l'arr\u00eat brutal du processus. En particulier, le probl\u00e8me se posait pour des valeurs comme \u00ab ${${::-${::-$${::-j}}}} \u00bb. <\/p>\n
De plus, il convient de noter que des chercheurs de l'entreprise Blumira ont propos\u00e9 une variante d'attaque contre des applications Java vuln\u00e9rables qui ne re\u00e7oivent pas de requ\u00eates r\u00e9seau externes, par exemple, des syst\u00e8mes de d\u00e9veloppeurs ou d'utilisateurs d'applications Java peuvent \u00eatre attaqu\u00e9s de cette mani\u00e8re. Le principe de la m\u00e9thode repose sur le fait que, lorsque des processus Java vuln\u00e9rables sont pr\u00e9sents sur le syst\u00e8me de l'utilisateur, n'acceptant des connexions r\u00e9seau qu'\u00e0 partir de l'h\u00f4te local (localhost) ou traitant des requ\u00eates RMI (Remote Method Invocation, port 1099), une attaque peut \u00eatre r\u00e9alis\u00e9e par du code JavaScript ex\u00e9cut\u00e9 lors de l'ouverture d'une page malveillante dans le navigateur des utilisateurs. Pour \u00e9tablir une connexion au port r\u00e9seau de l'application Java lors d'une telle attaque, l'API WebSocket est utilis\u00e9e, qui, contrairement aux requ\u00eates HTTP, ne subit pas de restrictions same-origin (WebSocket peut \u00e9galement \u00eatre utilis\u00e9 pour scanner les ports r\u00e9seau sur l'h\u00f4te local afin de d\u00e9terminer les gestionnaires r\u00e9seau disponibles).
<\/center> <\/p>\n
Les r\u00e9sultats de l'\u00e9valuation de la vuln\u00e9rabilit\u00e9 des biblioth\u00e8ques publi\u00e9s par Google sont \u00e9galement int\u00e9ressants, concernant les d\u00e9pendances li\u00e9es \u00e0 Log4j. Selon Google, le probl\u00e8me concerne 8 % de tous les packages dans le d\u00e9p\u00f4t Maven Central. En particulier, 35863 packages Java associ\u00e9s \u00e0 Log4j sont vuln\u00e9rables, qu'ils soient d\u00e9pendances directes ou indirectes. Log4j est utilis\u00e9 comme d\u00e9pendance directe de premier niveau dans seulement 17 % des cas, tandis que dans 83 % des packages affect\u00e9s, la liaison se fait via des packages interm\u00e9diaires d\u00e9pendant de Log4j, c'est-\u00e0-dire des d\u00e9pendances de deuxi\u00e8me niveau ou plus (21 % - deuxi\u00e8me niveau, 12 % - troisi\u00e8me, 14 % - quatri\u00e8me, 26 % - cinqui\u00e8me, 6 % - sixi\u00e8me). Les d\u00e9lais de correction des vuln\u00e9rabilit\u00e9s laissent encore \u00e0 d\u00e9sirer : une semaine apr\u00e8s la d\u00e9couverte de la vuln\u00e9rabilit\u00e9, le probl\u00e8me n'a \u00e9t\u00e9 r\u00e9solu que dans 4620 des 35863 packages identifi\u00e9s, soit 13 %.
<\/center> <\/p>\n
Entre-temps, l'Agence am\u00e9ricaine de cybers\u00e9curit\u00e9 et de protection des infrastructures a publi\u00e9 une directive d'urgence, obligeant les agences f\u00e9d\u00e9rales \u00e0 identifier les syst\u00e8mes d'information vuln\u00e9rables \u00e0 Log4j et \u00e0 installer les mises \u00e0 jour qui bloquent le probl\u00e8me d'ici le 23 d\u00e9cembre. D'ici le 28 d\u00e9cembre, les organisations doivent rendre compte des travaux effectu\u00e9s. Pour faciliter l'identification des syst\u00e8mes probl\u00e9matiques, une liste de produits dans lesquels la vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 confirm\u00e9e a \u00e9t\u00e9 pr\u00e9par\u00e9e (la liste contient plus de 23 000 applications). \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Une](\"\/wp-content\/uploads\/2021\/12\/811931e8c3ae3f3f3c2e81db361034e6.jpg\")
<\/center> <\/p>\n![\"Une](\"\/wp-content\/uploads\/2021\/12\/1e61b09923c7e055fa635545f1b3de6b.jpg\")
<\/center> <\/p>\n