Jeśli sfałszowanie podpisywania kodu w komputerze Mac może się nie powieść?

Jakie irytujące lub rzeczywiste problemy mogą wystąpić, gdy podpis cyfrowy aplikacji Mac jest uszkodzony?

Aplikacje na komputerze Mac mogą być podpisane cyfrowo. Kiedy podpis jest w jakiś sposób złamany, wiem, że kilka aplikacji może to zauważyć. Ale nie wiem, w jakim szczególe będą to po prostu irytacje lub naprawdę coś zepsują:

• Zapora systemu OS X może nie być w stanie poprawnie ustawić podpisu ad hoc, powodując wielokrotne monitowanie „Czy chcesz, aby aplikacja„ [..] ”akceptowała przychodzące połączenia sieciowe?”

• Aplikacje dozwolone przez kontrolę rodzicielską mogą już nie działać?

• Dostęp do pęku kluczy może być uszkodzony?

• Niektórzy twierdzą, że aktualizacja oprogramowania Apple może się nie powieść. Jeśli to prawda, zastanawiam się, czy to rzeczywiście zależy od podpisu podpisu kodu, czy może wynikałoby z niepasującego skrótu dla całej aplikacji lub informacji z plików BOM .

Więcej podstawowych informacji poniżej.

Szczegóły podpisywania kodu można wyświetlić za pomocą:

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

... co dałoby coś takiego (ale nie ostrzegałoby przed modyfikacjami):

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

Podpis można sprawdzić za pomocą:

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

Co dałoby:

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

... lub (nawet po prostu umieszczając dodatkowy plik w folderze ./Contents/Resources):

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

... lub (może gorszy niż powyższy komunikat):

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

Podpisywanie kodu wraca do OS 9 lub wcześniejszego, ale obecna implementacja została wprowadzona w 10.5 Leopard. Ars Technica pisze :

Podpisywanie kodu wiąże tożsamość weryfikowalną kryptograficznie z kolekcją kodu i zapewnia wykrycie wszelkich modyfikacji tego kodu. Nie udziela się żadnych gwarancji dotyczących zaangażowanych stron. Na przykład, jeśli pobierzesz aplikację podpisaną przez Acme Inc., nie możesz nic na to udowodnić, z wyjątkiem tego, że pochodzi ona od tego samego podmiotu, który twierdzi, że jest Acme Inc., kiedy ostatnio pobierałeś coś z ich strony internetowej.

Ten przykład pokazuje najbardziej przydatne zastosowanie technologii z perspektywy konsumenta. Podczas dzisiejszej aktualizacji aplikacji Mac OS X [w wersji 10.4 Tiger, AvB] użytkownik jest często monitowany o ponowne sprawdzenie, czy ta aplikacja ma dostęp do pęku kluczy w celu pobrania nazw użytkowników i haseł. Wydaje się, że to dobra funkcja bezpieczeństwa, ale tak naprawdę to tylko pociąga użytkowników komputerów Mac do ślepego klikania „Zawsze zezwalaj” za każdym razem, gdy się pojawia. I tak naprawdę, co zrobi przeciętny użytkownik, uruchom plik wykonywalny za pomocą deasemblera i ręcznie sprawdź, czy kod jest bezpieczny?

Z drugiej strony podpisana aplikacja może matematycznie udowodnić, że jest to rzeczywiście nowa wersja tej samej aplikacji od tego samego dostawcy, któremu zaufałeś w przeszłości. Rezultatem jest koniec okien dialogowych z prośbą o potwierdzenie wyboru, którego bezpieczeństwa nie można zweryfikować w rozsądny sposób.

W przypadku zapory w systemie Leopard 10.5 Apple wyjaśnia :

Po dodaniu aplikacji do tej listy Mac OS X podpisuje aplikację cyfrowo (jeśli nie została jeszcze podpisana). Jeśli aplikacja zostanie później zmodyfikowana, pojawi się monit o zezwolenie na przychodzące połączenia sieciowe lub odmówienie jej. Większość aplikacji się nie modyfikuje, a jest to funkcja bezpieczeństwa, która powiadamia o zmianie.

[..]

Wszystkie aplikacje niewymienione na liście, które zostały podpisane cyfrowo przez urząd certyfikacji zaufany przez system (do celów podpisywania kodu) mogą odbierać połączenia przychodzące. Każda aplikacja Apple w systemie Leopard została podpisana przez Apple i może odbierać połączenia przychodzące. Jeśli chcesz odrzucić cyfrowo podpisaną aplikację, najpierw dodaj ją do listy, a następnie wyraźnie odrzuć.

W wersji 10.6 Snow Leopard ten ostatni jest bardziej wyraźny (i można go wyłączyć), ponieważ „Automatycznie zezwól podpisanemu oprogramowaniu na odbieranie połączeń przychodzących. Pozwala oprogramowaniu podpisanemu przez ważny urząd certyfikacji na świadczenie usług dostępnych z sieci”.

^{(W wersji 10.6 opcje 10.5.1 „Zezwalaj na wszystkie połączenia przychodzące”, „Zezwalaj tylko na podstawowe usługi” i „Ustaw dostęp dla określonych usług i aplikacji” zostały zmienione na opcję „Zablokuj wszystkie połączenia przychodzące” lub listę dozwolonych aplikacji i opcji „Automatycznie zezwalaj podpisanemu oprogramowaniu na odbieranie połączeń przychodzących” i „Włącz tryb ukrywania”. Przed aktualizacją 10.5.1 „Zezwalaj tylko podstawowym usługom” było tak naprawdę nazywane „Blokuj wszystkie połączenia przychodzące”.)}

W przypadku aplikacji (Apple), które w jakiś sposób mają złamany oryginalny podpis, ten podpis ad hoc może w jakiś sposób nie zostać utrwalony i wiadomo, że spowodował problemy z configd, mDNSResponder i racoon.

Przykład, w którym podpisywanie kodu „zepsuje” aplikację:

• Keychain Access.app nie pozwoli ci przeglądać haseł, jeśli wykryje, że zostały zmienione.

Źródło: Apple Mailing List i Jaharmi's Irreality

To, co mogę ci powiedzieć, to Candybar, aplikacja do dostosowywania ikon, z której korzysta całkiem sporo osób, psuje cyfrowy podpis przynajmniej Findera i Docka (i prawdopodobnie niektórych innych podstawowych aplikacji systemowych), ponieważ zmienia pliki zasobów, a jak dotąd nic został zgłoszony jako problem z tego powodu. Tak więc próbkowanie w środowisku naturalnym przy użyciu podstawowych komponentów systemu operacyjnego powiedziałoby - niewiele!

EDYCJA: oto wynik sprawdzenia podpisu mojego kodu w Docku w systemie 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

Nieco szczegółowe objaśnienie podpisywania kodu w systemie Snow Leopard znajduje się w recenzji Snow Leopard firmy ars technica . O ile mi wiadomo, zerwanie podpisywania kodu tak naprawdę niczego nie zepsuje. Spowoduje to jednak niezaufanie aplikacji, co oznacza konieczność weryfikacji większej liczby ich działań.

Naprawiałem moje uprawnienia do dysku innego dnia (z Narzędzia dyskowego) i otrzymałem to ostrzeżenie:

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

Więc coś się stanie. Nie wiem, jakie to ma znaczenie.

Obecna implementacja podpisywania kodu jest dość bezzębna i zapewne została wyrzucona za drzwi z korzyścią dla twórców iPhone'ów. Mam nadzieję, że w przyszłości stanie się to obowiązkowe i mam nadzieję, że do tego czasu będzie znacznie łatwiejsze i tańsze.