Les développeurs ne se ruent pas sur les Mac Apple Silicon, Réactions à la publication du 10/11/2020

[Lionel]

Sauf grosse surprise, Apple lancera ce soir (vous pourrez suivre le direct sur notre page Keynote) ses premiers Mac embarquant une puce ARM. Dans la pratique, ces Mac pourront bénéficier des applications x86 (en émulation), mais aussi des applications iOS qui tourneront nativement dessus même si les développeurs sont appelés à en proposer des versions spécifiques.
Les développeurs ont aussi le droit de s'opposer à ce que leur application iOS soit proposée sur ces Mac.
9to5Mac a fait un tour de tout cela pour connaître les intentions des développeurs.

Pour le moment, pas de YouTube, ni l'essentiel des applications Google. Il en va de même pour Facebook ainsi qu'Instagram, WhatsApp et Messenger. Il en sera de même pour Snapchat, Amazon Prime Video et Disney+.

Certes, les choses peuvent bouger rapidement mais il semble clair que les autre GAFA ne sont pas pressés de mettre la main dans l'engrenage, voulant retarder ce qui est à nos yeux inéluctable : qu'Apple impose de passer par le Mac App Store pour installer des logiciels sur les machines ARM.

Lien vers le billet original

[iAPX]

Un point important à savoir, et qui me terrifie en terme de sécurité, c'est que par défaut (opt-out) toutes les applications iOS et iPadOS deviendront accessibles sous macOS sur les Mac ARM.
Ça change considérablement le modèle de sécurité avec un utilisateur qui peut être administrateur du système, mais aussi malgré les protections mises en place dans macOS si on a encore la possibilité de démarrer en mode Target.

Jusqu'à présent, pour attaquer des Apps iOS de l'intérieur il fallait faire des pieds et des mains, incluant les problèmes induit par le Certificate pre-pinning et le DoH (DNS-over-https) interdisant l'analyse de leurs échanges sans jailbreak et modifications de celles-ci sur l'appareil.
Il fallait se rabattre sur la version Android (le PKG zippé), où là c'est open-bar mais où des détails d'implémentation et d'usage d'API peuvent différer de mon expérience, par exemple via l'emploi de libraries/frameworks externes différents.

D'un coup, tout ceux qui le voudront pourront très facilement accéder à leurs entrailles, et je m'attend à des -mauvaises- surprises.
J'ai conseillé de ne pas déployer les Apps iOS sur macOS dans un premier temps, quitte à ouvrir l'option plus tard après analyse.

[X_Gebo]

Un point important à savoir, et qui me terrifie en terme de sécurité, c'est que par défaut (opt-out) toutes les applications iOS et iPadOS deviendront accessibles sous macOS sur les Mac ARM.
Ça change considérablement le modèle de sécurité avec un utilisateur qui peut être administrateur du système, mais aussi malgré les protections mises en place dans macOS si on a encore la possibilité de démarrer en mode Target.

Jusqu'à présent, pour attaquer des Apps iOS de l'intérieur il fallait faire des pieds et des mains, incluant les problèmes induit par le Certificate pre-pinning et le DoH (DNS-over-https) interdisant l'analyse de leurs échanges sans jailbreak et modifications de celles-ci sur l'appareil.
Il fallait se rabattre sur la version Android (le PKG zippé), où là c'est open-bar mais où des détails d'implémentation et d'usage d'API peuvent différer de mon expérience, par exemple via l'emploi de libraries/frameworks externes différents.

D'un coup, tout ceux qui le voudront pourront très facilement accéder à leurs entrailles, et je m'attend à des -mauvaises- surprises.
J'ai conseillé de ne pas déployer les Apps iOS sur macOS dans un premier temps, quitte à ouvrir l'option plus tard après analyse.

Question de béotien qui cherche à savoir, à comprendre : pourquoi les applications iOS seraient-elles plus porteuses de soucis de sécurité que les applications initialement développées pour Mac OS ?

[iAPX]

Un point important à savoir, et qui me terrifie en terme de sécurité, c'est que par défaut (opt-out) toutes les applications iOS et iPadOS deviendront accessibles sous macOS sur les Mac ARM.
Ça change considérablement le modèle de sécurité avec un utilisateur qui peut être administrateur du système, mais aussi malgré les protections mises en place dans macOS si on a encore la possibilité de démarrer en mode Target.

Jusqu'à présent, pour attaquer des Apps iOS de l'intérieur il fallait faire des pieds et des mains, incluant les problèmes induit par le Certificate pre-pinning et le DoH (DNS-over-https) interdisant l'analyse de leurs échanges sans jailbreak et modifications de celles-ci sur l'appareil.
Il fallait se rabattre sur la version Android (le PKG zippé), où là c'est open-bar mais où des détails d'implémentation et d'usage d'API peuvent différer de mon expérience, par exemple via l'emploi de libraries/frameworks externes différents.

D'un coup, tout ceux qui le voudront pourront très facilement accéder à leurs entrailles, et je m'attend à des -mauvaises- surprises.
J'ai conseillé de ne pas déployer les Apps iOS sur macOS dans un premier temps, quitte à ouvrir l'option plus tard après analyse.

Question de béotien qui cherche à savoir, à comprendre : pourquoi les applications iOS seraient-elles plus porteuses de soucis de sécurité que les applications initialement développées pour Mac OS ?

C'est une très bonne question

Sous iOS hors jailbreak et travail quand-même compliqué, ces applications vivent dans un petit monde fermé qui les protègent de l'extérieur, interdisant l'analyse de leur traffic (surtout lorsque utilisant le Certificate pre-pinning) voir même de savoir quels services elles contactent (DoH: DNS over https), avec un accès difficile au code compilé, aux données stockées par l'application, incluant les informations personnelles qui peuvent être utilisées localement mais aussi transmises à distance.
Sous macOS c'est bien plus facile, surtout avec le mode Target des mac permettant l'accès (depuis Linux souvent) au code d'une application ainsi qu'à tout ce qu'elle stocke pour la dépiauter et la vérifier de la même façon qu'on peut le faire avec un APK Android.

Il est aussi possible de la modifier, et de la resigner (quand nécessaire) pour exécuter la version modifiée ou la diffuser à un petit groupe.

Fondamentalement ça change tout le travail d'analyse de sécurité des App Mobiles, mais -aussi- offre des options pour les hacker, déverrouiller des fonctionnalités, trouver des failles dans ces Apps mais aussi dans les API utilisées.
Il va -aussi- être théoriquement possible de diffuser des "patchs" permettant de changer le comportement d'App iOS existantes lorsque exécutées sous macOS.

En gros ça ouvre une boîte de pandore sur des App iOS dont la sécurité générale est extrêmement médiocre pour ne pas dire inexistante (statistiquement).