(This is an Apple bug, and is being reported to product-security@apple.com contemporaneously with being filed here for our own records.)

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.

The library validation feature is documented thusly:

The code will only be able to link against system libraries and frameworks, or libraries, frameworks, and plug-in bundles with the same team identifier embedded in the code directory. Team identifiers are automatically recorded in signatures when signing with suitable Apple-issued signing certificates.

Team identifiers are overly broad for this purpose. Apple-issued signing certificates share the same Team ID even when issued for different purposes. For example, code signed with a Developer ID Application certificate has the same team ID as code signed with a Mac Development certificate, provided that a team agent or team admin has added the developer to their team. See https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDistributionGuide/MaintainingCertificates/MaintainingCertificates.html#//apple_ref/doc/uid/TP40012582-CH31-SW41 and https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDistributionGuide/ManagingYourTeam/ManagingYourTeam.html#//apple_ref/doc/uid/TP40012582-CH16-SW10.

This shifts the security model provided by library validation in a subtle but important way. The model was previously understood to be “as long as you protect the key you use to sign for distribution, library validation prevents you from loading unwanted code.” In reality, the model adds that “all developers on your team must protect their code signing keys as well; furthermore, you must trust all developers on your team for purposes of releasing code on behalf of your organization.” This is a gigantic shift.

An organization may treat the private key for its Developer ID Application code signing certificate as a closely-guarded secret, available to a small number of employees only on well-secured and not-easily-accessible systems, further protected by a strong passphrase.

By contrast, individual developers are not likely to secure the private keys for their development certificates as diligently. Development certificates are likely to be installed on development systems with only ordinary security precautions, and will normally be well-connected to the Internet. Because these certificates are assumed to be for the purposes of development and not production, the risks associated with incompletely securing them are assumed to be low, or at least lower than the risks of incompletely securing Developer ID certificates.

Furthermore, an organization would not reasonably assume that by granting an employee membership in its “Team” that the developer certificates such an employee would be able to obtain from Apple would enable that employee to release code on behalf of the organization. That privilege is normally reserved for those who hold the Developer ID certificate, whose creation is rightfully restricted to the highest access level within a team, the team agent.

By ignoring the certificate type used to sign a code object, the library validation feature allows any developer on a team, or anyone who can obtain any developer on the team’s private key, to release code that the code signature system will validate as having been released by the organization as a whole.

As a more concrete example, application A.app links against a library in B.framework and specifies library validation. Both A.app and B.framework are signed by the organization’s Developer ID Application certificate for release. A malicious employee is able to release a compromised version of B.framework signed with his or her own development certificate. A.app will load this compromised version of B.framework without complaint, despite having requested library validation. Furthermore, an outside attacker may be able to obtain the private key corresponding to even a conscientious employee’s development certificate more easily than they would be able to obtain the private key corresponding to the organization’s Developer ID certificate. In possession of any of the private keys corresponding to any of the organization’s certificates (as determined by the team ID), any outside attacker would be able to release a compromised version of B.framework that A.app will load without complaint.

The attached test case exhibits this problem. You can build it by running “build” after setting three variables to the common name (CN) values of three certificates: developer_id_cert should be a Developer ID certificate, mac_developer_cert should be a Mac Development certificate from the same team as developer_id_cert, and other_developer_id_cert should be a Developer ID certificate from an entirely different team. This will produce an executable signed with the first Developer ID certificate and requesting library validation, and three shared libraries, each signed by one of the three certificates above. It will also produce an unsigned shared library. The “test” script attempts to run the executable with each of these four shared libraries.

It is expected that the executable signed with the Developer ID certificate and requesting library validation will only be able to load the library signed by the same Developer ID certificate. In reality, the test executable will not only run in this configuration, but will also load the library signed by the Mac Development certificate that has the same Team ID.
 

Deleted: lv_team_id_test.tar.gz 784 bytes

lv_team_id_test.tar.gz 784 bytes Download