Apple fait face à une fuite de code. La séquence de démarrage d’iOS 9 se balade en effet dans la nature, posant d’évidentes questions de sécurité. À Cupertino, on cherche à rassurer : la protection de l’utilisateur est loin de dépendre de ce seul code.
Le code source de la séquence de boot d’iOS 9 est disponible sur GitHub, avec pour nom « iBoot ». On ne sait qui est à l’origine de cette fuite, mais précisons d’emblée qu’elle n’est pas nouvelle. Motherboard rapporte en effet que ces fichiers étaient apparus une première fois il y a plusieurs mois, sans attirer l’attention. Ils sont de retour et provoquent cette fois interrogations et inquiétudes.
Le système utilise cette séquence pour initialiser l’appareil et appeler les différentes briques. Un élément essentiel en sécurité, puisque les protections sont elles aussi chargées avec le reste. On connait l’appétit des créateurs de malwares pour cette chaine, les bootkits et rootkits en particulier en faisant leur plat favori. Plusieurs jailbreaks se sont également appuyés sur des failles du boot.
Les brèches sont justement ce qui inquiète maintenant : doit-on craindre un risque pour les utilisateurs ?
La question de la sécurité
La publication d’un code source pour une entreprise travaillant surtout via « l’obfuscation » – c’est-à-dire en cachant tout – peut représenter un vrai problème. Les mécanismes de contrôle d’erreur ne dépendent que des ingénieurs logiciels de la firme : le code n’est dans la plupart des cas pas audité, et n’est jamais inspecté par tout un chacun. Sauf accident.
Si l’on part du principe qu’un plus grand nombre d’yeux a toujours plus de chances de repérer des problèmes, la publication d’un code aussi sensible peut avoir des conséquences. La question est alors de savoir dans quelle mesure les utilisateurs courent un risque.
Actuellement, et selon les propres statistiques d’Apple, 65 % des utilisateurs d’iOS sont sur la version 11 et 28 % sur la 10. Ce qui laisse 7 % des terminaux sur des moutures plus anciennes – dont la 9 – surtout bloqués à cause d’appareils ne pouvant plus être mis à jour.
Outre l’éventuel danger pour ces clients, les systèmes plus récents sont-ils épargnés ? Il est évident qu’Apple ne réécrit pas l’ensemble de son système à chaque version. Des composants sont ajoutés, d’autres évoluent ou laissés intacts. La chaine de démarrage a très probablement évolué, ne serait-ce que pour prendre en charge APFS dans iOS 11, mais pas forcément au point d’être totalement transformée. Malheureusement, seule Apple est capable de mesurer ces changements.
Apple cherche à rassurer
La société a justement communiqué à plusieurs médias américains :
« Un vieux code source d’il y a trois ans a apparemment fuité, mais la conception de la sécurité de nos produits ne dépend pas que du secret de notre code source. Il y a de nombreuses couches de protections logicielle et matérielle présentes dans nos produits, et nous encourageons toujours nos utilisateurs à mettre à jour vers les nouvelles versions pour bénéficier des dernières protections ».
En d’autres termes, il n’y aurait rien à craindre. Pour autant, insister sur les mises à jour n’est pas anodin. D’une part parce qu’une piqure de rappel n’est pas de trop, surtout en des temps troublés où les utilisateurs remettent en cause le bien-fondé des mises à jour, « BatteryGate » en tête. D’autre part car le message peut être interprété différemment : un travail sera peut-être effectué sur la séquence de démarrage d’iOS, auquel cas il vaut mieux se tenir prêt. Parallèlement, Apple a envoyé une requête DMCA à GitHub pour supprimer le code, mais il est évident que ce dernier a déjà été téléchargé et copié de nombreuses fois.
Autre évidence : les chercheurs et pirates vont se plonger avec délectation dans ce code, dans l’espoir d’y détecter des faiblesses. Les premiers pourront prévenir Apple s’ils n’ont pas peur des éventuelles retombées juridiques (le code n’est pas libre), tandis que les seconds espèreront dénicher des vulnérabilités, idéalement toujours présentes dans iOS 10 et 11. Peut-être l'occasion pour des entreprises comme Zerodium de relancer une course aux dollars.
Commentaires (22)
iOS devient open source ! Super initiative de la part d’Apple !
… Ah, non, y’a erreur ? Tant pis.
Ils sont raisons, les trucs sensibles vaut mieux les laisser en closedsources.
Imaginez tout ce qu’on peut faire une fois qu’on dispose du bootloader des iPhone: installer un autre OS (ubuntu, ou android sur iphone 7 , l’ironie … ) , et également installer iOS sur des plateformes ARM étrangères, ainsi que fabriquer du hardware de tests afin d’essayer toutes sortes de choses, voire installer iOS ARM natif sur des machines virtuelles au lieu d’utiliser le simulateur x86 d’apple …et pourquoi pas faire du reverse engineering sur la plateforme, accéder aux zones protégées du système et probablement trouver des failles hard et soft à la pelle…
ouais alors va pondre les drivers pour installer un autre système, bon courage
Bah, c’est l’auteur de l’article qui dit ça. Il dit souvent des trucs très approximatifs en matière de logiciel et en particulier de sécurité. Sorti de Windows, il a du mal. Ici, il y a tous les poncifs habituels.
Il n’a pas l’air se savoir qu’Apple a pas mal de code en opensource comme l’a rappelé un commentateur.
Bof, il était déjà possible d’installer un dual booter android/iOS sur les iPhone 3g, ça n’a jamais rien donné.
Non, il dit qu’un code source qui n’est pas libre, quand il est publié, sera audité par beaucoup plus de monde et donc potentiellement des failles seront trouvées
Le sous-entendu est totalement contraire : si le code avait été libre depuis le début, il aurait été audité depuis la version 1 de iOS par un maximum de monde et serait meilleur
Avant d’affirmer que “OpenBSD est devenu une passoire” il faudrait peut-être avoir quelques preuves sérieuses.
Ah ça je dis pas le contraire
" /> Juste que vu ce qu’est devenu le hack sur iPhone y a peux de chance que ça arrive de nouveau :/
😂 commentaire vintage 😂
Y’a sa conférence là si tu es curieux.
https://media.ccc.de/v/34c3-8968-are_all_bsds_created_equally
Disons que le libre a l’avantage d’une plus grande réactivité et diversité des compétences car les sources étant ouvertes, une faille détectée dans l’exécution du code peut se voir comblée rapidement par une intervention externe. Il n’est pas rare que ceux qui communiquent la présence de faille proposent leur propre patch.
Là où sur du propriétaire, ils ne peuvent compter que sur la réactivité et la compétence du développement interne.
Dans les deux cas, tout repose sur une question de moyens (humains et financiers).
Mais les deux sont tout autant exposés à des défauts de sécurité… Surtout si le projet libre est géré par un gus dans son garage. Soit une grande partie de ceux-ci quant ils n’appartiennent pas à un Red Hat ou équivalent ou soutenus par un mécène.