Google granted Apple an extension to its 90-day disclosure policy.
Last week Google’s Project Zero published its discovery of a serious vulnerability in macOS and iOS affecting a function known as task_t. Apple released a patch a day before Google made the details public.
Ian Beer, the researcher who discovered the vulnerability, published an extensive explanation of the vulnerability. It is quite technical, but a great summary. One of the details most concerning to us was that the bug could override kernel-level code signing, which operating systems use to prevent malicious code from being executed at a low-level.
In the report, Beer wrote:
“…since this bug also allows us to gain any entitlements we want as well as root it’s easy to use it to defeat kernel code signing on OS X and load an unsigned kernel extension.”
While the bug itself was quite serious, I think this incident is more interesting when we look at what’s involved in getting a bug fixed.
Project Zero is a security team at Google specifically working on discovering zero-day vulnerabilities in popular software. The team does not just look at Google’s software, but any popular software that its users also utilize. This has led to vulnerability discoveries in widely used software including Windows, Android and the Linux kernel.
Project Zero’s goal is not only to find zero-day vulnerabilities, but to have them quickly fixed. If the vulnerabilities are not fixed, they have a 90-day disclosure policy, meaning that Project Zero will publicly publish the details of the vulnerability to make users aware of the risk.
There are different types of disclosure policies. Project Zero’s policy involves contacting the vendor first, withholding a public announcement for 90 days to give the vendor a chance to fix the vulnerability. This is known as responsible disclosure, also known as coordinated disclosure. It is seen as a middle road between full disclosure – which is immediate public disclosure with no ‘lead time’ given to the vendor, and non-disclosure – where the details of the vulnerability are never freely shared.
Project Zero’s responsible disclosure policy has been criticized for aiding attackers by making the details available before users have any defense. Proponents of responsible disclosure say that software companies often fail to fix these problems if not publicly pressured.
This particular task_t vulnerability was originally discovered in June of this year. Project Zero gives companies 90 days to fix any bugs before publically publishing its discovery – which means Google should have published the vulnerability on August 31st. However, extensive back-and-forth led the company to grant Apple an additional 55 days to fix the problem.
It took Apple three attempts to fix the problem – Project Zero’s researchers were able to circumvent the first two.
Now, this is not to say Apple is asleep at the wheel. This was a kernel level bug, which can be quite difficult to fix.
This is not the first time a major company failed to meet the 90-day disclosure policy. Project Zero discovered a vulnerability in Windows 8 that Microsoft failed to fix by the deadline.
When that happened, Project Zero wrote in a statement that:
“Disclosure deadlines are currently the optimal approach for user security – it allows software vendors a fair and reasonable length of time to exercise their vulnerability management process, while also respecting the rights of users to learn and understand the risks they face.”
Ben Hawkes, one of Project Zero’s team members, wrote on Twitter that “when we started Project Zero, vendors told us that they couldn’t possibly be expected to fix any kernel bugs in under 90 days.” He continued to say, this task_t bug in macOS/iOS “could have been fixed under deadline.”
Granting Apple nearly three extra months to fix this problem shows that Project Zero is sympathetic to how long and complicated the process can be. Though some have criticized the team for not sticking firmly to its 90-day rule, it seems best to allow flexibility.
Going public with vulnerabilities is not an easy choice. Millions of users can be put at risk when the details of an unpatched vulnerability are publicly disclosed. But without some pressure, vendors can take months and months to fix major security problems.
What are Zero-Days?
Zero-days are a certain type of security vulnerability that are being exploited in attacks before the software creators know about its existence. The name refers to the fact that the software creators had zero days to write/release a patch before it’s exploited.
Awareness of zero-day vulnerabilities has surged since Edward Snowden revealed widespread hacking and surveillance by the US government. In her book, journalist Kim Zetter documented the Stuxnet virus, which took advantage of multiple zero-days to sabotage Iran’s nuclear program.
Some security researchers and advocates now say that the importance of zero-days are overblown. They point to the fact that most attacks are not very sophisticated, often relying on phishing emails or bad password hygiene, rather than taking advantage of hard-to-find zero-day bugs.
But while zero-day bugs might not be very commonly used, they pose a major danger when they are. Zero-days present in operating systems and other widely used software (like web browsers) can make it easy to attack a specific target.