Envoy Proxy is a popular open-source edge and service proxy, vital in many cloud-native infrastructures. But like any powerful tool, it can have dangerous cracks. Let’s break down CVE-2023-35942—a “use-after-free” bug that threatened Envoy’s reliability for months. We’ll keep it clear: what happened, how it can be exploited, and what you should do to stay safe.

What is CVE-2023-35942?

Prior to versions 1.27., 1.26.4, 1.25.9, 1.24.10, and 1.23.12, Envoy Proxy has a vulnerability where a specific way of logging—gRPC access logging—can cause a crash. This happens if the *logger* uses the global scope of a *listener* and, while active, the listener gets “drained” (shut down or replaced).

Crash is triggered by actions legitimate users might take during upgrades or dynamic config changes.

- This is a use-after-free bug, meaning code tries to access memory that was already released—very risky in the world of C++ where Envoy is written.

Understanding the Vulnerability

Let’s illustrate the problem. Normally, you might use Envoy to log incoming/outgoing RPCs (Remote Procedure Calls) via gRPC. The loggers hook into the network “listener” that receives connections.

Here’s a basic snippet of how the access log config might look in Envoy’s YAML

access_log:
  - name: envoy.access_loggers.grpc
    typed_config:
      "@type": type.googleapis.com/envoy.config.accesslog.v3.HttpGrpcAccessLogConfig
      common_config:
        grpc_service:
          envoy_grpc:
            cluster_name: accesslog_service
        log_name: my_access_log

Imagine this logger is running on a listener. If that listener is removed or updated, the *underlying memory* (the objects it references) may be deleted. But if the logger still tries to use that memory, the process could either:

Behave unpredictably,

- Or, in the worst case, open the door for attackers to hijack execution (though no such exploit for code execution has been shown in this case).

Exploiting CVE-2023-35942: Walkthrough

This bug is mainly a crash issue. Here’s a simplified example showing what a use-after-free looks like in C++ (note: not the real Envoy code, but you’ll get the idea):

class Listener {
public:
    GrpcAccessLogger* logger;

    // When the listener is destroyed, logger pointer may now dangle!
};

void removeListener(Listener* listener) {
    delete listener; // All memory is freed, including logger
}

void logAccess(Listener* listener) {
    listener->logger->log(); // Oops: if listener is destroyed, this is a disaster!
}

If logAccess() gets called after removeListener(), the program could crash.

Updating or removing the listener while requests are still being handled.

3. The logger attempts to process a finishing request, referencing a deleted object and causing Envoy to crash.

Attackers could DOS (deny service) Envoy installations by automating this kind of listener churn, repeatedly causing crashes.

Upgrade immediately if you use gRPC logging.

- Envoy’s GitHub Security Advisory
- CVE Details at NIST: [CVE-2023-35942]

Stop listener updates

- Don’t dynamically update or remove listeners while traffic is flowing, until you can restart with a patched version.

Who is at risk? Anyone running Envoy with gRPC access logging on vulnerable versions.

- What’s the danger? Remote users or even your own scripts could crash (DoS) Envoy by causing listener drains.

Temporary fixes? Turn off gRPC access logs, avoid dynamic listener updates.

This issue is a reminder: always keep your core infrastructure—network proxies and API gateways—up to date.

References

- GitHub Envoy Security Advisory
- CVE-2023-35942 at NVD
- Upgrading Envoy Docs

*Written exclusively for this request. Please credit if shared.*

Timeline

Published on: 07/25/2023 19:15:00 UTC
Last modified on: 08/02/2023 18:36:00 UTC