Se a assinatura de código do Mac for adulterada, o que pode falhar?

Question

Quais aborrecimentos ou problemas reais podem ocorrer quando a assinatura digital de uma aplicação Mac é quebrada?

Aplicativos em um Mac podem ser assinados digitalmente. Quando a assinatura está de alguma forma quebrada, sei que algumas aplicações podem perceber isso. Mas eu não sei em que detalhes eles serão apenas aborrecimentos ou vão realmente quebrar as coisas:

• O firewall do OS X pode não ser capaz de definir corretamente uma assinatura ad hoc, fazendo com que um deles seja repetidamente solicitado "Deseja que o aplicativo '[..]' aceite conexões de rede de entrada?"

• Os aplicativos permitidos pelo Controle dos Pais podem não ser mais exibidos?

• O acesso a chaves pode estar quebrado?

• Alguns dizem que a atualização do software da Apple pode falhar. Se for verdade, então eu me pergunto se isso realmente depende da assinatura de assinatura de código, ou seria causado por algum hash não correspondente para o aplicativo inteiro, ou informações de Arquivos BOM .

Mais informações básicas abaixo.

Detalhes de assinatura de código podem ser exibidos usando:

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

... que produziria algo como o seguinte (mas não não avisa sobre modificações):

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

A assinatura pode ser validada usando:

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

O que produziria:

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

... ou (mesmo quando simplesmente colocar algum arquivo extra na pasta ./Contents/Resources de um aplicativo):

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

... ou (talvez pior que a mensagem acima):

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

A assinatura do código volta para o OS 9 ou anterior, mas a implementação atual foi introduzida no 10.5 Leopard . Ars Technica escreve :

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.

Para o firewall do 10.5 Leopard, a Apple explica :

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.

No 10.6 Snow Leopard, este último torna-se mais explícito (e pode ser desativado) como "Permitir automaticamente que um software assinado receba conexões de entrada. Permite que um software assinado por uma autoridade de certificação válida forneça serviços acessados a partir da rede". p>

^{(Em10.6,asopções10.5.1"Permitir todas as conexões de entrada", "Permitir somente serviços essenciais" e "Definir acesso para serviços e aplicativos específicos" foram renovadas como opção para "Bloquear todas as conexões de entrada" conexões ", ou uma lista de aplicativos permitidos e opções" Permitir automaticamente software assinado para receber conexões de entrada "e" Ativar modo furtivo ". Antes do 10.5.1 update , "Permitir apenas serviços essenciais" era na verdade chamado "Bloquear todas as conexões de entrada".)}

Para aplicativos (Apple) que, de alguma forma, têm sua assinatura original quebrada, essa assinatura ad hoc pode, de alguma forma, não ser persistida, e é conhecida para ter causado problemas para o configd, mDNSResponder e racoon.

    

Answer 1

Um exemplo de onde a assinatura de código "quebrará" um aplicativo:

• O Keychain Access.app não permitirá a exibição de senhas se detectar que ele foi adulterado.

Fonte: Lista de correspondência da Apple e Irrealidade de Jaharmi

    

Answer 2

O que posso dizer é que o Candybar, o aplicativo de personalização de ícones usado por muitas pessoas, quebra a assinatura digital de pelo menos o Finder e o Dock (e provavelmente alguns outros aplicativos do sistema principal) enquanto ele altera os arquivos de recursos Até agora, nada foi relatado como um problema por causa disso. Então, uma amostragem in-the-wild usando componentes do sistema operacional central diria - não muito!

EDIT: aqui está o resultado de verificar minha assinatura de código para o meu Dock no 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

    

Answer 3

Uma explicação um pouco detalhada da assinatura de código no Snow Leopard é fornecida em revisão do Snow Leopard da ars technica . Tanto quanto eu posso dizer, quebrar a assinatura do código não vai realmente quebrar nada. No entanto, isso fará com que os aplicativos não sejam confiáveis, o que significa ter que verificar mais suas ações.

    

Answer 4

Eu estava consertando minhas permissões de disco no outro dia (do Utilitário de Disco) e recebi este aviso:

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

Então, há algo que vai acontecer. Eu não sei o quanto isso é significativo.

    

Answer 5

A implementação atual da assinatura de código é bastante desdentada e provavelmente foi apressada para o benefício dos desenvolvedores do iPhone. Espero que ele se torne obrigatório em algum momento no futuro, e espero que se torne muito mais fácil e mais barato por esse tempo também.