Dans un billet publié le 30 juillet, Google explique que Chrome 127 contient une amélioration pour la protection des cookies sur Windows. Le système propose en effet une API dédiée pour la protection de ce type de données (DPAPI). Cependant, elle ne le fait qu’au repos ou contre les attaques par démarrage à froid.
Dans son billet, Google indique que l’API Data Protection ne peut rien contre les applications malveillantes capables d'exécuter du code en tant qu'utilisateur connecté. Si une telle application réussit à s’exécuter sur la machine, les données sont en danger.
Chrome 127 ajoute donc une nouvelle couche de protection pour les cookies. Ces derniers sont désormais chiffrés avec l’identité de l’application. Google dit avoir intégré des primitives de chiffrement liées à Chrome (App-Bound Encryption).
Google précise que le mécanisme possède des privilèges système. Un logiciel malveillant tentant l’opération avec les droits utilisateur classiques ne pourra pas récupérer les informations. Il lui faudra soit élever ses propres privilèges (plus difficile) soit tenter une injection de code dans Chrome. L’éditeur ajoute que cette dernière opération rendrait le logiciel suspect (Google parle de « bruit ») pour les antivirus et autres solutions de sécurité.
Avec les autres protections mises en place, Google veut augmenter le coût et le risque de détection pour les attaquants. En outre, si Chrome 127 protège les cookies avec ce mécanisme, tous les autres secrets stockés dans le navigateur y passeront également dans les prochaines moutures. Ce sera notamment le cas des mots de passe.
Selon Google, cette nouvelle protection est particulièrement efficace en entreprise, où les droits des applications sont strictement contrôlés.
![[Édito] Apple entre greenwashing et renouvellement à marche forcée](https://next.ink/wp-content/uploads/2024/09/Apple_greenwashing-510x247.webp "[Édito] Apple entre greenwashing et renouvellement à marche forcée")
Commentaires (34)
#1
- Elevation service, qui fait partie des sources de Chrome : https://chromium.googlesource.com/chromium/src/+/refs/heads/main/chrome/elevation_service/
Comment dire les choses simplement....
NON
NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON NON
#1.1
#1.2
#1.4
#1.3
- utilisateur simple : dispose de droits restreint et ne pas pas faire grand chose qui va nuire au système ou aux autres utilisateurs (mais qui peut nuire à son propre compte oui)
- utilisateur administrateur : dispose de droits restreint par défaut, mais peut les élever temporairement (par exemple, pour l'installation d'un programme). Il peut quasiment tout faire, mais pas tout.
- SYSTEM : accès complet à la machine (l'équivalent du root sous linux). C'est un compte système non associable à un compte utilisateur
Aujourd'hui, Chrome peut être installé par un utilisateur simple. Chrome ne sera alors disponible que par lui. Quand c'est un administrateur qui l'installe, il décide s'il veut l'installer pour lui ou pour tout le monde sur la machine.
Ceci étant dit, pourquoi tant de contestation me demanderas-tu ? A grand pouvoir, grande responsabilité (et ce n'est pas comme si le récent exemple de Crowdstrike ne venait pas nous le rappeler).
Ici, nous avons donc un Chrome qui peut être installé par un administrateur et utilisé par des utilisateurs avec droits simples (notons qu'une installation de Chrome par un utilisateur droit simple ne pourra pas installer le service qui nécessite des droits SYSTEM).
Nous avons donc un module "utilisateur" qui va communiquer avec un module "système" ayant les pleins droits sur la machine (toute similitude avec le drame d'il y a 2 semaines serait totalement fortuite). Même si je ne doute pas que les équipes de Google soient compétente en terme de sécurité, les bogues ça existent, et il y a régulièrement des mises à jour pour corriger des failles.
Ici, nous avons donc, en cas de faille, la possibilité pour un code malveillant s'exécutant "avec des droits simples" d'accéder non seulement à tous les fichiers de l'utilisateur, mais également à tous ceux des utilisateurs de la machine sur lequel il se trouve (voire plus via le réseau) si jamais une injection de code dans ce module de sécurité est découverte.
Au delà de l'accès aux données utilisateurs, une injection de code dans ce module pourrait permettre à un attaquant, et sans aucune restriction (utilisateur SYSTEM, ne l'oublions pas), de stopper toutes les solutions de protection présentes sur la machine et/ou de les rendre inefficace, offrant alors un vecteur d'attaque non seulement sur la machine, mais aussi sur le réseau auquel la machine appartient.
Nous avons affaire ici à un navigateur. Un navigateur est un miniOS en soit, et il n'est pas utile (=il ne devrait pas) installer des modules qui pourraient se révéler être de vraies bombes à retardement. De par son rôle, un navigateur est le premier moyen d'accès au Web, et se retrouve de facto comme cible privilégiée pour les attaques, qui peuvent venir aussi bien du web (par ex. une pub vérolée) que de la machine (un logiciel espion), sans parler de la "négligence" des utilisateurs.
Augmenter potentiellement les possibilités d'exploitation d'une faille me parait être une hérésie, surtout 2 semaines après le bogue CrowdStrike (avec comme similitude supplémentaire qu'il est bien difficile, même si cela reste faisable, de bloquer les mises à jour de Chrome).
Google a raison sur un point : ce sont des données sensibles qui doivent être protégées (notamment les jetons d'identifications). Mais au bout d'un moment :
- la responsabilité du navigateur doit s'arrêter et laisser faire le travail à des logiciels spécialement conçus pour (antivirus, EDR, etc.). Monitorer des accès à des fichiers par des applications, ça se fait depuis des lustres et c'est très utilisés pour détecter les comportements malveillants
- un navigateur n'est pas le seul à gérer des données sensibles. Il en va de même pour d'autres logiciels (en premier lieu, les drives et les clients lourds mails). La solution de Google ne protégera que Chrome pas le reste (et ce n'est pas à Google de protéger le reste)
Et si on zappe la partie sécurité, c'est sans compter les bogues qui ne manqueront pas d'arriver (perte des cookies, des mots de passe ou de tout autre données qui seront protégées par ce mécanisme). Ce n'est pas comme si Chrome avait justement "perdu" l'accès aux mots de passe pendant quelques heures il y a 2 jours....
#1.5
Ce service parle avec qui ? au main process de chrome ou au child window des onglets ?
De toute façon peuvent-ils faire autrement ? Puisque rester dans l'environnement utilisateur, ce service serait toujours à portée des malwares.
Ici tu évoque l'installation sans être admin (dans appdata), c'est quoi le % d'utilisation par rapport à l'installation normal dans program file ?
#1.6
Seulement si Chrome est installé pour tout le monde. Si c'est pour toi en tant que seul utilisateur, pas besoin de service pour ça. Il peut se mettre à jour tout seul.
Et tu peux désactiver ces services (chose que font généralement les services IT qui cherchent à contrôler les versions de Chrome installées).
Aucune idée. Google doit le savoir, mais je n'ai jamais vu de chiffre là-dessus (je confesse que je n'ai pas non plus chercher à les avoir ^^)
#1.7
#1.9
Es-ce qu'une solution intermédaire, avec Windows qui surveille que seul Chrome accède aux données, ne serait pas une meilleur approche (c'est possible dans Android, il me semble - j'ignore pour Windows, Mac OS ou les distributions Linux)?
Il me semble q'un groupe de malfrats numériques avait réussi l'exploit de reproduit un profil complet de ses victimes avec cookies, tokens & Co et cela lui permettait de contourner la double authentification (désolé, je ne retrouve plus le lienà.
La démarche de Google pour Chrome pourrait gêner ce genre d'opérations en rendant les données moins accessible, non ?
#1.10
Pour moi oui. Il faudrait effectivement un cloisonnement dans les données par application (la plupart n'ayant pas besoin de données "externes"), et quand elles ont besoin de données externes, c'est à l'utilisateur de les fournir (via une boite de dialogue pour ouvrir un fichier par exemple).
Il me semble que les applications UWP sous Windows fonctionnent ainsi. Il faudrait des droits plus fins par application.
Il y a au final que peu d'applications qui nécessitent réellement et légitimement d'accéder aux fichiers d'autres applications. A part les solutions de sécurité (antivirus) ou de sauvegarde, il doit bien y en avoir quelques unes, mais cela ne doit pas courir les rues (peut être aussi les gestionnaires de paquet, et encore !)
Oui, tout à fait. Mais cela ne protégerait que Chrome, alors qu'il y a d'autres données qui peuvent se révéler tout aussi critiques et qu'il est donc nécessaire de protéger également (ex: les drive, les clients lourds mails).
Que Chrome fasse des efforts pour protéger les données, c'est très bien. Que cette protection supplémentaire nécessite un module avec des droits super administrateur sur la machine, ça me parait hyperdangereux, d'autant plus que si le malware est déjà sur la machine, il peut communiquer directement avec ce module. Donc si le module a une faille... c'est tout le système voire le réseau qui est en danger.
#1.11
C'est un problème l'accés d'une application A aux données d'une application B.
Problème commun à Windows et Linux, il me semble. Seul Mac OS, iOS et Android l'ont résolu.
Pour les 2 premiers, il y a les flatpak, Appimage, snap & Co.
#1.12
Je dirais oui sur le principe. Après, il y aurait peut être des limitations. Par exemple, les navigateurs actuels utilisent de l'accélération graphique directement via le GPU. Je ne sais pas si c'est possible en UWP, et l'impact que cela aurait sur les performances.
#1.13
#1.14
Et vu que Chrome est installé sur plus d'un ordinateur sur 2 ayant Windows (dont la part de marché sur le Desktop est de plus de 90%), Chrome (et ses services) sont une cible de choix pour les pirates.
Une faille, si elle est exploitable, avec droits SYSTEM, sur des centaines de millions de postes, ça risque de faire très très très mal.
#1.8
La dernière chose que je veux dans mon navigateur web c'est un composant avec les droits SYSTEM.
Déjà, toutes mes applis sont installées en mode portable. Chrome est le seul pour lequel je dois faire cela à la main (installation en mode user dans une VM et récupération du répertoire chrome qui est dans APPDATA)
J'attends toujours une installation de chrome en mode portable, ou a défaut un moyen d'extraire le contenu de leur ChromeStandaloneSetup.exe
#2
Firefox ✅
#2.1
Que dire du fait que ff contourne la résolution de nom du système et préfère confier nos recherches à travers doh ? Même si cela part d'une bonne intention, cela ruine les efforts de contrôle parental et de blocage des pub par pihole par exemple.
Et les certificats de sécurité ? Ff se fout royalement des certificats du système, il ne fait confiance qu'aux siens. Ce n'est pas son rôle mais celui du système.
Une vraie plaie quand on utilise ses propres certificats internes même avec une architecture complète (certificats root, intermédiaire et client).
Ff fait chier avec ses messages de sécurité débiles pour des adresses en .home et des IP ula et il ne devrait pas.
A côté de cela ff continue d'imposer une barre d'adresse qui fait des recherches même quand on lui demande expressément d'afficher une barre de recherche séparée. Cela est idéal pour baver des informations internes à google.
Même avec ff, il faut savoir faire quelques configurations pour le sécuriser et je ne parle pas des plugins à ajouter.
#2.2
La configuration DNS ou du catalogue de certificat racine ne concerne pas l'utilisateur lambda.
Pour les entreprise, il est possible d'utiliser les GPO de Firefox (ou about:config) pour changer le comportement. Plus généralement "use-application-dns.net" bloque le DoH.
J'utilise Firefox sous Fedora et je n'ai pas de problème avec le .home et l'ULA (j'ai un routeur OpenWRT)
#2.3
C'est largement inacceptable de devoir en arriver là.
Firefox devrait tolérer sans broncher les certificats locaux auto signé ; des certificats correspondant à des adresses locales différentes de la passerelle et, si résolution de nom, une adresse dont le tld n'est pas valide comme .loc ou .home
Me parler de gpo dans ce cas est totalement hors sujet car la population gênée par ce problème n'a généralement pas les compétences.
Ce n'est pas pour rien que la freebox n'utilise pas https: il est plus simple de virer le message en http qu'en https, un comble
De même, si j'importe mes certificats d'autorité racine et intermédiaire dans Windows, je ne tolèrerai jamais que Firefox les ignore. J'appelle cela péter plus haut que son cul. Firefox peut toujours vérifier la validité d'un certificat avant de s'en servir mais il n'a pas à ignorer ceux du système.
Si chaque logiciel procède ainsi,c'est la chienlie
Concernant les manipulation avec about.config, vu le nombre d'instances de ff sur mes appareils, c'est juste une option que je cherche à éviter.
#2.4
Je n'ai pas ce comportement. J'ai testé et je peux ajouter facilement une exception pour un certificat autosigné. Il faut passer outre des messages d'avertissements, mais c'est tout à fait possible en quelque clic, sans avoir besoin de monter une autorité de certification locale.
C'est un choix réfléchis de la part de Firefox j'imagine. Pour ma part, Firefox est le seul navigateur installable sur certains systèmes obsolètes. Sur des systèmes non mis à jour, certaines CA persistent alors qu'elles ont été retirées de la liste des CA de confiance par les navigateurs et les systèmes d'exploitation (pour des raisons diverses et variées, le plus souvent lié à des manquements dans le processus de validation ou à un manque de communication). Sur ce genre de système non mis à jour, il est indispensable que le navigateur ignore purement et simplement la liste des CA du système.
Car oui, c'est tout con, mais il n'existe pas de révocation pour les certificats racines... car une révocation (CLR ou OCSP) doit être signée par le certificat parent, qui n'existe tout simplement pas dans ce cas là.
Chaque approche (se baser sur une liste interne ou sur la liste des CA du systèmes d'exploitation) à des avantages et des inconvénients. Il n'y a pas une méthode qui est meilleure que l'autre. Juste des contraintes différentes.
Les choix faits par Firefox ne te conviennent pas. Soit. Mais ce n'est pas pour autant que ce sont des choix irréfléchis et/ou inadmissibles.
#2.5
Que firefox ajoute des certificats récent sur un vieux os plus mis à jour, cela se comprend mais, encore une fois, les certificats locaux connus du système et valides doivent être utilisés.
Si on suit la logique que tu valides sans étayer, il serait normal que chaque navigateur et chaque logiciel réseau se fasse sa propre liste? C'est le cas en fait avec l'environnement java il me semble et cela pose aussi problème.
Administrer un réseau où chaque logiciel n'en fait qu'à sa tête est juste un enfer et on dit justement qu'il est pavé de bonnes intentions....
Historique des modifications :
Posté le 02/08/2024 à 00h01
Un certificat ayant une durée de validité, y compris un certificat racine, la non mise à jour de l'os ne peut pas rendre disponible ad vitam de vieux certificats. Firefox est donc en mesure de faire le tri par lui même concernant les certificats anciens et peut toujours vérifier la validité en ligne ou simplement avoir la liste des autorités qui ne sont plus valides.
Que firefox ajoute des certificats récent sur un vieux os plus mis à jour, cela se comprend mais, encore une fois, les certificats locaux connus du système et valides doivent être utilisés.
Si on suit la logique, il faudrait que chaque navigateur et chaque logiciel réseau se fasse sa propre liste? C'est le cas en fait avec l'environnement java il me semble et cela pose aussi problème.
Administrer un réseau où chaque logiciel n'en fait qu'à sa tête est juste un enfer et on dit justement qu'il est pavé de bonnes intentions....
#2.6
As-tu déjà regardé la durée de vie des certificats des AC ? Il n'est pas rare d'en voir avec des durées de validité de 20 ou 30 ans, voire même plus ! Donc des certificats avec des durées de vie aussi longue et sans révocation possibles, oui, il faut gérer ça.
Encore une fois non. Ce n'est pas une obligation. C'est un choix. Firefox a fait celui de ne pas dépendre de l'OS pour gérer les questions de sécurité lié aux certificats. Le fait que tu ne sois pas d'accord n'en fait pas un mauvais choix.
Je n'ai rien validé du tout. Je ne dis pas qu'une approche est meilleure qu'une autre. Je dis que les deux approches existent et se justifient.
Et je ne sais pas de quoi tu as besoin pour étayer. Des exemples ? Windows 7, fin de vie en 2015, supporté par Firefox jusqu'à l'année dernière. Dit autrement : firefox a supporté un OS déprécié pendant 9 ans de plus. 9 ans pendant lesquels cet OS n'avait justement plus de mise à jour des certificats CA, et où la stratégie de Firefox s'avère payante dans ce cas, luttant contre l'obsolescence logicielle.
Tu veux que j'aille encore plus loin ? Prenons l'exemple du CA de Symantec. Il a été retiré en 2018 de Firefox (et des autres navigateurs au passage) suite à des manquements répétés dans le processus de validation. Résultat des courses : une autorité de certification qui représentait près de 30% des certificats émis en janvier 2015 a été retiré des différents magasins. Un navigateur qui repose exclusivement sur l'OS l'aurait laissé passer, Windows 7 en premier (car plus supporté).
La stratégie de Mozilla, c'est aussi une sécurité supplémentaire en cas d'infection de ta machine. Ton système est infecté par un malware qui installe son propre CA dans le magasin de la machine et configure un proxy ? Firefox t'enverra bouler et t'avertira.
Ca tombe bien, ça fait quand même des années que Firefox permet d'utiliser le magasin de certificats de l'OS (depuis la version 49, soit 2016 !). Faut juste lui dire, car ce n'est pas la configuration par défaut...
Que les choix de Firefox ne te conviennent pas, je l'entends tout à fait. Mais ce n'est pas pour autant que se sont de mauvais choix et/ou qu'ils sont irréfléchis comme tu le prétends.
#2.7
Dans ma précédente réponse, j'ai écrit que firefox pouvait très bien tenir à jour les certificats à ne pas utiliser et cela conviendrait parfaitement pour le cas des vieux OS.
Si on en revient à ma problématique de réseau local et de certificats qui sont forcément autosignés ou issu d'autorités locales, que proposes tu pour qu'il ne soit pas nécessaire de créer une exception ? Dans un tel cas, je maintiens que Firefox ne devrait en aucun cas bloquer l'accès ou imposer leur page d'avertissement anxiogène car il n'y a aucun danger à accéder à son nas ou la page de configuration de sa box.
#2.9
Il s'agit de certificat de CA racine. Avoir des délais courts n'a pas de sens non plus. Un certificat racine n'est pas la pour protéger les sites, il est là pour signer / valider / révoquer les certificats qui vont protéger les sites et / ou les autorités de certifications intermédiaires.
Avoir des délais courts, ça signifie aussi que n'importe quel objet IoT non mis à jour arrêtera de fonctionner en quelques années (par ex. certaines "vieille TV" connecté ne peuvent plus se connecter à certains site aujourd'hui, justement à cause de problèmes de certificats, idem pour les vieux smartphones).
Ce qu'il ne faut pas lire... Aucun danger, es-tu réellement sûr ? C'est même là qu'il y a le plus de danger, notamment avec la multiplication des objets connectés. Mais non, voyons, c'est le réseau local, aucun souci, 100% confiance... ce n'est pas comme si les attaques de type MITM étaient infaisable sur les réseaux domestiques
Et Firefox n'est pas le seul, tout navigateur digne de ce nom te fera la même chose, car c'est ainsi que les choses fonctionnent, que tu le veuilles ou non (et j'ai compris que tu ne le voulais pas).
Lorsque tu ajoutes une exception pour un certificat auto-signé, la validation initiale t'incombe. Mais passée cette étape, la connexion est sécurisé et chiffrée au même titre qu'un certificat validée par une CA. Un changement de certificat, et Firefox (ou tout autre navigateur) va de nouveau t'envoyer bouler, ce qui doit t'alerter.
#2.11
J'entends bien ton argument concernant les certificats autosignés mais il faudrait à minima dans ce cas que le message soit compréhensible par l'utilisateur lambda. Genre: "firefox ne peut pas assurer la sécurité de cette connexion car vous accédez à un appareil local. Cliquez sur le le bouton xxxx si c'est bien ce que vous souhaitez."
Et pour ceux qui possèdent une autorité locale, ce que pourraient faire automatiquement les box un jour avec le passage à IPv6, que propose tu ?
Ce qui me dérange est le discours sur le fait qu'ils ont forcément pensé à tout et obligatoirement pris la seule bonne décision possible. Tu sais bien qu'une décision n'est la meilleure que dans un contexte donné. Dans le cas de Firefox, l'équipe n'a pas bien bossé les problématiques de LAN à mon sens.
Tous ces popups avec des messages angoissants ne font qu'habituer les gens à cliquer sur ok sans réfléchir car c'est vécu comme du harcellement. Au final, la sécurité ne s'en retrouve pas augmenté mais bel et bien diminuée comme avec la freebox qui ne gère pas du tout https pour éviter ces débats d'ayatollah.
#2.12
On n'a rarement aucune compétence réseau quand on sait ce qu'est un NAS au point d'en acquérir un, l'installer et le configurer.
Ce qui me dérange, c'est que tu attends, de moi, que je te fournisse des solutions. Réponse : je n'en ai pas. Je ne fais qu'expliquer pourquoi c'est comme ça, et pourquoi le peu que tu proposes est irréalisable.
Si toi tu as la solution, n'hésite pas à la proposer ne serait-ce que sur le bugzilla de Mozilla. J'attends ton ticket avec impatience. C'est la première chose à faire, au lieu de te plaindre ici tout en disant des contrevérités sur Firefox.
Autre chose : les critiques que tu fais sur le fonctionnement des certificats locaux, ce n'est pas une problématique propre à Firefox. Tous les navigateurs ont le même. Alors, stp, arrête de dire sans arrêt des trucs comme "l'équipe n'a pas bien bossé les problématiques de LAN à mon sens" pour cracher sur Mozilla alors que le problème se révèle être systémique si j'adopte ton point de vue.
#2.13
Mais j'apprécie trop firefox pour le reste. Globalement j'en fais la promotion mais cela n'empêche pas la critique.
#2.8
Sauf erreur de ma part, FF ESR 115 a encore des MàJ sous W7 (115.13 en juillet).
#2.10
Et en plus, c'est une ESR, donc bénéficie d'un support étendu. La nouvelle ESR vient de sortir (128, ce 9 juillet). On peut donc encore espérer quelques semaines de support pour la version 115 (ce qui vient en plus renforcer mon propos ^^).
Merci pour la précision
#3
#3.1
Avec l'augmentation de l'utilisation des seconds facteurs d'authentification, les cookies peuvent être plus sensibles que les mots de passe.
#3.2
#3.3
Et la saisie automatique des identifiants, mots de passe et TOTP est devenu compliqué. Je m'en rends compte avec keepassxc.
Récupérer les jetons peut donc devenir plus intéressant pour de multiples raisons mais ce n'est qu'une hypothèse personnelle.
#3.4