santa icon indicating copy to clipboard operation
santa copied to clipboard

PrinterProxy crashing on macOS Ventura

Open meta-github opened this issue 1 year ago • 9 comments

White testing beta releases of macOS Ventura, we have observed, that PrinterProxy did not start:

Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid))

We have observed that PrinterProxy should have an ad-hoc signature, but somehow Santa replaces the binary and the resulting binary is unable to start on macOS Ventura.

Steps to reproduce on a system with macOS Ventura and Santa enabled:

  • remove app for a printer in ~/Library/Printers
  • start a print dialog using the same printer (app will be recreated)
  • the app for your printer will not open and it will crash if you start it manually
  • verify the code signature of the PrinterProxy: on macOS Ventura it should be adhoc signed, but it is not

The same works flawlessly and without a crash after Santa is disabled.

Santa version is 2022.7.

meta-github avatar Aug 21 '22 12:08 meta-github

This could be caused by the EnableBadSignatureProtection option in Santa. Could you run santactl fileinfo on the newly created app, and post the result here ?

np5 avatar Aug 23 '22 17:08 np5

# santactl fileinfo /Users/j905960/Library/Printers/PullPrint.app/Contents/MacOS/PrinterProxy
Path                   : /Users/j905960/Library/Printers/PullPrint.app/Contents/MacOS/PrinterProxy
SHA-256                : a385ef727cf74a53b8a14fa6982ba135618989f3e96be261cdc26b1f2e0a9705
SHA-1                  : 85ff3d2afb830d4eea3f79da5fa16ebfcdd68ea8
Bundle Name            : PrinterProxy
Bundle Version         : 605
Bundle Version Str     : 18
Type                   : Executable (arm64, x86_64)
Code-signed            : Yes
Rule                   : Allowed (Certificate)
Signing Chain:
    1. SHA-256             : d84db96af8c2e60ac4c851a21ec460f6f84e0235beb17d24a78712b9b021ed57
       SHA-1               : efdbc9139dd98dbae5a9c7165a096511b15eaef9
       Common Name         : Software Signing
       Organization        : Apple Inc.
       Organizational Unit : Apple Software
       Valid From          : 2020/10/29 19:32:38 +0100
       Valid Until         : 2026/10/24 19:39:41 +0200

    2. SHA-256             : 5bdab1288fc16892fef50c658db54f1e2e19cf8f71cc55f77de2b95e051e2562
       SHA-1               : 1d010078a61f4fa4694aff4db1ac266ce1b45946
       Common Name         : Apple Code Signing Certification Authority
       Organization        : Apple Inc.
       Organizational Unit : Apple Certification Authority
       Valid From          : 2011/10/24 19:39:41 +0200
       Valid Until         : 2026/10/24 19:39:41 +0200

    3. SHA-256             : b0b1730ecbc7ff4505142c49f1295e6eda6bcaed7e2c68c5be91b5a11001f024
       SHA-1               : 611e5b662c593a08ff58d14ae22452d198df6c60
       Common Name         : Apple Root CA
       Organization        : Apple Inc.
       Organizational Unit : Apple Certification Authority
       Valid From          : 2006/04/25 23:40:36 +0200
       Valid Until         : 2035/02/09 22:40:36 +0100

meta-github avatar Aug 23 '22 18:08 meta-github

EnableBadSignatureProtection is not set in our config profile for santa.

meta-github avatar Aug 23 '22 18:08 meta-github

Sorry, I thought is sounded familiar. I have a Printer proxy that santa blocks on my computer (12.5.1), but the signature is reported as Code-signed: Yes, but can't validate as Info.plist is missing.

np5 avatar Aug 23 '22 18:08 np5

In fact, santa is not blocking our PrinterProxy, it is macOS Ventura that does not like the broken signature of the app and it prevents the app from starting. The signature gets broken by santa which replaces an adhoc signed binary by something else. That's the analysis of Apple:

2022-08-23 19:59:31.503835+0200 0x214bfa Default 0x0 400 0 com.google.santa.daemon: I com.google.santa.daemon: PrinterProxy workaround applied to: /Users/j905960/Library/Printers/PullPrint.app/Contents/MacOS/PrinterProxy

meta-github avatar Aug 23 '22 19:08 meta-github

Santa replaces the binary inside the printer app with the original from /System/Library/PrivateFrameworks/PrintingPrivate.framework because the adhoc signed one has no significant changes and due to not being signed is not trusted. This workaround is necessary so you don't have to allowlist every printer added to every machine. It looks like Ventura is not happy with this workaround and we'll need to find a replacement workaround

russellhancox avatar Aug 23 '22 20:08 russellhancox

Another thing I learned today! While trying to understand what was going on, I also noticed that the first time I manually launch the Proxy in the terminal after configuring a printer on 12.5.1 (when it is still the ad-hoc signed version that will be replaced by Santa), it crashes with a code signature error. The second time, it works.

np5 avatar Aug 23 '22 20:08 np5

I do not know it it helps, but I have just tested in a ventura VM, and same thing: the first manual execution after the printer is created, when the binary on disk is still the ad-hoc signed one, fails. The second one is successful. The PrinterProxy binary copied from the private framework seems to work.

np5 avatar Aug 23 '22 20:08 np5

The behavior np5 describes above is the expected behavior but that is not what I'm seeing on Ventura β1, the OS is killing the copied binary because of a Launch Constraint violation. We'll need to look at whether we can work around this as the adhoc signed binary that the OS normally produces will be blocked by hosts in Lockdown mode.

russellhancox avatar Aug 24 '22 14:08 russellhancox

Tested with beta 11, we no longer see PrinterProxy crashing on Ventura, even after Santa (testet with v2022.8) applied the existing workaround. So, it seems that Apple has changed something in macOS Ventura which prevents the bug.

meta-github avatar Oct 14 '22 10:10 meta-github

Thanks for the update!

russellhancox avatar Oct 14 '22 13:10 russellhancox