La société Qualys quatre dans OpenBSD, l'une d'elles permettant de se connecter à certains services réseau sans authentification, tandis que les trois autres augmentent leurs privilèges dans le système. Le rapport de Qualys souligne la réaction rapide des développeurs d'OpenBSD — tous les problèmes ont été dans et dans les 40 heures suivant la notification privée.
La vulnérabilité exploitable à distance est causée par une erreur lors de l'organisation de l'appel du gestionnaire d'authentification dans la bibliothèque libc, qui appelle
le programme /usr/libexec/auth/login_style avec des arguments passés en ligne de commande. En particulier, lors de l'appel de login_style avec le paramètre optionnel « -s service », il est possible de passer le nom du protocole. Si le nom d'utilisateur commence par le symbole « - », ce nom sera traité comme une option lors du lancement de login_style. Par conséquent, si l'on spécifie lors de l'authentification le nom d'utilisateur « -schallenge » ou « -schallenge:passwd », login_style interprétera cet appel comme une demande d'utilisation du gestionnaire .
Le problème est que le protocole S/K dans login_style n'est pris en charge que formellement, mais est en réalité ignoré avec un indicateur de succès d'authentification. Ainsi, un attaquant peut se faire passer pour l'utilisateur « -schallenge », contourner l'authentification et accéder sans fournir de mot de passe ou de clés. Tous les services réseau utilisant des appels standards libc pour l'authentification pourraient être potentiellement affectés. Par exemple, la possibilité de contourner l'authentification est confirmée dans smtpd (AUTH PLAIN), ldapd et radiusd.
Dans sshd, la vulnérabilité ne se manifeste pas, car il dispose d'une protection supplémentaire vérifiant la présence de l'utilisateur dans le système. Cependant, sshd peut être utilisé pour vérifier la vulnérabilité du système — lors d'un appel avec le nom d'utilisateur « -sresponse:passwd », la connexion se bloque, car sshd attend du login_passwd le retour des paramètres d'appel (challenge), tandis que login_passwd attend la transmission des paramètres manquants (le nom « -sresponse » est considéré comme une option). Un attaquant local pourrait potentiellement essayer de contourner l'authentification dans l'outil su, mais donner le nom « -sresponse » entraîne un crash du processus en raison du retour d'un pointeur nul lors de l'exécution de la fonction getpwnam_r(« -schallenge », …).
Autres vulnérabilités :
- CVE-2019-19520 — élévation locale de privilèges via une manipulation de l'outil xlock, fourni avec le drapeau sgid, changeant le groupe en « auth ». Dans le code de xlock, la redéfinition des chemins vers les bibliothèques est interdite uniquement lors du changement d'identifiant utilisateur (setuid), ce qui permet à un attaquant de modifier la variable d'environnement « LIBGL_DRIVERS_PATH » et de charger sa propre bibliothèque partagée, dont le code sera exécuté après l'élévation des privilèges au groupe « auth ».
- CVE-2019-19522 — permet à un utilisateur local appartenant au groupe « auth » d'exécuter du code avec des droits root lors de l'activation du système d'authentification via S/Key ou YubiKey (désactivés par défaut). L'accès au groupe « auth », qui peut être obtenu par l'exploitation de la vulnérabilité mentionnée ci-dessus dans xlock, permet d'écrire des fichiers dans les répertoires /etc/skey et /var/db/yubikey. Par exemple, un attaquant peut ajouter un nouveau fichier /etc/skey/root pour générer des clés à usage unique pour une authentification en tant qu'utilisateur root via S/Key.
- CVE-2019-19519 — possibilité d'augmenter les limites de ressources via une manipulation de l'outil su. Lorsqu'une option « -L » est spécifiée, signalant une répétition cyclique des tentatives d'authentification en cas d'échec, la classe d'utilisateur n'est définie qu'une seule fois et n'est pas réinitialisée lors des tentatives suivantes. L'attaquant peut exécuter « su -l -L » et à la première tentative entrer un login étranger avec une autre classe de compte, mais à la deuxième tentative, il peut s'authentifier avec succès sous son propre compte. Dans cette situation, les limites pour l'utilisateur seront définies selon la classe d'utilisateur spécifiée lors de la première tentative (par exemple, le nombre maximal de processus ou la taille de la mémoire pour un processus). Cette méthode ne fonctionne que pour emprunter des limites à des utilisateurs non privilégiés, car l'utilisateur root doit faire partie du groupe wheel).
Il convient également de noter dans OpenBSD, une nouvelle méthode de vérification de la validité des appels système, compliquant davantage l'exploitation des vulnérabilités. Cette méthode permet l'exécution des appels système uniquement s'ils sont effectués à partir de zones mémoire préalablement enregistrées. Pour marquer les zones mémoire un nouvel appel système .
Source : opennet.ru
