hoakley December 22, 2018 Macs, Technology

How thoroughly does Gatekeeper check existing apps?

My previous article about checking bundle signatures and my new app Signet to make this easy has proved controversial, despite its paucity of comments. This article looks at one contentious issue, whether checking signatures has any relevance or purpose.

My critic is Jeff Johnson, a very experienced and knowledgeable macOS and iOS developer whose opinions I greatly respect. In tweets, he stated (as part of a long discussion):
“The code signature is irrelevant to whether you should remove old apps and bundles.”
“I disagree with the whole notion that there are “signature problems”. Code signatures are designed for Gatekeeper. Gatekeeper is designed for first launch. Gatekeeper has changed over the years. Old signatures on installed apps are irrelevant, not a problem.”

Earlier, I had a shorter exchange of tweets with Thomas Reed, a security researcher for whom I also have great respect. He has been trying to raise awareness of problems with code signatures to encourage developers to do their own internal code signature checks. He wrote:
“Since macOS doesn’t check code signatures after the first run, malware could infect many of the apps on your system, without root, and you’d never know. All it would take is running the wrong app once. Plus, of course, when malware gets revoked, it’ll still run on infected Macs.”

I’m going to look at his case in more detail in an article here tomorrow, but for the moment I think it’s fair to say that these opinions are both based on the observation that, once an app or another form of code bundle has passed its full signature check at first launch, no further checks are made on that code signature. Here I will show that that is no longer true in macOS 10.14.2 (at least).

One simple test you can try is to make copies of different types of app and make changes to those copies, then try opening them. Of course, unsigned apps can tolerate substantial change without anything being aware; you have to break something internal within the app, such as its code, to cause any real problem.

For normal signed apps, the situation is much the same. In this case, I actually removed the app’s original executable code and replaced it entirely. The error message doesn’t refer to any security issue, just that something inside the app is broken.

App Store apps are more sensitive to such tampering. Fiddling with their Info.plist or making substantial changes to their code can more readily trigger warnings, which in this case aren’t quite rendered correctly by macOS, which seems unaware of the Unicode double quotation characters.

But the results are quite different when you make changes to a notarized app. Changing just a single character in the copyright string in its Info.plist, or changing two characters in a URL string embedded in the executable code, resulted in the notarized app (Signet, of course) unexpectedly quitting when it tried to start up.

This behaviour isn’t typical of Gatekeeper checks, though, and the dialog doesn’t appear to have originated from there. However the error codes generated are the same as those reported by Signet:
-67030 invalid Info.plist (plist or signature have been modified) when Info.plist has been changed, and
-67061 invalid signature (code or signature have been modified) when the executable code has been changed.

So something is checking the signatures of notarized apps when they are launched, even though they don’t have the quarantine flag set. In this case, the app had never even been uploaded, but was being run on the Mac on which it had been built. It’s time to take to the log to discover what happened (times are given in clock seconds).

30.343884 SecTrustEvaluateIfNecessary 30.345255 com.apple.securityd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (lsd[355]/0#-1 LF=0) 30.345305 com.apple.securityd cert[2]: AnchorTrusted =(leaf)[force]> 0 30.346576 com.apple.securityd MacOS error: -67030 30.346629 com.apple.securityd MacOS error: -67030 30.361455 SecTrustEvaluateIfNecessary 30.362900 com.apple.securityd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (amfid[124]/0#-1 LF=0) 30.362964 com.apple.securityd cert[2]: AnchorTrusted =(leaf)[force]> 0 30.364183 com.apple.securityd MacOS error: -67030 30.378125 com.apple.securityd MacOS error: -67030 30.378189 com.apple.securityd MacOS error: -67030 30.378271 com.apple.securityd MacOS error: -67030 30.378316 com.apple.securityd MacOS error: -67030 30.378356 com.apple.MobileFileIntegrity Basic requirement validation failed, error: (null) 30.378463 /Applications/SignetTest.app/Contents/MacOS/Signet signature not valid: -67030 30.378478 AMFI: code signature validation failed. 30.380499 SecTrustEvaluateIfNecessary 30.381862 com.apple.securityd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (amfid[124]/0#-1 LF=0) 30.381904 com.apple.securityd cert[2]: AnchorTrusted =(leaf)[force]> 0 30.383124 com.apple.securityd MacOS error: -67030 30.383692 com.apple.MobileFileIntegrity <private>: Broken signature with Team ID fatal. 30.383781 mac_vnode_check_signature: /Applications/SignetTest.app/Contents/MacOS/Signet: code signature validation failed fatally: When validating /Applications/SignetTest.app/Contents/MacOS/Signet: The code contains a Team ID, but validating its signature failed. Please check your system log. 30.383800 proc 17245: load code signature error 4 for file "Signet" 30.403372 com.apple.launchservices RETURNING: { "ApplicationType"="Foreground", "CFBundleExecutablePath"="/Applications/SignetTest.app/Contents/MacOS/Signet", "CFBundleIdentifier"="co.eclecticlight.Signet", "DeathTime"=now-ish 2018/12/21 09:18:30, "LSBundlePath"="/Applications/SignetTest.app", "LSDisplayName"="SignetTest", "LSExitStatus"=9, "pid"=17245 } 30.648151 Saved crash report for Signet[17245] version ??? to Signet_2018-12-21-091830_Howards-iMac-Pro.crash

Similar results were seen after small changes in executable code, but returning the error code of -67061 instead.

I had wondered whether the subsystem responsible for these additional checks might have been TCC, with its considerably extended roles in Mojave. However, they occur in response to standard SecTrustEvaluateIfNecessary entries (just as with signed but not notarized code), and the only log entries of relevance are from the com.apple.securityd subsystem performing signature checks.

Perhaps none of this should be surprising. Signatures contain a lot more than certificate information. They consist of three parts:

The seal, which is a collection of hashes of each component covered by the signature.
The digital signature, consisting of the seal encrypted using the signer’s identity, to guarantee the seal’s integrity.
Code requirements, rules governing verification of the code signature.

The evidence here is that com.apple.securityd has compared the hashes in the signature’s seal with hashes computed for the app bundle, and detected anomalies which show that the contents of the bundle had changed since it was signed. This may be linked to the new notarization ticket which is ‘stapled’ in notarized apps, or could be obtained from the traditional signature.

So, at present in Mojave we have:

Most macOS system bundles – protected by SIP and signed, so cannot be changed.
Apple bundled apps – protected by SIP and signed, so cannot be changed.
App Store apps – signed and more likely to break if changed.
Notarized apps – signed+notarized and almost certain to break if changed.
Other third party apps and bundles – signed or unsigned, not checked after first run unless the developer codes in their own checks.

I believe that code signing was introduced in macOS in 2007, extended and enhanced considerably with the introduction of Gatekeeper in 2012, and notarization is new with Mojave in 2018.

The first benefit of code signing which Apple lists in its Code Signing Guide is to:
“Ensure that a piece of code has not been altered since it was signed. The system can detect even the smallest change, whether it was intentional (by a malicious attacker, for example) or accidental (as when a file gets corrupted). When a code signature is intact, the system can be sure the code is as the signer intended.”

Thanks to Jeff Johnson @lapcatsoftware and Thomas Reed @thomasareed for their absorbing discussions.

20Comments

Add yours

1

Joss on December 22, 2018 at 12:18 pm

I’m not 100% sure, but some third-party notarized apps are also protected by SIP, like macOS system applications.

I.e. when a standard notarized application is tweaked, it will break, of course, but it can still be run by the user if he allows it to. However, some (currently only few, it seems) notarized apps seem to have additional security failsafes built in (baked into the executable code?), like 1Password, iMazing etc., and they are protected by SIP. If you tweak their bundles, they will not run under any circumstances, unless you disable parts of SIP (debug), or change the actual code to circumvent these built-in security measures. (But I don’t know if the latter is even possible.)

This would actually make sense for the two apps I mentioned, because they deal with your iOS data (iMazing) and passwords/credentials (1Password), so as a developer you would want to offer your customers the best possible protection.

LikeLiked by 1 person
- 2
  
  hoakley on December 22, 2018 at 12:30 pm
  
  As far as I can tell from testing here, there is no option to run a notarised app which fails its signature check: it is forced to crash and gone. There is no dialog offering the user any option.
  There are ways for an app to put itself under SIP if they wish. That’s not a feature of notarization as far as I know.
  Howard.
  
  LikeLike
  - 3
    
    Joss on December 22, 2018 at 12:36 pm
    
    That’s true. You need to code-sign again, and a quick adhoc signature is sufficient.
    
    But that doesn’t work with apps protected by SIP. But I didn’t know this was separate from notarization. Thank you.
    
    LikeLiked by 1 person
4

Jeff Johnson on December 22, 2018 at 1:46 pm

Some notes:
* It’s important to keep in mind that there are multiple layers of security technology operating here, e.g., Gatekeeper, sandboxing, and — new in Mojave — the hardened runtime.
* App Store apps are installed as root:wheel, so modifying them in place is not possible unless you have root.
* App Store apps must be sandboxed, so whenever you’re testing a App Store app, you’re also testing a sandboxed app.
* Notarized apps must have the hardened runtime enabled, so whenever you’re testing a notarized app, you’re also testing the hardened runtime.
* In my testing, Gatekeeper only applies to quarantined apps. Once an app has been approved by the user, no further Gatekeeper checks are ever done, as far as I’ve seen.
* In Xcode, the hardened runtime exceptions include “Disable Library Validation” and “Disable Executable Memory Protection”. These seem relevant to the issues at hand.
* I have no particular objection to app self-tests, but an attacker who can modify the app’s executable can also bypass the app’s self-tests, so this is not a particularly reliable security precaution.
* An attacker who can modify the app locally could also re-sign the app, replacing the invalid signature with a new valid signature. This is one reason why I think post-install code signing checks are security theater.
* The most likely entry point for app tampering would be in its embedded libraries, so modifying those would probably be a better test than modifying the main executable.
* If you get an app crash dialog from the system (with a Report… button), then you’ve already bypassed Gatekeeper and gotten to the point where dyld is attempting to run the app.

LikeLiked by 1 person
- 5
  
  Joss on December 22, 2018 at 2:20 pm
  
  Not sure if Gatekeeper doesn’t test again at some point. For example, you can create a Gatekeeper exclusion list, where you can add applications with `sudo spctl –add –label /path/to/App.app && sudo spctl –enable –label `. As I understand it, if you only allow an application past GK, macOS will at some point nag you again, unless you manage it using the spctl command.
  
  As for post-install code signing checks, they are indeed security theater, *unless* you have a database with the previous version. Then, if something changes, e.g. the developer’s original signature to an attacker’s signature or to an adhoc signature, or if library injection at application launch is detected, you’d receive a warning. And that would actually be enhanced security.
  
  LikeLiked by 1 person
  - 6
    
    hoakley on December 22, 2018 at 5:25 pm
    
    I think that you’re dismissing any measure which isn’t bombproof as being ‘security theatre’. You can apply that to the idea of a database, as any store containing such information would naturally be a target, and so on. This is surely about risk reduction: raising the bar over which the malware developer has to jump to the point where only the best-funded, technically-savvy can compete.
    The moment that you allow ad hoc signing, anything which relies in part or wholly on signatures has a clear means of exploitation. But preventing such signing would also block important features which users rely on. There are so many good security reasons for removing AppleScript and Automator, for example, but it wouldn’t prove too popular a measure!
    Having so much completely unsigned code on Macs a decade after the introduction of signatures doesn’t seem, to me at least, to be helping anyone.
    Howard.
    
    LikeLike
- 7
  
  hoakley on December 22, 2018 at 5:10 pm
  
  Thank you, Jeff. Your points are good and well-taken.
  I’d be very interested to know what is triggering the signature check when you run a notarized app after first run. There is no doubt – you can see in the log extract above – that com.apple.securityd is performing one, and it is picking up the small changes in the binary, which means it is comparing the actual hash with that in the signature. This then throws the correct error, presumably from that static code check on the app bundle.
  As I wrote, the app crash behaviour is more typical now of TCC, but there’s nothing that I can see in the log to suggest that it is TCC which is triggering the signature check. But I also believe that Apple security engineers are more keen these days to crash apps like this than present friendly dialogs, for obvious reasons.
  Sadly, the term Gatekeeper is never used in the log. But the pattern of entries is very similar to that which occurs at first run. Of course in this case, it’s not being performed on a translocated app.
  Your thoughts on app tampering are rather different from those of others. It’s surely far easier to replace a complete unsigned bundle – which may well not be the app bundle itself – than to try modifying either the main executable or libraries. That is what Thomas Reed has demonstrated, and which appears quite technically undemanding.
  The question of what is ‘security theatre’ in the context of signatures is also interesting. Isn’t the whole of Gatekeeper now mere security theatre, as it is so easy and cheap to acquire a developer ID? When’s the last time that any significant malware for macOS wasn’t signed using a Developer ID? That hurdle is so low as to not even be a challenge to a script kiddy, surely.
  Indeed, you could argue that as macOS would always have to support ad hoc signing, the whole concept of signatures is so easy to break that it is inevitably security theatre. However, I think that this is about successive layers reducing risk by making it harder for malware to succeed. This eliminates all but the more serious malware developers, and blocking them is going to be irreducibly difficult.
  Howard.
  
  LikeLike
  - 8
    
    Jeff Johnson on December 22, 2018 at 6:41 pm
    
    I’d recommend that if you want to perform “scientific” tests of the macOS security measures, you need to control the variables. Testing apps “in the wild” is not ideal, because there are too many variables. The best way would be to create a test app that you control completely. This way you can separately and individually test sandboxing, the hardened runtime, notarization, etc. Otherwise you don’t know which is the causal factor.
    
    As far as tampering is concerned, my suggestion was just in response to your testing, which involved modifying shipping apps. Of course it would be great for malware authors if they can replace the whole app bundle. I’m just saying that historically speaking, it’s been easier to sneak code into the libraries than into the main executable.
    
    LikeLiked by 1 person
    - 9
      
      hoakley on December 22, 2018 at 7:02 pm
      
      I’m losing the plot here.
      I open a notarized app after first run (in fact, without any quarantine flag), which triggers a signature check, which crashes the app when it returns an error. That doesn’t happen with sandboxed apps, but only following hardening and notarization. Whether it’s actually something which we call Gatekeeper which ordered the signature check isn’t actually important, is it? It is working like that thing that we have called Gatekeeper. Whether we call it that or something different, it is doing the same thing that Gatekeeper does, but on second and subsequent runs. Cf argument over nomenclature of a duck, only in this case ducks are far better defined and documented.
      Howard.
      
      LikeLike
    - 10
      
      Jeff Johnson on December 22, 2018 at 7:45 pm
      
      Well, I thought that everyone would be interested in the true underlying explanation behind the macOS behavior. In any case, re-reading the article I noticed something that I glossed over originally: “In this case, the app had never even been uploaded, but was being run on the Mac on which it had been built.” This strongly suggests to me that the true cause was the hardened runtime, and notarization was irrelevant. I do question the notion that “it is doing the same thing that Gatekeeper does”. While it’s clear that some kind of check is being performed, but it’s not at all clear that it’s the exact same kind of check as a first-launched quarantined app.
      
      LikeLiked by 1 person
    - 11
      
      hoakley on December 22, 2018 at 8:21 pm
      
      Jeff,
      I’m sure that everyone is interested in the true underlying explanation. However, given the universally true statement that macOS doesn’t check app signatures after first run, which has prevailed for the last six years, I thought that the observation that this appears to change with notarization might perhaps be of more than passing interest too.
      As our construct of what Gatekeeper is, is assembled largely from observing its behaviour, and may be quite different from Apple’s engineering reality, questions of terminology seem somewhat unclear, to me at least. Maybe you know of some official documentation that I don’t?
      I don’t know how much time you spend browsing the log, but I have now studied dozens, perhaps even scores, of app opens since we were blessed with the unified log in Sierra (and I remember them fondly from before). The com.apple.securityd entries there are absolutely characteristic of that subsystem checking a signature, and the error which it returns is not only correct, but is of a class which is only returned (and meaningful) when a signature has been checked. It really, really is a duck. Maybe Apple has cunningly disguised it and it’s really a wolf?
      As I wrote, I can’t establish from the log entries which part of macOS actually called com.apple.securityd to check that signature. But we know that Gatekeeper already performs such checks in certain circumstances. We know that sandboxing doesn’t. So just to answer your question, I have just built a hardened but non-notarized version of that app, ironically Signet (at least you may agree it now has a useful purpose!). Changing one character in that version’s Info.plist file causes an identical crash, with the appropriate signature error. So the evidence that I now have points at hardening as being the crucial factor.
      Being only hardened, it has no notarization ticket stapled in its bundle. So whatever is causing that signature check is doing so as a result of hardening. As we don’t know exactly what hardening does, it’s still waddling around and quacking like mad!
      But it leaves unaltered the observation that notarized (and now it seems hardened but non-notarized, if anyone were ever to bother) apps have their signatures checked when opened each time, not just on first run. I think that is a significant change for Mojave. Or am I just imagining this?
      Howard.
      
      LikeLike
    - 12
      
      Jeff Johnson on December 22, 2018 at 9:55 pm
      
      The hardened runtime is certainly new to Mojave, there’s no controversy about that. I did a quick test, and at first I could modify a hardened app’s main executable, thereby breaking the code signature, without any apparent consequences, until I realized that I had disabled SIP. After re-enabling SIP in recovery, the app did indeed crash on launch after the main executable was modified. However, I changed a character in the Info.plist with no problem, and I also changed a character in MainMenu.nib with no problem, both of which break the code signature, but the app still launched fine. So this check appears to be very limited, and not a full bundle code signature check like Gatekeeper. I assume I could “maliciously craft” an image file or something in the bundle without the kernel noticing a problem. Not sure why yours crashed on Info.plist mod, although perhaps some of that info is embedded in the binary too.
      
      LikeLiked by 1 person
    - 13
      
      hoakley on December 22, 2018 at 10:12 pm
      
      I have tried changing Info.plist on several notarized and non-notarized apps – it’s one of the easiest tests as it’s simple to do with BBEdit, rather than farting around with a hex editor. All I normally do is change the capital A in All rights in the copyright notice to capital O. I have also changed build numbers with the same effect. With notarized apps here, changing either of those in the Info.plist results in an identical crash every time.
      What happened in the log when your modified hardened app opened and didn’t crash? Was the signature check performed and returned no error, or did it not occur?
      The apparent association with SIP seems puzzling to me. Does disabling SIP turn off any other signature checking?
      Howard.
      
      LikeLike
    - 14
      
      Jeff Johnson on December 22, 2018 at 11:34 pm
      
      I think I figured out your crashing issue: you’re dealing with Gatekeeper Path Randomization. If I modify the Info.plist in the Downloads folder, then it crashes. I believe this is because Gatekeeper caches its assessments by path, so when you launch from Downloads, the app gets a new random path and thus needs a new assessment. Try downloading the app, moving it to /Applications, launch the app, approve, quit, and *then* modify the Info.plist.
      
      The association with SIP is because SIP enforces (most of) the hardened runtime protections: https://lapcatsoftware.com/articles/hardened-runtime-sandboxing.html
      
      LikeLiked by 1 person
    - 15
      
      hoakley on December 23, 2018 at 12:01 am
      
      Thanks, Jeff. It’s almost midnight and I’ve been up for 18 hours, much of it with grandchildren, so I’ll take a look at this in the morning if you don’t mind.
      Two thoughts, though, while you enjoy your movie: first, let me remind you that none of my test apps have been downloaded, so none has even the remains of a quarantine xattr. So surely Gatekeeper never goes near them (in the ordinary way of macOS)? They’ve consequently never been near the Downloads folder either, and their app signature is identical to a perfectly-signed and notarized app in /Applications.
      The other is, yes, I did read your excellent article about hardening and SIP. The snag is that – once again – SIP doesn’t exist in log entries. Most of the features of hardening appear in the log in TCC activities, which coincides neatly with the terminology introduced at WWDC. TCC has gone from an occasional participant in Sierra to being one of the most active subsystems in Mojave. It is TCC which force-crashes 10.14 SDK apps which exceed their entitlements, etc. – which is a very similar process to these signature failures.
      You may well have seen some of the TCC log walkthroughs that I have published here. It’s getting to be quite an old friend now.
      Howard.
      
      LikeLike
    - 16
      
      Jeff Johnson on December 23, 2018 at 12:26 am
      
      Ok, if the apps weren’t downloaded, were they ever launched from their non-/Applications path *before* getting modified? The same principle applies, because Gatekeeper — or you might say SecAssessment (man spctl) — caches its assessments by path. So when you launch the unmodified app, it caches the assessment, and then the next time you launch it uses the cached assessment instead of a new assessment. But if you’ve never launched the app at that path, it’s going to check.
      
      SIP is a kernel-level protection, so you might not see that in the logs, and also why you can’t disable it unless you boot into the recovery volume. But SIP is also behind most of the TCC protections too. If you disable SIP, then you can suddenly access files and such that you couldn’t before on Mojave.
      
      LikeLiked by 1 person
    - 17
      
      hoakley on December 23, 2018 at 4:15 pm
      
      Thanks, Jeff: that is most helpful and has spawned many further experiments and much log-gazing. I’ll post a summary in the morning.
      Howard.
      
      LikeLike
18

John Daniel (@etresoft) on December 22, 2018 at 6:59 pm

I would encourage you to be a little more circumspect about repeating claims from the security industry. They are trying to sell a product and nothing sells better than fear, except for Apple+fear. I’m particularly fascinated by the idea that Gatekeeper is worthless because Developer IDs are easy to purchase. One blog post says “OMG! A Microsoft certificate was revoked!” and the next post assumes that any certificate is a perpetual free pass. Maybe we should stop calling these things “certificates” and start calling them what they really are – a kill-switch. Once you think of it that way, then it seems like a pretty bad idea for a malware developer to buy a kill-switch. Perhaps that is why most adware is still unsigned. They don’t want to purchase Apple kill-switches for their adware.

It is easy to blog about these things when you don’t have to deal with the messy reality of developing and supporting software. Why doesn’t macOS check the signature of all apps every time they run? Have you tried running codesign on apps like Xcode? That can take 15 minutes or more with a mechanical hard drive. Is this a big enough risk to have every Mac in the world checking signatures on every app at every run?

LikeLiked by 1 person
- 19
  
  hoakley on December 22, 2018 at 7:21 pm
  
  Sorry, John, I didn’t realise that I don’t have to deal with the messy reality of developing and supporting software.
  Perhaps before offering someone unsolicited advice (which doesn’t appear relevant to the substance of the article above) you should check your facts. My software may be fairly simple and free, but I can assure you that I develop it, and support it here too, and I have been developing and supporting software since 1987, including a range of commercial products for Classic Mac OS.
  Neither am I simply repeating claims from the security industry. I am surprised that you take such an uncritical view of security research as to condemn it as just generating fear. Far from repeating any claims, the article above actually calls into question the frequent statement that signatures aren’t checked after first run, and provides evidence that, in notarized apps, they are now, although Jeff seems to disbelieve that. I can’t win, unless you just want me to shut up and go away, which would be by far my easiest option.
  I am also very familiar with the arguments over whether signatures should be checked more generally by macOS after first run, which isn’t actually anything to do with the article above. Is it?
  Howard.
  
  LikeLike
  - 20
    
    John Daniel (@etresoft) on December 22, 2018 at 9:21 pm
    
    I don’t take an uncritical view, but I do take a pragmatic one. And I never said anything about generating fear. I said “selling fear”. I’m very familiar with the security industry. It is distinct and separate from the rest of the software industry. If you post something on the internet, unsolicited advice is inevitable. Would you prefer uncritical praise? Your blog has been generally very highly regarded and respected. You are diving into the details of macOS in a way that people haven’t done for a while. I appreciate that and many other people do as well. But security is a different area. It is far more social than technical.
    
    LikeLike

·Comments are closed.

Share this:

Related