1570209 - [Mac] Loading of unsigned shared libraries not blocked by Hardened Runtime

Status: RESOLVED INVALID

(Core :: Security: Process Sandboxing, defect, P2)

Description

[Haik Aftandilian [:haik]]

With macOS Hardened Runtime, loading of unsigned shared libraries (dylibs) is meant to be prevented. However, I've encountered two cases where loading of unsigned dylibs is not being blocked. These may turn out to be different bugs.

1. Using DYLIB_INJECT_LIBRARIES. Bug 1562756 was filed for using DYLIB_INJECT_LIBRARIES before Hardened Runtime was enabled, but our enabling of Hardened Runtime unexpectedly didn't prevent it. As noted on bug 1562756 comment 10,

I tested a basic app built with Xcode 10.2.1 on 10.15 Beta 4 (19A512f) with Hardened Runtime enabled (allowing dyld variables) and I could also load an unsigned shared library using DYLD_INSERT_LIBRARIES. That behavior is consistent with what we see with Firefox on 10.15.

However, with Xcode 11.0 beta 2 (11m337n) running on 10.15 Beta 4 (19A512f), with the same test program, using DYLD_INSERT_LIBRARIES with an unsigned shared library fails. That triggers the "Code has to be at least ad-hoc signed" error message. After signing the dylib, DYLD_INSERT_LIBRARIES worked.

2. When plugin child processes load their plugin binary. On macOS 10.15, the GMP process was able to load unsigned versions of the Widevine CDM (libwidevinecdm.dylib) after clearing the quarantine extended attribute (see bug 1566523).

Comment 1

[Haik Aftandilian [:haik]]

These may turn out to be macOS bugs, but filing here now to log progress on debugging.

Comment 2

[Haik Aftandilian [:haik]]

Attachment: Screenshot showing the old and new definition of com.apple.security.cs.disable-library-validation

Comment 3

[Haik Aftandilian [:haik]]

Apple has changed the definition[1] of com.apple.security.cs.disable-library-validation from the more strict

A Boolean value that indicates whether the app may load plug-ins or frameworks signed by other developers

to the more permissive

A Boolean value that indicates whether the app may load arbitrary plug-ins or frameworks, without requiring code signing

Given the new definition, and how we set com.apple.security.cs.disable-library-validation=true, the behavior is no longer a bug because loading of unsigned libraries is expected.

As a consequence, we should change Firefox's setting to false to require signed dylibs. I'll file a bug to make that change.

This doesn't need to be a security bug any more.

1. https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-library-validation

Comment 4

[Haik Aftandilian [:haik]]

Setting com.apple.security.cs.disable-library-validation=false is now meant to allow loading unsigned libraries. So this is working as expected given the update to Apple's docs. Closing bug.