Vulnérabilités

Toutes les versions antérieures à 3.7.0.

Moyenne

Lors de l'établissement d'une connexion backend vers la JVM, les versions antérieures du Wrapper supposaient un niveau de confiance raisonnable pour les processus s'exécutant dans l'environnement local. Bien que la connexion ait été authentifiée, elle s'appuyait sur une clé exposée sur la ligne de commande. Il existait une fenêtre étroite pendant laquelle un processus malveillant pouvait capturer la clé et gagner une condition de course en se connectant avant la JVM.

Sous Windows, le risque de capture de la clé était limité car la clé n'était exposée qu'aux processus s'exécutant sous le même compte utilisateur ou avec des privilèges Administrateur. Cependant, il existait un risque de pipe squatting : un attaquant pouvait potentiellement créer de manière préventive le pipe nommé avant le Wrapper, empêchant ainsi l'établissement de la connexion légitime.

Ces vulnérabilités concernent principalement les systèmes multi-utilisateurs où des utilisateurs non fiables disposent de droits d'exécution locaux, ou les environnements déjà compromis. En cas d'exploitation, l'attaquant local pourrait provoquer un déni de service (empêchant la JVM de se connecter), intercepter des données sensibles échangées entre le Wrapper et la JVM, ou, dans certains cas, envoyer un identifiant de processus (PID) falsifié pour tromper le Wrapper afin qu'il termine un processus non prévu.

À partir de la version 3.7.0, le Wrapper a adopté une posture de sécurité plus stricte qui ne suppose plus un environnement local de confiance. Pour établir un canal réellement sécurisé avec la JVM, plusieurs aspects de la communication backend ont été repensés, de la création du canal à l'authentification et à la vérification de l'intégrité des données.

Les changements les plus notables sont :

• Le type de connexion backend par défaut a été changé en PIPE, qui est intrinsèquement plus sécurisé que les sockets TCP/IP pour la communication inter-processus un-à-un.

• Sous Windows, des protections supplémentaires empêchent le pipe squatting et les attaques par déni de service, renforcées par la validation du PID et du SID (Security Identifier) lors de l'authentification du processus pair.

• Pour tous les types de connexion, la clé d'authentification, auparavant transmise comme propriété système de ligne de commande (-Dwrapper.key), est désormais délivrée exclusivement au processus Java lancé et générée avec une entropie cryptographique plus forte, atténuant le risque de divulgation ou de devinette.

• Le cycle de vie de la connexion a été repensé pour rejeter et ignorer les tentatives de connexion non autorisées (garantissant la disponibilité pour le processus légitime) et pour se réinitialiser proprement si la JVM doit être redémarrée.

• L'intégrité du PID client signalé (ainsi que des PID des processus enfants pour l'édition Professional) reçu via la connexion établie est désormais strictement vérifiée afin d'empêcher la terminaison non autorisée de processus.

• Sur les systèmes Unix, les descripteurs de fichiers du canal backend ne sont plus hérités par des sous-processus non liés, éliminant ainsi un vecteur potentiel d'interférence.

• Mettez à niveau vers la version 3.7.0 du Wrapper ou une version supérieure.

• En attendant qu'une mise à niveau puisse être effectuée, envisagez les mesures d'atténuation suivantes applicables sur les systèmes Unix :

  • Lors de l'exécution de la version 3.6.0 ou ultérieure du Wrapper (voir #13), utilisez wrapper.backend.type=PIPE. Comme les pipes anonymes s'appuient sur des descripteurs de fichiers hérités exclusivement par les processus enfants, la connexion est intrinsèquement protégée des processus locaux non liés même si la clé d'authentification est visible.

  • Assurez-vous que le durcissement au niveau du système d'exploitation est configuré pour masquer les lignes de commande des processus aux utilisateurs non privilégiés. Les mécanismes varient selon la plateforme (par ex., hidepid pour /proc sous Linux, ou security.bsd.see_other_uids=0 sysctl sous FreeBSD). Notez que certains systèmes d'exploitation restreignent cette visibilité par défaut.

• Assurez-vous que la machine hébergeant le Wrapper restreint l'accès d'exécution local uniquement aux utilisateurs de confiance.

Toutes les versions antérieures à 3.6.3.

Avertissement

Les applications utilisant le Wrapper 3.5.16 ou supérieur peuvent définir wrapper.disable_tests à TRUE pour bloquer une utilisation abusive potentielle des fonctionnalités de test. Si ce paramètre n'est pas appliqué, le risque de sécurité est élevé pour les applications autorisant l'exécution de code non vérifié — et potentiellement malveillant.

La classe WrapperManager expose plusieurs méthodes conçues pour tester les défaillances courantes des applications. Bien qu'utiles pour les tests, ces méthodes peuvent poser un risque de sécurité si elles sont invoquées par du code non fiable à l'exécution.

Le Wrapper prend en charge l'utilisation d'un Security Manager pour contrôler l'accès à ces fonctionnalités et à d'autres depuis ses toutes premières versions. Cependant, le Security Manager est rarement utilisé par les développeurs, et a donc été déprécié depuis Java 17, puis désactivé au démarrage depuis Java 24.

En alternative, la propriété wrapper.disable_tests a été introduite dans la version 3.5.16 pour désactiver globalement les méthodes de test. Cependant, sa valeur par défaut était FALSE dans toutes les versions antérieures à 3.6.2, ce qui signifie que la propriété devait être explicitement ajoutée à la configuration et définie à TRUE pour être effective.

Si ni le Security Manager ni la propriété wrapper.disable_tests ne sont utilisés pour restreindre l'accès, du code non fiable s'exécutant au sein de l'application (tel qu'un plugin malveillant ou compromis, un fichier JAR ou un module chargé dynamiquement) pourrait invoquer ces méthodes, provoquant des problèmes tels que des ralentissements ou des plantages, menant à une condition de déni de service (DoS).

La version 3.6.3 améliore la posture de sécurité par défaut en changeant la valeur par défaut de wrapper.disable_tests à TRUE, en journalisant un avertissement lorsque la propriété est explicitement définie à FALSE, et en ajoutant des mesures pour empêcher l'exécution non fiable de toute fonctionnalité de test au sein de la JVM.

• Ajoutez wrapper.disable_tests=TRUE à votre fichier de configuration (si la version du Wrapper est 3.5.16 ou supérieure), ou

• Mettez à niveau vers au moins la version 3.6.3 du Wrapper.

• En tant que directive générale pour une conception d'application sécurisée, restreignez toujours le chargement des plugins et modules au code de confiance et vérifié.

Versions de 3.5.8 à 3.5.60.

Critique (si des données sensibles sont transmises via le backend, ce qui est possible depuis la version 3.5.57, et que le backend est défini sur PIPE)

Lors de l'utilisation de wrapper.backend.type=PIPE, le Wrapper créait un pipe nommé avec des permissions trop ouvertes. Les éditions Windows ne sont pas concernées et peuvent utiliser PIPE en toute sécurité.

Il existait un problème de sécurité lorsque les propriétés wrapper.app.property étaient utilisées pour transmettre des données sensibles via le backend, car il était possible pour tout utilisateur ayant accès au serveur de consulter le contenu du pipe.

Le type de transmission par défaut utilise SOCKET, qui n'a pas ce problème.

• Utilisez wrapper.backend.type=SOCKET, ou

• Mettez à niveau vers la version 3.6.0 du Wrapper (ou supérieure), qui utilise des pipes anonymes avec des permissions appropriées.

Toutes les versions antérieures à 3.5.58.

Avertissement

Pour des raisons de compatibilité avec les anciennes versions de Windows, Microsoft a décidé que SeImpersonatePrivilege serait activé par défaut pour les services Windows. Ce privilège est automatiquement ajouté par le gestionnaire de contrôle des services (SCM) via l'ajout dynamique du groupe SERVICE lorsqu'un service est démarré.

SeImpersonatePrivilege permet à un processus d'emprunter l'identité d'un autre utilisateur. Bien que cela puisse être utile pour tester le comportement du processus sous différents contextes utilisateur, cela peut également poser des risques de sécurité importants. Le privilège peut en effet être abusé pour s'élever au compte LocalSystem qui possède le niveau de privilèges le plus élevé sur un système Windows.

Ce problème de sécurité ne s'applique qu'aux services configurés pour s'exécuter avec un compte autre que LocalSystem (sinon le service possède déjà les privilèges les plus élevés possibles). Cependant, il est souvent judicieux de s'exécuter sous un compte de service dédié afin de restreindre l'accès de l'application Java sur le système hôte, et inversement, d'empêcher d'autres processus tiers d'accéder à l'application et aux fichiers du Wrapper.

À partir de la version 3.5.58, le Wrapper désactivera SeImpersonatePrivilege lorsqu'il s'exécute en tant que service Windows avec un compte autre que LocalSystem (NT AUTHORITY\SYSTEM). La plupart des applications Java n'auront pas besoin de ce privilège, mais s'il est nécessaire, la propriété wrapper.ntservice.impersonation peut être utilisée pour le réactiver.

• Mettez à niveau vers la version 3.5.58 du Wrapper ou une version supérieure.

• Définissez les privilèges requis pour le service (nécessite l'édition Professional, version 3.5.57 ou supérieure).

• Il est possible de modifier les paramètres de la stratégie de sécurité locale, mais il existe un risque d'affecter d'autres services (non recommandé).

Toutes les versions antérieures à 3.5.58.

Élevée (si les conditions ci-dessous sont remplies).

L'API Java du Wrapper fournit la méthode WrapperManager.log() pour permettre au code utilisateur de journaliser un message au niveau de journalisation spécifié. Si le second argument, qui est le message à journaliser, contenait un caractère '%', le Wrapper pouvait planter, provoquant un déni de service.

Votre application est à risque si elle utilise des saisies utilisateur qui sont finalement transmises à la méthode WrapperManager.log().

• Mettez à niveau vers la version 3.5.58 du Wrapper ou une version supérieure.

• Ou, assurez-vous de supprimer tout caractère '%' dans le message à journaliser avant d'appeler WrapperManager.log().

Version 3.5.55.

Avertissement

Binaires Windows non signés.

Veuillez utiliser la version 3.5.56, qui est signée avec un certificat EV mis à niveau.

Versions 3.5.44 et 3.5.45.

Avertissement

Le fichier jar est signé avec un ancien certificat de signature de code (expirant le 15/12/2020 mais avec un horodatage valide jusqu'au 27/06/2027).

Le fichier jar peut être exécuté en toute sécurité.

Aucune action particulière n'est requise.

Version 3.5.44.

Moyenne

Les binaires Windows (wrapper.exe, wrapperw.exe, wrapper.dll) ne sont pas signés numériquement.

Bien que l'absence de signature ne constitue pas en soi une menace de sécurité, il n'est pas possible de vérifier l'authenticité et l'intégrité des binaires sans signature numérique. Microsoft Defender SmartScreen peut donc bloquer la première exécution et avertir d'un risque de sécurité.

• Mettez à niveau vers la version 3.5.45 du Wrapper ou une version supérieure.

• Assurez-vous toujours de télécharger les binaires du Wrapper depuis le site officiel de Java Service Wrapper et de les stocker dans un endroit sûr où ils ne peuvent pas être altérés.

Versions de 3.5.35 à 3.5.40.

Élevée (lorsque wrapper.lang.windows.encoding est utilisé)

À partir de la version 3.5.35, wrapper.lang.windows.encoding permet de modifier l'encodage de la locale utilisée par le processus Wrapper. Cela est utile, par exemple, pour imprimer la sortie des journaux en UTF-8 ou en utilisant un encodage spécifique.

Lorsque wrapper.lang.windows.encoding est défini, le Wrapper lit la sortie de la JVM dans un mode différent. Ce mode présente un bogue où un caractère pourcentage '%' dans la sortie de la JVM pouvait provoquer le plantage du Wrapper.

Votre application est particulièrement exposée si les saisies des utilisateurs clients peuvent se retrouver dans les journaux, la rendant vulnérable aux attaques par déni de service.

• Mettez à niveau vers la version 3.5.41 du Wrapper ou une version supérieure, ou

• Commentez wrapper.lang.windows.encoding ou définissez-le à sa valeur par défaut (ANSI).

Version 3.5.35.

Élevée

wrapper.lang.windows.encoding permet de modifier l'encodage de la locale utilisée par le processus Wrapper. Les chaînes UTF-8 sont traitées avec une fonction séparée qui utilise un tampon de taille fixe de 4096 caractères. Une sortie JVM plus large que cette largeur provoquerait un débordement de tampon.

Votre application est particulièrement à risque si de grandes saisies utilisateur peuvent se retrouver dans les journaux, car elles pourraient provoquer le plantage du Wrapper et mener à un déni de service.

Le Wrapper n'est pas concerné lorsque wrapper.lang.windows.encoding est laissé à sa valeur par défaut 'ANSI' ou lorsqu'un encodage autre que UTF-8 est utilisé.

• Mettez à niveau vers la version 3.5.41 du Wrapper ou une version supérieure, ou

• Définissez wrapper.lang.windows.encoding à une valeur autre que UTF-8.

Versions de 3.5.8 à 3.5.11.

Critique

Sur les plateformes UNIX, l'umask par défaut est défini à 0000 plutôt que d'hériter de la valeur du processus parent lors de l'exécution en tant que processus démon.

Les journaux et autres fichiers ont un accès en lecture/écriture global.

L'umask par défaut du processus Java serait également 0000, et donc celui de tous les fichiers créés par l'application Java, à moins qu'ils ne définissent explicitement de nouvelles permissions.

Le fichier d'ancrage, s'il est utilisé, peut être supprimé par n'importe qui et provoquer l'arrêt du Wrapper.

• Mettez à niveau vers la version 3.5.12 du Wrapper ou une version supérieure, ou

• Définissez la propriété wrapper.umask à une valeur sûre.

Toutes les versions antérieures à 3.3.7.

Avertissement

Une politique de sécurité SELinux stricte pouvait empêcher le Wrapper de charger la bibliothèque libwrapper.so.

Ceci n'est un problème que lors de l'exécution sur un système avec SELinux activé.

• Mettez à niveau vers la version 3.3.7 du Wrapper ou une version supérieure.

Toutes les versions antérieures à 3.3.0.

Élevée

Des plantages peuvent occasionnellement se produire sous UNIX 64 bits, causés par un problème de synchronisation native lorsque des signaux système sont interceptés. Bug #1614010.

Cette vulnérabilité pourrait être utilisée par des processus tiers pour tenter des attaques par déni de service.

Les binaires 32 bits ne sont pas concernés. Windows n'est pas concerné.

• Mettez à niveau vers la version 3.3.0 du Wrapper ou une version supérieure, ou

• Utilisez wrapper.ignore_signals=TRUE (non recommandé).

Versions de 3.0.0 à 3.1.2, puis de 3.2.2 à 3.2.3.

Élevée

La valeur de wrapper.ntservice.account et de wrapper.ntservice.password était stockée en clair dans le registre si elles étaient spécifiées sur la ligne de commande lors de l'installation du Wrapper en tant que service Windows.

• Bug #1538725

• Bug #1110183

• Mettez à niveau vers la version 3.1.2 du Wrapper ou une version supérieure.

• Ne spécifiez pas wrapper.ntservice.account ni wrapper.ntservice.password sur la ligne de commande lors de l'installation du Wrapper en tant que service Windows.

Toutes les versions antérieures à 2.2.6.

Élevée

Un caractère pourcentage '%' dans la sortie de la JVM pouvait provoquer le plantage du Wrapper.

Votre application est particulièrement exposée si les saisies des utilisateurs clients peuvent se retrouver dans les journaux, la rendant vulnérable aux attaques par déni de service.

• Mettez à niveau vers la version 2.2.6 du Wrapper ou une version supérieure.