Google Patched an Actively-Exploited Zero-Day Bug in Chrome (threatpost.com) 14
"Google released an update to its Chrome browser that patches a zero-day vulnerability in the software's FreeType font rendering library that was actively being exploited in the wild, Threatpost reported this week:
Security researcher Sergei Glazunov of Google Project Zero discovered the bug which is classified as a type of memory-corruption flaw called a heap buffer overflow in FreeType. Glazunov informed Google of the vulnerability on Monday. Project Zero is an internal security team at the company aimed at finding zero-day vulnerabilities.
By Tuesday, Google already had released a stable channel update, Chrome version 86.0.4240.111, that deploys five security fixes for Windows, Mac & Linux — among them a fix for the zero-day, which is being tracked as CVE-2020-15999 and is rated as high risk. "Google is aware of reports that an exploit for CVE-2020-15999 exists in the wild," Prudhvikumar Bommana of the Google Chrome team wrote in a blog post announcing the update Tuesday... "The fix is also in today's stable release of FreeType 2.10.4," Ben Hawkes, technical lead for the Project Zero team, tweeted. Meanwhile, security researchers took to Twitter to encourage people to update their Chrome browsers immediately to avoid falling victim to attackers aiming to exploit the flaw...
In addition to the FreeType zero day, Google patched four other bugs — three of high risk and one of medium risk — in the Chrome update released this week... So far in the last 12 months Google has patched three zero-day vulnerabilities in its Chrome browser.
By Tuesday, Google already had released a stable channel update, Chrome version 86.0.4240.111, that deploys five security fixes for Windows, Mac & Linux — among them a fix for the zero-day, which is being tracked as CVE-2020-15999 and is rated as high risk. "Google is aware of reports that an exploit for CVE-2020-15999 exists in the wild," Prudhvikumar Bommana of the Google Chrome team wrote in a blog post announcing the update Tuesday... "The fix is also in today's stable release of FreeType 2.10.4," Ben Hawkes, technical lead for the Project Zero team, tweeted. Meanwhile, security researchers took to Twitter to encourage people to update their Chrome browsers immediately to avoid falling victim to attackers aiming to exploit the flaw...
In addition to the FreeType zero day, Google patched four other bugs — three of high risk and one of medium risk — in the Chrome update released this week... So far in the last 12 months Google has patched three zero-day vulnerabilities in its Chrome browser.
PoC font file for anyone interested (Score:5, Insightful)
Attached to the Freetype bug case:
https://savannah.nongnu.org/bu... [nongnu.org]
Does "zero-day" actually mean anything anymore? (Score:4, Interesting)
It used to be the case that zero-day meant that an exploit was discovered within the same day that the thing being exploited was released... but at some point, the definition mutated to become an exploit that is discovered outside of the organization it was created in before the developer knows about it or has a fix for it.
Which in actuality is a bit weird... because almost all exploits would fit that definition, since if the developer has a fix for it, then the exploit doesn't work in the first place.
Re: (Score:2)
Re: (Score:3)
> It used to be the case that zero-day meant that an exploit was discovered within the same day that the thing being exploited was released.
Who was using that definition? It's bordering on impossible from a software engineering standpoint.
For a long time the number was always based on days after patch release because patches aren't that hard to reverse-engineer.
So zero-day is a pre-patch exploit. Those are the worst because they hit even the most responsible users at times.
And yes, trade-press reporter
Re: (Score:2)
How that generally happens is as a result of enough details on how something works being either released or sometimes even simply leaked before actual publication, and by the time the product is actually released, someone has already figured out how to use whatever limited information they had before to defeat it some aspect of it, and they discover that the exploit they had thought of actually works against t
Re: (Score:2)
"Who was using that definition?"
That usage goes back to the warez community. The term is cited in the book "The Internet in Public Life" released in 2004, so would have been in use on the 1990's if not earlier.
Here is a citation from January 31st, 1998: http://web.textfiles.com/ezine... [textfiles.com]
Re: (Score:2, Informative)
It used to be the case that zero-day meant that an exploit was discovered within the same day that the thing being exploited was released... but at some point, the definition mutated to become an exploit that is discovered outside of the organization it was created in before the developer knows about it or has a fix for it.
Which in actuality is a bit weird...
At least in the security industry, the term never referred to "discovery" time, it is a counter from when a patch or update to fix it is released.
Outside of the industry I'm sure the confusion comes due to the news media, but in a way it makes some sense why and isn't weird at all.
You've probably noticed how often nowadays when an exploit is mentioned in the media, there are times when little to no details are released.
This is because there's been a big push in the security industry to now do everything in
Buffer overflow in the year 2020 (Score:4, Interesting)
Why are buffer over-flows still working? Isn't this what DEP* and ASLR** are meant to prevent? Windows 7 is EOL and it has DEP and ASLR. So why is this news news?
*Data Execution Prevention
**Address Space Layout Randomisation
Re: (Score:2)
The high end exploit writers have bypasses for these. Essentially you need an information leak vulnerability which you can chain with the buffer overflow giving you a way to locate useable addresses in memory. Someone with an OSEE certification from Offensive Security can do this.
Re: (Score:2)
I don't know enough about it. Like why doesn't the OS simply know what is data and what is code and not execute the data.
If code is compiled with a good compiler then doesn't it clearly specify what is data and what is code in the outputted code? Are areas of memory not correctly labelled by executables? Does fault lie with compilers or the OS?
So memory protection doesn't work both ways? The OS won't execute data but it will allow code to be over-written by data.... Clearly that shouldn't be allowed, OS fai
Re: (Score:2)
This is a heap overflow so essentially data in memory owned by the app has pointers inside it that are being corrupted and used to control execution. Yeah it's a C/C++ thing. Browsers are all about speed so they're still in these languages as well as the OS.
Re: (Score:2)
ROP defeats ASLR in most cases. LLVM has some interesting workarounds in the pipeline.
Re: (Score:2)
There are workarounds for DEP and ASLR. DEP is bypassed by Return Oriented Programming (ROP), a technique where your instructions aren't instructions, but return addresses and the processor is simply processing return from subroutine instructions off a carefully constructed stack.
You mig
Re: (Score:2)
Thanks for the answer. ROP is a pretty ingenious attack and I'm amazed that people have even gotten that to work in the wild, it is indeed far harder to mitigate than the security that ASLR and DEP provide.