By 
What’s the most secure browser? It depends on when we ask.
Not too long ago, we discovered a critical security flaw in Firefox. This week, Chrome is addressing fixes for yet more critical vulnerabilities.
Google Chrome’s Issue
- Critical CVE-2024-10487: Out of bounds write in Dawn. Reported by Apple Security Engineering and Architecture (SEAR) on 2024-10-23
- High CVE-2024-10488: Use after free in WebRTC. Reported by Cassidy Kim(@cassidy6564) on 2024-10-18
Google recently patched vulnerabilities in its Chrome browser, one of which was marked as critical, tracked as CVE-2024-10487. The vulnerability allowed remote attackers to perform out-of-bounds memory access via a crafted HTML page.
We don’t know many details yet, at least until a majority of users update their browsers or after ensuring there are no third-party dependencies using Chrome’s older version.
What was disclosed is that the issue lies in Dawn, an open-source implementation of the WebGPU standard. Now, correct us if we’re wrong, but since Dawn is used as the implementation of WebGPU in Chromium-based browsers, there’s a risk that they are affected as well. This can include: Brave, Opera, Edge, Vivaldi, Ark, and others.
How to prevent out-of-bounds in C/C++
As we’ve written several times on the topic, out-of-bounds is essentially accessing memory outside of the program’s set limit.
Use AddressSanitizer (-fsanitize=address or ASan):
Something as simple as:
|
1 2 3 4 5 |
int main() { int arr[3] = {1, 2, 3}; arr[4] = 5; // Buffer overflow return 0; } |
When compiled with -fsanitize=address, running this program would produce an error like:
|
1 |
Copy==12345==ERROR: AddressSanitizer: stack-buffer-overflow on address... |
Use Static Analyzers
Compiler warnings (which are great) aren’t the only tools available at your disposal. Many static analyzers can help with additional expensive checks that compilers don’t perform. There are Cppcheck and Clang-Tidy, to name a few, that serve as both linters and bug detection tools.
Safer Code
This should serve as a standard layer, but it’s more important to have a compiler or analyzer that can catch issues first. It’s no use writing safe code 99% of the time while leaving the remaining 1% with vulnerabilities.
Conclusions
It seems that questions regarding which browser is the strongest and most secure are becoming harder to answer.
As with all software, vulnerabilities lie deep in code. We see ‘out-of-bounds memory’ issues again and again, and we might argue that maybe it’s time for C programmers to take a step back and evaluate, or even reconsider the language itself. We understand that having access to memory allocation in a programming language leads to these types of vulnerabilities where attackers can take advantage and read data outside of the program itself.
In other news that we’re working on reporting soon, Opera had a 0-day vulnerability that could have been exploited using an extension store attack.