Le lancement de Big Sur n’est décidément pas de tout repos. Apple a déjà reconnu ses torts sur le contrôle du lancement des applications tierces. Ces dernières sont en outre soumises à de nouvelles limitations… auxquelles les applications maison peuvent échapper. Le problème, soulevé pendant la bêta, n’a pas été corrigé.
Mais que se passe-t-il avec Big Sur ? Apple n’a de cesse de parler de sécurité, mais le message devient moins net quand la communication se heurte à la pratique.
On a déjà vu récemment comment des applications tierces avaient été dans l’incapacité de se lancer à cause d’un problème interne avec certains serveurs de l’entreprise. Ils étaient en charge de vérifier l’authenticité des certificats des développeurs via OCSP. Ne répondant pas aux requêtes, ils ont laissé les applications dans un état imprévu. Le problème a duré moins d’une heure, mais a été particulièrement visible et a largement attiré l’attention.
Apple a fait amende honorable. Reconnaissant que les adresses IP étaient collectées et que les échanges étaient de plus non chiffrés, elle a annoncé la suppression de ces informations et a promis une connexion sécurisée, ainsi que d’autres efforts. Des promesses à vérifier, car le chiffrement ne sera mis en place que dans le courant de l’année prochaine.
L’attention se tourne désormais vers un autre problème, lié à la disparition des anciennes extensions du noyau. Or, la solution de remplacement impose certaines limites… qu'outrepassent les propres applications d’Apple, avec un comportement que certains chercheurs pointent comme une possible porte d’entrée aux malwares. Explications.
L’adieu aux kexts
Le système d’Apple proposait depuis très longtemps des extensions au noyau nommées kexts, contraction de « kernel extensions ». Elles permettaient l’accès à des fonctions de très bas niveau. Ce que l’entreprise n’a plus voulu il y a quelques années.
Pour High Sierra, premier serrage de vis : les kernel extensions étaient bloquées par défaut. Ce qui supposait que l’on pouvait donc les réactiver. Des applications comme Little Snitch avaient besoin de cette manipulation pour être pleinement fonctionnelles. Avec Catalina, Apple a proposé sa solution de remplacement : DriverKit. Comme Microsoft plusieurs années avant, l’éditeur souhaitait que les développements se fassent en espace utilisateur, et non plus en espace noyau.
Le choix est légitime d’un point de vue sécurité : un processus ayant accès au noyau a des privilèges nettement supérieurs à un autre en espace utilisateur, où les règles très strictes l’empêchent normalement de faire des dégâts trop sérieux. D’un point de vue purement fonctionnel en revanche, il s’agissait d’une perte sèche, car DriverKit n’offrait pas les mêmes capacités. Et il fallait faire avec, car Apple l’avait annoncé, Big Sur interdirait purement et simplement les kexts.
Maintenant que le système est là, les applications doivent faire avec.
Un sérieux problème découvert il y a un mois et demi
Objective Development, société éditrice de Little Snitch, a cependant découvert un sérieux souci pendant la bêta de Big Sur, comme elle l'explique dans un billet publié mardi.
Les pare-feux et VPN, notamment, avaient l’obligation désormais de passer par le Network Extension Framework, conçu avec DriverKit et devant donc permettre à ce type d’applications de continuer à fonctionner, mais en espace utilisateur. Une API spécifique était disponible pour les filtres. Or, l’entreprise a découvert que des services Apple contournaient ce mécanisme.
Le 1er juillet, Objective Development a fait remonter le bug à Apple : le processus de téléchargement des mises à jour échappait aux règles édictées par le pare-feu. Trois mois plus tard, il fallait se rendre à l’évidence : il ne s’agissait pas d’un processus isolé. Ainsi, l’App Store, Maps ou encore FaceTime avaient le même comportement. En tout, 56 applications, constituant une liste qui n’a depuis de cesse de faire parler d’elle. Ces trouvailles ont été à nouveau communiquées à Apple, le 1er octobre.
Objective Development ne remet pas en cause l’idée que certains processus soient essentiels à la sécurité de la machine. « Mais cacher ces connexions complètement à l’utilisateur n’a aucun sens. Cela contredit l’idée de transparence et d’un système digne de confiance, et affaiblit la confiance de l’utilisateur en ce système », pointe l’entreprise.
Comme nous l’avions souligné pour les mécanismes de sécurité liés à OCSP, Objective Development pointe l’importance cruciale du choix. Dans son Little Snitch, l’utilisateur est libre par exemple de bloquer toutes les connexions, au point de rendre la machine inutilisable en réseau, local ou Internet. Cette liberté est accompagnée de messages d’avertissement, de règles par défaut et d’autres mécanismes pour que le choix soit aussi éclairé que possible. Apple a même annoncé que les utilisateurs pourraient dans le courant de l’année prochaine désactiver la vérification des certificats.
Le risque d’un comportement détourné par les malwares
La question qui se pose maintenant est de savoir si ces droits octroyés aux applications et services internes pourraient être détournés par du code malveillant.
On s’étonne qu’Apple, d’ordinaire vigilante, ne se soit pas posé la question plus tôt, ou du moins n’ait pas choisi d’en parler. La firme est la première à s’insurger quand on lui demande de percer des portes dérobées dans ses propres défenses, comme elle l’avait fait face au FBI après la tuerie de San Bernardino.
Plusieurs chercheurs en sécurité se sont emparés de la question, notamment Patrick Wardle. Il y a quelques jours, il tweetait ainsi sur le sujet, se demandant si ce passe-droit pouvait être utilisé par un malware pour exécuter son code en passant inaperçu. La réponse est oui.
D’après ses propres tests, captures à l’appui, il a montré qu’un processus pouvait récupérer un niveau semblable de privilège, tout en échappant au pare-feu. Une conséquence logique, puisque les 56 applications de la fameuse liste ont une activité qui ne peut être bloquée par les applications tierces. Un autre chercheur, Wojciech Reguła, est arrivé aux mêmes conclusions, lui aussi expliquant que la manipulation était aisée.
Apple aurait reconnu qu’il s’agissait d’un « bug »
On entre maintenant dans une zone mystérieuse. Plusieurs chercheurs ont vu passer un message expliquant qu’Apple aurait reconnu qu’il s’agirait d’un bug. Les tweets en question ont depuis été effacés. Reste des réponses à un certain Russ Bishop, dont le compte Twitter est privé et montre une pomme dans la « bio ». Or, on trouve très facilement sur LinkedIn un Russell Bishop, ingénieur chez Apple depuis juillet 2016. L'employé en a peut-être trop dit, avant de se rétracter.
Le consensus parmi les chercheurs semble être qu'Apple va donc réagir. Mais ils se posent également la question : comment pourrait-il s’agir d’un bug ? Le fonctionnement de cette liste d’applications repose très clairement sur un mécanisme d’exclusion. En clair, elles échappent volontairement à un processus auquel sont soumis les éditeurs tiers. D’autant plus que ce « bug » a été signalé à plusieurs reprises il y a plus d'un mois.
Qu’Apple réagisse devant la tempête semble acquis : la société ne peut laisser cette situation perdurer, surtout avec une communication axée sur la sécurité et la vie privée. Le problème est bien pire qu’avec la vérification des certificats via OCSP, car la liste d’exclusions peut être détournée par des logiciels malveillants, avec les conséquences que l’on imagine.
On attend donc une réaction officielle d’Apple, qui n’a pour l’instant répondu à aucune requête de la presse américaine. La situation mérite une explication, et même si l’entreprise s’en sort avec une pirouette en insistant sur l’idée de « bug », les communications des applications internes doivent revenir à leur état antérieur : vérifiables et blocables par les pare-feux.
