OS X : GateKeeper ne fait toujours pas correctement son travail de sécurité

Il y a plus efficace que les listes

Le 19 janvier 2016 à 08h17

4 min

Logiciel

En octobre dernier, un chercheur indiquait comment la protection GateKeeper d’OS X pouvait être contournée facilement. Apple avait a priori résolu le problème, mais pas selon Patrick Wardle : la société n’a rien corrigé, et la brèche peut toujours être exploitée.

Patrick Wardle est un ancien de la NSA, travaillant depuis comme directeur de la recherche chez Synack. En octobre dernier, il tirait la sonnette d’alarme : GateKeeper ne remplissait pas correctement sa mission. Ce composant, apparu dans Lion (version 10.7.5), a pour principale mission de contrôler l’exécution des logiciels et de vérifier surtout leur certificat.

Remorquage de binaires vérolés

Si le logiciel provient de l’App Store, c’est qu’il a été contrôlé en amont et qu’il n’y a pas de raison de se méfier. Dans le cas contraire, il suffit qu’il ait un certificat électronique reconnu par Apple. S’il n’en possède pas, OS X affiche un message d’erreur indiquant qu’en raison des paramètres de sécurité, le logiciel n’a pas le droit de s’exécuter. Il s’agit du paramètre par défaut, qui peut être durci pour n’autoriser que les applications du Store, ou au contraire relâché pour autoriser tous les logiciels, avec ou sans certificats.

Or, comme montré par Wardle, GateKeeper (littéralement gardien de porte) pouvait aisément être berné puisqu’il ne remplissait pas sa mission jusqu’au bout. Sa protection pouvait être ainsi contournée si la vérification binaire se concentrait sur un premier fichier, qui en profitait ensuite pour tracter vers lui un autre binaire, cette fois malveillant. Il en avait averti Apple, qui avait répliqué le mois suivant avec une mise à jour.

Une simple liste noire

Seulement voilà, Patrick Wardle n’en a pas fini avec GateKeeper, et pour cause, puisque le problème est toujours présent. La solution retenue par Apple est en effet simpliste : mettre sur liste noire les applications dont Wardle s’est servi pour ses tests et démonstrations. Un vrai cache-misère que le chercheur dénonce dans un nouveau billet de blog : « Même sur un système OS X 10.11.2 entièrement mis à jour, GateKeeper est simple à contourner ».

Le chercheur indique que rien dans le correctif d’Apple ne permet de combattre le problème. Se concentrer sur une liste noire des binaires à bloquer ne corrige pas le problème sous-jacent, et Wardle indique qu’en conséquence, les pirates peuvent « redémarrer leur distribution de chevaux de Troie » et aux États de recommencer leurs attaques de type MITM (Man In The Middle). Pour Apple, cela revient à mettre en place un nouveau jeu du chat et de la souris, puisqu'il lui faudra surveiller les binaires utilisés pour contourner GateKeeper et mettre à jour constamment la liste.

Wardle participait d’ailleurs à la conférence ShmooCon (dédiée aux hackers) dimanche 17 janvier pour expliquer en détail les problèmes de GateKeeper.

Prudence en attendant que GateKeeper soit renforcé

En attendant qu’Apple déploie une vraie solution, il est évidemment recommandé aux utilisateurs de faire attention aux sources de téléchargements. Le Mac App Store et les sites officiels des applications un tant soit peu connues ne causeront pas de difficultés, mais la situation peut vite dégénérer sur un utilitaire qui promettrait monts et merveilles.

On rappellera d’ailleurs qu’Apple a dû faire face à des applications mobiles vérolées parce qu’elles avaient été compilées par des versions contaminées de l’environnement Xcode. Ces moutures avaient été téléchargées par des développeurs chinois qui ne cherchaient, initialement, qu’à récupérer le logiciel plus rapidement, Apple ne possédant pas de serveurs locaux dans le pays (la société a promis d’en installer). Le cas rappelle que la sécurité peut basculer très rapidement, quelles que soient les raisons qui ont poussé l’utilisateur vers un téléchargement.

Commentaires (32)

MacGuiPro

Le 20/01/2016 à 14h56

C’est la différence entre les théoriciens et les industriels. Un industriel va viser le pragmatisme et le résultat net et rapide. Des choses comme les Paréto, les QCDP,… Ca tend à faire du quick’n’dirty au final. Le dogmatisme (code propre, bien documenté,…) ça part bien souvent aux oubliettes. Après quelques années dans l’industrie, les principes de l’école sont bien vite rejetés.

(note aux haterz : mes propos ne constituent en aucun cas un jugement de valeur de la politique d’Apple, des fois qu’il y aurait des envies de voir le mal partout)

Zerdligham

Le 20/01/2016 à 17h47

Tout dépend de l’exercice précisément.

Dans le cas d’exercices qui testent la capacité d’un étudiant à produire une fonctionnalité relativement simple, tester la fonctionnalité peut suffire. Pour reprendre mon exemple d’inversion de chaînes de caractères, même si c’est une démo, l’examinateur pourrait demander à l’étudiant de lui montrer le résultat sur quelques mots qu’il choisit au hasard, si ça marche, il y a de grandes chances que le code ne soit pas truandé.

Pour un exercice plus subtil, une analyse du code peut être nécessaire (pour vérifier une complexité, ou si tous les cas ne sont pas simplement testables par exemple). Et encore, si le prof se préoccupe plus de l’algo que du programme lui-même, et que l’élève fait une présentation convaincante de comment son algo gère tous les cas problématiques, le code lui-même n’est pas très important.

Xaelias

Le 20/01/2016 à 19h48

Zerdligham a écrit :

Tout dépend de l’exercice précisément.

Dans le cas d’exercices qui testent la capacité d’un étudiant à produire une fonctionnalité relativement simple, tester la fonctionnalité peut suffire. Pour reprendre mon exemple d’inversion de chaînes de caractères, même si c’est une démo, l’examinateur pourrait demander à l’étudiant de lui montrer le résultat sur quelques mots qu’il choisit au hasard, si ça marche, il y a de grandes chances que le code ne soit pas truandé.

Pour un exercice plus subtil, une analyse du code peut être nécessaire (pour vérifier une complexité, ou si tous les cas ne sont pas simplement testables par exemple). Et encore, si le prof se préoccupe plus de l’algo que du programme lui-même, et que l’élève fait une présentation convaincante de comment son algo gère tous les cas problématiques, le code lui-même n’est pas très important.

Mais même sans parler de truandage, c’est quoi l’intérêt de l’exercice si le prof regarde pas le code? Je sais que je suis capable d’inverser une chaîne… l’intérêt c’est que le prof regarde et me dise que dans ce language là, cette méthode là est plus propre/efficace/etc.

Zerdligham

Le 21/01/2016 à 10h50

Selon l’exercice, on peut y voir deux intérêts:

1- Toi tu sais peut-être que tu sais faire, mais le prof ne sait pas. Si ton programme fonctionne, il saura que tu sais faire.

2- Dans certains cas, l’intérêt sera de te faire réfléchir au problème, et de contrôler rapidement si ta réflexion était bonne. Évidemment, dans l’exemple que j’ai donné, il n’y a pas à réfléchir des masses, mais dans d’autres cas, le simple fait de faire un programme qui marche, même s’il est dégueulasse niveau code, sera la preuve d’une réflexion de bonne qualité.

J’ai eu une fois un projet qui consistait à programmer une IA optimale au puissance 4. Clairement, la difficulté n’était pas dans le code lui-même, mais dans la conception des algos.

Du coup simplement jouer ton IA contre une IA optimale programmée par le prof, permet déjà de se faire une bonne idée de la qualité de ton travail : si tu gagnes, c’est que tu as bien réfléchi, si tu perds, c’est l’échec. Lire ton code est intéressant, mais secondaire.

Xaelias

Le 21/01/2016 à 14h16

Zerdligham a écrit :

Selon l’exercice, on peut y voir deux intérêts:

1- Toi tu sais peut-être que tu sais faire, mais le prof ne sait pas. Si ton programme fonctionne, il saura que tu sais faire.

2- Dans certains cas, l’intérêt sera de te faire réfléchir au problème, et de contrôler rapidement si ta réflexion était bonne. Évidemment, dans l’exemple que j’ai donné, il n’y a pas à réfléchir des masses, mais dans d’autres cas, le simple fait de faire un programme qui marche, même s’il est dégueulasse niveau code, sera la preuve d’une réflexion de bonne qualité.

J’ai eu une fois un projet qui consistait à programmer une IA optimale au puissance 4. Clairement, la difficulté n’était pas dans le code lui-même, mais dans la conception des algos.

Du coup simplement jouer ton IA contre une IA optimale programmée par le prof, permet déjà de se faire une bonne idée de la qualité de ton travail : si tu gagnes, c’est que tu as bien réfléchi, si tu perds, c’est l’échec. Lire ton code est intéressant, mais secondaire.

Non ça n’est pas secondaire. Le résultat en soit est très peu informatif. Ce qui est intéressant, c’est que le prof regarde, et puisse te dire où tu aurais pu/dû faire mieux. Surtout dans un truc où tu crées tes algos toi-même j’ai envie de dire ^^

En effet, regarder le code n’est pas systématiquement utile. Mais franchement, j’ai eu aussi des cours en France où au final ça revenait à ça. Très clairement tous les élèves trouvaient ça débile, et pour en avoir discuté en bilan de fin de semestre avec la direction et les profs, le prof qui enseignait la matière était d’accord que ce qu’on lui avait demandé de faire était stupide (c’était un essai, les erreurs arrivent je lui en veux pas ^^).

Si je prends des cours de codes, c’est pour que le prof puisse m’aider à m’améliorer. Sinon je vais sur internet, et je fais des trucs genre codewars qui se contente de te dire si ton programme fonctionne ou pas.

jpaul

Le 19/01/2016 à 08h30

GateKeeper est de toutes façons une vaste blague niveau sécurité. Il n’a qu’une seule utilité commerciale pour Apple en forçant les développeurs à devoir adhérer au programme développeur.

TheStig Abonné

Le 19/01/2016 à 08h31

Comme toujours, quel que soit le système, la protection la plus efficace reste un cerveau sain placé entre la chaise et le clavier… 

;)

Obidoub

Le 19/01/2016 à 08h42

La solution retenue par Apple est en effet simpliste : mettre sur liste

noire les applications dont Wardle s’est servi pour ses tests et

démonstrations.

….what ? Ils sont sérieux ?

On dirait une solution française : un hacker annonce la présence d’une faille ? –> Mettons cette personne en prison !

MacGuiPro

Le 19/01/2016 à 08h44

Pour configurer un mac pour Mme Michu (la célèbre Mme Michu), une protection comme GateKeeper constitue déjà un premier pas pour sécuriser l’utilisation d’applications. En limitant au store on limite l’installation d’applications douteuses. Après pour un utilisateur avancé, on est d’accord, GateKeeper est une des premières choses qui sautent.

alex.d. Abonné

Le 19/01/2016 à 08h44

TheStig a écrit :

Comme toujours, quel que soit le système, la protection la plus efficace reste un cerveau sain placé entre la chaise et le clavier… 

;)

Quand le problème vient d’une application légitime compilée avec une version vérolée de Xcode, c’est plus compliqué que PEBCAK.

 

megatom

Le 19/01/2016 à 08h47

Obidoub a écrit :

….what ? Ils sont sérieux ?

On dirait une solution française : un hacker annonce la présence d’une faille ? –> Mettons cette personne en prison !

C’est clair que ça fait très amateur de la part d’Apple…

Norde

Le 19/01/2016 à 08h53

Plus qu’amateur : malhonnête !

“La solution retenue par Apple est en effet simpliste : mettre sur liste

noire les applications dont Wardle s’est servi pour ses tests et

démonstrations.”

 

Réaliser un correctif incomplet ça peut arriver (pour x raisons), mais sciemment masquer le problème tout en ne corrigeant rien du tout ça c’est tout autre chose…

MacGuiPro

Le 19/01/2016 à 08h55

C’est peut-être parce que le problème est plus complexe qu’il n’en a l’air. Apple a très bien pu commencer par masquer les binaires connus et affectés, pendant ce temps ils cherchent une vraie solution. Après tout on ne connaît pas les causes du marquage des binaires.

Oliewan Abonné

Le 19/01/2016 à 09h04

Si tel était le cas Apple aurait prévenu Wardle, ne serait-ce que pour éviter que le gars continue de tirer al sonnette d’alarme.

Mais la, ben non.

MacGuiPro

Le 19/01/2016 à 09h06

Je connais pas la politique d’Apple en matière de gestion des failles, mais il doit y avoir des précédents. Peut-être qu’Apple a pour habitude de ne pas négocier avec les terroristes chercheurs en sécurité. Rien n’indique qu’Apple n’a pas pris en compte le problème de manière plus profonde et ne travaille pas en interne sur une solution. C’est leur politique du secret.

jpaul

Le 19/01/2016 à 09h07

MacGuiPro a écrit :

Pour configurer un mac pour Mme Michu (la célèbre Mme Michu), une protection comme GateKeeper constitue déjà un premier pas pour sécuriser l’utilisation d’applications. En limitant au store on limite l’installation d’applications douteuses. Après pour un utilisateur avancé, on est d’accord, GateKeeper est une des premières choses qui sautent.

Je ne suis pas vraiment d’accord avec ça. Niveau sécurité ça n’apporte rien (d’autant que ce n’est pas parce qu’un programme est signé par un compte Apple Developper qu’il n’est pas malveillant, même si du coup effectivement il peut être plus facilement blacklisté), et ça empêche juste les développeurs non affiliés à Apple de distribuer des applications simples à installer.

Bien sûr on peut le faire sauter facilement et sans réellement se mettre en danger, mais qui va le faire ? Et pourquoi Apple a t’elle décidé que le réglage revenait de lui même après 30 jours (ça aussi on peut le faire sauter, mais il faut passer par de la ligne de commande).

Franchement j’admire beaucoup l’ingénierie d’Apple (et j’adore mon Macbook Air) , tant sur le plan matériel que logiciel, ils ont des années d’avance en terme de miniaturisation, intégration, outils de développement, qualité logicielle, design, ergonomie (quoique ce point se discute) … mais la philosophie de cette boite me débecte de plus en plus.

MacGuiPro

Le 19/01/2016 à 09h16

Là c’est moi qui ne suis pas d’accord. Hormis quelques cas d’infection somme toute assez rare, le téléchargement d’applicatifs depuis un store, ayant eu les API utilisées validées, comme sur iPhone/Android/Windows Phone par exemple apporte certaines garanties de sécurité. Cela permet de limiter (pas éradiquer, je suis d’accord) les malwares. Aujourd’hui c’est devenu un réflexe naturel que d’avoir une boutique à applications (qu’elle soit ou non fournie), et d’aller y piocher ses applications. Bloquer par défaut l’exécution d’applications non signées par un constructeur c’est limiter l’impact des malwares.

Qu’Apple laisse les utilisateurs dans un “pré carré” pour les applications en n’autorisant que ses applications à se lancer est à mon sens une bonne chose pour limiter les infections.

Et oui, ça bloque les développeurs tiers (on l’a vu avec VLC qui était contre l’idéologie de l’App Store d’Apple et s’est volontairement retirée du store), ça impose d’accepter les règles de la boîte (pas de pr0n par exemple), mais si c’est une décision idéologiquement discutable, elle est sécuritairement bénéfique sur le long terme.

Bejarid

Le 19/01/2016 à 09h39

MacGuiPro a écrit :

(on l’a vu avec VLC qui était contre l’idéologie de l’App Store d’Apple et s’est volontairement retirée du store)

Si ils sont effectivement contre l’idée du store, ce n’est pas tant idéologiquement que pratiquement. Ça rend le multiplateforme très chiant à gérer (clairement un enfer).

Ensuite, si ils ne sont pas présent chez l’App Store, ce n’est pas de leur décision, car ils se sont retroussés les manches et ont trouver les contournements (malgré leurs couts conséquents en temps/complexité ajoutée, ils l’ont fait sur quasi tous les stores). Mais Apple les a fait sauter à répétition, avant de carrément les blacklister. Je crois qu’ils le sont toujours d’ailleurs.

Enfin, ce n’était que la plus grosse des erreurs de tes commentaires, car malheureusement le reste est également à coté de la plaque. Mais on va pas y passer la journée n’est-ce pas, si t’as envie de défendre Apple au lieu de chercher à comprendre la réalité, ça ne regarde que toi.

 

Bye-ne~

MacGuiPro

Le 19/01/2016 à 09h49

Tout d’abord, quand je parle de retrait idéologique de l’App Store, c’est prouvé. Un des développeurs a demandé le retrait en 2011 de l’application VLC, pour des raisons de licence : http://www.zdnet.fr/actualites/ios-vlc-de-retour-dans-l-app-store-39814782.htm 

Edit : un autre lien : http://www.mac4ever.com/actu/68191_vlc-bientot-de-retour-sur-ios-mais-pas-sur-l-app-store

  

Ensuite, VLC est disponible sur de nombreuses plate-formes, dans des stores ou non. C’est peut-être galère, mais ça assure une bonne visibilité. Et apparemment les développeurs prennent le temps de faire des portages sous Android (dans le Google Store), sous Windows (dans le Microsoft Store),… Donc c’est peut-être chiant, mais les développeurs le font. Je ne vois pas de raison de se priver du marché des iPhones.

Apple a aussi fait sauter VLC (comme ils ont fait sauter beaucoup d’applications proposant des contenus non contrôlés, comme Wikipedia de mémoire). Mais VLC est bel et bien dispo sur l’Apple Store. Il n’empêche que parmis ces retraits, il y a bien eu un retrait du fait des développeurs de VLC (cf ma source).

Et je te remercie de me remettre dans le droit chemin, si le reste de mes erreurs est du niveau de celle-ci, je n’ai pas à m’en faire. Et ce n’est pas parce que j’apprécie les produits Apple que je les défends à corps perdu, je sais garder un regard objectif, merci. Bisous.

Hardwired

Le 19/01/2016 à 10h30

Gatekeeper sert plus à renforcer le sentiment de sécurité et de confiance envers l’écosystème Apple qu’à renforcer la sécurité de la plate-forme elle-même. La confiance entre un éditeur de logiciels et un utilisateur est essentielle sinon on n’installerait jamais rien. De ce point de vue Gatekeeper est bien adapté pour un utilisateur débutant en informatique. Une fois à l’aise avec le système et le concept des ‘sources sûres’ rien n’empêche l’utilisateur de désactiver la fonction  pour installer LibreOffice ou VLC par exemple. On peut toujours utiliser un antivirus pour plus de sécurité mais aucun système n’est 100% sûr d’après notre sysadmin.

anonyme_17187f2fe30034ef77b37a104608a3ce

Le 19/01/2016 à 12h12

Toujours quelqu’un pour les défendre les yeux fermés…. bravo " />

MacGuiPro

Le 19/01/2016 à 12h16

C’est vrai que j’ai dit “c’est bien allez-y les yeux fermés”… " />

Je constate qu’Apple ne parle pas, je n’émet pas de jugement de valeur ou de défense. Mais bon, apparemment dans un monde binaire il faut critiquer Apple ou être un fanboy.

Bejarid

Le 19/01/2016 à 12h44

MacGuiPro a écrit :

Tout d’abord, quand je parle de retrait idéologique de l’App Store, c’est prouvé. Un des développeurs a demandé le retrait en 2011 de l’application VLC, pour des raisons de licence : http://www.zdnet.fr/actualites/ios-vlc-de-retour-dans-l-app-store-39814782.htm 

Tu parlais de retrait “idéologique” hors là on parle d’un retrait temporaire pour question légale (et dès que la question a obtenu sa réponse l’appli est revenu, avant de se faire ré-éjecté par Apple). Ou t’es idiot, ou t’es un fanboy, je te laisse choisir.

Gros poutoux " />

MacGuiPro

Le 19/01/2016 à 12h47

OK alors je te laisse relire la définition d’une idéologie. Bonne chance.

Winderly

Le 19/01/2016 à 12h50

Obidoub a écrit :

….what ? Ils sont sérieux ?

On dirait une solution française : un hacker annonce la présence d’une faille ? –> Mettons cette personne en prison !

gros + 1

Ça fait rêver.

YamaLandia

Le 19/01/2016 à 13h02

MacGuiPro a écrit :

OK alors je te laisse relire la définition d’une idéologie. Bonne chance.

Définition du Larousse : “Système spéculatif vague et nébuleux.” " />

MacGuiPro

Le 19/01/2016 à 13h03

Ca colle avec la GPL v2, non ? " />

Zerdligham

Le 19/01/2016 à 15h26

Grandiose. Ça me fait penser aux gens qui résolvent les exercice comme ça :

Énonce : Écrire une fonction qui inverse une chaine de caractère (exemple : toto => otot, voiture => erutiov)

Réponse :

string inverse(string str) {

switch(str) {

 case 'toto' : return 'otot';   


 case 'voiture' : return 'erutiov';

}

}

Passé 10 ans, n’importe qui devrait savoir que c’est trop gros pour passer.

Xaelias

Le 19/01/2016 à 22h32

Déconne pas, j’ai fais quelques mois d’étude aux US, un de nos TPs, bousiller quelques données sur le DD pour “supprimer” des fichiers, et les restaurer, dans la mesure du possible. Certains mecs ont rendu un truc entièrement à base de print. Le correcteur a même pas ouvert leur code source, et ils ont eu la note maximale.

Plus c’est gros, plus ça passe " />

YamaLandia

Le 20/01/2016 à 08h08

Zerdligham a écrit :

Grandiose. Ça me fait penser aux gens qui résolvent les exercice comme ça :

Énonce : Écrire une fonction qui inverse une chaine de caractère (exemple : toto => otot, voiture => erutiov)

Réponse :

string inverse(string str) {
switch(str) {    


  case 'toto' : return 'otot';    


  case 'voiture' : return 'erutiov';    


}    
}

Passé 10 ans, n’importe qui devrait savoir que c’est trop gros pour passer.

http://www.commitstrip.com/fr/2015/12/22/whats-the-difference-between-a-fix-and-a-fix/ " />

Zerdligham

Le 20/01/2016 à 08h58

Xaelias a écrit :

Plus c’est gros, plus ça passe " />

En soit, ne pas ouvrir le code ne ma choque pas plus que ça. Par contre, tester le code de l’élève uniquement sur l’exemple de l’énoncé… C’est peut-être le prof qui n’avait pas 10 ans, pour être d’une telle naïveté " />

YamaLandia a écrit :

http://www.commitstrip.com/fr/2015/12/22/whats-the-difference-between-a-fix-and-a-fix/ " />

Certes, c’est sale, mais selon la difficulté de la correction propre et la durée de vie du logiciel, c’est pas nécessairement stupide. Mieux vaut passer 10 minutes tous les deux ans que monopoliser 50 jh qui auraient pu être plus profitables ailleurs.

Xaelias

Le 20/01/2016 à 14h50

Zerdligham a écrit :

En soit, ne pas ouvrir le code ne ma choque pas plus que ça. Par contre, tester le code de l’élève uniquement sur l’exemple de l’énoncé… C’est peut-être le prof qui n’avait pas 10 ans, pour être d’une telle naïveté " />

Certes, c’est sale, mais selon la difficulté de la correction propre et la durée de vie du logiciel, c’est pas nécessairement stupide. Mieux vaut passer 10 minutes tous les deux ans que monopoliser 50 jh qui auraient pu être plus profitables ailleurs.

Moi ça me choque. Parce que pour un master en Computer Science, y’a pas que le résultat qui compte. Et le code source est plus important que le résultat finale.

PS: C’est même pas le prof qui choisit l’exemple, c’est l’étudiant qui fait une démo. T’imagines bien que c’est dur de fake ce que tu veux faire…