BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Le Point Sur L'Actualité De Java - Semaine Du 13 Décembre 2021

Le Point Sur L'Actualité De Java - Semaine Du 13 Décembre 2021

Le tour d'horizon dans l'écosystème Java de cette semaine du 13 décembre 2021, présente des nouvelles du JDK 19, des mises à jour sur la vulnérabilité Log4Shell, des déclarations des fournisseurs sur Log4Shell liées à leurs produits, des versions ponctuelles de divers projets liés à Spring et Hibernate, WildFly 26, Payara Platform, Quarkus 2.5.3.Final, Apache Camel 3.14.0, Piranha 21.11.0 et Apache Tika 2.2.0.

JDK 18

Une semaine après le passage du JDK 18 à Rampdown Phase One, ce fut une semaine calme pour l'activité de construction de JDK 18. Plus de détails sur le Build 27 peuvent être trouvés dans les notes de release.

JDK 19

Le Build 2 du JDK 19 early-access builds a également été rendue disponible la semaine dernière, avec des mises à jour de la version 1 qui incluent des correctifs pour divers problèmes.

Pour les JDK 18 et JDK 19, les développeurs sont encouragés à signaler les bugs via la Java Bug Database.

Mises à jour de la vulnérabilité Log4Shell

Deux CVE supplémentaires, CVE-2021-4104 et CVE-2021-45046, lié à la vulnérabilité Log4Shell d'origine, CVE-2021-44228, ont été publiés pour fournir des informations mises à jour

Il a été déterminé que Log4j 2.15.0, la version qui a traité la CVE-2021-44228, la vulnérabilité Log4Shell, était incomplète car une vulnérabilité existait toujours dans certaines configurations autres que celles par défaut. Comme décrit dans la CVE-2021-45046 :

Cela pourrait permettre aux attaquants de contrôler les données d'entrée du Thread Context Map (MDC) lorsque la configuration de la journalisation utilise un pattern layout autre que celle par défaut avec une recherche de contexte (par exemple, $${ctx:loginId}) ou un pattern de Thread Context Map (%X, %mdc, ou %MDC) pour créer des données d'entrée malveillantes à l'aide d'un pattern JNDI Lookup entraînant une attaque par déni de service (DOS). Log4j 2.15.0 fait de son mieux pour restreindre les recherches LDAP JNDI à localhost par défaut. Log4j 2.16.0 résout ce problème en supprimant la prise en charge des patterns de recherche dans les messages et en désactivant la fonctionnalité JNDI par défaut.

Déclarations du fournisseur sur la vulnérabilité Log4Shell

Red Hat déclare sur Quarkus :

Comme Quarkus, ses extensions et dépendances n'utilisent pas la bibliothèque principale log4j version 2, il n'est PAS sensible à cette vulnérabilité. Dans la plupart des cas, aucune action corrective n'est requise pour les projets soutenus par Quarkus que vous pourriez avoir.

Red Hat déclare sur WildFly :

Cette vulnérabilité est dans le code de l'artefact Log4j 2 org.apache.logging.log4j:log4j-core. Le projet du serveur d'applications WildFly ne fournit pas cet artefact, et il ne l'a jamais fait. Ainsi, la seule façon dont une application s'exécutant sur WildFly serait vulnérable à la vulnérabilité CVE-2021-44228 est si l'artefact log4j-core a été ajouté à l'installation du serveur, soit via un module JBoss Modules fourni par l'utilisateur, soit plus probablement en ajoutant log4j-core dans un artefact de déploiement d'application.

Tomitribe déclare sur Tomcat, TomEE et ActiveMQ qui comprend une description détaillée de la vulnérabilité et comment tester :

Tomcat, TomEE et ActiveMQ eux-mêmes ne sont pas livrés avec log4j2, donc s'exécutant directement avec leur configuration par défaut, ils ne sont pas vulnérables à ce problème.

Hibernate déclare sur les projets Hibernate :

Les projets Hibernate ne sont pas affectés par les vulnérabilités derrière CVE-2021-45046 et CVE-2021-44228 : aucun des projets Hibernate n'a de dépendance d'exécution sur Log4j core.

Nous utilisons JBoss Logging, qui fournit une API pont minimale vers le backend de votre enregistreur de choix et ne propose pas de fonctionnalités sophistiquées sur les lookups JNDI.

Object Computing, Inc. déclare sur le framework Micronaut :

Par défaut, les applications Micronaut utilisent Logback. Ainsi, la plupart des applications Micronaut ne sont pas affectées.

Cependant, votre application serait vulnérable si elle incluait une entrée non fiable dans les messages de journal et tire log4j-core en tant que dépendance transitive.

L'Apache Software Foundation déclare sur Apache Camel en production :

Apache Camel ne dépend pas directement de Log4j 2, nous ne sommes donc pas affectés par la CVE-2021-44228.

Si vous avez explicitement ajouté la dépendance Log4j 2 à vos propres applications, assurez-vous de mettre à niveau.

La déclaration d'IBM sur Open Liberty fournit un guide sur Log4j CVE-2021 -44228, CVE-2021-4104 et CVE-2021-45046 incluant un certain nombre de FAQ :

Open Liberty ne livre pas log4j et, par conséquent, les données journalisées par Open Liberty ne vous mettront pas en danger. Cependant, log4j est un framework largement utilisé et vos applications peuvent utiliser Log4J. Par conséquent, nous avons préparé les questions-réponses suivantes pour les développeurs à la recherche de conseils.

Spring Framework

Ce fut une semaine chargée chez Spring car un certain nombre de versions ponctuelles et importantes ont été faites pour certains de leurs projets.

Spring Framework 5.3.14 et 5.2.19 ont été publiés avec 36 corrections de bugs et améliorations et 11 corrections de bugs et améliorations, respectivement.

En route vers Spring Framework 6.0, la première version milestone a été mise à disposition qui jette les bases pour exiger un JDK 17+ et Jakarta EE 9. Une partie de la nouvelle infrastructure comprendra également un nettoyage des fonctionnalités dépréciés et obsolètes. Les développeurs sont encouragés à consulter la page de mise à niveau et plus de détails peuvent être trouvés dans cet article d'actualité d'InfoQ.

Spring Cloud 2020.0.5, nom de code Ilford, a été publié pour inclure les mises à niveau des sous-projets Spring Cloud tels que Spring Cloud Kubernetes, Spring Cloud Gateway, Spring Cloud Vault et Configuration Spring Cloud.

La quatrième version milestone de Spring GraphQL 1.0.0 a été mise à disposition avec des améliorations du modèle de programmation d'annotations et une prise en charge étendue de Spring Data à partir de Spring GraphQL 1.0.0-M3. Les nouvelles fonctionnalités de Spring GraphQL 1.0.0-M4 incluent les projections d'interface et la validation standard du bean pour les arguments GraphQL, et la prise en charge de Query By Example.

Spring Cloud Square 0.4.0-RC1 a été mis à disposition en tant que version de correction de bugs. Vous trouverez plus de détails dans les release notes.

WildFly

Red Hat a publié WildFly 26 et WildFly Preview 26 avec : la prise en charge de MicroProfile 5,0 ; la configuration cloud améliorée en permettant aux développeurs de remplacer les valeurs des attributs de gestion à l'aide de variables d'environnement ; et un nouveau type de JAAS security realm dans le sous-système Elytron. Vous trouverez plus de détails dans la liste des problèmes.

Les images Docker de WildFly 26 Source-to-Image (S2I) ont été publiées sur quay.io, l'utilitaire de Red Hat pour créer, analyser et distribuer des images de conteneurs. Ces images désapprouvent désormais quay.io/wildfly/wildfly-centos7 et quay.io/wildfly/wildfly-runtime-centos7.

Payara

Payara a publié son édition de décembre 2021 de Payara Platform. L'édition Payara Platform Community 5.2021.10 comprend six améliorations, un correctif de sécurité, sept correctifs de bugs et deux mises à niveau de composants. L'édition Payara Platform Enterprise 5.34.0 comprend sept améliorations, un correctif de sécurité, huit correctifs de bugs et une mise à niveau de composant.

Le correctif de sécurité pour les deux éditions adresse CVE-2021-40690, une vulnérabilité identifiée dans les versions d'Apache Santuario antérieures à 2.2.3 et 2.1.7 dans lesquels la propriété secureValidation est incorrectement transmise lors de la création des classes KeyInfo et KeyInfoReference. Cela permet à un attaquant d'abuser d'un XPath Transform pour extraire des fichiers locaux .xml dans un élément RetrievalMethod.

Vous trouverez plus de détails dans les release notes des éditions Community et Enterprise.

Hibernate

Hibernate Reactive 1.1.1.Final a été publié avec la prise en charge d'Hibernate ORM 5.6.2.Final. Plus de détails peuvent être trouvés dans la liste des problèmes.

Les versions de maintenance d'Hibernate Validator 6.2.1.Final et 7.0.2.Final ont été rendus disponibles la semaine dernière. Malgré le fait que tous les projets Hibernate sont livrés avec JBoss Logging, Log4j2 reste une dépendance de test et il a été déterminé que les analyses de sécurité ne sont pas aussi fines qu'elles pourraient l'être.

Quarkus

Une troisième version de maintenance, Quarkus 2.5.3.Final, a été mise à disposition par Red Hat comportant de nombreuses corrections de bugs et des améliorations de la documentation. Vous trouverez plus de détails dans le changelog.

Apache Camel

Apache Camel 3.14.0 a été mis à disposition avec 111 nouvelles fonctionnalités, améliorations et corrections de bugs. Il s'agit de la dernière version à prendre en charge le JDK 8. Plus de détails peuvent être trouvés dans les release notes.

Piranha

Piranha 21.11.0 a été publié. Surnommée l'édition "Are we there ?", cette version comprend des plugins Maven pour Piranha Micro et Piranha Server. De plus amples détails peuvent être trouvés dans leur documentation et issue tracker.

Apache Tika

Apache Tika a publié la version 2.2.0 de sa boîte à outils d'extraction de métadonnées. Anciennement un sous-projet d'Apache Lucene, cette dernière version comprend : une mise à niveau vers log4j 2.15.0, un nouvel analyseur pour les fichiers OneNote téléchargés depuis Office365 ; de nombreuses améliorations de la détection de fichiers telles que les profils JPEG XL, MARC, ICC ; et des améliorations aux modules tika-pipes.

 

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT