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

The Chocolate Factory's bug hunters revise 90-day disclosure rules


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.

Picture this

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 full 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 abused by miscreants using the web giant's exploit. If your patch doesn't fully work, your users are now left completely vulnerable while hackers play merry havoc with your busted code as you scramble to emit a followup update.

In either case, of course, you're racing against malware developers who are poring over your security patch, as soon as it is released, to find a way to attack unpatched users – though bear in mind, when Google goes public, it typically posts proof-of-concept exploit code, taking care of most of that effort for miscreants.

AI_doomsday_clock

Bad news: Google drops macOS zero-day after Apple misses bug deadline. Good news: It's fiddly to exploit

READ MORE

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. ®


Other stories you might like

  • Cisco warns of security holes in its security appliances
    Bugs potentially useful for rogue insiders, admin account hijackers

    Cisco has alerted customers to another four vulnerabilities in its products, including a high-severity flaw in its email and web security appliances. 

    The networking giant has issued a patch for that bug, tracked as CVE-2022-20664. The flaw is present in the web management interface of Cisco's Secure Email and Web Manager and Email Security Appliance in both the virtual and hardware appliances. Some earlier versions of both products, we note, have reached end of life, and so the manufacturer won't release fixes; it instead told customers to migrate to a newer version and dump the old.

    This bug received a 7.7 out of 10 CVSS severity score, and Cisco noted that its security team is not aware of any in-the-wild exploitation, so far. That said, given the speed of reverse engineering, that day is likely to come. 

    Continue reading
  • Apple gets lawsuit over Meltdown and Spectre dismissed
    Judge finds security is not a central feature of iDevices

    A California District Court judge has dismissed a proposed class action complaint against Apple for allegedly selling iPhones and iPads containing Arm-based chips with known flaws.

    The lawsuit was initially filed on January 8, 2018, six days after The Register revealed the Intel CPU architecture vulnerabilities that would later come to be known as Meltdown and Spectre and would affect Arm and AMD chips, among others, to varying degrees.

    Amended in June, 2018 the complaint [PDF] charges that the Arm-based Apple processors in Cupertino's devices at the time suffered from a design defect that exposed sensitive data and that customers "paid more for their iDevices than they were worth because Apple knowingly omitted the defect."

    Continue reading
  • Apple M1 chip contains hardware vulnerability that bypasses memory defense
    MIT CSAIL boffins devise PACMAN attack to let existing exploits avoid pointer authentication

    Apple's M1 chip has been found to contain a hardware vulnerability that can be abused to disable one of its defense mechanisms against memory corruption exploits, giving such attacks a greater chance of success.

    MIT CSAIL computer scientists on Friday said they have identified a way to bypass the M1 chip's pointer authentication, a security mechanism that tries to prevent an attacker from modifying memory references without being detected.

    In a paper titled "PACMAN: Attacking Arm Pointer Authentication with Speculative Execution," Joseph Ravichandran, ​​Weon Taek Na, Jay Lang, and Mengjia Yan describe how they were able to use speculative execution – the way in which modern processors perform calculations before they may or may not be needed, to accelerate execution – to discern the pointer authentication code that allows pointer modification on a protected system.

    Continue reading

Biting the hand that feeds IT © 1998–2022