If Mac code signing is tampered with, what might fail?

What annoyances or real problems may occur when the digital signature of a Mac application is broken?

Applications on a Mac can be digitally signed. When the signature is somehow broken, I know a few applications may notice that. But I don't know in what detail these will be just annoyances or will really break things:

• The OS X firewall may not be able to correctly set an ad hoc signature, causing one to be repeatedly prompted "Do you want the application '[..]' to accept incoming network connections?"

• Applications allowed by Parental Controls might no longer run?

• Keychain Access might be broken?

• Some say Apple software update might fail. If true, then I wonder if this indeed depends on the Code Signing signature, or would be caused by some non-matching hash for the whole application, or information from BOM files.

More background information below.

Code signing details can be shown using:

codesign --display -vv /Applications/iTunes.app/

...which would yield something like the following (but would not warn about modifications):

[..]
CDHash=86828a2d631dbfd417600c458b740cdcd12b13e7
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
[..]

The signature can be validated using:

codesign --verify -vv /Applications/iTunes.app/

Which would yield:

/Applications/iTunes.app/: valid on disk
/Applications/iTunes.app/: satisfies its Designated Requirement

...or (even when simply putting some extra file in an application's ./Contents/Resources folder):

/Applications/iTunes.app/: a sealed resource is missing or invalid

...or (maybe worse than the above message):

/Applications/iTunes.app/: code or signature modified

Code signing goes back to OS 9 or earlier, but the current implementation was introduced in 10.5 Leopard. Ars Technica writes:

Code signing ties a cryptographically verifiable identity to a collection of code and ensures that any modification to that code is detected. No guarantees are made about the parties involved. For example, if you download an application signed by Acme Inc., you can prove nothing about it except that it came from the same entity claiming to be Acme Inc. the last time you downloaded something from their web site.

This example actually highlights the most useful application of the technology from a consumer's perspective. When upgrading a Mac OS X application today [in 10.4 Tiger, AvB], the user is often prompted to re-verify that this application is allowed to access the Keychain to retrieve usernames and passwords. This seems like a good security feature, but all it really does is train Mac users to blindly click "Always Allow" each time it appears. And really, what is the average user going to do, run the executable through a disassembler and manually verify that the code is safe?

A signed application, on the other hand, can mathematically prove that it is indeed a new version of the same application from the same vendor that you expressed trust for in the past. The result is an end to dialog boxes asking you to confirm a choice whose safety you have no reasonable way to verify.

For the firewall in 10.5 Leopard, Apple explains:

When you add an application to this list, Mac OS X digitally signs the application (if it has not been signed already). If the application is later modified, you will be prompted to allow or deny incoming network connections to it. Most applications do not modify themselves, and this is a safety feature that notifies you of the change.

[..]

All applications not in the list that have been digitally signed by a Certificate Authority trusted by the system (for the purpose of code signing) are allowed to receive incoming connections. Every Apple application in Leopard has been signed by Apple and is allowed to receive incoming connections. If you wish to deny a digitally signed application you should first add it to the list and then explicitly deny it.

In 10.6 Snow Leopard, the latter is made more explicit (and can be disabled) as "Automatically allow signed software to receive incoming connections. Allows software signed by a valid certificate authority to provide services accessed from the network".

^{(In 10.6, the 10.5.1 options "Allow all incoming connections", "Allow only essential services" and "Set access for specific services and applications" have been revamped into a choice for either "Block all incoming connections", or a list of allowed applications and options "Automatically allow signed software to receive incoming connections" and "Enable stealth mode". Prior to the 10.5.1 update, "Allow only essential services" was actually called "Block all incoming connections".)}

For (Apple) applications that somehow have their original signature broken, this ad hoc signature might somehow not be persisted, and is known to have caused trouble for configd, mDNSResponder and racoon.

Solution 1:

An example of where code signing will 'break' an application:

• Keychain Access.app will not allow you to view passwords if it detects it has been tampered with.

Source: Apple Mailing List and Jaharmi's Irreality

Solution 2:

What I can tell you is Candybar, the icon customisation app used by quite a lot of people, breaks the digital signature of at least Finder and Dock (and probably some other core system applications) as it changes resource files, and yet so far nothing has been reported as a problem because of this. So an in-the-wild sampling using core OS components would say - not much!

EDIT: here is the result of checking my code signature for my Dock in Snow Leopard:

⚛$ 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