Ce qui arrive sur votre Mac ne reste pas toujours sur votre Mac, Réactions à la publication du 15/11/2020

[Rédaction]

... et c'est encore moins le cas avec l'arrivée de Big Sur.

Vous avez peut-être remarqué sur votre Mac un ralentissement du lancement des applications ces derniers jours. Un ralentissement dû à une fonctionnalité de sécurité de macOS.

Introduite il y a deux ans, cette fonctionnalité consiste à envoyer à un serveur d'Apple (ocsp.apple.com) la signature unique du fichier exécutable de chaque application que vous tentez d'exécuter sur votre Mac. En réponse, le serveur indique au Mac si l'application en question peut ou non être lancée.

Si le serveur est injoignable (Mac non connecté à Internet ou requête bloquée par un pare-feu), l'application se lance immédiatement. S'il est joignable, elle n'est lancée qu'une fois qu'une réponse positive a été reçue. Ainsi, en cas de surcharge des serveurs, comme c'est arrivé les 12 et 13 novembre, l'allongement du temps de réponse du serveur provoque le ralentissement du lancement des applications, constaté par de nombreux utilisateurs.

Un dysfonctionnement qui tombe particulièrement mal, alors même qu'Apple vient de sortir macOS Big Sur, qui rend plus compliqué la désactivation de ce système. En effet, s'il n'y a jamais eu d'option officielle permettant de la désactiver, cette fonctionnalité pouvait jusqu'à présent être bloquée avec un pare-feu installé sur le Mac, comme LittleSnitch. Ce n'est plus possible sous Big Sur, qui a mis en place une protection de certains processus système : leurs requêtes réseau ne peuvent plus être filtrées par un pare-feu local, ni passer par certains VPN (un VPN virtuel aurait aussi permis de les bloquer localement).

Il semblerait que pour l'instant le blocage soit encore possible via le fichier /etc/hosts, en y ajoutant une entrée pour faire pointer ocsp.apple.com vers 127.0.0.1. Mais pour combien de temps ?

Venant d'Apple, qui se présente régulièrement comme un défenseur de la vie privée, ces restrictions sont en tout cas particulièrement mal venues, d'autant plus que les données sont transmises en clair et que les requêtes transitent par des serveurs n'appartenant pas à Apple (Apple utilise les services d'Akamai pour mieux absorber la charge), ce qui donne une grande surface d'attaque pour intercepter les requêtes et déterminer les logiciels utilisés par les Mac situés derrière une IP publique donnée, mais aussi, de deviner de manière indirecte d'autres informations : profession, horaires de travail, période de congé, loisirs…

Pire, l'absence de chiffrement pourrait éventuellement ouvrir à un attaquant la possibilité de déterminer quelles applications il vous autorise à utiliser sur votre Mac, en renvoyant des réponses négatives aux requêtes qu'il aura réussi à intercepter (ce n'est toutefois pas trivial, la réponse étant normalement signée par le serveur)…

MàJ : la signature envoyée est en fait propre à chaque développeur/éditeur, et non à chaque application, ce qui limite un peu la portée des informations pouvant être récupérées (l'attaquant peut par exemple déterminer que vous utilisez des logiciels Adobe et Microsoft, mais pas lesquels précisément).


Lien vers le billet original

[tchek]

Allez op c'est parti :
https://sneak.berlin/20201112/your-computer-isnt-yours/

[linus]

Est ce que ce n'est pas là le fonctionnement normal de la Notarisation des applications ?
Jusque récemment, un appli n'avait le choix qu'entre aucun contrôle (lancement via le Open du Finder) et un contrôle tatillon (App Store).
App Store = signature + sandboxing (bac à sable) et certaines applis sont impossible à sandboxer (j'en sais quelque chose !)
Apple, très attaquée là-dessus, a fini par proposer une alternative plus simple.
Notarisation = signature + enregistrement sur les serveurs d'Apple d'un code unique pour chaque application. A chaque lancement le code de l'application est comparé avec le code conservé par Apple.
La notarisation, c'est BEAUCOUP plus facile et souple que le sandboxing.

Si c'est bien ça, je ne m'associerais pas à ceux qui crient ici contre ce mécanisme de sécurité. D'ailleurs j'en suis bénéficiaire pour plusieurs applis scientifiques impossible à publier sur l'App Store.
Ah oui, c'est vrai, je n'ai encore essayé Big Sur.

Publier sur l'App Store est un vrai travail
1- créer tous les certificats nécessaires
2- installer les clés publiques/privées sur sa machine
3- créer un identifiant unique
4- remplir les multiples champs des pages décrivant l'application sur iTunes Connect ... un vrai travail !
5- imposer un OS minimum pour tous les binaires, framework, dylib
6- créer un fichier contenant une description des autorisations de l'appli ("entitlements") ce qui est parfois assez difficile
7- durcir tous les binaires
8- signer le bundle + sandboxing via les "entitlements"
9- créer un package .pkg
10- signer le .pkg
11- envoyer le .pkg signé à Apple
12- attendre pas mal une réponse de validation
13- si ça a marché, soumettre l'application à Apple
14- attendre plusieurs jour le verdict ... assez souvent négatif pour l'une ou l'autre bricole
15- refaire une bonne partie de ce processus jusqu'à ce que mort s'en suive.
Une vraie galère !

Oui, oui, Xcode automatise pas mal tout ça si on a la chance d'utiliser un language supporté par Xcode et de ne pas devoir utiliser un autre environnement de développement permettant du développement multiplateforme.
Avant, on compilait/linkait et vogue la galère, maintenant c'est prise de tête. Avant on n'avait pas non plus besoin de clés compliquées, de digicodes, etc... avant... mais on vit aujourd'hui et il y a des virus et autres malwares !

Notariser une application c'est presque pareil que ci-dessus mais quand même nettement plus facile et nettement plus rapide. La réponse automatique d'Apple ne se fait attendre que 10' pas des heures ou des jours.

Ce message a été modifié par linus - 17 Nov 2020, 00:33.