A recently discovered security vulnerability in how third party vendors are checking Apple's "code-signing" process potentially made it easier to trick macOS users into running malicious third-party code.
Developers have been warned of the risk, but users still need to upgrade their software to guard against attacks exploiting the shortcomings, disclosed on Tuesday.
The flaw created a means to impersonate Apple, according to researchers at cloud identity manager Okta. Specifically, by exploiting this vulnerability, a hacker could trick users of third-party security tools into believing their code is Apple-approved, making it easier to get them running malicious code on a macOS machine.
The trick is quite subtle and relies on a number of preconditions – so exploitation would be difficult in practice. Okta has no evidence of the flaw ever being abused, which isn't to say it's a non-issue, only that it's not exactly a gaping hole.
Here's the science bit
The vuln exists in the difference between how the Mach-O loader loads signed code against how improperly used code-signing APIs check signed code. It might be exploited via a malformed universal/fat binary.
A Fat/Universal file is a binary format that contains several Mach-O (executable, dyld, or bundle) files with each targeting a specific native CPU architecture (i386, x86_64, or PPC).
According to Okta, the conditions for the vulnerability to work are as follows:
- The first Mach-O in the Fat/Universal file must be signed by Apple, and can be i386, x86_64, or even PPC
- The malicious binary, or non-Apple supplied code, must be ad hoc signed and i386-compiled for an x86_64 bit target macOS
- The CPU_TYPE in the Fat header of the Apple binary must be set to an invalid type or a CPU type that is not native to the host chipset
Breaking the chain of trust
By exploiting the security loophole, hackers would be able to break the chain of trust in code signed by Apple and in macOS security that people take for granted. All third-party security, forensics and incident response tools that used the official code-signing API are affected, the researchers claimed.
Okta Research and Exploitation team member Josh Pitts said his firm found that "virtually all" third-party Apple security products that verified signed code using the official Apple APIs did not verify the cryptographic signature properly.
Pitts was able to create a malformed program that, to these security products, would look to be signed by Apple itself, thereby bypassing a core security feature in these products. The bypass affects Fat/Universal file format and is related to a lack of verification of nested formats.
The security weakness could have been abused since the 2005 introduction of OSX Leopard as the flaw takes advantage of OSX's multi-CPU architecture support in the form of a malformed Fat/Universal file. It affects macOS and older versions of OSX.
Successful attackers using the technique could gain access to personal data, financial details or sensitive insider information, claimed researchers.
With the help of CERT/CC, all known affected vendors have been notified, clearing the way for Okta to publicly disclose the vulnerability on 12 June. Okta urged users of Apple's security tools to update their software. It also encouraged the security research community to look more closely into issues involving the code-signing process.
The firm has published a list of affected vendors, alongside associated security notes:
- VirusTotal – CVE-2018-10408
- Google – Santa, molcodesignchecker – CVE-2018-10405
- Facebook – OSQuery – CVE-2018-6336
- Objective Development – LittleSnitch – CVE-2018-10470
- F-Secure – xFence (also LittleFlocker) – CVE-2018-10403
- Objective-See – WhatsYourSign, ProcInfo, KnockKnock, LuLu, TaskExplorer (and others) – CVE-2018-10404
- Yelp – OSXCollector – CVE-2018-10406
- Carbon Black – Cb Response – CVE-2018-10407
Code-signing is the process of using public key infrastructure to digitally sign compiled code or scripts to verify their origin and make sure they have not been modified. ®