App not launching after signing with hardened runtime

Question

SrCobranza OP

Created Apr ’20

Replies 6

Boosts 0

Views 4k

Participants 3

Hello, I'm trying to notarize my app so it can be opened without having to change the security settings.

After signing all the executables with the following command (hardened runtime enabled):

$ codesign --deep --force --verbose=2 --sign "Developer ID Application: My Name" --options runtime path/to/executable

And then checking the signature:

$ codesign --verify --deep --strict --verbose=2 MyApp.app
MyApp.app: valid on disk
MyApp.app: satisfies its Designated Requirement

When I launch the application I have the following error:

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x5] Code Signature

Application Specific Information:
dyld: launch, loading dependent libraries, ignoring DYLD_* env vars

Dyld Error Message:
  Library not loaded: @rpath/liblua.dylib
  Referenced from: /Users/USER/*/MyApp.app/Contents/MyApp/bin/lua
  Reason: no suitable image found.  Did find:
/Users/USER/*/MyApp.app/Contents/MyApp/bin/lua.app/Contents/MacOS/../../../liblua.dylib: code signature in (/Users/USER/*/MyApp.app/Contents/MyApp/bin/lua.app/Contents/MacOS/../../../liblua.dylib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.

Searching over the forum I've found that a solution could be to enable some entitlements, so I've enabled all of them and signed the application again, but the problem remains.

Any ideas?

Boost

Answer 1

SrCobranza OP

Apr ’20

Ok, I've found out that some of my .dylib were not being signed in my script. Now I'm including all the files and launching the app throws a different error:

Exception Type: EXC_BAD_ACCESS (Code Signature Invalid)

Exception Codes: 0x0000000000000032, 0x00000000fe52ffab

Exception Note: EXC_CORPSE_NOTIFY

Termination Reason: Namespace CODESIGNING, Code 0x2

kernel messages:

VM Regions Near 0xfe52ffab:

VM_ALLOCATE 00000000128f7000-0000000012937000 [ 256K] rw-/rwx SM=PRV

--> VM_ALLOCATE 00000000fe520000-00000000fe530000 [ 64K] r-x/rwx SM=COW

__TEXT 0000000100000000-0000000100877000 [ 8668K] r-x/rwx SM=COW /Users/USER/*/MyApp.app/Contents/MyApp/bin/clibs/libwx.dylib

If I put the app into a dmg and upload it with the "xcrun altool" command it's being notarized successfully.

Maybe this helps?

$ spctl -vvv --assess --type exec Redist/Release/MyApp.app

Redist/Release/MyApp.app: invalid API object reference

1

Answer 2

DTS Engineer OP

Apple

Apr ’20

First up, don’t use

--deep

. My

--deep

Considered Harmful post explains why.

Second, I recommend that you look through my Signing a Mac Product For Distribution post. It covers much of the basics.

As to what’s causing your latest crash, it seems likely that that you have a language runtime that’s JITing code. Note that the crashing PC, 0xfe52ffab, is in the middle of a heap region.

If you ignore notarisation for the moment — that is, you build the app locally, signed with the hardened runtime flag — does it still crash? If so, my initial advice is that you apply the

com.apple.security.cs.allow-jit

hardened runtime exception entitlement. If the JIT engine is using our recommended techniques (

MAP_JIT

), that should be sufficient.

If not, you can probably get things working with other hardened runtime exception entitlements, but my advice is that you first engage with the developer of the runtime to see if they have a version that’s been updated to only require

com.apple.security.cs.allow-jit

.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

1

Answer 3

SrCobranza OP

Apr ’20

Hi eskimo, thanks for your answer.

Exactly, the problem was that the app was crashing after signing with the hardened runtime enabled (notarization process was not involved yet).

I've been trying to fix it by adding different exceptions entitlements and it finally worked after adding "com.apple.security.cs.allow-unsigned-executable-memory". The "com.apple.security.cs.allow-jit exception" wasn't needed.

Just in case someone runs into the same issue, this is the final entitlements.plist file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
</dict>
</plist>

And I'm doing the signing with this command (without the "--deep" option, as you suggested) for all of my executables:

codesign --force --entitlements entitlements.plist --verbose=2 --sign "Developer ID Application: My Certificate Name" --options runtime path/to/executable

0

Answer 4

Megan@rogueco OP

Apr ’20

Thanks for sharing!

0

Answer 5

DTS Engineer OP

Apple

May ’20

Just in case someone runs into the same issue, this is the final
entitlements.plist
file

That’s good to know but…

Folks, please don’t just blindly apply these entitlements. They significantly undermine the security guarantees provided by the hardened runtime. If your app uses a JIT, you should only need

com.apple.security.cs.allow-jit

. If that’s insufficient, you need to dig into the code to find out why.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

1

Answer 6

SrCobranza OP

May ’20

Yes, that's true.

In this case I needed a quick workaround to ship the application, and since we're going to deprecate it soon anyway, it didn't worth the effort. But yes, definitively something to take into account for others running into the same issue, thanks for the suggestion.

0