DARKNAVY

In May of this year, we noticed that Chrome fixed a V8 vulnerability that was being exploited in the wild in this update. We quickly pinpointed the fix for this vulnerability and discovered that it was a rare bug in the Parser module, which piqued our interest greatly. This led to the following research. From Patch to PoC First, let’s take a look at the patch for this vulnerability: diff --git a/src/ast/scopes.cc b/src/ast/scopes.cc index 660fdd2e9ad..de4df35c0ad 100644 --- a/src/ast/scopes.cc +++ b/src/ast/scopes.cc @@ -2447,7 +2447,7 @@ bool Scope::MustAllocate(Variable* var) { var->set_is_used(); if (inner_scope_calls_eval_ && !var->is_this()) var->SetMaybeAssigned(); } - DCHECK(!var->has_forced_context_allocation() || var->is_used()); + CHECK(!var->has_forced_context_allocation() || var->is_used()); // Global variables do not need to be allocated. return !var->IsGlobalObjectProperty() && var->is_used(); } diff --git a/src/parsing/parser-base.h b/src/parsing/parser-base.h index 40914d39a4f..65c338f343f 100644 --- a/src/parsing/parser-base.h +++ b/src/parsing/parser-base.h @@ -2661,6 +2661,7 @@ typename ParserBase<Impl>::BlockT ParserBase<Impl>::ParseClassStaticBlock( } FunctionState initializer_state(&function_state_, &scope_, initializer_scope); + FunctionParsingScope body_parsing_scope(impl()); AcceptINScope accept_in(this, true); // Each static block has its own var and lexical scope, so make a new var The patch is very simple, the actual effective fix is just one line of code. This line introduces a variable of type FunctionParsingScope when parsing the static initialization block of a class. Let’s examine what this newly introduced variable does: ...

Introduction The Chromium Embedded Framework (CEF) is an open-source framework that allows developers to embed the Chromium engine in their applications. Although CEF is widely employed in a range of popular software, including WeChat and the Epic Games Launcher, there has been little security research on it. In this article, we will use the Steam Client Browser (a CEF-based application) as an example to present the vulnerabilities we found and how we exploited them to build three Remote Code Execution (RCE) chains. ...

As consumers, when faced with five different brands and models of smartphones or ten different smart cars, it’s difficult for us to determine which one can effectively prevent our privacy from being stolen or maliciously accessed, such as our location or even hearing our conversations inside the car. Even as ordinary consumers, we currently have no way of knowing. As technology professionals who have long studied in APT(Advanced Persistent Threat) attacks, we understand that these devices can ultimately be compromised in the face of advanced persistent attacks. ...

Introduction In 2018, with the release of ARMv8.5-A, a brand new chip security feature MTE (Memory Tagging Extensions) emerged. Five years later, in 2023, the first smartphone to support this feature was released — Google Pixel 8 — marking the official entry of MTE into the consumer market. Although this feature is not yet enabled by default, developers can turn it on themselves for testing. As a powerful defense against memory corruption, there has not yet been a comprehensive analysis of MTE’s defensive boundaries, capabilities, and its impact on performance on the internet. Previously, Google Project Zero published a series of articles about MTE, focusing on the more low-level security aspects of MTE. However, the actual impact of MTE on real software security remains a mystery. To discuss this topic, heap allocators provide an excellent starting point. Heap memory corruption issues have gradually become the mainstream type of binary vulnerabilities. For reference, see the presentation by MSRC at CppCon 2019: ...

Introduction When we examine a third-party library vulnerability in a real environment, we often encounter numerous complex variables that exist within the vulnerability’s context. Exploiting such a vulnerability is not as easy as one might imagine. Here is the information we know: The overflowed variable huffman_tables, has a size of 0x2f28. The heap chunk is allocated in the renderer’s ThreadPool, while most objects are allocated in the main thread. We can write a partially controlled 4-byte integer with an offset that is a multiple of 8 bytes. In Chrome, different-sized heap chunks are stored in separate buckets, isolating objects of different sizes to ensure security. Typically, achieving heap exploitation in Chrome requires identifying objects of the same size for layout purposes and then utilizing Use-After-Free (UAF) or Out-of-Bounds (OOB) techniques to manipulate other objects, leading to information disclosure or control-flow hijacking. In the following, we will share the objects we have discovered, as well as attempting to bypass this mechanism. ...

Vulnerability Localization In the initial phase of vulnerability analysis, due to the absence of readily available PoCs or detailed analysis reports, we first attempted to read and understand the patch code for CVE-2023-4863 in the upstream repository of webmproject/libwebp. However, the WebM Project’s official patch was relatively complex, making it difficult for us to accurately pinpoint the root cause of the vulnerability. Thus, we turned our attention to Apple’s official patch for CVE-2023-41064, and performed a comparison of the ImageIO framework before and after the update using BinDiff. We noticed that Apple’s patch involved fewer code changes and was much easier to understand. ...