Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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".

Mac OS X 10.6 Firewall: Automatically allow signed software to receive incoming connections

(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.

share|improve this question
    
I guess The Tentacle's answer says it all (and no matter how hard I try: breaking signatures has not even shown me a warning for Keychain Access yet). Still, I wonder if anyone has encountered problems. Hope the question is not too long to read... ;-) –  Arjan Oct 4 '09 at 13:58
    
added certificate tag –  quack quixote Oct 4 '09 at 14:46
    
Nice: someone re-signed the Safari 4 beta (with its tabs on top) to make it compatible with Keychain: see the comments by "petersconsult" at macosxhints.com/article.php?story=20090925131057394 –  Arjan Nov 12 '09 at 20:18

5 Answers 5

up vote 1 down vote accepted

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

share|improve this answer
    
Of course, now that you mention it, this is the application I should have used for my very first tests! :-) –  Arjan Nov 18 '09 at 18:34

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
share|improve this answer
    
Aha, I'll investigate that a bit! Some manual changed icons did not break code signing for some other applications. The makers themselves wrote in 2008: As for changing your application icons by hand, you are more than welcome to do so! As a warning: if Apple enables the built-in code signing in a future Mac OS X minor update, your applications will simply no longer launch. This is what we're trying to safely avoid by disabling that feature until we get a sense from Apple of their plans. -- macupdate.com/info.php/id/8948?rord=mod –  Arjan Sep 29 '09 at 15:58
    
I've added the result after hand-modifying my dock in Snow Leopard... –  The Tentacle Sep 29 '09 at 23:37
    
Ah, stupid. So far the only thing I tested was the program icon (by pasting a new icon through Finder's Get Info), not any icon as used by the program itself. Ok, code signing broken for sure. The Candybar developer's comment is still a bit scary to me, but Apple would get a lot of people into trouble when suddenly changing the current (non-)effects. –  Arjan Sep 30 '09 at 10:20
    
Well the test is to modify resources in a network-facing app and see if breaking the signing stops the automatic passthrough from the application firewall... –  The Tentacle Sep 30 '09 at 12:30
    
(Hmmm, the CandyBar developer has removed that January 10th 2008 comment from MacUpdate. Google cache still shows it, but apparently there's a new version for OS X 6.1 so either the problem has been solved, or CandyBar wants to let sleeping dogs lie...? Let's assume there's no issues then!) –  Arjan Oct 7 '09 at 4:59

A somewhat detailed explanation of code signing in Snow Leopard is provided in ars technica's Snow Leopard review. As far as I can tell, breaking code signing will not really break anything. However, it will cause apps to become untrusted which means having to verify more of their actions.

share|improve this answer
    
It's actually the 10.5 Leopard review. One nice quote from the 10.6 review though: "And let's not forget the "Mac OS X" technologies that we later learned were developed for the iPhone and just happened to be announced for the Mac first (because the iPhone was still a secret), like Core Animation and code signing." -- arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars –  Arjan Oct 5 '09 at 16:32

I was repairing my Disk Permissions the other day (from Disk Utility), and got this warning:

Warning: SUID file "System/.../ARDAgent" has been modified and will not be repaired.

So there's something that will happen. I don't know how significant that is.

share|improve this answer
    
Interesting, especially as Apple lists this in "Mac OS X 10.5: Disk Utility's Repair Disk Permissions messages that you can safely ignore" at support.apple.com/kb/TS1448 No word from Apple on how this was changed and why it doesn't matter though... Does codesign --verify indeed show a broken signature? –  Arjan Oct 10 '09 at 8:23

The current implementation of code signing is pretty toothless and was probably rushed out the door for the benefit of the iPhone developers. Hopefully it will become mandatory at some point in the future, and hopefully it will become a lot easier and cheaper by that time as well.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.