Cette faille est similaire à « Copy Fail » tout en ayant une action différente à deux « cartouches », càd qu’elle teste de deux manières différentes l’accès administrateur « pour obtenir gain de cause ».
Une « belle cochonnerie » qui n’a pas pu être remontée correctement au-travers de CVE, à cause d’un indélicat qui a « moufté sur un réseau social » (apparemment).
Conséquence : aucun patch officiel pour aucune distribution à ce jour !
Cela se fera certainement, parce que la faille est sérieuse.
En attendant, un moyen de « correction » — à faire avec des droits administrateurs :
C’est dommage car on ne comprend pas, trop malgré toute cette doc, si la faille est exploitable à distance, ou uniquement si l’attaquant a un accès physique à la machine. Avec CopyFail on savait qu’il fallait un accès physique. Vous avez une idée de votre côté ?
Idem que Copy Fail, même « Aqua Bite » comme dit le pingouin
Cependant, si les module ESP ne sont pas utilisé (comme c’est le cas chez moi), il n’y a donc pas de risque. Mais le blocage du module est toujours bon à prendre.
esp4 et esp6 sont des modules du noyau Linux qui implémentent le protocole IPsec Encapsulating Security Payload (ESP) pour IPv4 et IPv6 respectivement. Ils fournissent le traitement ESP côté noyau utilisé par IPsec : cryptage/décryptage des paquets, authentification et protection contre la relecture.
Donc si vous utilisez IPsec, vous êtes vulnérable. On pourrait penser que cela rend la faille utilisable à distance, mais rien n’est sur. Elle l’est en local c’est certain.
Ce qui doit être intéressant c’est aussi de regarder du cote de fournisseurs comme Fortigate qui ont potentiellement le même problème.
Pour le choix de passer en TLS au lieu d’IPsec, un bout de reflexion ci-dessous:
Réponse courte : Non—les VPN basés sur TLS (SSL/TLS) peuvent être cryptographiquement robustes, mais IPsec est généralement préféré car il offre une protection de la couche réseau, une gestion des clés mature basée sur IKE, de meilleures performances/évolutivité pour l’accès à distance site à site et entreprise, et la parité des fonctionnalités à venir.
Les points clés pour décider lesquels utiliser :
Cryptographie : TLS et IPsec peuvent utiliser des chiffrements forts ; la sécurité dépend des suites de chiffrement choisies, des longueurs de clé et des versions de protocole.
Couche et étendue : IPsec fonctionne au niveau de la couche IP (protège tout le trafic de manière transparente) ; TLS protège les sessions au niveau de la couche transport/application (peut nécessiter une gestion par application).
Authentification et gestion des clés : IPsec (IKEv2) offre des durées de vie SA/IKE standardisées et des méthodes d’authentification adaptées aux entreprises ; TLS utilise une liaison certificat/TLS et peut être tout aussi sécurisé, mais présente souvent différents compromis opérationnels.
Surface d’attaque et posture du client : Les VPN TLS basés sur un navigateur ou de type proxy peuvent exposer différents vecteurs d’attaque (composants web, plugins). IPsec basé sur le client limite souvent l’exposition à moins de composants. balanced.plus
Performance et évolutivité : IPsec offre généralement un meilleur débit et une charge de travail plus faible pour les tunnels à grande échelle ou de site à site.
Interopérabilité et fonctionnalités : Les documents et outils Fortinet favorisent désormais IPsec pour la prise en charge de la parité des fonctionnalités et de la migration.
Cette faille a été découverte grâce à des recherches menées par un type plutôt sympa, suite à la découverte de CopyFail. En très peu de temps, ça fait deux failles énormes découvertes sur Linux. Mais je soupçonne que maintenant, tout un tas de gars plus ou moins recommandables vont chercher encore de nouvelles failles exploitables en suivant ce même filon. On risque d’en voir arriver d’autres.
C’est une grosse faille qui a induit la suivante
facile à contourner, et rapidement corrigée.
Il faut tout de même avoir accès à la machine avec un compte actif pour l’exploiter.
Sans compter que Copy Fail n’aurait jamais été découverte sans le contrôle d’une IA.
Il semblerait selon l’analyse de Stephane Bortzmeyer que si la Debian est à jour de noyau, la faille ne soit pas fonctionnelle — que le correctif anti-DF soit installé ou non !
