Nginx : CVE critiques et sécurisation de votre serveur web

Nginx est le deuxième serveur web le plus utilisé au monde et le premier reverse proxy. Sa réputation de légèreté et de performance est bien méritée, mais comme tout logiciel critique exposé sur internet, Nginx accumule des vulnérabilités qui nécessitent une veille régulière.

CVE-2021-23017 : Buffer Overwrite dans le Resolver DNS (CVSS 7.7)

La vulnérabilité DNS d'Nginx

En mai 2021, une vulnérabilité dans le resolver DNS de Nginx — le composant qui résout les noms de domaine pour les configurations de proxy. En forgeant une réponse DNS malveillante, un attaquant pouvait provoquer un écrasement d'un octet dans la mémoire du processus Nginx.

Conditions d'exploitation :

• resolver configuré dans nginx.conf (pas activé par défaut)
• L'attaquant doit contrôler ou intercepter les réponses DNS

# Configuration vulnérable
resolver 8.8.8.8 valid=300s;
resolver_timeout 5s;

Versions affectées : Nginx 0.6.18 à 1.20.0

Bien que le score CVSS soit "seulement" 7.7, en pratique l'exploitation sur des architectures spécifiques pouvait conduire à une exécution de code.

CVE-2022-41741 et CVE-2022-41742 : ngx_http_mp4_module (CVSS 8.1)

Deux vulnérabilités dans le module ngx_http_mp4_module (traitement de fichiers MP4 pour la vidéo à la demande) :

• CVE-2022-41741 : Corruption mémoire permettant potentiellement une exécution de code via un fichier MP4 forgé
• CVE-2022-41742 : Lecture mémoire hors limites via un fichier MP4 forgé

Ces CVE ne sont exploitables que si mp4 est configuré dans nginx.conf — un module désactivé par défaut mais souvent activé dans les configurations de streaming vidéo.

CVE-2013-2028 : Stack Buffer Overflow (CVSS 7.5)

Une vulnérabilité historique mais importante : un débordement de pile dans le traitement des requêtes chunked HTTP/1.1. Affectait Nginx 1.3.9 à 1.4.0 et permettait une exécution de code à distance. Patchée rapidement mais illustre que même des composants fondamentaux peuvent être vulnérables.

Mauvaises configurations Nginx courantes

La plupart des problèmes Nginx viennent de la configuration, pas du moteur lui-même.

Alias Path Traversal

# VULNÉRABLE — path traversal possible
location /static {
    alias /var/www/files/;
}
# /static../etc/passwd → lit /var/www/files/../etc/passwd = /etc/passwd

# CORRECT — utiliser root ou ajouter / final
location /static/ {
    alias /var/www/files/;
}

Exposition de fichiers sensibles

# DANGEREUX — expose les fichiers de backup et config
location / {
    root /var/www/html;
}
# Accessible : /backup.sql, /.env, /config.php.bak

# CORRECT — bloquer les extensions sensibles
location ~* \.(env|sql|bak|conf|ini|log|sh|git)$ {
    deny all;
    return 404;
}

Status page accessible publiquement

# DANGEREUX — révèle les connexions actives
location /nginx_status {
    stub_status on;
}

# CORRECT
location /nginx_status {
    stub_status on;
    allow 127.0.0.1;
    deny all;
}

Sécuriser Nginx

1. Mettre à jour Nginx

# Vérifier la version
nginx -v

# Mettre à jour Debian/Ubuntu
apt-get update && apt-get upgrade nginx

# Mettre à jour CentOS/RHEL
yum update nginx

# Vérifier la version après mise à jour
nginx -v

2. Configuration de base sécurisée

# nginx.conf — paramètres de sécurité globaux
http {
    # Masquer la version Nginx
    server_tokens off;

    # Limiter les méthodes HTTP
    # (dans chaque server block)
    
    # Timeouts pour prévenir les attaques lentes
    client_body_timeout 10;
    client_header_timeout 10;
    keepalive_timeout 5 5;
    send_timeout 10;

    # Limiter la taille des requêtes
    client_max_body_size 10m;
    client_body_buffer_size 128k;

    # Protection contre le clickjacking et XSS
    add_header X-Frame-Options SAMEORIGIN always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}

3. Configuration TLS sécurisée

server {
    listen 443 ssl http2;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Protocoles sécurisés uniquement
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # HSTS
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
}

4. Rate limiting pour prévenir les attaques

# Définir une zone de rate limiting
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

5. Désactiver les modules inutiles à la compilation

Si vous compilez Nginx depuis les sources :

./configure \
  --without-http_autoindex_module \
  --without-http_ssi_module \
  --without-http_geo_module \
  # Supprimer les modules non utilisés

Pour les versions packagées, utilisez les packages -light qui incluent moins de modules.

Nginx Plus vs Nginx Open Source

Nginx Plus (version commerciale) bénéficie de patches de sécurité prioritaires et d'un support dédié. Pour une infrastructure critique, cette option mérite d'être considérée.

Vérifiez les CVE Nginx sur cveo.tech — cherchez nginx pour voir l'historique complet des vulnérabilités référencées par la NVD.