Published on January 7th, 2020 📆 | 5033 Views ⚑0
Yeah, says Google Project Zero, when you think about it, going public with exploit deets immediately after a patch is emitted isn’t such a great idea
Patting itself on its back for motivating software makers to fix 97.7 per cent of the vulnerabilities it identifies within its 90-day disclosure deadline, Google’s bug-hunting unit Project Zero has decided to ease up on those racing to patch their flawed products.
This month, Project Zero revised its Disclosure Policy so that it will publicly reveal details of a security flaw precisely 90 days after privately disclosing the details to the relevant vendor. This is a change from the previous policy under which bugs were revealed after 90 days or when fixed, whichever came first.
As a result of the amended policy, vulnerability details will remain undisclosed for a longer period of time, giving developers enough time to fix their code, and netizens to test and install the patches, before Googlers make technical details and proof-of-concept exploits public for all to see. Project Zero will, we note, reveal vulnerability details sooner if there’s mutual agreement between the affected vendor and the web goliath’s team.
There are also other exceptions: vendors can request an additional 14-day grace period if a vulnerability will be fixed after the 90-day deadline but before 104 days have elapsed. And a seven-day deadline still applies for vulnerabilities being actively exploited in the wild.
So, imagine this scenario: Project Zero privately informs you that your application has a security hole in it. You spend the next two weeks fixing and testing a resolution for the flaw, and then roll out a suitable patch to your users. Folks now have the best part of 90 days to install this update and be safe before Google goes public with details of your programming blunder. If the patch breaks during these 90 days, you still have time to address it before the Silicon Valley monster lifts the veil.
Under the old approach, Project Zero would privately tell you that your app has a security hole in it. You then spend the next two weeks fixing and testing the update, and roll out the patch to your users. Googlers immediately spot this, and make their bug report public. Your users are now in a race to update their systems before the hole is exploited by miscreants using the web giant’s exploit. If your patch doesn’t fully work, your users are now left completely vulnerable while hackers can play merry havoc with your busted code as you scramble to emit a followup update.
Bad news: Google drops macOS zero-day after Apple misses bug deadline. Good news: It’s fiddly to exploit
In a blog post on Tuesday, Tim Willis, Project Zero manager, explained that the policy tweak is intended to encourage more thorough patch development and better patch adoption, while maintaining the policy’s original goal of driving faster patch development.
“Too many times, we’ve seen vendors patch reported vulnerabilities by ‘papering over the cracks’ and not considering variants or addressing the root cause of a vulnerability,” Willis wrote. “One concern here is that our policy goal of ‘faster patch development’ may exacerbate this problem, making it far too easy for attackers to revive their exploits and carry on attacking users with little fuss.”
In other words, Project Zero researchers hope the consistent 90-day revelation time will give vendors’ security engineers more time after a patch is initially developed to ensure it covers minor exploit changes that could bypass code repairs. They also anticipate that the potential lag between patch development and vulnerability disclosure will leave more time for patches to be deployed, making exploitation less likely.
Willis said Project Zero expects to evaluate whether its revised policy is working as intended later this year. ®
M3 – The ML, AL and Analytics Conference from DigitalMunition