Quels ennuis ou problèmes réels peuvent survenir lorsque la signature numérique d'une application Mac est rompue?
Les applications sur un Mac peuvent être signées numériquement. Lorsque la signature est en quelque sorte cassée, je sais que quelques applications peuvent le remarquer. Mais je ne sais pas dans quel détail ce ne seront que des ennuis ou ça cassera vraiment les choses:
Le pare-feu OS X n'est peut-être pas en mesure de définir correctement une signature ad hoc, ce qui provoque l'invitation répétée de "Voulez-vous que l'application" [..] "accepte les connexions réseau entrantes?"
Les applications autorisées par le contrôle parental pourraient ne plus fonctionner?
L'accès au trousseau est peut-être interrompu?
Certains disent que la mise à jour du logiciel Apple pourrait échouer. Si cela est vrai, je me demande si cela dépend en effet de la signature de signature de code, ou s'il serait provoqué par un hachage non correspondant à l'ensemble de l'application, ou des informations provenant des fichiers de nomenclature .
Plus d'informations générales ci-dessous.
Les détails de signature du code peuvent être affichés en utilisant:
codesign --display -vv /Applications/iTunes.app/
... qui donnerait quelque chose comme ce qui suit (mais ne mettrait pas en garde contre les modifications):
[..]
CDHash=86828a2d631dbfd417600c458b740cdcd12b13e7
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
[..]
La signature peut être validée en utilisant:
codesign --verify -vv /Applications/iTunes.app/
Ce qui donnerait:
/Applications/iTunes.app/: valid on disk
/Applications/iTunes.app/: satisfies its Designated Requirement
... ou (même en plaçant simplement un fichier supplémentaire dans le dossier ./Contents/Resources d'une application):
/Applications/iTunes.app/: a sealed resource is missing or invalid
... ou (peut-être pire que le message ci-dessus):
/Applications/iTunes.app/: code or signature modified
La signature de code remonte à OS 9 ou antérieur, mais l'implémentation actuelle a été introduite dans 10.5 Leopard. Ars Technica écrit :
La signature de code lie une identité cryptographiquement vérifiable à une collection de code et garantit que toute modification de ce code est détectée. Aucune garantie n'est donnée sur les parties impliquées. Par exemple, si vous téléchargez une application signée par Acme Inc., vous ne pouvez rien prouver, sauf qu'elle provenait de la même entité prétendant être Acme Inc. la dernière fois que vous avez téléchargé quelque chose à partir de leur site Web.
Cet exemple met en évidence l'application la plus utile de la technologie du point de vue du consommateur. Lors de la mise à niveau d'une application Mac OS X aujourd'hui [dans 10.4 Tiger, AvB], l'utilisateur est souvent invité à revérifier que cette application est autorisée à accéder au trousseau pour récupérer les noms d'utilisateur et les mots de passe. Cela semble être une bonne fonctionnalité de sécurité, mais tout ce qu'il fait, c'est former les utilisateurs Mac à cliquer aveuglément sur "Toujours autoriser" chaque fois qu'il apparaît. Et vraiment, que va faire l'utilisateur moyen, exécuter l'exécutable via un désassembleur et vérifier manuellement que le code est sûr?
Une application signée, d'autre part, peut prouver mathématiquement qu'il s'agit bien d'une nouvelle version de la même application du même fournisseur pour laquelle vous avez fait confiance dans le passé. Le résultat est la fin des boîtes de dialogue vous demandant de confirmer un choix dont vous n'avez aucun moyen raisonnable de vérifier la sécurité.
Pour le pare-feu dans 10.5 Leopard, Apple explique :
Lorsque vous ajoutez une application à cette liste, Mac OS X signe numériquement l'application (si elle n'a pas déjà été signée). Si l'application est modifiée ultérieurement, vous serez invité à autoriser ou à refuser les connexions réseau entrantes. La plupart des applications ne se modifient pas elles-mêmes, et c'est une fonction de sécurité qui vous informe du changement.
[..]
Toutes les applications ne figurant pas dans la liste qui ont été signées numériquement par une autorité de certification approuvée par le système (à des fins de signature de code) sont autorisées à recevoir les connexions entrantes. Chaque application Apple dans Leopard a été signée par Apple et est autorisée à recevoir les connexions entrantes. Si vous souhaitez refuser une demande signée numériquement, vous devez d'abord l'ajouter à la liste, puis la refuser explicitement.
Dans 10.6 Snow Leopard, ce dernier est rendu plus explicite (et peut être désactivé) car "Autoriser automatiquement les logiciels signés à recevoir les connexions entrantes. Permet aux logiciels signés par une autorité de certification valide de fournir des services accessibles à partir du réseau".
(Dans 10.6, les options 10.5.1 «Autoriser toutes les connexions entrantes», «Autoriser uniquement les services essentiels» et «Définir l'accès pour des services et applications spécifiques» ont été remodelées en un choix pour «Bloquer toutes les connexions entrantes» ou une liste des applications et options autorisées "Autoriser automatiquement les logiciels signés à recevoir les connexions entrantes" et "Activer le mode furtif". Avant la mise à jour 10.5.1 , "Autoriser uniquement les services essentiels" était en fait appelé "Bloquer toutes les connexions entrantes".)
Pour les applications (Apple) dont la signature d'origine est en quelque sorte cassée, cette signature ad hoc peut ne pas être persistante et est connue pour avoir causé des problèmes pour configd, mDNSResponder et racoon.