For years it was possible to make malicious code designed to run on OSX and macOS computers fool security tools into thinking it had been digitally signed by Apple. That is the finding made public this week by a researcher at software company Okta.
Obviously, this was not good – code signing is an important security technology so anything that undermines it, and the trust it creates, is a big deal.
Code signing is a security construct that uses public key infrastructure to digitally sign compiled code or even scripting languages to ensure a trusted origin and to ensure that the deployed code has not been modified.
… On macOS/iOS, code signing focuses on the Mach-O binary and application bundles to ensure only trusted code is executed in memory.
The problem was caused by the way many well-regarded developers implemented Apple’s code-signing APIs to interact with Apple’s Fat/Universal binaries from at least 2007 until earlier this year when the issue was reported to them.
The explanation offered by researcher Josh Pitts is hard to follow if you’re not familiar with Apple development, but the core of it is that as long as certain pre-conditions were met, it was possible to game code-signing verification.
Those conditions being:
- The first Mach-O in the Fat/Universal file must be signed by Apple, can be i386, x86_64, or even PPC [PowerPC].
- The malicious binary, or non-Apple supplied code, must be adhoc 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.
Essentially, as long as one file in a Mach-O binary and application bundle was legitimately signed – even something ancient for the defunct PowerPC architecture – a malicious file targeting macOS could be sneaked along with it.
That’s like vouching for the entire contents of a zip archive full of files and folders just because one of the files inside it is clean.
Luckily, it appears nobody knew about the weakness, or at least there is no evidence they did. But, as is always the case, the post-mortem has begun – and developers are blaming Apple’s documentation.
One security developer told Motherboard:
The code signing APIs are a bit confusing, because if you say, ‘please validate this file’ it can say, ‘yes, everything looks good’ even if the programs in the Fat file are signed by two different code signers.
Arguably, both sides should have carried out greater due diligence.
The research has generated an impressive list of CVEs for a wide range of security tools, which might not even be a complete, Okta said.
These include VirusTotal (CVE-2018-10408), Google Santa (CVE-2018-10405), Facebook OSQuery (CVE-2018-6336), Objective Development LittleSnitch (CVE-2018-10470), F-Secure xFence/LittleFlocker (CVE-2018-10403), Objective-See WhatsYourSign, ProcInfo/KnockKnock/ LuLu/TaskExplorer/others (CVE-2018-10404), Yelp OSXCollector (CVE-2018-10406), Carbon Black Cb Response (CVE-2018-10407).
As serious as this is, it’s worth remembering that code signing is just one way of vouching for a file and that effective security tools, like an effective security posture, use defence in depth. And, as much as this undermines trust in the process of secure development it’s better to know than not, however embarrassing that may be in the short term.
What to do?
If you’re using any of the affected software, check with your vendor for updates.
If you’re writing code, don’t cut corners for the sake of speed when you’re doing cryptographic verification (or anything else for that matter). If you’re validating FAT binaries, validate every component in the bundle and make sure they all pass muster.