Vous consultez actuellement l'aide de la version:

Présentation


L’équipe d’AEM chez Adobe travaille en étroite collaboration avec le projet NotSoSerial open source pour limiter les vulnérabilités décrites dans CVE-2015-7501. NotSoSerial est accordé sous licence Apache 2 et comprend du code ASM accordé sous sa propre licence de type BSD.

Le fichier JAR d’agent inclus dans ce module est la distribution de NotSoSerial modifiée par Adobe. Pour plus d’informations, voir la section Historique des révisions ci-dessous.

NotSoSerial est une solution de niveau Java à un problème de niveau Java, et il n’est pas spécifique à AEM. Il ajoute un contrôle en amont à une tentative de désérialisation d’un objet. Ce contrôle teste un nom de classe par rapport à une liste blanche et/ou une liste noire de style pare-feu. En raison du nombre limité de classes dans la liste noire par défaut, il est peu probable que cela ait un impact sur vos systèmes ou votre code.

Par défaut, l’agent effectue un contrôle de liste noire en vérifiant les classes vulnérables actuellement connues. Cette liste noire est destinée à vous protéger contre la liste actuelle des attaques qui utilisent ce type de vulnérabilité.

La liste noire et la liste blanche peuvent être configurées en suivant les instructions de la section Configuration de l’agent de cet article.

L’agent est conçu pour vous aider à limiter les dernières classes vulnérables connues. Si votre projet désérialise des données non approuvées, il peut être vulnérable aux attaques par déni de service, aux attaques de mémoire insuffisante et aux futures attaques inconnues de désérialisation.

Adobe prend officiellement en charge Java 6, 7 et 8, toutefois, il semble que NotSoSerial prend également en charge Java 5.

Installation de l’agent

Remarque :

Si vous avez déjà installé le correctif de sérialisation pour AEM 6.1, supprimez les commandes de démarrage de l’agent de la ligne d’exécution Java.

  1. Installez le lot com.adobe.cq.cq-serialization-tester.

  2. Accédez à la console web de lots : http://<serveur>:<port>/system/console/bundles.

  3. Recherchez le lot de sérialisation et démarrez-le. Cela devrait charger automatiquement et dynamiquement l’agent NotSoSerial.

Installation de l’agent sur les serveurs d’applications

L’agent NotSoSerial n’est pas inclus dans la distribution standard d’AEM pour les serveurs d’applications. Cependant, vous pouvez l’extraire du fichier de distribution JAR d’AEM et l’utiliser avec la configuration de votre serveur d’applications :

  1. Tout d’abord, téléchargez le fichier QuickStart AEM et extrayez-le :

    java -jar aem-quickstart-6.2.0.jar -unpack
  2. Accédez à l’emplacement du QuickStart AEM que vous venez de décompresser, et copiez le dossier crx-quickstart/opt/notsoserial/ dans le dossier crx-quickstart de l’installation du serveur d’applications AEM.

  3. Modifiez la propriété de /opt sur l’utilisateur exécutant le serveur :

    chown -R opt <user running the server>
  4. Configurez l’agent et vérifiez qu’il a été correctement activé, comme indiqué dans les sections suivantes de cet article.

Configuration de l’agent

La configuration par défaut est appropriée pour la plupart des installations. Cela inclut une liste noire des classes vulnérables connues pour l’exécution distante et une liste blanche de modules où la désérialisation des données de confiance doit être relativement sécurisée.


La configuration de pare-feu est dynamique et peut être changée à tout moment en :

  1. accédant à la console web à l’adresse http://serveur:port/system/console/configMgr ;

  2. recherchant Configuration du pare-feu de désérialisation et en cliquant dessus.

    Remarque :

    Vous pouvez également atteindre la page de configuration directement en accédant à l’URL :

    • http://serveur:port/system/console/configMgr/com.adobe.cq.deserfw.impl.DeserializationFirewallImpl

Cette configuration contient la liste blanche, la liste noire et la consignation de désérialisation.

Liste blanche

Dans la section Liste blanche se trouvent les classes ou les préfixes de modules pour lesquels la désérialisation est autorisée. Il est important de noter que si vous désérialisez vos propres classes, vous devez ajouter les classes ou les modules à cette liste blanche.

Liste noire

Dans la section Liste noire, se trouvent les classes pour lesquelles la désérialisation n’est jamais autorisée. L’ensemble initial de ces classes est limité à celles qui sont considérées comme vulnérables aux attaques d’exécution à distance. La liste noire est appliquée avant toute entrée de la liste blanche.

Journalisation des diagnostics

Dans la section pour la journalisation des diagnostics, vous pouvez choisir plusieurs options afin de consigner les moments où la désérialisation a lieu. Les désérialisations sont uniquement consignées lors de la première utilisation, elles ne le sont pas pour les utilisations suivantes.

La valeur par défaut class-name-only vous notifie les classes qui sont désérialisées.

Vous pouvez également définir l’optionfull-stack qui consigne une pile Java de la première tentative de désérialisation afin de vous informer lorsque votre désérialisation a lieu. Cela peut être utile pour rechercher et supprimer la désérialisation de votre utilisation.

Vérification de l’activation de l’agent

Vous pouvez vérifier la configuration de l’agent de désérialisation en accédant à l’URL :

  • http://serveur:port/system/console/healthcheck?tags=deserialization

Lorsque vous accédez à l’URL, la liste des contrôles de l’intégrité associés à l’agent s’affiche. Vous pouvez déterminer si l’agent est correctement activé en vérifiant la réussite des contrôles de l’intégrité. S’ils échouent, vous pouvez être amené à charger l’agent manuellement.

Pour plus d’informations sur la résolution des incidents avec l’agent, voir Gestion des erreurs lors du chargement dynamique de l’agent ci-dessous.

Remarque :

Si vous ajoutez org.apache.commons.collections.functors à la liste blanche, le contrôle de l’intégrité échoue systématiquement.

Gestion des erreurs lors du chargement dynamique de l’agent

Si des erreurs sont exposées dans le journal, ou si les étapes de vérification détectent un problème lors du chargement de l’agent, vous devrez peut-être charger l’agent manuellement. Cela est également recommandé au cas où vous utilisez un JRE (Java Runtime Environment) plutôt qu’un JDK (Java Development Toolkit), dans la mesure où les outils pour le chargement dynamique ne sont pas disponibles.

Pour charger l’agent manuellement, suivez les instructions ci-dessous :

  1. Modifiez les paramètres de démarrage de la JVM du fichier JAR de CQ, en ajoutant l’option suivante :

    -javaagent:<aem-installation-folder>/crx-quickstart/opt/notsoserial/notsoserial.jar

    Remarque :

    Pour cela, utilisez également l’option -nofork de CQ/d’AEM, avec les paramètres appropriés de mémoire JVM, car l’agent ne sera pas activé sur une JVM divisée.

    Remarque :

    La distribution Adobe du fichier JAR de l’agent NotSoSerial réside dans le dossier crx-quickstart/opt/notsoserial/ pour votre installation AEM.

  2. Arrêtez et redémarrez la JVM.

  3. Vérifiez à nouveau l’activation de l’agent en suivant les étapes décrites ci-dessus dans Vérification de l’activation de l’agent.

Autres considérations

Si vous exécutez sur une JVM IBM, voir la documentation sur la prise en charge de l’API Attach Java à cet emplacement.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne