[gull] Je surf pour vous - 2024-05-13

Marc SCHAEFER schaefer at alphanet.ch
Wed May 15 10:14:34 CEST 2024


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é ...)



More information about the gull mailing list