Rubbish software security patches responsible for a quarter of zero-days last year
- Reference: 1612339388
- News link: https://www.theregister.co.uk/2021/02/03/enigma_patch_zero/
- Source link:
In a presentation at USENIX's [1]Enigma 2021 virtual conference on Tuesday, Stone offered an overview of the zero-day exploits detected in 2020. A zero-day, she explained for attendees outside the infosec community, refers to an exploit targeting a previously unidentified vulnerability.
[2]
Zero-day flaws are a problem because they may be exploited for long periods of time before they're detected and dealt with. There were 24 of them in 2020, [3]four more than in 2019 , Stone said.
"Looking at them all together as a group, the number that stuck out the most to me was that six out of the 24 zero-days exploited in 2020 are variants of previously disclosed vulnerabilities," she said. "On top of that, three out of the 24 vulnerabilities were incompletely patched, meaning that with just a few tweaks, you could have an exploit that still works even after the patch was applied."
[4]
Stone argues that pushing partial patches makes life too easy for attackers.
"We're not requiring attackers to come up with all new bug classes, to develop brand new exploitation, to look at code that has never been researched before," she said. "We're allowing the reuse of lots of different vulnerabilities that we previously knew about."
To illustrate her point, Stone reviewed several zero-day exploits from 2020, including repeated attacks on Microsoft's legacy JScript engine in Internet Explorer.
In January 2018, she explained, a security researcher reported multiple Internet Explorer vulnerabilities to Microsoft. By December 2018, after exploitation of one of these was spotted in the wild, she said, Microsoft issued a fix for [5]CVE-2018-8653 . Another zero-day followed in September 2019, requiring further repairs to address CVE-2019-1367.
Apple emits emergency iOS security updates while warning holes may have been exploited in wild by hackers [6]READ MORE
There was another zero-day in November 2019, resulting in CVE-2019-1429. And then another one in January 2020, with CVE-2020-0674. Finally, the bug appears to have been dealt with in April 2020, with the patch for [7]CVE-2020-0968 .
Stone said the same attacker, according to Google's threat analysis research, exploited all four of these vulnerabilities. "That attacker had four different chances to use these security vulnerabilities to exploit users," she said.
Looking in detail at the vulnerable code, Stone showed how closely related the vulnerabilities were. The common issue for these bugs, she explained, is that a JScript object is not tracked by the garbage collector and that failing to properly dispose of those objects leads to a use after free vulnerability. And that could be achieved by various similar bits of code.
Stone recounted another zero-day that exploited a type confusion bug in Google's V8 JavaScript engine. The exploit was possible because Google's code failed to handle a NaN (not a number) result from the addition of JavaScript values Negative Infinity and Positive Infinity when iterating over a list of integers.
In this instance, a report by security researchers led to CVE-2019-13764 and a patch. In February 2020, Sergei Glazunov, a Project Zero researcher, found that there was a zero-day exploiting CVE-2019-13764 despite the patch. So he analyzed the patch and found it was incomplete – it addressed one way of exploiting the bug but not another. So that led to CVE-2020-6883 and another patch. But that patch caused other problems, so an updated patch was issued.
Stone argues we need to make zero-days harder by not allowing attackers to use prior disclosures to craft their malware.
"We need correct and comprehensive patches for all vulnerabilities from our vendors," she said. "We can't be leaving things open once they're known about."
Stone also challenged security researchers to help by analyzing bugs and performing variant analysis so vulnerabilities can be reported thoroughly and comprehensively. And she urged end users to demand better patches from vendors.
[8]
"If we adopt this behavior for every single vulnerability that is found or reported to us, then we can definitely make it harder for attackers to use zero-day exploits," she said. ®
Get our [9]Tech Resources
[1] https://www.usenix.org/conference/enigma2021/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YBqCSYCwOJPn4TT0JUzigwAAAJc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://googleprojectzero.blogspot.com/2020/07/detection-deficit-year-in-review-of-0.html
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YBqCSYCwOJPn4TT0JUzigwAAAJc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2018-8653
[6] https://www.theregister.com/2021/01/26/apple_ios_zero_days/
[7] https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2020-0968
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YBqCSYCwOJPn4TT0JUzigwAAAJc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://whitepapers.theregister.com/
I definitely agree, but we all know why this has come to pass : the availability of the Internet.
As much as I simply cannot do without it these days, back when it was barely available with a 56K modem, software makers had to get it right out of the door, because patching was inconcievable. You would have had to create tens of thousands of floppies, make deals with computing magazine vendors and publish that you had a patch for your product. The cost alone would have been enough to make beancounters faint.
No, back in the day, you got it right before getting it out. But today, we don't need to do that any more. We get it just about right and ship it, secure in the notion that, if somebody happens on an issue, well, we'll post a patch and all will be well.
What is worse is that patching is apparently become a shoddy process as well. The article states :
So he analyzed the patch and found it was incomplete – it addressed one way of exploiting the bug but not another. So that led to CVE-2020-6883 and another patch. But that patch caused other problems, so an updated patch was issued
The coder patched the problem he was submitted, he did not analyze the issue in its entirety. Then he had to patch the other part, and screwed that up so he had to re-patch. Three patches for the same thing. That is shoddy programming, because we can.
"We need correct and comprehensive patches for all vulnerabilities from our vendors," she said.
Actually, we need tolerably bug free software to start with from all our vendors.
I've never been able to quite get my head round the assumption that it's perfectly OK to release a product riddled with flaws and rely on point fixes after the fact to eliminate them.
In no other branch of engineering would this have passed muster in the past, but now software has permeated most other branches of engineering, their standards are being dragged down to that level as well.
This is not a trivial issue - lives are already being lost as a result.