Tout un article sur une seule adresse IPv4 sans aucune mention d'IPv6 et son pendant :: 🙄
Sinon, ils disent faire un responsible disclosure, mais seul Webkit a déployé un correcrif… Je trouve ça étrange, non ?
Dans l'article ils disent que Google aura complètement distribuer le correctif avec la version 133 (en commençant avec la version 128) et actuellement, ils ont déployés la version 127 seulement.
Posté par Psychofox (Mastodon) .
Évalué à 7 (+4/-0).
Dernière modification le 09 août 2024 à 11:29.
Je crois que c'est parce que c'est un problème connu et qu'il n'est pas universellement considéré comme une faille de sécurité en tant que telle.
Au final la vraie faille de sécurité, c'est de laisser des sites web faire executer du code à un navigateur autre que du langage de formatage de document, et ce de façon à peu près invisible pour l'utilisateur. Sans javascript et webassembly, les sites seraient bien différents, on n'aurait pas toutes ces "applications web", des trucs comme jitsi, mais on n'aurait pas tous ces problèmes récurrents de sécurité.
Il est aussi très naïf de penser que parce qu'un service tourne en local ou sur un réseau derrière un firewall, il ne doit pas être sécurisé.
Ce serait pas très différent avec des applications de bureau maison codées avec des bibliothèques maisons. Il y aurait tout de même des stores android et compagnie, avec une situation comparable ou chaque appli a potentiellement des failles et ou il faut sécuriser à balle la plateforme. Tu déporterai simplement les problèmes de sécurités ailleurs, à mon avis.
Sauf à fantasmer d'un monde avec des clients standards à des services éventuellement commerciaux, mais ce monde de standard a donné … le web. Bref, on tourne en rond.
D'un point de vu utilisateur, l'installation du application native implique un effort supplémentaire. Par ailleurs tu n'installerais pas cette appli par erreur juste parce que tu as cliqué sur un lien.
Là le problème c'est que madame ou monsieur tartampion peuvent être sur un site sûr, y communiquer avec une personne à priori de confiance[1] mais ouvrir une page qui t'attaques simplement parce que ton interlocuteur a vu quelque chose de drôle et veut te le faire partager. Ce serait quand même moins trivial avec du web sans exécution de code automatique.
[1] dans le sens qu'elle ne te veut pas elle-même du mal
Posté par Psychofox (Mastodon) .
Évalué à 6 (+3/-0).
Dernière modification le 09 août 2024 à 14:42.
Oui et c'est bien que tu sortes ce sujet: de nos jours tout client mail décent ne va charger aucune image distante ni rien exécuter qui est en pièce jointe. T'as le choix de ne pas y toucher.
La le navigateur web, c'est comme si il te chargeait les pièces jointes et exécutait les macros d'un fichier word ou excel sans te demander ton avis.
Non c'est globalement une sandbox, il ne donne certainement pas accès au système de fichier avec les droits de l'utilisateur par défaut. Une macro excel peut créer des fichiers ou lire n'importe quoi si toi tu as l'accès. Pour le web ou pour une appli android tu dois donner ces droits d'accès.
Un accès "réseau" semble de toute façon inévitable pour un truc comme le web, ou on peut faire des liens vers n'importe quel serveur. Ici c'est juste ça qui est en jeu, cet accès réseau ne doit pas donner accès à n'importe quel service local n'importe comment. Est-ce un truc spécifique au web ? Pas exactement certain. Là on va avoir apparemment une suite logique qui est … la création d'un droit spécifique pour l'accès au réseau local, qui devra être accordé au cas par cas. Ça a l'air d'être une bonne chose d'une manière générale, je vois pas pourquoi une appli android par exemple devrait n'avoir aucun accès au réseau d'une manière générale sous prétexte de sécurité. L'accès au réseau local est une autre histoire, surtout si il y a les deux en même temps.
Je fais juste quelques essais pour voir à quel point je pourrais être impacté :
uBlock origin bloque les requêtes vers 0.0.0.0 ;
le mode https only de Firefox bloque l'attaque vers http://0.0.0.0 => je n'ai pas de service local en https pour tester, mais ça doit bloquer s'il n'a pas un certification valide :-) ;
sans le mode https only, Firefox bloque une requête d'un site en https vers un autre en http
Bref pour être vulnérable, il faut aller sur un site en http sans uBlock origine et avoir un service qui écoute sur en http sur 0.0.0.0 et ne pas avoir de mécanisme complémentaire de protection réseau (un firewall?) ou applicative (tout bon service doit avoir un mécanisme d'authentification, n'est-ce pas M. Docker ?).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
À noter aussi que grâce aux règles CORS, même si le site malveillant peut envoyer des requêtes à localhost il ne peut pas accéder à la réponse de la part du client.
D'après ce que j'ai compris de l'article CORS en protège pas de la faille, la réponse n'étant pas nécessaire pour exécuter du code arbitraire sur l'hôte. C'est bien là tout le problème.
Et comme le fait remarquer devnewton plus haut, certains services installés sur la plupart des machines : cups ou systemd-resolved sont potentiellement vulnérables.
# Bientôt le :: day....
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Tout un article sur une seule adresse IPv4 sans aucune mention d'IPv6 et son pendant
::🙄Sinon, ils disent faire un responsible disclosure, mais seul Webkit a déployé un correcrif… Je trouve ça étrange, non ?
Dans l'article ils disent que Google aura complètement distribuer le correctif avec la version 133 (en commençant avec la version 128) et actuellement, ils ont déployés la version 127 seulement.
[^] # Re: Bientôt le :: day....
Posté par Psychofox (Mastodon) . Évalué à 7 (+4/-0). Dernière modification le 09 août 2024 à 11:29.
Je crois que c'est parce que c'est un problème connu et qu'il n'est pas universellement considéré comme une faille de sécurité en tant que telle.
Au final la vraie faille de sécurité, c'est de laisser des sites web faire executer du code à un navigateur autre que du langage de formatage de document, et ce de façon à peu près invisible pour l'utilisateur. Sans javascript et webassembly, les sites seraient bien différents, on n'aurait pas toutes ces "applications web", des trucs comme jitsi, mais on n'aurait pas tous ces problèmes récurrents de sécurité.
Il est aussi très naïf de penser que parce qu'un service tourne en local ou sur un réseau derrière un firewall, il ne doit pas être sécurisé.
[^] # Re: Bientôt le :: day....
Posté par Thomas Douillard . Évalué à 6 (+4/-1).
Ce serait pas très différent avec des applications de bureau maison codées avec des bibliothèques maisons. Il y aurait tout de même des stores android et compagnie, avec une situation comparable ou chaque appli a potentiellement des failles et ou il faut sécuriser à balle la plateforme. Tu déporterai simplement les problèmes de sécurités ailleurs, à mon avis.
Sauf à fantasmer d'un monde avec des clients standards à des services éventuellement commerciaux, mais ce monde de standard a donné … le web. Bref, on tourne en rond.
[^] # Re: Bientôt le :: day....
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0).
D'un point de vu utilisateur, l'installation du application native implique un effort supplémentaire. Par ailleurs tu n'installerais pas cette appli par erreur juste parce que tu as cliqué sur un lien.
Là le problème c'est que madame ou monsieur tartampion peuvent être sur un site sûr, y communiquer avec une personne à priori de confiance[1] mais ouvrir une page qui t'attaques simplement parce que ton interlocuteur a vu quelque chose de drôle et veut te le faire partager. Ce serait quand même moins trivial avec du web sans exécution de code automatique.
[1] dans le sens qu'elle ne te veut pas elle-même du mal
[^] # Re: Bientôt le :: day....
Posté par Thomas Douillard . Évalué à 3 (+1/-1).
Ben on avait ça avec l'email et les pièces jointes piégées aussi, avec client en dur ou pas.
[^] # Re: Bientôt le :: day....
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 09 août 2024 à 14:42.
Oui et c'est bien que tu sortes ce sujet: de nos jours tout client mail décent ne va charger aucune image distante ni rien exécuter qui est en pièce jointe. T'as le choix de ne pas y toucher.
La le navigateur web, c'est comme si il te chargeait les pièces jointes et exécutait les macros d'un fichier word ou excel sans te demander ton avis.
[^] # Re: Bientôt le :: day....
Posté par Thomas Douillard . Évalué à 2 (+0/-1).
Non c'est globalement une sandbox, il ne donne certainement pas accès au système de fichier avec les droits de l'utilisateur par défaut. Une macro excel peut créer des fichiers ou lire n'importe quoi si toi tu as l'accès. Pour le web ou pour une appli android tu dois donner ces droits d'accès.
Un accès "réseau" semble de toute façon inévitable pour un truc comme le web, ou on peut faire des liens vers n'importe quel serveur. Ici c'est juste ça qui est en jeu, cet accès réseau ne doit pas donner accès à n'importe quel service local n'importe comment. Est-ce un truc spécifique au web ? Pas exactement certain. Là on va avoir apparemment une suite logique qui est … la création d'un droit spécifique pour l'accès au réseau local, qui devra être accordé au cas par cas. Ça a l'air d'être une bonne chose d'une manière générale, je vois pas pourquoi une appli android par exemple devrait n'avoir aucun accès au réseau d'une manière générale sous prétexte de sécurité. L'accès au réseau local est une autre histoire, surtout si il y a les deux en même temps.
# uBlock Origin avec EasyList corrige le problème
Posté par Glandos . Évalué à 7 (+5/-0).
Cette adresse est bloquée dans EasyList.
Et dans la liste embarqué par défaut dans uBlock Origin aussi : https://github.com/uBlockOrigin/uAssets/blob/master/filters/quick-fixes.txt#L180
# Blocage par Firefox
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+1/-1).
Je viens de tester avec un
await fetch("http://0.0.0.0:8080", {mode: "no-cors"}), Firefox bloque à cause du https :Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Blocage par Firefox
Posté par Voltairine . Évalué à 1 (+1/-0).
Et donc, qu'essayez vous de prouver ?
Est-ce que le POC donné dans l'article fonctionne ou pas ?
Par ailleurs on peut trouver étrange la réponse sur à une requête sur 0.0.0.0 ou [::] comme le font certains commentaires sur l'article de lwn.net
[^] # Re: Blocage par Firefox
Posté par devnewton 🍺 (site web personnel) . Évalué à 2 (+0/-1).
Je fais juste quelques essais pour voir à quel point je pourrais être impacté :
Bref pour être vulnérable, il faut aller sur un site en http sans uBlock origine et avoir un service qui écoute sur en http sur 0.0.0.0 et ne pas avoir de mécanisme complémentaire de protection réseau (un firewall?) ou applicative (tout bon service doit avoir un mécanisme d'authentification, n'est-ce pas M. Docker ?).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Blocage par Firefox
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 09 août 2024 à 14:33.
Ah tiens j'ai trouvé un service vulnérable qui permettrait une attaque rigolote sur Ubuntu: ipp.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Blocage par Firefox
Posté par ted (site web personnel) . Évalué à 3 (+1/-0).
À noter aussi que grâce aux règles CORS, même si le site malveillant peut envoyer des requêtes à localhost il ne peut pas accéder à la réponse de la part du client.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Blocage par Firefox
Posté par Voltairine . Évalué à 1 (+1/-0).
D'après ce que j'ai compris de l'article CORS en protège pas de la faille, la réponse n'étant pas nécessaire pour exécuter du code arbitraire sur l'hôte. C'est bien là tout le problème.
Et comme le fait remarquer devnewton plus haut, certains services installés sur la plupart des machines : cups ou systemd-resolved sont potentiellement vulnérables.
# chez OpenBSD, problème réglé depuis 26 ans
Posté par Psychofox (Mastodon) . Évalué à 10 (+8/-0). Dernière modification le 09 août 2024 à 20:22.
En effet ils avaient décidé en 1998 de faire en sorte que 0.0.0.0 et 255.255.255.255 ne pointent pas vers localhost dans un souci de sécurité.
https://marc.info/?l=openbsd-ports&m=172318365826454&w=2
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.