Tomcat corrige une faille DoS WebDAV à exploiter à distance

Ubuntu a publié l’avis USN-8450-1 pour corriger plusieurs vulnérabilités dans Tomcat, dont une faiblesse exploitable à distance menant à un déni de service lorsque le composant WebDAV est exposé. Le scénario mis en avant par l’éditeur concerne l’envoi de requêtes LOCK et PROPFIND contenant un corps de requête trop volumineux, ce qui peut provoquer une consommation excessive de ressources côté serveur. L’impact attendu n’est pas une exécution de code ou une élévation de privilèges, mais une dégradation forte de disponibilité, avec saturation CPU, mémoire ou threads de traitement selon l’architecture et la configuration du service.

Le sujet mérite l’attention des administrateurs systèmes, équipes DevOps et RSSI pour une raison simple : dans de nombreux environnements, Tomcat n’est pas directement exposé comme un serveur WebDAV, mais des applications, connecteurs ou configurations historiques peuvent laisser ce vecteur accessible sans besoin métier réel. Dans ce contexte, une faille de disponibilité sur des méthodes HTTP rarement utilisées devient un problème d’hygiène d’exposition autant qu’un problème de patch management.

La source de référence ici est l’avis officiel Ubuntu USN-8450-1: Tomcat vulnerabilities, qui indique que des versions de Tomcat empaquetées dans Ubuntu étaient vulnérables avant publication des mises à jour de sécurité. L’avis Ubuntu s’appuie sur les correctifs amont du projet Apache Tomcat. Lorsque le score CVSS ou l’identifiant CVE exact d’une faiblesse ne sont pas explicitement confirmés dans la source consultée, il est préférable de se référer directement à l’avis Ubuntu et aux notes de sécurité Apache Tomcat pour la cartographie complète des vulnérabilités concernées.

Pour les environnements francophones, ce type d’alerte concerne directement les déploiements auto-hébergés sur VM ou serveurs dédiés chez OVHcloud, Scaleway ou o2switch, mais aussi les plateformes internes où Tomcat est placé derrière nginx, HAProxy ou un WAF. Même lorsque le frontal HTTP absorbe une partie des requêtes anormales, il ne faut pas supposer que le backend Java est protégé par défaut : si les méthodes WebDAV transitent et que les limites de taille ne sont pas strictes, la charge peut atteindre Tomcat.

L’enjeu opérationnel est donc double :

• appliquer sans délai les mises à jour de sécurité Ubuntu publiées dans le cadre de USN-8450-1 ;
• vérifier si WebDAV est réellement nécessaire, puis réduire la surface d’attaque en bloquant les méthodes HTTP inutiles et en ajoutant des garde-fous côté reverse proxy.

Versions affectées

L’avis USN-8450-1 indique que des paquets Tomcat fournis par Ubuntu étaient vulnérables avant installation des mises à jour de sécurité publiées par Ubuntu. La bonne pratique consiste à raisonner en termes de paquets distribués par la distribution, et non uniquement en termes de version amont Apache Tomcat, car un même numéro de version apparent peut inclure des correctifs rétroportés par Ubuntu.

Les familles de paquets concernées dans Ubuntu sont celles de tomcat10 et/ou tomcat9 selon la version de la distribution installée. La liste exacte dépend de la branche Ubuntu déployée et du paquet présent sur l’hôte. L’information fiable à retenir est la suivante :

• sont affectés les systèmes Ubuntu utilisant un paquet Tomcat concerné non mis à jour avant la publication de USN-8450-1 ;
• sont corrigés les systèmes ayant installé la version corrigée publiée par Ubuntu via les dépôts de sécurité ;
• les correctifs correspondent aux mises à jour de sécurité Ubuntu et aux correctifs amont intégrés par le projet Apache Tomcat.

Pour éviter toute ambiguïté sur votre parc, il faut interroger directement le système et comparer la version installée à celle proposée par les dépôts de sécurité actifs.

Vérifier les paquets installés

Sur Ubuntu et dérivés, les commandes suivantes permettent d’identifier les paquets Tomcat présents et leur version :

dpkg -l | grep tomcat
apt-cache policy tomcat9
apt-cache policy tomcat10

Exemple de lecture :

• si Installed est inférieur à Candidate, une mise à jour de sécurité reste à appliquer ;
• si Installed correspond à Candidate et que les dépôts de sécurité Ubuntu sont bien activés, le correctif de l’avis USN doit être présent ;
• si Tomcat a été installé manuellement depuis une archive amont et non via APT, l’avis Ubuntu ne couvre pas ce déploiement : il faut alors suivre les notes de sécurité Apache Tomcat et mettre à niveau l’instance manuellement.

Identifier les services réellement exposés

Sur beaucoup de serveurs, le paquet est installé mais le service n’est pas directement joignable depuis Internet. Il faut donc distinguer :

• les nœuds où Tomcat écoute uniquement en local sur 127.0.0.1 ou derrière un proxy frontal ;
• les nœuds où le connecteur HTTP ou AJP est exposé plus largement ;
• les applications qui ont activé le support WebDAV ou laissé des méthodes HTTP non filtrées.

Quelques vérifications utiles :

ss -ltnp | grep java
grep -R "Servlet" /etc/tomcat* /var/lib/tomcat* /usr/share/tomcat* 2>/dev/null
grep -R "WebDAV" /etc/tomcat* /var/lib/tomcat* /usr/share/tomcat* 2>/dev/null

Ces commandes ne remplacent pas une revue de configuration applicative, mais elles aident à repérer rapidement un service Tomcat actif et des éléments de configuration liés à WebDAV.

Vecteur d’attaque

Le vecteur décrit par la source est distant et passe par des requêtes HTTP LOCK et PROPFIND avec un corps de requête trop volumineux. Ces méthodes appartiennent à l’écosystème WebDAV, une extension de HTTP historiquement utilisée pour l’édition distante de ressources, la gestion de propriétés et le verrouillage de contenus.

Dans un environnement moderne, WebDAV n’est pas toujours activé volontairement pour un usage métier. Il peut être :

• hérité d’une configuration ancienne ;
• activé pour des besoins d’administration ou de publication de contenu ;
• laissé accessible parce que le reverse proxy relaie toutes les méthodes HTTP sans filtrage ;
• présent dans un conteneur ou une image standardisée sans revue spécifique de la surface exposée.

Pourquoi LOCK et PROPFIND comptent

Contrairement aux méthodes plus courantes comme GET, POST ou HEAD, les méthodes WebDAV déclenchent des traitements spécifiques sur les ressources et leurs métadonnées. Lorsqu’un composant vulnérable accepte des corps de requête anormalement volumineux pour ces méthodes, plusieurs effets peuvent se cumuler :

• allocation mémoire importante pour lire, bufferiser ou parser la requête ;
• occupation prolongée des threads de traitement ;
• surcoût de parsing XML ou de gestion de propriétés selon l’implémentation ;
• augmentation de la pression sur la JVM, le garbage collector et les buffers réseau ;
• épuisement progressif des ressources si l’attaque est répétée ou parallélisée.

Le résultat observable n’est pas nécessairement un crash immédiat. Dans beaucoup de cas, l’attaque se traduit d’abord par une dégradation :

• temps de réponse qui explosent ;
• augmentation du nombre de connexions en attente ;
• erreurs 502 ou 504 côté reverse proxy ;
• redémarrages de service si un superviseur détecte un état dégradé ;
• OOM killer ou arrêt de la JVM dans les cas les plus sévères.

Scénario d’attaque concret

Un scénario réaliste en production est le suivant :

• un serveur expose une application Java derrière nginx ;
• le proxy transmet toutes les méthodes HTTP au backend Tomcat ;
• aucune limite stricte n’est définie sur la taille des corps de requête pour les méthodes WebDAV ;
• l’attaquant envoie une série de requêtes PROPFIND ou LOCK avec de très gros corps ;
• Tomcat consomme des ressources de façon disproportionnée ;
• les utilisateurs légitimes subissent des lenteurs ou une indisponibilité partielle ou totale.

Le point important ici est que l’attaquant n’a pas besoin d’identifiants si l’endpoint est accessible avant authentification ou si le filtrage des méthodes n’existe pas au niveau frontal. Même lorsqu’une authentification est requise plus loin dans la chaîne, une partie du coût de traitement peut être engagée avant le rejet.

Impact métier

Le principal impact est la disponibilité. Pour des services internes, cela peut interrompre des workflows applicatifs, des interfaces d’administration ou des API métier. Pour des services publics, les conséquences peuvent inclure :

• indisponibilité du site ou de l’application ;
• dégradation des SLA ;
• mobilisation d’équipes d’astreinte ;
• surconsommation d’infrastructure, notamment en environnement auto-scalé ;
• bruit dans la supervision, masquant d’autres incidents.

Dans des architectures mutualisées, un seul service Tomcat vulnérable peut aussi affecter le nœud hôte par contention mémoire ou CPU, avec impact collatéral sur d’autres applications. C’est particulièrement vrai sur des VM sous-dimensionnées, des instances à mémoire limitée ou des clusters où plusieurs services Java cohabitent.

Comparaison avec des problèmes récurrents de surface HTTP

Sans assimiler cette vulnérabilité à d’autres familles de failles, elle rappelle un point structurel : les méthodes HTTP rarement nécessaires en production restent souvent autorisées par défaut. En pratique, de nombreux incidents de sécurité ou de disponibilité ne viennent pas d’une fonctionnalité explicitement utilisée, mais d’une surface laissée ouverte parce qu’elle n’a jamais été revue. WebDAV est un bon exemple de ce décalage entre exposition technique et besoin métier réel.

Pour les équipes sécurité, le bon réflexe n’est donc pas seulement de patcher Tomcat, mais de vérifier si l’on accepte encore des méthodes comme LOCK, PROPFIND, MKCOL, COPY ou MOVE là où seules GET, POST et parfois PUT sont attendues.

Impact

L’avis Ubuntu décrit un déni de service par consommation excessive de ressources. Sur le terrain, l’effet exact dépend de plusieurs paramètres :

• version précise de Tomcat et correctifs présents ;
• activation effective de WebDAV ou d’un traitement associé ;
• taille maximale autorisée pour les requêtes ;
• présence d’un reverse proxy et de limites côté frontal ;
• nombre de threads du connecteur et capacité de la JVM ;
• profil mémoire de l’application hébergée.

Dans une architecture simple avec Tomcat directement exposé, l’impact peut être visible très vite. Dans une architecture en couches, le reverse proxy peut absorber une partie de la pression, mais aussi devenir lui-même un facteur aggravant si les timeouts et buffers sont mal réglés. Par exemple :

• si nginx accepte un gros corps et le relaie au backend, la pression se déplace vers Tomcat ;
• si le proxy attend longtemps la réponse du backend, les workers frontaux peuvent s’accumuler ;
• si l’auto-scaling se déclenche sur CPU ou latence, l’attaque peut générer un coût d’infrastructure inutile.

Dans des environnements conteneurisés, il faut aussi surveiller :

• les limites memory et cpu des pods ;
• les redémarrages répétés dus aux sondes de santé ;
• les erreurs en cascade sur les dépendances appelées par l’application ;
• les files d’attente ou pools JDBC qui se saturent lorsque les threads HTTP sont bloqués.

Autrement dit, même une vulnérabilité classée “DoS” et non “RCE” peut avoir un impact opérationnel élevé sur un service critique.

Comment patcher

La remédiation prioritaire consiste à installer les mises à jour de sécurité Ubuntu publiées dans le cadre de USN-8450-1. Si vous utilisez les paquets de la distribution, la méthode recommandée est de passer par apt.

Mise à jour via APT

sudo apt update
sudo apt install --only-upgrade tomcat9 tomcat10

Selon le système, un seul de ces paquets sera installé. Si vous ne savez pas lequel est présent, commencez par lister les paquets installés :

dpkg -l | grep tomcat

Ensuite, appliquez la mise à niveau ciblée du paquet réellement utilisé, par exemple :

sudo apt update
sudo apt install --only-upgrade tomcat9

ou :

sudo apt update
sudo apt install --only-upgrade tomcat10

Pour une mise à jour plus large du système incluant les correctifs de sécurité disponibles :

sudo apt update
sudo apt upgrade

Après installation, redémarrez le service si cela n’a pas été fait automatiquement :

sudo systemctl restart tomcat9
sudo systemctl restart tomcat10

Là encore, adaptez au service réellement présent. Vérifiez ensuite son état :

sudo systemctl status tomcat9
sudo systemctl status tomcat10

Validation post-correctif

Une fois la mise à jour appliquée, contrôlez trois points :

• la version installée correspond bien à la version corrigée publiée par Ubuntu ;
• le service a redémarré proprement ;
• les méthodes WebDAV inutiles ne sont plus exposées en frontal.

Commandes utiles :

apt-cache policy tomcat9
apt-cache policy tomcat10
journalctl -u tomcat9 --since "1 hour ago"
journalctl -u tomcat10 --since "1 hour ago"

Si Tomcat n’est pas fourni par les dépôts Ubuntu mais déployé manuellement depuis le site Apache, il faut appliquer la version corrigée publiée par l’éditeur amont selon votre branche supportée. Dans ce cas, la source de vérité devient la documentation de sécurité Apache Tomcat et non le packaging Ubuntu.

Cas des images et conteneurs

Si vous déployez Tomcat via image conteneur, la mise à jour ne doit pas se limiter au nœud hôte. Il faut :

• reconstruire l’image avec une base Ubuntu corrigée ou une image Tomcat amont mise à jour ;
• redéployer les pods ou conteneurs ;
• vérifier qu’aucune ancienne image vulnérable ne reste utilisée dans le cluster.

Dans une chaîne CI/CD, cela implique souvent :

• mise à jour du Dockerfile ;
• nouveau build ;
• scan de vulnérabilités post-build ;
• déploiement progressif avec surveillance de la latence et des erreurs.

Mitigation

Si le patch ne peut pas être appliqué immédiatement, il faut réduire l’exposition. L’objectif n’est pas de remplacer le correctif, mais de limiter le risque d’exploitation à distance en attendant la mise à jour.

Désactiver ou bloquer WebDAV si non nécessaire

La mesure la plus efficace est de vérifier si WebDAV est réellement utilisé. Dans de nombreux environnements, la réponse est non. Si c’est le cas, il faut empêcher le passage des méthodes concernées au plus près de l’entrée réseau.

Exemple avec nginx, pour refuser explicitement certaines méthodes :

if ($request_method ~ ^(LOCK|PROPFIND|MKCOL|COPY|MOVE|UNLOCK)$) {
    return 405;
}

Cette logique doit être intégrée avec précaution dans la configuration du site ou du serveur, testée puis rechargée :

sudo nginx -t
sudo systemctl reload nginx

Exemple avec HAProxy :

acl dav_methods method LOCK PROPFIND MKCOL COPY MOVE UNLOCK
http-request deny if dav_methods

Le point clé est de bloquer ce qui n’a pas de justification métier. Si certaines méthodes sont requises sur un périmètre précis, le filtrage doit être contextualisé par chemin, hôte ou backend.

Limiter la taille des requêtes côté frontal

Puisque le vecteur mentionné repose sur des corps de requête trop volumineux, il est pertinent d’imposer des limites strictes côté reverse proxy.

Avec nginx :

client_max_body_size 1m;

La valeur doit être adaptée au besoin métier réel. Une API d’upload ne peut pas avoir la même limite qu’une application d’administration sans transfert de fichiers. L’objectif est de faire tomber les requêtes anormales avant qu’elles n’atteignent Tomcat.

Pour des applications derrière Apache HTTP Server, des directives de limitation de taille et de méthodes peuvent également être mises en place au niveau du vhost ou du reverse proxy. Là encore, il faut s’appuyer sur la configuration officielle de votre frontal HTTP.

Réduire la surface au niveau réseau

Si Tomcat n’a pas vocation à être accessible directement depuis Internet, vérifiez :

• les règles de sécurité cloud ;
• les groupes de sécurité ;
• les ACL réseau ;
• les pare-feu locaux comme ufw ou nftables.

Exemple avec ufw pour n’autoriser que le frontal reverse proxy ou le réseau interne approprié :

sudo ufw status
sudo ufw deny 8080/tcp

Il ne s’agit pas d’une règle universelle à appliquer aveuglément, mais d’un rappel : beaucoup d’instances Tomcat restent exposées sur 8080 par simple oubli.

Ajuster les garde-fous JVM et applicatifs

Sans corriger la vulnérabilité, certains réglages peuvent améliorer la résilience :

• timeouts plus stricts côté proxy et backend ;
• limites de threads raisonnables pour éviter l’emballement ;
• surveillance de la mémoire heap et non-heap ;
• alertes sur redémarrages, OOM et saturation des connecteurs.

Ces mesures ne bloquent pas l’attaque, mais elles réduisent parfois l’impact ou accélèrent la détection.

Détection

La détection doit chercher des traces d’usage anormal des méthodes WebDAV et des symptômes de saturation. En l’absence d’IoC uniques publiés pour cette faille, les meilleurs indicateurs sont comportementaux.

Indicateurs côté logs HTTP

Sur les reverse proxies et journaux d’accès Tomcat, recherchez :

• des requêtes LOCK ou PROPFIND inhabituelles ;
• des corps de requête volumineux associés à ces méthodes ;
• une hausse brutale de réponses 4xx, 5xx, 502 ou 504 ;
• des rafales provenant d’une même adresse IP ou d’un petit ensemble d’IP ;
• des user-agents atypiques ou absents.

Exemples de recherches simples :

grep -E '"(LOCK|PROPFIND) ' /var/log/nginx/access.log
grep -E '"(LOCK|PROPFIND) ' /var/log/apache2/access.log
grep -E 'LOCK|PROPFIND' /var/log/tomcat*/catalina*.log

Si vos logs incluent la taille de requête ou des champs enrichis, créez une vue dédiée pour les méthodes WebDAV afin d’identifier rapidement les valeurs aberrantes.

Indicateurs côté système

Une exploitation en cours ou récente peut s’accompagner de :

• hausse CPU du processus Java ;
• consommation mémoire anormale ;
• augmentation du nombre de connexions actives ;
• threads bloqués ou très nombreux ;
• messages d’erreur dans journalctl ou les logs Tomcat.

Quelques commandes utiles :

top -p $(pgrep -d',' -f tomcat)
ss -tan | grep ':8080'
journalctl -u tomcat9 --since "2 hours ago"
journalctl -u tomcat10 --since "2 hours ago"

Dans un cluster Kubernetes ou une plateforme orchestrée, ajoutez :

• analyse des redémarrages de pods ;
• surveillance des événements OOM ;
• corrélation entre pics de latence et méthodes HTTP rares ;
• revue des métriques du reverse proxy et de l’ingress controller.

IoC pratiques à surveiller

Pour ce type de vulnérabilité DoS, les IoC les plus utiles sont des patterns d’activité :

• présence de requêtes LOCK et PROPFIND sur des applications qui n’utilisent pas WebDAV ;
• pics de trafic vers des chemins de publication, dépôts documentaires ou racines applicatives ;
• augmentation de la taille moyenne des requêtes sur ces méthodes ;
• corrélation temporelle entre ces requêtes et une dégradation de disponibilité ;
• multiplication de connexions incomplètes ou longues si le frontal tente de relayer les corps volumineux.

Ces indicateurs doivent être intégrés à la supervision existante, idéalement avec des alertes dédiées sur les méthodes HTTP inhabituelles. Si votre SOC collecte les journaux via un SIEM, une règle simple sur request_method IN ("LOCK","PROPFIND") peut déjà faire remonter des expositions non documentées.

Recommandations stratégiques

Au-delà du correctif immédiat, cette alerte rappelle plusieurs principes de durcissement serveur :

• inventorier les méthodes HTTP autorisées par application et par frontal ;
• documenter les usages réels de WebDAV et supprimer les activations historiques non justifiées ;
• appliquer des limites de taille cohérentes avec les besoins métier ;
• isoler Tomcat derrière un reverse proxy filtrant ;
• mettre à jour les images de base et paquets système de façon régulière ;
• tester la résilience face aux méthodes rares et aux gros corps de requête dans les revues de configuration.

Pour les RSSI, le sujet est aussi un rappel de gouvernance : les vulnérabilités de disponibilité sur des composants middleware comme Tomcat passent parfois sous le radar parce qu’elles ne promettent pas une compromission complète. Pourtant, sur des services critiques, un DoS exploitable à distance peut avoir un coût opérationnel et réputationnel significatif, surtout si l’exposition est triviale et la mitigation absente.

Dans l’écosystème Ubuntu, l’avis USN-8450-1 s’inscrit dans le cycle normal de maintenance de sécurité des paquets serveur. Pour les organisations françaises, il est utile de croiser ce type d’alerte avec les pratiques de veille interne, les bulletins éditeurs et, lorsque pertinent, les recommandations du CERT-FR sur la réduction de surface d’attaque et le maintien en condition de sécurité des services exposés.

La source originale à citer et à consulter pour la liste précise des paquets corrigés reste l’avis officiel Ubuntu : USN-8450-1: Tomcat vulnerabilities. Pour les environnements non gérés par paquets Ubuntu, il faut également consulter les notes de sécurité du projet Apache Tomcat afin d’aligner la branche déployée sur une version amont corrigée.

En pratique, la priorité est claire : mettre à jour Tomcat via les paquets de sécurité Ubuntu, vérifier si WebDAV est réellement exposé, bloquer les méthodes HTTP inutiles et imposer des limites de taille côté reverse proxy. Pour aller plus loin sur le durcissement des services exposés, la réduction de surface HTTP et les garde-fous d’exploitation, un détour par la catégorie /categorie/pratiques reste pertinent dans une démarche d’hygiène serveur durable.