
Détecter et corriger les instances vulnérables d'Apache Commons Text dans les artefacts Java JAR/WAR ; identifier les classes par empreinte et analyser le bytecode pour les sites d'appel de CVE-2022-42889 (Text4Shell).
Cliquez pour trouver :
commons-text et leurs versionscommons-textcommons-text pour désactiver les comportements vulnérablesCVE-2022-42889 peut représenter une menace sérieuse pour un large éventail d'applications basées sur Java. Les questions importantes qu'un développeur peut se poser dans ce contexte sont :
commons-text ? Quelles versions ?Le code publié inclut-il commons-text ? Quelle version de la bibliothèque y est incluse ? Répondre à ces questions peut ne pas être immédiat en raison de deux facteurs :
Dépendances transitives : même si commons-text ne figure pas dans la liste des dépendances directes du projet, il peut être utilisé indirectement par une autre dépendance.
Le code de cette bibliothèque peut ne pas apparaître directement comme un fichier séparé, mais plutôt être intégré dans un autre fichier jar de code.
JFrog publie un outil pour aider à résoudre ce problème : scan_commons_text_versions. L'outil recherche le code de classe de StringLookupFactory (indépendamment des noms de fichiers .jar contenus et du contenu des fichiers pom.xml), et tente de déterminer la version des objets afin d'indiquer si la version incluse de commons-text est vulnérable.
commons-text ?Cette question est pertinente dans les cas où le développeur souhaite vérifier si les appels à commons-text dans la base de code peuvent transmettre des données potentiellement contrôlées par un attaquant. Bien que la façon la plus sûre de corriger la vulnérabilité, comme indiqué dans les avis de sécurité, soit d'appliquer les correctifs appropriés, contrôler et vérifier l'impact potentiel en supposant que commons-text n'est pas corrigé peut être utile dans de nombreuses situations.
scan_commons_text_calls_jar.py, qui localise les appels aux fonctions vulnérables dans les .jar compilés, et rapporte les résultats sous forme de nom de classe et noms de méthodes dans lesquels chaque appel apparaît.
commons-text vulnérables sur mon système, comment puis-je désactiver rapidement le comportement dangereux ?La mise à jour reste la meilleure solution - cette solution est destinée à l'application rapide de correctifs à chaud
Dans le contexte de la vulnérabilité CVE-2022-42889, la classe org/apache/commons/text/lookup/ScriptStringLookup dans commons-text permet l'exécution de scripts qui peuvent être intégrés dans une chaîne reçue d'une source contrôlée par un attaquant via ${script}. Par conséquent, les invocations de la fonction ScriptStringLookup.lookup indiquent que la fonctionnalité est activée.
Nous fournissons un outil, Text4ShellPatch, qui permet de corriger cet appel spécifique afin que la fonctionnalité d'exécution de scripts ne puisse pas être utilisée. Après application du correctif, la bibliothèque exécutera toujours un script renvoyant un message d'avertissement (au lieu du code potentiellement contrôlé par l'attaquant)
De même, les lookups DNS et URL peuvent charger du contenu non fiable s'ils sont contrôlés par un attaquant via ${dns} et ${url} ; ainsi, leurs lookups respectifs DnsStringLookup et UrlStringLookup peuvent être désactivés par un correctif pour renvoyer un message d'avertissement,
commons-text vulnérables ?Deux de nos outils offrent ensemble la possibilité de scanner et de corriger les fichiers jar commons-text vulnérables.
Un exemple de script bash est présent dans ce dépôt Github sous le nom scan_and_patch.sh. En résumé, il utilise le script scan_commons_text_versions.py pour trouver, sous un root-folder spécifique, les fichiers jar commons-text vulnérables avec une version vulnérable, puis exécute l'outil Text4ShellPatch sur eux comme suit.

scan_commons_text_versions.pypython scan_commons_text_versions.py root-folder [-quiet] [-exclude folder1 folder2 ..]
L'outil analyse root_folder de manière récursive à la recherche de fichiers .jar et .war ; dans chaque fichier localisé, l'outil recherche une classe StringLookupFactory.class (récursivement dans chaque fichier .jar). Si au moins une des classes est trouvée, l'outil tente de déterminer sa version (y compris certaines variations trouvées dans les correctifs et les backports de correctifs) afin d'indiquer si le code est vulnérable.
Avec l'option -quiet, seules les conclusions concernant les versions sont affichées, et les autres messages (fichiers non trouvés / archives impossibles à ouvrir / archives protégées par mot de passe) sont masqués.
Les dossiers apparaissant après -exclude (optionnel) sont ignorés.
scan_commons_text_calls_jar.pyL'outil nécessite Python 3 et les bibliothèques tierces suivantes : jawa, tqdm, easyargs, colorama
pip install -r requirements.txt
Le cas d'utilisation par défaut :
python scan_commons_text_calls_jar.py root-folder
analysera récursivement tous les fichiers .jar dans root-folder, en affichant pour chacun les emplacements (nom de classe et nom de méthode) des appels aux méthodes lookup/replace/replaceIn de StringSubstitutor/StringLookup.
L'outil peut être configuré pour d'autres cas d'utilisation à l'aide des options de ligne de commande suivantes.
text_4_shell_patchjava -jar Text4ShellPatch.jar TARGET_JAR [PATCHING_MODE]
Where TARGET_JAR is the application to patch and PATCHING_MODE is
0 (default): Patch Script lookup
1: Patch Script + DNS + URL lookups
[Note: The original Jar will be kept in the same folder with the .orig.jar extension]
L'outil recherche la classe org/apache/commons/text/lookup/ScriptStringLookup dans le jar commons-text fourni et remplace le contenu de la fonction lookup() par un message d'avertissement puis sort de la fonction. Ainsi, eval n'existera plus dans la nouvelle classe ScriptStringLookup.
Il peut également corriger les classes DnsStringLookup et URLStringLookup et désactiver la fonction lookup() lorsque l'option PATCHING_MODE est définie sur 1.
Un fichier de sauvegarde est généré au cours du processus dans le même chemin avec l'extension .orig.jar.
Text4ShellPatch peut être modifié et compilé avec Maven à l'aide de la simple commande :
mvn clean assembly:single. Cela créera un fichier Text4ShellPatch.jar dans le dossier target/.
Le correctif peut être appliqué à un fichier jar spécifique, pour le lookup script uniquement ou pour script, dns et url afin d'obtenir une meilleure protection au cas où ils ne sont pas destinés à être utilisés dans l'application,
Une sauvegarde est générée au même emplacement que le jar original avant son remplacement par le jar corrigé. Le nom du fichier de sauvegarde suit le motif suivant : <original_jar_name>_YYYY.MM.DD_HH.mm.ss.orig.jar où YYYY, MM, DD sont respectivement l'année, le mois et le jour, et HH, mm, ss sont respectivement l'heure, les minutes et les secondes.
Il est également possible de localiser les versions vulnérables de commons-text et de les corriger automatiquement, comme le montre la question suivante.
| Option | Valeur par défaut | Utilisation |
|---|
--class_regex | (.*StringSubstitutor|.*StringLookup) | Expression régulière pour le nom de classe requis |
--method_regex | (lookup|replace|replaceIn) | Expression régulière pour le nom de méthode requis |
--quickmatch_string | (StringLookup|StringSubstitutor) | Condition préalable pour l'analyse des fichiers : les fichiers .jar ne contenant pas l'expression régulière spécifiée seront ignorés |
--class_existence | Non défini | Lorsqu'elle n'est pas définie, recherche les appels à classe::méthode comme spécifié par les expressions régulières. Lorsqu'elle est définie, --method_regex est ignoré et l'outil recherchera l'existence des classes spécifiées par --class_regex dans le jar. |
--no_quickmatch | Non défini | Lorsqu'elle est définie, la valeur de --quickmatch_string est ignorée et tous les fichiers jar sont analysés |
--caller_block | .*org/apache/commons/text | Si la classe appelante correspond à cette expression régulière, elle ne sera pas affichée |