Hello, On Mon, May 13, 2024 at 05:06:55PM +0200, Philippe Strauss via gull wrote: > Critical OpenVPN Zero-Day Flaws Affecting Millions of Endpoints > https://cybersecuritynews.com/openvpn-zero-day-flaws/
Comme je suis abonné à la liste openvpn, voici quelques infos: Il y a récemment eu 2 annonces de vulnérabilités OpenVPN (enfin, une date de quelques années mais est revenue d'actualité). La 1ère vulnérabilité ne vous concerne pas si vous n'êtes pas sous plateforme propriétaire non standard Microsoft Windows (c'est un de ces bugs usuels de chemin de recherche de bibliothèque partagée, qui comprend sous Microsoft, contrairement aux systèmes standards UNIX/POSIX, le répertoire courant (*)). Il est d'ailleurs corrigé depuis 3-4 mois dans OpenVPN, donc la notion de "zero day" est un peu abusive ici. En résumé, c'est une attaque de privilege escalation, il faut un compte local. J'ai de la peine à voir dans quel scénario on tournerait un OpenVPN sur une machine multi-utilisateur Microsoft, mais d'un autre côté, oui, si OpenVPN propose un chemin permettant le privilege escalation, cela veut dire que n'importe quelle vulnérabilité usuelle Microsoft rendra inutile la précaution souvent rappelée de jamais faire des tâches courantes sous un compte administrateur. La 2e vulnérabilité ne vous concerne que si votre client OpenVPN tourne sous une machine (standard ou Microsoft) *qui utilise un client DHCP* dans un réseau potentiellement *malicieux*. Exemple: vous êtes dans un cybercafé, et vous avez un dhclient sous Linux ou un truc qui fait la même chose sous Microsoft. Le problème (assez ancien, connu, etc) est le suivant: il existe une option DHCP (sauf erreur la 121) qui permet de rerouter le trafic. Un serveur DHCP malicieux peut donc forcer, par modification de la table induite sur le client DHCP qui tourne aussi OpenVPN, un envoi de paquets en clair par Internet et non pas via le tunnel / VPN chiffré et authentifié. Se cache derrière cela la notion de précision de longueur de préfixe dans le routage. La bonne nouvelle est que l'OS POSIX Android ne supporte pas cette option. La mauvaise est que la plupart du temps, Microsoft et Linux la supportent. La véritable correction me semblerait de désactiver cette option sauf si on en a besoin. A ma connaissance, il n'y a pas encore de véritable correctif déployé pour cette 2e vulnérabilité, même si elle date déjà de quelques temps. Sous Linux, on peut utiliser `ip rule' pour faire primer les règles de routage d'OpenVPN sur toute règle de routage. Ou on peut -- comme sous Microsoft -- configurer son firewall pour éviter tout "leak". En bref, mettre une politique DROP sur OUTPUT, puis autoriser uniquement le trafic à destination du serveur VPN et du serveur DHCP. On peut supposer que ce genre de ip rules ou règles de firewall seront prochainement proposées par les distributions. Ou peut-être que l'option 121 sera désactivée par défaut dans les clients DHCP -- je pense que ce qui empêche de le faire est justement que ceux qui en ont besoin (redirection p.ex. de tout un réseau via un VPN), ne sauraient pas l'activer ... (*) autre exemple d'exploit: faire télécharger à une victime une bibliothèque partagée malicieuse sous Microsoft (une "DLL"), elle sera probablement déposée dans le Internet temporary folder. Ensuite faire télécharger une application quelconque du site officiel, même en vérifiant son empreinte ou sa signature numérique. Si cette application est lancée du MEME répertoire Internet temporary folder et qu'elle dépend d'une bibliothèque dont le nom et la version correspond à celle malicieuse du répertoire courant, celle du répertoire courant sera chargée A LA PLACE DE CELLE DU SYSTEME! Le pirate aura donc contrôle total de votre compte utilisateur. Microsoft propose divers work-arounds pour plein de problèmes de sécurité lié à la façon incorrecte dont ils configurent leur équivalent de LD_LIBRARY_PATH (ils vont dans ".", ils vont dans ~ etc), mais à voir cet article récent ce n'est pas très efficace: https://www.upguard.com/blog/dll-hijacking OpenVPN n'était donc -- de loin -- pas la seule méthode de privilege escalation sous Microsoft. Il en reste autant que de logiciels, apparemment. Attention, Microsoft parle souvent de bug de "PRELOADING" à ce sujet, alors qu'à ma connaissance on ne parle pas du tout de LD_PRELOAD qui est un tout autre comportement (ça sert surtout à faire changer de comportement un programme, pas pour des privilege escalation, en tout cas sous Linux vu que LD_PRELOAD et LD_LIBRARY_PATH sont évidemment ignorés en cas d'exécutable SU/GID, par exemple. Evidemment, si Microsoft ne fait pas ça et exécute du preloading aussi depuis le répertoire courant ou le user directory lorsqu'il exécute un exécutable privilégié ...) _______________________________________________ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
