📄 contenu.md 🔒 fd64c8dd…0160d159 Se connecter pour télécharger ← Retour
# 14. Dernières failles détectées — correctifs et analyse

Cette section documente des failles réelles et publiquement divulguées,
vérifiées par recherche datée début 2026 — jamais inventées ni supposées.
Organisation systématique par **catégorie de composant**, chaque entrée
suivant la même structure fixe : versions touchées, gravité, mécanisme
(pourquoi), risque concret, et commande de correction précise. Les
commandes utilisent la syntaxe `apt` (Debian/Ubuntu) à titre d'exemple —
adapter vers `dnf`/`rpm` (Fedora/RHEL/Rocky) ou le gestionnaire de la
distribution utilisée ; le principe (mettre à jour le paquet concerné puis
redémarrer le service ou la machine) reste identique.

**Attention — cette section documente des correctifs, jamais du code
d'exploitation.** Consulter systématiquement l'avis de sécurité officiel
de sa distribution avant d'appliquer une correction en production.

## Catégorie A — Noyau Linux (élévation de privilèges / déni de service)

### CVE-2026-46333 — Élévation de privilèges locale via ptrace

- **Versions touchées** : toutes branches antérieures aux versions
  corrigées ci-dessous ; correctif public le 14 mai 2026.
- **Versions corrigées (minimum sûr par branche)** : 5.10.260 · 5.15.211 ·
  6.1.177 · 6.6.144 · 6.12.95 · 6.18.38 · 7.0.14 · 7.1.3.
- **Gravité** : élevée.
- **Pourquoi** : un défaut de logique dans le traitement de `ptrace`
  (l'appel système qui permet à un processus d'inspecter/contrôler un
  autre processus, utilisé par les débogueurs) permettait à un processus
  non privilégié de contourner les vérifications de permission attendues.
- **Risque** : un utilisateur local sans privilège pouvait lire le fichier
  `/etc/shadow` via l'utilitaire `chage`, extraire les clés d'hôte SSH via
  `ssh-keysign`, ou exécuter des commandes en tant que root via `pkexec` —
  élévation de privilèges locale complète, sans interaction réseau.
- **Correction** :
  ```
  sudo apt update && sudo apt full-upgrade
  sudo reboot
  uname -r   # comparer au minimum sûr de la branche utilisée
  ```

### CVE-2026-63979 — Use-after-free dans le sous-système TLS noyau

- **Versions touchées** : noyau 6.4 et ultérieur, uniquement les systèmes
  utilisant les gestionnaires TLS intégrés au noyau (`net/handshake`).
- **Versions corrigées** : mêmes minimums sûrs que CVE-2026-46333
  ci-dessus (correctif publié dans le même cycle de maintenance).
- **Gravité** : critique — CVSS 9.8.
- **Pourquoi** : une erreur de gestion mémoire (utilisation d'une zone
  déjà libérée, ou déréférencement d'un pointeur nul selon le chemin de
  code emprunté) dans le sous-système qui gère les poignées de main TLS
  directement dans le noyau, plutôt que dans une bibliothèque en espace
  utilisateur.
- **Risque** : plantage du noyau (déni de service) dans le cas le plus
  bénin, exécution de code arbitraire en contexte noyau dans le pire cas.
- **Correction** :
  ```
  sudo apt update && sudo apt full-upgrade
  sudo reboot
  uname -r   # comparer au minimum sûr de la branche utilisée
  ```

## Catégorie B — Outils privilégiés locaux (sudo)

### CVE-2025-32463 — Élévation de privilèges root via sudo (chroot)

- **Versions touchées** : sudo 1.9.14 à 1.9.17 (inclus).
- **Version corrigée** : 1.9.17p1 ou supérieure.
- **Gravité** : critique — CVSS 9.3.
- **Pourquoi** : la fonctionnalité `chroot` de sudo (destinée à exécuter
  une commande dans un environnement racine alternatif) permettait, dans
  certaines conditions, de faire charger une bibliothèque partagée
  malveillante par un processus qui s'exécute ensuite avec les privilèges
  root — contournement de l'isolation attendue.
- **Risque** : un utilisateur local avec un accès sudo même limité pouvait
  obtenir une exécution de code arbitraire en tant que root.
- **Correction** :
  ```
  sudo apt update && sudo apt install --only-upgrade sudo
  sudo -V   # vérifier version >= 1.9.17p1
  ```
  Durcissement complémentaire recommandé (`visudo`, jamais éditer
  `/etc/sudoers` directement) : ajouter `Defaults !use_chroot` et
  supprimer toute directive `CHROOT=`/`runchroot=*` existante.

## Catégorie C — Services d'accès distant (OpenSSH)

### CVE-2026-35414 — Contournement d'authentification (principals + virgule)

- **Versions touchées** : OpenSSH antérieur à 10.3, uniquement les
  déploiements utilisant des certificats SSH avec autorité de
  certification (pas l'authentification par clé classique).
- **Version corrigée** : 10.3 ou supérieure.
- **Gravité** : élevée.
- **Pourquoi** : un défaut de validation d'entrée dans le traitement de
  l'option `principals` d'un fichier `authorized_keys`, dans un scénario
  précis combinant une autorité de certification et un caractère virgule
  dans le nom de principal d'un certificat SSH.
- **Risque** : un utilisateur disposant d'un certificat valide signé par
  une autorité de confiance pouvait s'authentifier en tant que **root**
  sur un serveur vulnérable, en contournant la restriction de principal
  attendue.
- **Correction** :
  ```
  sudo apt update && sudo apt install --only-upgrade openssh-server openssh-client
  sudo systemctl restart sshd
  ssh -V   # vérifier version >= 10.3
  ```

### CVE-2026-35387 — Mauvaise interprétation des algorithmes ECDSA

- **Versions touchées** : OpenSSH antérieur à 10.3, configurations ayant
  explicitement restreint la liste des algorithmes ECDSA acceptés.
- **Version corrigée** : 10.3 ou supérieure.
- **Gravité** : modérée à élevée selon la configuration.
- **Pourquoi** : une erreur d'interprétation de configuration faisait que
  le serveur OpenSSH traitait une liste d'algorithmes ECDSA comme
  signifiant « tous les algorithmes ECDSA autorisés », même quand
  l'administrateur avait explicitement restreint cette liste.
- **Risque** : un administrateur pensant avoir restreint les algorithmes
  de signature acceptés (ex. pour exclure une courbe jugée moins robuste)
  se retrouvait en réalité avec **tous** les algorithmes ECDSA acceptés —
  écart silencieux entre la configuration voulue et le comportement réel.
- **Correction** :
  ```
  sudo apt update && sudo apt install --only-upgrade openssh-server
  sudo systemctl restart sshd
  ```
  Après mise à jour, revérifier explicitement `HostKeyAlgorithms`/
  `PubkeyAcceptedAlgorithms` dans `sshd_config` — la correction du bug
  peut changer le comportement réel du filtrage déjà en place.

## Catégorie D — Telnet et persistance malveillante (famille Mirai / Tengu)

Les deux failles ci-dessous concernent `telnetd` (GNU inetutils). La 3e
entrée est **volontairement classée à part** : ce n'est PAS un CVE — c'est
une technique de persistance activement observée sur le terrain, qui
n'exploite aucune faille logicielle précise mais détourne une
fonctionnalité matérielle standard. La distinction est faite explicitement
pour ne jamais confondre une vulnérabilité corrigeable par un correctif
avec une technique d'attaque qui abuse d'un mécanisme fonctionnant
exactement comme prévu par sa conception.

### CVE-2026-24061 — Contournement d'authentification telnetd

- **Versions touchées** : `telnetd` de GNU inetutils — faille introduite
  en 2015, restée non détectée pendant plus de 11 ans, découverte et
  divulguée en janvier 2026.
- **Version corrigée** : dernière version de GNU inetutils publiée après
  janvier 2026 — vérifier le changelog officiel du paquet de sa
  distribution.
- **Gravité** : critique — CVSS 9.8. Activement exploitée (inscrite au
  catalogue des vulnérabilités exploitées connues de la CISA), plusieurs
  vagues d'attaques observées depuis le 22 janvier 2026, groupe `rwxrwx`
  notamment identifié.
- **Pourquoi** : positionner la variable d'environnement `USER` à la
  valeur `-f root` au moment de la connexion fait que `login` traite à
  tort la session comme déjà pré-authentifiée.
- **Risque** : shell root non authentifié, sans aucun mot de passe requis,
  sur tout service `telnetd` exposé et non corrigé.
- **Correction** :
  ```
  sudo apt update && sudo apt install --only-upgrade inetutils-telnetd
  ```
  Recommandation plus robuste : désactiver `telnet` entièrement plutôt que
  de le patcher — protocole non chiffré, obsolète depuis longtemps face à
  SSH :
  ```
  sudo systemctl disable --now telnet.socket
  sudo apt purge inetutils-telnetd
  ```

### CVE-2026-32746 — Débordement de tampon telnetd (exécution de code à distance, pré-authentification)

- **Versions touchées** : `telnetd` de GNU inetutils (gestionnaire de la
  sous-option LINEMODE SLC — *Set Local Characters*).
- **Gravité** : critique — CVSS 9.8.
- **Pourquoi** : une écriture hors limites se produit dans le traitement
  d'un message spécialement conçu, envoyé pendant la négociation initiale
  de la connexion — **avant même l'affichage d'une invite de connexion**.
- **Risque** : exécution de code arbitraire à distance, par un attaquant
  non authentifié, sans qu'aucun identifiant valide ne soit nécessaire.
- **Correction** : identique à CVE-2026-24061 — mise à jour du paquet ou,
  de préférence, désactivation complète du service telnet.

### Technique active (PAS un CVE) — botnet Tengu : persistance par abus du chien de garde matériel

- **Composant concerné** : tout appareil Linux embarqué exposant un
  service telnet accessible (routeurs, caméras, enregistreurs) et
  disposant d'un chien de garde matériel (*watchdog*, `/dev/watchdog`) —
  présent sur la quasi-totalité de ces appareils, indépendamment du
  fabricant ou du micrologiciel.
- **Vecteur d'entrée observé** : force brute sur les identifiants telnet
  par défaut — même technique historique que Mirai en 2016. Tengu en est
  un dérivé modernisé, documenté fin juillet 2026.
- **Pourquoi ce n'est pas un CVE** : le chien de garde matériel fonctionne
  exactement comme prévu par sa conception (redémarrer l'appareil si un
  processus cesse de le réarmer, garde-fou contre un blocage logiciel) —
  Tengu détourne cette fonctionnalité légitime, il n'exploite aucun défaut
  de code précis, corrigeable par un correctif.
- **Mécanisme** : un processus caché, déguisé en thread noyau, réarme en
  continu le chien de garde matériel tant que le maliciel tourne. Si un
  défenseur termine le processus principal du maliciel, le chien de garde
  cesse d'être réarmé et redémarre l'appareil après environ 30 secondes —
  donnant au maliciel une nouvelle occasion de se réinstaller dès le
  démarrage suivant.
- **Risque** : la simple terminaison du processus malveillant déclenche un
  redémarrage complet de l'appareil, effaçant au passage la plupart des
  preuves forensiques volatiles. Le maliciel écrase en plus les binaires
  `reboot`/`shutdown` avec un en-tête ELF corrompu (« binary bricking »),
  empêchant un redémarrage ou un arrêt propre par l'administrateur via les
  commandes standards.
- **Diagnostic** (un diagnostic, jamais une correction en soi) :
  ```
  sudo fuser -v /dev/watchdog
  sudo lsof /dev/watchdog
  ```
  Un processus inattendu (différent du démon `watchdog` légitime du
  système) détenant ce périphérique ouvert est un signal fort de
  compromission.
- **Correction réelle** : fermer le vecteur d'entrée AVANT toute tentative
  de nettoyage (désactiver `telnet`, changer les identifiants par défaut,
  corriger CVE-2026-24061/CVE-2026-32746 ci-dessus) — supprimer
  simplement le processus déclenche le redémarrage protecteur du maliciel,
  sans rien résoudre. Étant donné le « binary bricking » des binaires
  `reboot`/`shutdown`, une réinstallation complète du micrologiciel depuis
  une source de confiance est souvent la seule remédiation réellement
  fiable — un simple nettoyage logiciel en place n'est pas suffisant.

## Tableau récapitulatif

| Catégorie | CVE | Versions touchées | Version corrigée | Gravité |
|---|---|---|---|---|
| Noyau | CVE-2026-46333 | toutes branches < minimum sûr | voir liste par branche | Élevée |
| Noyau | CVE-2026-63979 | 6.4 et ultérieur (TLS noyau) | voir liste par branche | Critique 9.8 |
| sudo | CVE-2025-32463 | 1.9.14 à 1.9.17 | 1.9.17p1 | Critique 9.3 |
| OpenSSH | CVE-2026-35414 | < 10.3 (certificats CA) | 10.3 | Élevée |
| OpenSSH | CVE-2026-35387 | < 10.3 (ECDSA restreint) | 10.3 | Modérée-Élevée |
| Telnet | CVE-2026-24061 | telnetd GNU inetutils (depuis 2015) | dernière version | Critique 9.8 |
| Telnet | CVE-2026-32746 | telnetd GNU inetutils | dernière version | Critique 9.8 |
| Telnet | Tengu (technique, pas un CVE) | appareils avec watchdog matériel exposé | fermer le vecteur + réinstaller le micrologiciel | Critique (persistance) |

## Principe général de veille — ne pas se fier qu'à cette liste

Cette liste est un instantané daté, jamais exhaustif ni définitif. Réflexe
systématique recommandé sur un système en production :

```
# Debian/Ubuntu — liste des mises à jour de sécurité disponibles
apt list --upgradable 2>/dev/null | grep -i security

# Vérifier la version noyau réellement active après un correctif
uname -r
```

S'abonner au flux d'avis de sécurité officiel de sa distribution reste la
seule source réellement fiable et à jour — cette section, comme tout
document statique, se périme dès sa publication.

*(Schéma disponible : `schema.svg`, dans ce dossier.)*
13.2 Ko BLAKE3 : fd64c8dd…0160d159