当 Mac 应用程序的数字签名被破坏时,可能会出现哪些烦恼或实际问题?
Mac 上的应用程序可以进行数字签名。当签名以某种方式被破坏时,我知道一些应用程序可能会注意到这一点。但我不知道这些细节会是烦恼还是真的会破坏一切:
OS X 防火墙可能无法正确设置临时签名,导致反复提示“您是否希望应用程序‘[..]’接受传入的网络连接?”
家长控制允许的应用程序可能不再运行?
钥匙串访问可能坏了?
有人说 Apple 软件更新可能会失败。如果是真的,那么我想知道这是否确实取决于代码签名,或者是由整个应用程序的某些不匹配的哈希值引起的,或者来自BOM 文件。
下面有更多背景信息。
可以使用以下方式显示代码签名详细信息:
codesign --display -vv /Applications/iTunes.app/
...这将产生类似以下内容的结果(但不是警告修改):
[..]
CDHash=86828a2d631dbfd417600c458b740cdcd12b13e7
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
[..]
可以使用以下方法验证签名:
codesign --verify -vv /Applications/iTunes.app/
其结果为:
/Applications/iTunes.app/: valid on disk
/Applications/iTunes.app/: satisfies its Designated Requirement
...或者(即使只是将一些额外的文件放入应用程序的 ./Contents/Resources 文件夹中):
/Applications/iTunes.app/: a sealed resource is missing or invalid
...或者(可能比上面的消息更糟糕):
/Applications/iTunes.app/: code or signature modified
代码签名可以追溯到 OS 9 或更早版本,但当前的实现被引入10.5 Leopard。Ars Technica写道:
代码签名将一个加密可验证的身份与一组代码联系起来,并确保检测到对该代码的任何修改。对相关方没有任何保证。例如,如果您下载了由 Acme Inc. 签名的应用程序,您无法证明任何事情,只能证明它来自上次您从其网站下载内容时声称是 Acme Inc. 的同一实体。
这个例子实际上从消费者的角度突出了这项技术最有用的应用。如今,在升级 Mac OS X 应用程序(10.4 Tiger,AvB 版)时,用户通常会被提示重新验证该应用程序是否被允许访问 Keychain 以检索用户名和密码。这似乎是一个很好的安全功能,但它实际上只是训练 Mac 用户在每次出现“始终允许”时盲目地点击它。而实际上,普通用户会怎么做呢?通过反汇编程序运行可执行文件并手动验证代码是否安全?
另一方面,已签名的应用程序可以通过数学方法证明它确实是来自您过去信任的同一供应商的同一应用程序的新版本。结果是不再需要对话框要求您确认您无法合理验证其安全性的选择。
对于 10.5 Leopard 中的防火墙,Apple解释:
当您将应用程序添加到此列表时,Mac OS X 会对该应用程序进行数字签名(如果尚未签名)。如果该应用程序后来被修改,系统将提示您允许或拒绝传入网络连接。大多数应用程序不会自行修改,这是一项通知您更改的安全功能。
[...]
所有不在列表中的应用程序,如果已由系统信任的证书颁发机构进行数字签名(用于代码签名),则允许接收传入连接。Leopard 中的每个 Apple 应用程序都已由 Apple 签名,并允许接收传入连接。如果您希望拒绝数字签名的应用程序,则应首先将其添加到列表中,然后明确拒绝它。
在 10.6 Snow Leopard 中,后者变得更加明确(并且可以禁用),即“自动允许签名的软件接收传入连接。允许由有效证书颁发机构签名的软件提供从网络访问的服务”。
(在 10.6 中,10.5.1 中的“允许所有传入连接”、“仅允许基本服务”和“设置特定服务和应用程序的访问权限”选项已修改为“阻止所有传入连接”或允许的应用程序列表以及“自动允许签名的软件接收传入连接”和“启用隐身模式”选项。在10.5.1 更新,“仅允许基本服务”实际上被称为“阻止所有传入连接”。)
对于(Apple)应用程序,如果其原始签名因某种原因被破坏,则此临时签名可能无法保留,并且已知惹麻烦适用于 configd、mDNSResponder 和 racoon。
答案1
答案2
我可以告诉你的是,Candybar 是一款图标自定义应用,被很多人使用,它在更改资源文件时至少破坏了 Finder 和 Dock(可能还有一些其他核心系统应用)的数字签名,但到目前为止,还没有报告任何因此而导致的问题。因此,使用核心操作系统组件进行的野外采样表明 - 问题不大!
编辑:这是检查我的 Snow Leopard 中的 Dock 代码签名的结果:
⚛$ codesign --verify --verbose /System/Library/CoreServices/Dock.app/
/System/Library/CoreServices/Dock.app/: a sealed resource is missing or invalid
/System/Library/CoreServices/Dock.app/Contents/Resources/expose-window-selection-big.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/expose-window-selection-small.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/finder.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/frontline.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/indicator_large.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/indicator_medium.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/indicator_small.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/scurve-l.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/scurve-m.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/scurve-sm.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/scurve-xl.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/trashempty.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/trashfull.png: resource modified
答案3
Snow Leopard 中的代码签名的详细解释ars technica 的 Snow Leopard 评论据我所知,破坏代码签名实际上不会破坏任何东西。但是,它会导致应用程序变得不受信任,这意味着必须验证更多操作。
答案4
目前的代码签名实施效果很差,可能是为了 iPhone 开发人员的利益而匆忙推出的。希望将来某个时候它能成为强制性的,也希望到那时它能变得更容易、更便宜。