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
# BientĂŽt le :: day....
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Ăvalué à  4.
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. 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 thoasm . Ăvalué à  6.
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.
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 thoasm . Ăvalué à  3.
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. 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 thoasm . Ăvalué à  2.
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.
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.
Je viens de tester avec un
await fetch("http://0.0.0.0:8080", {mode: "no-cors"}), Firefox bloque à cause du https :Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Blocage par Firefox
Posté par Voltairine đłïžâđ . Ăvalué à  1.
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.
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 ?).
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Blocage par Firefox
Posté par devnewton đș (site web personnel) . Ăvalué à  4. 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.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Blocage par Firefox
Posté par ted (site web personnel) . Ăvalué à  3.
Ă 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.
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. 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
Suivre le flux des commentaires
Note : les commentaires appartiennent Ă celles et ceux qui les ont postĂ©s. Nous nâen sommes pas responsables.