CVE-2023-36199 - Denial of Service in SKALE Network sgxwallet via trustedGenerateEcdsaKey

The world of blockchain security is moving fast, and vulnerabilities can have a big impact, especially when they affect trusted components. Recently, CVE-2023-36199 was discovered in the SKALE Network’s sgxwallet (version 1.9. and below). This post gives a plain-English explanation of the issue, how it works under the hood, and some practical advice for defenders and developers.

What Is SKALE Network and sgxwallet?

SKALE Network is an open-source, Ethereum-compatible network designed to scale smart contract platforms. One of its components, sgxwallet, uses Intel SGX enclaves to securely generate and store sensitive keys, like ECDSA private keys. In other words, it’s supposed to protect keys from attacks, keeping them locked in hardware-backed memory spaces.

What’s CVE-2023-36199 All About?

CVE-2023-36199 is a denial of service (DoS) vulnerability. It allows an attacker—without any special permissions—to crash the sgxwallet or make it unresponsive, by abusing the trustedGenerateEcdsaKey part of the system.

Short summary:

A bug lets someone send special (or malformed) requests to the trustedGenerateEcdsaKey function, which handles private key generation, causing the whole process (or sometimes the whole enclave) to crash.

Breaking Down the Vulnerable Code

Let’s look at a simplified version of what happens under the hood.

Inside trustedGenerateEcdsaKey, user input isn’t always carefully checked. Imagine a simplified function like this (not the real code, but good enough to explain):

sgx_status_t trustedGenerateEcdsaKey(const user_input_t *input, ecdsa_key_t *key) {
    // Input validation is missing or weak!
    if (input == NULL || key == NULL) {
        return SGX_ERROR_INVALID_PARAMETER;
    }

    // The dangerous part: acting directly on user-provided data
    memcpy(key->data, input->raw, input->length);

    // Imagine input->length could be very large or zero—bad!
    // This may cause buffer overflows, unhandled exceptions, or enclave crashes.

    // ...proceed to generate ECDSA key...
    // If something fails badly, the enclave may die!

    return SGX_SUCCESS;
}

If the attacker supplies a large, malformed, or deliberately crafted input (for example, a length way larger than what’s expected), the wallet process can crash and take down the enclave.

The attack works like this

1. Attacker finds a way to call trustedGenerateEcdsaKey—this might be via an API or even a local process.

2. He/she sends broken or oversized data as the “user_input”.

The sgxwallet crashes, causing a denial of service.

No shell, no data theft—just a dead or frozen wallet process. But in a blockchain network, downed validator/wallet nodes can cause real disruption.

Real-World Risk

- Attackers can trigger this repeatedly, potentially taking whole clusters of wallet nodes offline.

The Fix

SKALE Network developers quickly issued a fix in versions after 1.9.. Here’s how they patched it (again, in simplified code):

sgx_status_t trustedGenerateEcdsaKey(const user_input_t *input, ecdsa_key_t *key) {
    if (input == NULL || key == NULL || input->length > EXPECTED_MAX || input->length == ) {
        return SGX_ERROR_INVALID_PARAMETER;
    }
    memcpy(key->data, input->raw, input->length);
    // Continue safely...
}

The takeaway: Always check your inputs, especially in trusted code running inside enclaves.

Defense and Recommendations

- Upgrade the sgxwallet component to the latest version (official repo here).

Original References

- SKALE Network's Advisory and GitHub Patch (sgxwallet)
- Official NVD Entry for CVE-2023-36199
- SKALE Security Guide

Conclusion

This bug is a classic example of why even trusted execution environments need regular code reviews, input checks, and defense-in-depth. In blockchain, reliability is key—so don’t let a simple input validation error bring down your node.

Keep your SKALE nodes patched, always. Stay safe out there!

*Post by: [Your Name or Handle]*

*For more news and hands-on guides about blockchain and crypto security, follow this blog!*

Timeline

Published on: 08/25/2023 20:15:08 UTC
Last modified on: 08/29/2023 20:53:23 UTC