Zoom retire son serveur web local, mais il n'était pas le seul

Nicolas Furno |

Face à la polémique (lire : Le client macOS de Zoom peut activer la webcam de votre Mac sans votre accord), le service de visioconférence professionnelle Zoom a finalement cédé. Une mise à jour diffusée dans la nuit désactive totalement le serveur web en local installé sur macOS, celui-là même qui permettait de lancer une réunion de visioconférence sans aucune interaction de la part de l’utilisateur. Ce serveur local, encore, qui n’était pas supprimé quand l’app était désinstallée, qui fonctionnait en arrière-plan et qui réinstallait Zoom à chaque fois que l’utilisateur cliquait sur le lien d’une réunion.

L’iSight, webcam d’Apple commercialisée dans les années 2000. (Photo Quattro Vageena (CC BY-NC-ND 2.0))

Si vous aviez installé Zoom et que vous n’aviez pas supprimé le serveur en suivant les instructions données hier, vous pouvez ouvrir l’app et la mettre à jour. La nouvelle version se chargera de faire le ménage et de supprimer ce serveur local. L’entreprise a aussi ajouté un bouton pour désinstaller Zoom qui enlèvera toutes ses ressources, sans exception. Jusque-là, des éléments devaient être manuellement supprimés pour se débarrasser totalement de l’app.

Tout est bien qui finit bien pour Zoom, mais la polémique révèle que cette app était loin d’être une exception. Cette pratique qui consiste à installer un serveur local pour contourner des limites imposées par le navigateur est en fait assez courante, comme le rappelle un autre chercheur en sécurité. Kevin Beaumont liste sur Twitter d’autres apps de visioconférence qui ont utilisé la même astuce. Il cite notamment RingCentral, qui est en fait identique à Zoom sur le plan technique, et BlueJeans.

La technique dépasse même le cadre de la visioconférence. Depuis que les navigateurs ont abandonné NPAPI, une API créée dans les années 1990 pour permettre à un navigateur de charger un module tiers pour lire un contenu, plusieurs services et apps ont opté pour un serveur web local. On ne connaît probablement pas tous ceux qui l’ont fait, mais cette liste de trois noms donne une idée de l’étendue du problème. Un client Torrent, un antivirus ou même Logitech utilisent cette technique.

En soi, faire tourner un serveur local sur un Mac n’est pas un problème. Le souci, c’est que ces apps utilisent ce serveur pour contourner les mesures de sécurité légitimes des navigateurs. Pour faire simple, cela leur permet de demander au navigateur d’ouvrir une URL standard, comme s’il s’agissait d’un site web, plutôt que de lui demander d’ouvrir une app. Le navigateur n’y voit que du feu, mais c’est une faille de sécurité potentielle, une app installée sur un Mac ayant un pouvoir de nuisance bien supérieur à un site.

Face à cette mauvaise publicité, on peut imaginer que Google, Apple ou encore Mozilla vont réagir en ajoutant des restrictions supplémentaires dans leurs navigateurs respectifs. En attendant, il n’y a pas grand-chose que l’on peut faire contre cette pratique.

avatar Amaczing | 

Aïe 😓

avatar stewbaba | 

On découvre tous les jours la vulnérabilité de nos systèmes. La sécurité est un leur.

avatar BeePotato | 

Correction ultra-mineure, juste pour chipoter au sujet de la légende de la photo : l’iSight n’était en fait pas la toute première webcam d’Apple, qui avait déjà sorti, près de 10 ans plus tôt, la QuickTime Video Conferencing Camera 100.
Elle a cependant connu moins de succès que l’iSight. :-)

avatar Nicolas Furno | 

@BeePotato

Pan sur les doigts ! Ça m'apprendra à vouloir faire mon savant… :-)

Je corrige.

avatar BeePotato | 

@ Nicolas Furno :
Faut avouer tout de même que la QuickTime Video Conferencing Camera, c’est un produit plutôt obscur de nos jours par rapport à l’iSight. Même à l’époque de sa sortie, d’ailleurs, ce n’était pas un produit vendu par palettes.

avatar ⚜Dan | 

La (iSight) Quicktime Video Conferencing Camera était quand même 1800$ US.
J'estime donc que le cota de 1200$ de plus pour les appareils Apple en 2019 soit complètement justifier a mon sens.

avatar xDave | 

Des restrictions de la part d’Apple Google Microsoft?
Ah je suis curieux de voir comment ils bloqueraient un appel à localhost sans faire suer un serveur local légitime type MAMP.

avatar Sgt. Pepper | 

@xDave

Au minimum avertir l’utilisateur qu’un server local est utilisé ?

avatar xDave | 

@Sgt. Pepper

Comment? À quel moment?
Comment distinguer une App qui a un port ouvert d’un serveur dédié à ce genre de blague?
Avertir on click?

Ça semble lourd. On va avoir plein d’alertes intempestives?

Je ne sais pas 😐

avatar YAZombie | 

Déjà ils pourraient prévenir au moment de la désinstallation que la procédure n'élimine pas le serveur web afin de simplifier les connections futures, voire donner le choix de conserver ou pas cette fonction de réinstallation automatisée. C'est bancal parce qu'on sait bien que le virus principal se situe entre le clavier et la chaise, mais au moins ils ne feraient pas les choses en douce 🤷‍♂️️

avatar xDave | 

@YAZombie

Qui ils?
Mr Zoom ayant fait ça pour contourner un sandboxing, j’imagine que les liens logiciels entre le serveur et l’application sont bien planquées

avatar YAZombie | 

@ xDave: si tu relis l'article, le problème n'est pas tant l'existence du serveur web mais que celle-ci ne soit pas annoncée, ni ses dangers. Toi ou moins trouvons cette existence inadmissible, mais si d'autres veulent prendre le risque pour une simplicité d'usage accrue, il faut au moins que ce soit réellement un choix, donc qu'on l'annonce au moment de l'installation.
L'autre problème est donc le fait que ce serveur ne soit pas désinstallé en même temps que Zoom. C'est là où vient ma remarque ci-dessus.

Pour résumer, ma philosophie ici serait: c'est mal de faire ce genre de choses et je refuserais de prendre ce risque, mais si une entreprise ne voit pas d'autre solution pour répondre à sa promesse (ici l'extrême simplicité pour se joindre à une téléréunion), elle se doit d'être entièrement transparente sur les compromis adoptés pour que le client fasse le choix en connaissance de cause.
Je suis plus clair?

avatar byte_order | 

@YAZombie
> Déjà ils pourraient prévenir au moment de la désinstallation que la procédure n'élimine
> pas le serveur web afin de simplifier les connections futures, voire donner le choix de
> conserver ou pas cette fonction de réinstallation automatisée.

Quelque chose me dit que le portage Mac est pas le plus rentable qui soit, et comme
d'habitude du coup il est fait à minima, voir baclé. L'oubli n'est p'tet pas volontaire ni même fait par choix de l'éditeur à l'occasion...

avatar YAZombie | 

@byte_order: j'entends ce que tu dis, et je peux imaginer que ça puisse avoir été le cas. Mais quand le problème leur a été signalé, au départ ils sont restés campés sur leur position au lieu de proposer des alternatives satisfaisantes, notamment la transparence. C'est vraiment ça que je critique. Les impératifs techniques, ou les aléas dus à la sous-traitance par exemple, j'en comprends tout à fait le poids 👍️

avatar byte_order | 

@xDave
> Ah je suis curieux de voir comment ils bloqueraient un appel à localhost
> sans faire suer un serveur local légitime type MAMP.

Via une politique CORS externe -> localhost configurable par l'utilisateur.

Ce qui ne gènerait probablement pas tant que ça un dev avec sa pile MAMP, vu qu'il teste probablement soit purement en localhost directement, soit depuis un autre terminal, beaucoup rarement en mélengeant les 2.

avatar Xalio | 

Je ne fais pas confiance, j’ai un cache physique sur la webcam. 😎

avatar John0 | 
avatar byte_order | 

> Le navigateur n’y voit que du feu, mais c’est une faille de sécurité potentielle,
> une app installée sur un Mac ayant un pouvoir de nuisance bien supérieur à un site.

Il manque assurément un support du CORS désactivable par l'utilisateur (à la première apparition par exemple) pour les URL vers localhost.
Ainsi, le navigateur cesserait de ne vouloir voir que du feu (comment, cette page venant de telle adresse non locale demande l'accès à telle ressource en localhost ?!) et pourrait prévenir l'utilisateur et lui demander ce qu'il souhaite maintenant - et à l'avenir. En bref, arrêtons de de sandboxer tout *y compris* l'utilisateur, alerter sur les risques oui, mais au final c'est lui et lui seul qui doit avoir le choix final.

A défaut, on créer des situations où des verrous "de sécurité pour le bien de l'utililsateur mais il n'a pas son mot à dire" amènent à des contournements parce que les utilisateurs, eux, veulent les usages légitimes qui font sens, et se voir demander à chaque fois son accord pour activer la webcam quand c'est toujours le même site qui le demande, cela fait pas sens, non.

Demandez à Microsoft le retour client des UAC de Windows à une époque...

avatar xDave | 

@byte_order

C’est le délicat exercice d’équilibre entre l’expérience utilisateur et la sécurité

CONNEXION UTILISATEUR