trustd on macOS

[0xdd]

Hi all! Something pretty odd happened during yesterday's release of Big Sur, so I figured I'd make a post. I already sent @Steve a DM on Twitter about it, since it might be something to cover on SN.

I noticed yesterday that, out of the blue, it was taking anywhere from 30 seconds to 5 minutes to launch non-Apple apps on my Mac. I figured there was some kind of memory leak, so I restarted the machine, but the problem persisted. For a second I was worried about some kind of hardware failure, since the machine kept beachballing and mouse movement was laggy. Things got weird when the same problem happened on another of my Macs at the same time.

Apparently, whenever you launch an app on macOS, the trustd daemon will send a hash of that app to ocsp.apple.com for verification. Apple was having some massive outages yesterday related to the Big Sur release, so while this server was still online, it was taking a long time between requests. The temporary fix was to disconnect from the internet (which stops this mechanism) or block/redirect that DNS entry using the hostfile or at the router. Supposedly this is sent in the clear per https://sneak.berlin/20201112/your-computer-isnt-yours/.

I think there's some pretty big privacy implications here, especially since there have been some changes to the network stack on Big Sur. Application firewalls like Little Snitch and LuLu can no longer block certain processes Apple includes on their "ContentFilterExclusionList", see

https://twitter.com/x/status/1327034191523975168

.

I figured this certainly would be worthy of discussion here

 

[PHolder]

This is simply a bad design choice by Apple. They really should find a different mechanism than an always on query for every attempted app launch. It's technically the most secure way, if a large number of apps were being added to the block list regularly, but one can hardly presume that to be the case. Check ONCE at install, remember the result, and have a mechanism to push updates to the bad list regularly. Yes, in theory an app which had been delisted would still be allowed to run on some devices for some time after being delisted, but doing it the way they do is just asking for abuse. Imagine if somone MITMed their service somehow and declined all app launches on all Macs everywhere! It would be pandemonium, and potentially unfixable until the MITM were resolved.

 

[JulioHM]

omg! I saw that earlier.

It's not just terrible design. It completely goes against their own speech about user privacy.

And if you think that is an Apple thing, keep dreaming. Windows 10 has is also bloated with telemetry software, by design. I've been wondering why Microsoft decided to allow people to keep using an unlicensed copy of Windows indefinitely. I guess this is the answer.

 

[0xdd]

Great points about bad design and Windows 10 telemetry. It caught me a bit off guard, to be honest. The article I posted was pretty sensationalist (Louis Rossman made a video on YouTube that went even further down that route), but I think it does raise a few good points about all of this being one in the clear and how this could be subject to abuse. I'm curious to see if Apple even responds to it. Ars did write an article on it, but didn't really delve too far into the notarization process. I did find a post from Eclectic Light Company that really explained the notarization process pretty well https://eclecticlight.co/2020/08/28/how-notarization-works/.

 

[EdwinG]

I agree and I disagree.

trustd uses the OCSP protocol, which is plain text. Guess what, your web browser also uses that protocol in plain text when you visit a TLS protected website (unless you're using Google Chrome, because Google decided so).
It is used to confirm whether a X.509 certificate is revoked or not.

My thoughts:

• Can it be abused?
  Of course.
• Can it be improved?
  Yes.
  
  I would like to see it use TLS, but how… You need to support versions of TLS that won't be supported in the future; not an easy problem to solve.
• Is it important to have OCSP validation?
  I would argue that yes. It allows to assert that the application wasn't tampered during transmission over the network, and that no malicious code was injected.
  
  I don't know how often certificate revocation occurs at Apple, but I do expect it to happen regularly. We just don't hear about them, because they're low key and I believe most often developer initiated with no malicious action.
  • Should Apple have monopoly of the Code Signing certificates on macOS?
    Yes and no.
    
    Yes for anything affecting low-level system components, like kernel extensions, DriverKit applications and virtualization software.
    No for more regular applications, like Microsoft Word, Cyberduck and Firefox. They could have a certificate authority program that does it on their behalf.
• Does trustd send the hash of the application to Apple every time it is started?
  No. That response is cached on the computer for at most 12 hours (see the screenshot below of one such response).
  
  I've actually tried to trigger it with multiple Microsoft apps, and it only polled once. It seems to be tied to the developer certificate in use, and not to the application itself. So you might know the developer of the app one uses, but not which application and not what occurs within the application.
  
  For instance, Microsoft Excel, Microsoft Word and Microsft PowerPoint use the same exact certificate. You'll not be able to tell from the OCSP request which app is being launched.
  
  OCSP response for a Microsoft Apple Developer Certificate.
  
  
• Does Apple use the same servers to validate their own applications?
  Yes, they do, except if the application lives in the /System/Applications folder.
• Can it be moved to be fully client-side?
  We get into the "why CRL failed" territory. You're going to have to keep a list of every revoked certificate, ever, on every computer (including those that were never distributed publicly)… That can become bandwidth heavy really fast.
  
  Unlike server authentication certificates, code signing certificates might not expire on their own - as long as they have a valid cryptographic timestamp within the validity period. You need to revoke them if something bad occurs (e.g.: developer's code signing private key got compromised). And unlike TLS,
  
  That's why software signed 10 years ago (e.g.: Windows 7) are still able to start without cryptographic security warnings.

FYI, here's the OCSP target for forums.grc.com:

 

[0xdd]

I had a feeling that this was the place to come for a really in-depth explanation of what's going on here Seriously, thanks @Ed7789 for taking the time to clearly explain all of this. The design makes much more sense to me now. I would think it's pretty clear that the security advantages of such a system outweigh the potential for abuse. From what I've read, I believe the system will fail safe if it cannot resolve an address for ocsp.apple.com, but since the servers were reachable (but slow to respond), the problems occurred.

 

[saguaro]

I did find a post from Eclectic Light Company that really explained the notarization process pretty well https://eclecticlight.co/2020/08/28/how-notarization-works/.

Howard is a genius. His site is gold.

 

[a viewer]

you can't stop this process or the system won't run your application. However, you could use something like little snitch or hands off! to restrict applications from calling home