RegreSSHion : exécution de code à distance (RCE) sur le serveur OpenSSH des systèmes Linux basés sur glibc

 (qualys.com)
1 points par GN⁺ 2024-07-02 | 1 commentaires | Partager sur WhatsApp

Résumé

  • Découverte d’une faille de sécurité dans OpenSSH : une vulnérabilité d’exécution de code à distance (RCE) a été découverte dans le serveur OpenSSH (sshd) en raison d’une condition de concurrence dans le gestionnaire de signaux. Cette faille affecte sshd dans sa configuration par défaut.
  • Origine de la vulnérabilité : cette faille est une régression de la CVE-2006-5051, signalée en 2006, causée par une modification de code introduite dans OpenSSH 8.5p1 en octobre 2020.
  • Impact de la vulnérabilité : elle peut être exploitée à distance sur les systèmes Linux basés sur glibc, affecte le code privilégié de sshd et permet potentiellement une exécution de code à distance avec les privilèges root.
  • Méthode d’exploitation : l’exploitation de cette faille nécessite d’identifier un chemin de code spécifique, puis de l’interrompre au bon moment. La recherche a commencé sur d’anciennes versions d’OpenSSH avant d’être étendue aux versions récentes.
  • Correctifs et atténuation : des correctifs et des mesures d’atténuation sont fournis pour résoudre la vulnérabilité.

SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 (Debian 3.0r6, 2005)

Théorie

  • Gestionnaire SIGALRM : dans cette version, le gestionnaire SIGALRM appelle packet_close(), qui appelle buffer_free(), qui appelle à son tour xfree() puis free(). free() n’est pas async-signal-safe.
  • Analyse du code de malloc : l’analyse du code de malloc a révélé un chemin exploitable si l’appel à free() est interrompu par SIGALRM, puis rappelé dans le gestionnaire SIGALRM.

Pratique

  • Méthode d’attaque : l’attaque consiste à interrompre un appel à free() dans le code qui analyse une clé publique DSA, puis à l’exploiter depuis le gestionnaire SIGALRM pour obtenir une exécution de code à distance.
  • Gagner la condition de concurrence : environ 10 000 tentatives sont nécessaires pour remporter cette condition de concurrence, ce qui prend en moyenne environ une semaine.

Timing

  • Stratégie de timing : pour minimiser la latence réseau, le dernier octet est envoyé au tout dernier moment et le temps d’aller-retour est suivi pour ajuster le timing. Cela augmente les chances de gagner la condition de concurrence.

SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 (Ubuntu 6.06.1, 2006)

Théorie, 1re étape

  • Gestionnaire SIGALRM : dans cette version, le gestionnaire SIGALRM n’appelle pas packet_close(), et comme la fonction malloc verrouille toujours, une autre solution est nécessaire.
  • Utilisation de PAM : il a été constaté que pam_end() de PAM n’est pas async-signal-safe, et un chemin exploitable a été recherché à partir de ce point.

Théorie, 2e étape

  • Analyse de pam_start() : si pam_start() est interrompu, la structure PAM peut rester dans un état incohérent, ce qui peut être exploité depuis le gestionnaire SIGALRM.
  • Technique House of Mind : la technique House of Mind a été utilisée pour manipuler les allocations mémoire et obtenir une exécution de code à distance avec les privilèges root.

Pratique

  • Méthode d’attaque : l’attaque manipule les allocations mémoire à l’aide de noms d’utilisateur longs et augmente les chances de gagner la condition de concurrence via plusieurs appels à pam_start().

Timing

  • Stratégie de timing : la stratégie de timing utilisée sur la version Debian précédente a été réutilisée pour améliorer les probabilités de succès. En moyenne, cela prend 1 à 2 jours.

SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2 (Debian 12.5.0, 2024)

Théorie

  • Gestionnaire SIGALRM : dans cette version, le gestionnaire SIGALRM appelle syslog(), qui appelle lui-même des fonctions qui ne sont pas async-signal-safe.
  • Analyse de glibc : syslog() dans glibc appelle malloc, qui n’est pas async-signal-safe. De plus, la fonction malloc de glibc ne verrouille pas en mode monothread.

Correctifs et atténuation

  • Correctif : la vulnérabilité a été signalée aux développeurs d’OpenSSH, et un correctif a été fourni pour la résoudre.

Avis de GN⁺

  • Importance de la sécurité : OpenSSH est un logiciel de sécurité extrêmement important, et cette vulnérabilité constitue un cas très rare.
  • Difficulté d’exploitation : exploiter cette faille exige un timing extrêmement précis et un grand nombre de tentatives.
  • Solutions alternatives : il existe diverses solutions de sécurité en plus d’OpenSSH, et il est recommandé de les utiliser conjointement.
  • Défi technique : cette recherche représente un défi technique de très haut niveau et peut être une grande source d’inspiration pour les chercheurs en sécurité.
  • Atténuation de la vulnérabilité : il est important d’appliquer les derniers correctifs de sécurité et de renforcer les paramètres de sécurité.

À lire aussi

1 commentaires

 
GN⁺ 2024-07-02
Réactions sur Hacker News

  • Le correctif du RCE a été rendu public de manière presque « discrète » il y a près d’un mois

    • Lorsque PerSourcePenalties est activé, sshd(8) surveille l’état de fin des processus enfants de session de pré-authentification
    • Il enregistre des pénalités lorsque le client tente l’authentification de manière répétée ou lorsque sshd plante
    • Ce patch modifie l’architecture binaire pour supprimer une vulnérabilité spécifique et atténuer toute une classe d’exploits

  • Dans le diff qui a introduit le bug, la fonction a été refactorisée comme suit

    • Fonction d’origine : sigdie(const char *fmt,...)
    • Fonction refactorisée : sshsigdie(const char *file, const char *func, int line, const char *fmt, ...)
    • Un #ifdef est manquant
    • Cela aurait pu être évité si davantage de personnes avaient relu la pull request

  • Commentaire intéressant dans les notes de version d’OpenSSH

    • Un exploit réussi a été démontré sur des systèmes Linux/glibc 32 bits avec l’ASLR
    • Cela semble aussi possible sur des systèmes 64 bits

  • OpenBSD n’est pas affecté par cette vulnérabilité, car le gestionnaire SIGALRM appelle syslog_r()

    • Il utilise une version de syslog() sûre en contexte de signal asynchrone
    • Un refactoring a été nécessaire pour minimiser la quantité de code dans le gestionnaire de signal

  • Après examen de syslog(3) de musl, il semble qu’il ne soit pas facilement exploitable, contrairement à glibc

    • Tout se trouve sur la pile ou dans des variables statiques protégées pour la réentrance

  • Un patch pour FreeBSD est sorti, et comme il n’utilise pas glibc, il est probablement peu ou pas affecté

  • Définir LoginGraceTime 0 dans le fichier sshd_config permet d’atténuer le problème

    • Cela le rend vulnérable aux attaques par déni de service, mais empêche l’exécution de code à distance

  • Un patch pour Debian 12 est disponible, et Debian 11 n’est pas affecté

  • Les notes de version d’OpenSSH et un lien vers le patch minimal sont fournis

  • D’un point de vue indépendant, trouver une seule vulnérabilité devrait déjà suffire

    • Il existe une tendance à ne prendre les choses au sérieux ou à ne verser une prime que lorsqu’on a trouvé toute la chaîne complète