Was kann fehlschlagen, wenn die Mac-Codesignatur manipuliert wird?


11

Welche Belästigungen oder tatsächlichen Probleme können auftreten, wenn die digitale Signatur einer Mac-Anwendung beschädigt ist?

Anwendungen auf einem Mac können digital signiert werden. Wenn die Signatur irgendwie kaputt ist, weiß ich, dass einige Anwendungen dies bemerken. Aber ich weiß nicht, in welchem ​​Detail dies nur Ärger sein oder Dinge wirklich kaputt machen wird:

  • Die OS X-Firewall ist möglicherweise nicht in der Lage, eine Ad-hoc-Signatur korrekt festzulegen. Dies führt dazu, dass wiederholt eine Aufforderung "Soll die Anwendung '[..]' eingehende Netzwerkverbindungen akzeptieren?" Angefordert wird.

  • Von der Kindersicherung zugelassene Anwendungen werden möglicherweise nicht mehr ausgeführt?

  • Der Schlüsselbundzugriff ist möglicherweise fehlerhaft?

  • Einige sagen, dass das Apple-Software-Update möglicherweise fehlschlägt. Wenn dies zutrifft, frage ich mich, ob dies tatsächlich von der Signatur der Codesignatur abhängt oder durch einen nicht übereinstimmenden Hash für die gesamte Anwendung oder durch Informationen aus Stücklistendateien verursacht wird .

Weitere Hintergrundinformationen finden Sie weiter unten.


Details zur Codesignatur können angezeigt werden mit:

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

... was ungefähr Folgendes ergeben würde (aber nicht vor Änderungen warnen würde ):

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

Die Signatur kann validiert werden mit:

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

Welches würde ergeben:

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

... oder (auch wenn Sie einfach eine zusätzliche Datei in den Ordner ./Contents/Resources einer Anwendung legen):

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

... oder (vielleicht schlimmer als die obige Meldung):

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

Die Codesignatur geht auf OS 9 oder früher zurück, aber die aktuelle Implementierung wurde in 10.5 Leopard eingeführt. Ars Technica schreibt :

Durch die Codesignatur wird eine kryptografisch überprüfbare Identität mit einer Codesammlung verknüpft und sichergestellt, dass Änderungen an diesem Code erkannt werden. Über die beteiligten Parteien werden keine Garantien gegeben. Wenn Sie beispielsweise eine von Acme Inc. signierte Anwendung herunterladen, können Sie nichts darüber beweisen, außer dass sie von derselben Entität stammt, die behauptet, Acme Inc. zu sein, als Sie das letzte Mal etwas von ihrer Website heruntergeladen haben.

Dieses Beispiel zeigt tatsächlich die aus Verbrauchersicht nützlichste Anwendung der Technologie. Beim heutigen Upgrade einer Mac OS X-Anwendung [in 10.4 Tiger, AvB] wird der Benutzer häufig aufgefordert, erneut zu überprüfen, ob diese Anwendung auf den Schlüsselbund zugreifen darf, um Benutzernamen und Kennwörter abzurufen. Dies scheint eine gute Sicherheitsfunktion zu sein, aber alles, was es wirklich tut, ist, Mac-Benutzer zu schulen, jedes Mal blind auf "Immer zulassen" zu klicken, wenn es angezeigt wird. Und wirklich, was wird der durchschnittliche Benutzer tun, die ausführbare Datei über einen Disassembler ausführen und manuell überprüfen, ob der Code sicher ist?

Eine signierte Anwendung kann dagegen mathematisch beweisen, dass es sich tatsächlich um eine neue Version derselben Anwendung desselben Anbieters handelt, für die Sie in der Vergangenheit Vertrauen geäußert haben. Das Ergebnis ist ein Ende der Dialogfelder, in denen Sie aufgefordert werden, eine Auswahl zu bestätigen, deren Sicherheit Sie nicht angemessen überprüfen können.

Für die Firewall in 10.5 Leopard erklärt Apple :

Wenn Sie dieser Liste eine Anwendung hinzufügen, signiert Mac OS X die Anwendung digital (sofern sie noch nicht signiert wurde). Wenn die Anwendung später geändert wird, werden Sie aufgefordert, eingehende Netzwerkverbindungen zuzulassen oder zu verweigern. Die meisten Anwendungen ändern sich nicht selbst. Dies ist eine Sicherheitsfunktion, die Sie über die Änderung informiert.

[..]

Alle Anwendungen in der Liste, die von einer vom System vertrauenswürdigen Zertifizierungsstelle digital signiert wurden (zum Zwecke der Codesignatur), dürfen eingehende Verbindungen empfangen. Jede Apple-Anwendung in Leopard wurde von Apple signiert und darf eingehende Verbindungen empfangen. Wenn Sie eine digital signierte Anwendung ablehnen möchten, sollten Sie sie zuerst zur Liste hinzufügen und dann explizit ablehnen.

In 10.6 Snow Leopard wird letzteres expliziter gemacht (und kann deaktiviert werden), da "Signierte Software automatisch eingehende Verbindungen empfangen kann. Ermöglicht Software, die von einer gültigen Zertifizierungsstelle signiert wurde, Dienste bereitzustellen, auf die über das Netzwerk zugegriffen wird".

Mac OS X 10.6-Firewall: Signierte Software kann automatisch eingehende Verbindungen empfangen

(In 10.6 wurden die 10.5.1-Optionen "Alle eingehenden Verbindungen zulassen", "Nur wichtige Dienste zulassen" und "Zugriff für bestimmte Dienste und Anwendungen festlegen" in eine Auswahl für "Alle eingehenden Verbindungen blockieren" oder eine Liste überarbeitet der zulässigen Anwendungen und Optionen "Signierter Software automatisch erlauben, eingehende Verbindungen zu empfangen" und "Stealth-Modus aktivieren ". Vor dem 10.5.1-Update wurde "Nur wesentliche Dienste zulassen" tatsächlich als "Alle eingehenden Verbindungen blockieren " bezeichnet.)

Bei (Apple-) Anwendungen, bei denen die ursprüngliche Signatur irgendwie beschädigt ist , wird diese Ad-hoc-Signatur möglicherweise nicht beibehalten, und es ist bekannt , dass sie Probleme für configd, mDNSResponder und racoon verursacht hat.


Ich denke, die Antwort von The Tentacle sagt alles (und egal wie sehr ich es auch versuche: Das Brechen von Signaturen hat mir noch nicht einmal eine Warnung für den Schlüsselbundzugriff gezeigt). Trotzdem frage ich mich, ob jemand auf Probleme gestoßen ist. Hoffe die Frage ist nicht zu lang zum Lesen ... ;-)
Arjan

Zertifikat Tag hinzugefügt
Quack Quijote

Schön: Jemand hat die Safari 4-Beta (mit den Registerkarten oben) neu signiert, um sie mit dem Schlüsselbund kompatibel zu machen. Siehe die Kommentare von "petersconsult" unter macosxhints.com/article.php?story=20090925131057394
Arjan,

Antworten:


1

Ein Beispiel dafür, wo die Codesignatur eine Anwendung "kaputt macht":

  • Mit Keychain Access.app können Sie keine Kennwörter anzeigen, wenn festgestellt wird, dass sie manipuliert wurden.

Quelle: Apple Mailing List und Jaharmis Irreality


Nun, da Sie es erwähnen, ist dies natürlich die Anwendung, die ich für meine ersten Tests hätte verwenden sollen ! :-)
Arjan

3

Was ich Ihnen sagen kann, ist Candybar, die App zur Anpassung von Symbolen, die von vielen Leuten verwendet wird. Sie bricht die digitale Signatur von mindestens Finder und Dock (und wahrscheinlich einigen anderen Kernsystemanwendungen), da sie Ressourcendateien ändert, und bisher nichts wurde aus diesem Grund als Problem gemeldet. Eine In-the-Wild-Stichprobe mit Kernkomponenten des Betriebssystems würde also sagen - nicht viel!

BEARBEITEN: Hier ist das Ergebnis der Überprüfung meiner Codesignatur für mein 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

Aha, ich werde das ein bisschen untersuchen! Einige manuell geänderte Symbole haben die Codesignatur für einige andere Anwendungen nicht unterbrochen. Die Macher selbst haben 2008 geschrieben: Wenn Sie Ihre Anwendungssymbole von Hand ändern möchten, können Sie dies gerne tun! Als Warnung: Wenn Apple die integrierte Codesignatur in einem zukünftigen Mac OS X Minor-Update aktiviert, werden Ihre Anwendungen einfach nicht mehr gestartet. Dies versuchen wir sicher zu vermeiden, indem wir diese Funktion deaktivieren, bis wir von Apple ein Gefühl für ihre Pläne bekommen. - macupdate.com/info.php/id/8948?rord=mod
Arjan

Ich habe das Ergebnis hinzugefügt, nachdem ich mein Dock in Snow Leopard von Hand geändert habe ...
The Tentacle

Ah, dumm. Bisher habe ich nur das Programmsymbol getestet (indem ich ein neues Symbol über Finders Get Info eingefügt habe), kein Symbol, wie es vom Programm selbst verwendet wird. Ok, die Codesignatur ist sicher kaputt. Der Kommentar des Candybar-Entwicklers ist für mich immer noch etwas beängstigend, aber Apple würde viele Leute in Schwierigkeiten bringen, wenn sie plötzlich die aktuellen (Nicht-) Effekte ändern.
Arjan

Nun, der Test besteht darin, Ressourcen in einer netzwerkfähigen App zu ändern und zu prüfen, ob das Unterbrechen der Signatur den automatischen Passthrough von der Anwendungsfirewall stoppt ...
The Tentacle

(Hmmm, der CandyBar-Entwickler hat diesen Kommentar vom 10. Januar 2008 aus MacUpdate entfernt. Der Google-Cache zeigt ihn immer noch an, aber anscheinend gibt es eine neue Version für OS X 6.1, sodass entweder das Problem gelöst wurde oder CandyBar schlafende Hunde liegen lassen möchte. Nehmen wir an, es gibt dann keine Probleme!)
Arjan

0

Eine etwas ausführliche Erklärung der Codesignatur in Snow Leopard finden Sie in der Snow Leopard-Rezension von ars technica . Soweit ich das beurteilen kann, wird das Brechen der Codesignatur nichts wirklich kaputt machen. Es wird jedoch dazu führen, dass Apps nicht mehr vertrauenswürdig sind, was bedeutet, dass mehr ihrer Aktionen überprüft werden müssen.


Es ist eigentlich die 10.5 Leopard Bewertung. Ein schönes Zitat aus dem 10.6-Test: "Und vergessen wir nicht, dass die" Mac OS X "-Technologien, die wir später erfuhren, für das iPhone entwickelt wurden und zufällig zuerst für den Mac angekündigt wurden (weil das iPhone noch ein Geheimnis war). wie Core Animation und Code Signing. " - arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars
Arjan

0

Ich habe neulich meine Festplattenberechtigungen repariert (vom Festplatten-Dienstprogramm) und die folgende Warnung erhalten:

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

Es wird also etwas passieren. Ich weiß nicht, wie wichtig das ist.


Interessant, zumal Apple dies in "Mac OS X 10.5: Meldungen zum Reparieren von Datenträgerberechtigungen, die Sie ignorieren können" auf support.apple.com/kb/TS1448 auflistet. Kein Wort von Apple darüber, wie dies geändert wurde und warum dies nicht der Fall ist. egal aber ... Zeigt codesign --verifytatsächlich eine kaputte Signatur?
Arjan

0

Die derzeitige Implementierung der Codesignatur ist ziemlich zahnlos und wurde wahrscheinlich zum Nutzen der iPhone-Entwickler aus der Tür gehetzt. Hoffentlich wird es irgendwann in der Zukunft obligatorisch, und hoffentlich wird es bis dahin auch viel einfacher und billiger.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.