Exploiting IPC With New Desynchronization Primitives

Exploiting IPC With New Desynchronization Primitives

Speakers: Martin Doyhenard, Security Researcher, Onapsis

Conference: HITB Amsterdam

YouTube: https://www.youtube.com/watch?v=CTil1laLf98

Overview

In this compelling talk, Martin Doyhenard, a Security Researcher at Onapsis, unveils a series of critical vulnerabilities impacting SAP's Internet Communication Manager (ICM), a foundational component present in virtually all SAP installations worldwide. The presentation, titled "Exploiting IPC With New Desynchronization Primitives," delves into how low-level inter-process communication (IPC) mechanisms within the ICM can be abused to achieve high-impact attacks, including HTTP request desynchronization, use-after-free conditions, and even a theoretical path to remote code execution.

The significance of these findings cannot be overstated. SAP systems are the backbone of global enterprises, managing critical business processes such as finance, human capital, and supply chain operations. With over 400,000 installations globally, including 90% of Fortune 500 companies, compromising an SAP system can lead to severe business disruption and significant financial damage. Doyhenard's research highlights that these vulnerabilities, collectively codenamed ICIMAD, affected all SAP products and exposed over 20,000 internet-facing systems.

The talk meticulously dissects SAP's proprietary HTTP server, the ICM, revealing how its internal architecture and communication protocols, specifically the Memory Pipe Interface (MPI), introduce unique attack surfaces. By combining novel desynchronization techniques with memory corruption primitives, Doyhenard demonstrates how attackers can hijack user sessions, poison application caches, and ultimately lay the groundwork for a complete system compromise. This research underscores the importance of scrutinizing core infrastructure components, even those with proprietary implementations, for subtle flaws that can have far-reaching security implications.

Background

▶ Watch: Introduction to SAP Security and ICM (0:00)

SAP systems, ubiquitous in enterprise environments, expose their application logic through web services, primarily via HTTP and HTTPS. The central component facilitating this communication is the Internet Communication Manager (ICM). The ICM acts as SAP's proprietary HTTP server, handling all external client requests. Crucially, it is present by default in every SAP installation, whether on-premise, cloud-based (like S/4HANA), or even as a web dispatcher, making it a universal attack surface across the SAP ecosystem.

Doyhenard explains that while the ICM handles the initial HTTP communication, the actual business logic resides in separate worker processes, typically Java or ABAP virtual machines. The ICM's role is to receive requests, parse them, and then forward them to the appropriate worker process for resolution. This inter-process communication (IPC) is managed by a proprietary framework called the Memory Pipe Interface (MPI). Instead of copying entire requests and responses between processes, MPI utilizes shared memory. The ICM and worker processes exchange MPI pointers that reference specific MPI buffers, which are fixed-size memory segments, each 2^16 bytes (65 kilobytes) in size. Requests and responses are written into and read from these buffers, minimizing data copying and improving efficiency.

When a request arrives at the ICM, a worker thread is assigned. This thread reads the request from the TCP socket, reserves an MPI buffer, and stores the initial request data. The ICM then employs an HTTP parser and a series of internal handlers to attempt to resolve the request. These handlers are functions within the ICM binary designed to address specific types of requests quickly without involving the heavier worker processes. Key internal handlers include:

• Cache Handler: Always called, attempts to serve requests from the ICM's internal cache.
• Admin Handler: Called for URLs with the prefix /sap/admin.
• Authentication Handler: Called for specific authentication-related URL prefixes.
• Java/ABAP Handler: Always included at the end of the handler list; if no other internal handler can resolve the request, this handler forwards it to the respective Java or ABAP worker process.

Requests exceeding the 65KB MPI buffer size are handled by allocating multiple MPI buffers, with MPI pointers linking them together. Once a request is processed and a response is generated, the MPI buffers are freed, and their references are cleared, making them available for subsequent requests. The talk highlights that the efficiency and proprietary nature of this IPC mechanism, coupled with the ICM's role as a front-facing HTTP server, create unique opportunities for attackers to desynchronize its internal state and exploit memory management flaws.

Key Findings

▶ Watch: First Vulnerability: HTTP Desynchronization in ICM (12:10)

Doyhenard's research uncovered two primary, critical vulnerabilities within SAP's ICM, which can be chained and leveraged for severe impact:

1. HTTP Request Desynchronization (CVE-2023-0016, CVSSv3 10.0): This vulnerability arises when a large HTTP request (exceeding 65 kilobytes) is sent to an endpoint that is resolved by an internal ICM handler (e.g., /sap/admin). The ICM initially stores the first 65KB of the request in an MPI buffer and processes it. However, because an internal handler resolves the request quickly, the ICM worker thread believes the request-response cycle is complete and frees the MPI buffer. Crucially, the remaining portion of the large request's body is still present on the TCP socket. The ICM then attempts to read from the socket again, interpreting this leftover data as a new, isolated request. This split interpretation, particularly when an upstream proxy perceives the original large request as a single, valid message, leads to a classic HTTP request desynchronization (smuggling) scenario. Attackers can inject arbitrary HTTP prefixes that will be prepended to subsequent legitimate client requests, effectively hijacking sessions or manipulating responses.

1. Use-After-Free (UAF) in MPI Buffer Management (CVE-2023-0017, CVSSv3 8.1): This vulnerability exploits a flaw in how the ICM manages MPI buffers when processing pipelined requests. If an attacker sends two pipelined requests, where the first request is large (exceeding 65KB), the ICM allocates multiple MPI buffers for the first request and a separate buffer for the second, pipelined request. When the first (large) request is resolved, the MPI_FreeBuffers function is called. This function, intended to free all buffers associated with that worker thread, prematurely frees the MPI buffer designated for the second pipelined request. However, the worker thread retains a reference to this now-freed buffer. This creates a classic use-after-free condition, where the attacker's worker thread holds a pointer to a memory region that has been returned to the system's free pool and can subsequently be reallocated to another worker thread, potentially for a different client's request.

These core vulnerabilities, particularly the UAF, open doors to more advanced exploitation techniques:

• Cache Poisoning: By leveraging the UAF, an attacker can tamper with a victim's response in memory, specifically injecting the SAP-Cache-Control header along with arbitrary malicious content (e.g., JavaScript). This forces the ICM's cache handler to store the attacker-controlled response for a legitimate endpoint, leading to persistent compromise of that resource for all subsequent clients.
• Heap Buffer Overflow leading to Remote Code Execution (RCE): Doyhenard outlines a theoretical path to RCE by chaining the UAF with cache poisoning. An attacker could use the UAF to tamper with both the SAP-Cache-Control header and the reported length of a cached response. When the ICM attempts to load this corrupted cache entry, it allocates a buffer based on the original, shorter length but then writes the tampered, longer response, resulting in a heap buffer overflow. This overflow could corrupt critical heap structures, such as pointers to internal handlers, allowing an attacker to redirect execution flow and achieve remote code execution. While achieving stable RCE would require bypassing ASLR and hitting specific heap layouts, the underlying primitive for memory corruption is demonstrated.

Technical Deep Dive

▶ Watch: Second Vulnerability: Pipelining leads to Use-After-Free (28:00)

The core of the ICM's operation revolves around efficient handling of HTTP requests and IPC with backend worker processes. When a client initiates a TCP connection, the ICM assigns a worker thread. This thread is responsible for the entire request-response cycle.

1. Request Ingestion: The worker thread reads the incoming HTTP request from the socket. For efficiency, it reserves an MPI buffer (a 65KB shared memory segment) and stores the initial request data there. If the request exceeds 65KB, additional MPI buffers are reserved, and a chain of MPI pointers links these segments.

1. HTTP Parsing and Internal Handlers: The ICM's HTTP parser processes the request headers. Based on the parsed information, a list of internal handlers is dynamically created. These handlers are functions within the ICM binary designed to resolve requests without involving the heavier backend worker processes. The Cache Handler is always invoked first, attempting to serve the request from an internal cache. Other handlers, like the Admin Handler (for /sap/admin paths) or Authentication Handler, are called based on specific URL prefixes. If an internal handler successfully resolves the request, it generates a response, which is then sent back to the client, and the associated MPI buffers are freed.

1. Forwarding to Worker Process: If no internal handler can resolve the request, the Java/ABAP Handler (the fallback) is invoked. This handler sends the MPI pointer (or pointers, for large requests) referencing the request data in shared memory to the appropriate backend worker process. The worker process performs the business logic, generates a response in a new MPI buffer, and sends its MPI pointer back to the ICM worker thread. The ICM then forwards this response to the client.

Vulnerability 1: HTTP Request Desynchronization (CVE-2023-0016)

This vulnerability exploits a subtle interaction between large requests and internal handlers. Consider a request with a Content-Length header indicating a size greater than 65KB, sent to an endpoint handled by an internal handler, such as /sap/admin.

• The ICM worker thread receives the request. It reserves an MPI buffer and stores the first 65KB of data.
• The HTTP parser and internal handlers are called. The Admin Handler successfully resolves the request based on the URL prefix and the initial 65KB of data.
• A response is generated and sent back to the client. The MPI buffer(s) used for the processed portion of the request are freed.
• The Critical Flaw: The ICM worker thread, having completed what it perceives as a full request-response cycle, returns to reading from the TCP socket. However, the remaining portion of the original large request (beyond the initial 65KB) is still on the socket. The ICM then interprets this leftover data as the start of a new, entirely separate request.

This behavior creates a desynchronization. While an upstream proxy might have seen one large, legitimate request, the ICM internally splits it into two. The attacker can craft the remaining portion of the request to be a malicious HTTP prefix that will be prepended to the next request received from any client on that same TCP connection. This allows for classic HTTP smuggling attacks, where an attacker can manipulate a victim's subsequent requests or responses. The speaker emphasizes that this vulnerability is particularly stealthy because the initial large request appears entirely normal to any proxy, making detection difficult.

Vulnerability 2: Use-After-Free (UAF) in MPI Buffer Management (CVE-2023-0017)

This UAF condition arises from how the ICM handles pipelined requests, especially when combined with large request sizes.

• An attacker sends two pipelined requests over a single TCP connection. The first request is intentionally crafted to be large (e.g., >65KB).
• The ICM worker thread receives the data. It reserves multiple MPI buffers for the large first request.
• The HTTP parser, recognizing the pipelined nature, also reserves a separate MPI buffer for the second request.
• The worker thread then processes the first (large) request. The MPI pointers for its buffers are sent to the backend worker process, a response is generated, and sent back to the client.
• The Critical Flaw: After the first request's response is sent, the MPI_FreeBuffers function is called. This function is designed to free all MPI buffers currently associated with that specific worker thread. Crucially, this includes the MPI buffer that was reserved for the second, still-pending pipelined request.
• Despite the buffer being freed, the worker thread retains its MPI pointer reference to this now-invalid memory location.

This creates a use-after-free scenario. The freed MPI buffer is returned to a global pool, often managed as a stack (Last-In, First-Out). This means it is highly probable that the next worker thread (potentially serving a different client on a different TCP connection) that requests an MPI buffer will be allocated the same freed buffer. The attacker's worker thread, still holding the dangling pointer, can then interact with this reallocated buffer, effectively tampering with the data of another, legitimate client's request or response.

Exploiting UAF: Cache Poisoning and Heap Buffer Overflow

The UAF is a powerful primitive that can be leveraged for significant impact:

• Tampering Requests/Responses: By winning a race condition, an attacker can use their dangling MPI pointer to modify the contents of a reallocated MPI buffer. If this buffer is used for a victim's incoming request, the attacker can alter the request mid-flight. More powerfully, if the buffer is used to store a victim's response from the backend, the attacker can inject arbitrary data into that response before it reaches the victim's browser.

• Persistent Cache Poisoning: This is a direct consequence of response tampering. An attacker can inject an SAP-Cache-Control header and malicious content (e.g., JavaScript alert(1)) into a victim's response. The ICM's Cache Handler, upon seeing this header, will then store the attacker-controlled content in its persistent cache for the URL the victim originally requested. Subsequent requests to that legitimate URL will then serve the poisoned, malicious content, leading to a persistent compromise of that specific application endpoint.

• Heap Buffer Overflow (RCE Path): The speaker details how cache poisoning can be escalated to a heap buffer overflow, a potential precursor to RCE. The ICM's cache stores not only the response body but also metadata, including the expected length of the response. If an attacker leverages the UAF to tamper with a response that also contains an SAP-Cache-Control header, they can strategically modify both the response body and the metadata stored in the cache file, specifically corrupting the recorded length.
• When a client later requests the poisoned resource, the Cache Handler reads the corrupted metadata. It allocates a heap buffer based on the incorrect, shorter length specified in the metadata.
• However, it then attempts to write the actual, longer, attacker-controlled response body into this undersized buffer. This results in a heap buffer overflow, overwriting adjacent memory regions.
• By carefully crafting the overflow, an attacker could potentially overwrite critical data structures on the heap, such as pointers to internal handlers. If a handler pointer is overwritten with an attacker-controlled address, the next time that handler is invoked, execution flow can be redirected to arbitrary code, leading to Remote Code Execution (RCE).
• Doyhenard acknowledges the significant challenges in achieving stable RCE, including bypassing Address Space Layout Randomization (ASLR), precisely hitting target heap structures, and dealing with the ICM's tendency to crash during unstable exploitation attempts. He notes that successful RCE required combining this with another vulnerability to obtain memory layout information, and even then, it was highly unreliable, taking "about two hours" in real tests to achieve.

Demo / Proof of Concept

▶ Watch: Persistent Cache Poisoning via Use-After-Free Demo (36:30)

The talk included compelling demonstrations of the HTTP request desynchronization and the use-after-free leading to cache poisoning. While the remote code execution path was discussed theoretically, it was not demonstrated live due to its inherent instability and the need for additional memory layout information.

HTTP Request Desynchronization and NWA Endpoint Exploitation

The first demonstration showcased the HTTP request desynchronization (CVE-2023-0016) by targeting an SAP NWA (NetWeaver Administrator) endpoint. This endpoint has two key features:

1. Open Redirect: It can redirect users to an attacker-controlled domain if a malicious Host header is injected.
2. Parameter Reflection: It reflects content from a POST request's body into the query string of the redirection URL.

The attack flow demonstrated was:

• An attacker sends a specially crafted, large HTTP POST request to /sap/admin. The request's body is designed to exceed 65KB, with the critical malicious payload (a POST to NWA with a forged Host header like evil.com and a Content-Length of 100) placed precisely at the 65KB boundary.
• The ICM processes the first 65KB (resolved by the Admin Handler), sends a response to the attacker, but leaves the malicious NWA POST payload on the socket.
• When a legitimate victim sends a subsequent request, the ICM concatenates the attacker's leftover NWA POST payload with the victim's request (which becomes the body of the NWA POST).
• The NWA endpoint then processes this combined request. It performs an open redirect to evil.com, reflecting the victim's original request (including their cookies) in the query string of the redirect URL.
• The victim's browser follows the redirect, sending their sensitive session cookies and original request details to evil.com, effectively hijacking their session.

Botnet Creation via Self-Propagating Desynchronization

An innovative extension of the desynchronization attack was demonstrated: creating a self-propagating botnet.

• After hijacking the victim's request and redirecting them to evil.com, the malicious server (evil.com) responds with an HTML page containing a hidden form.
• This form is pre-filled with the exact desynchronization payload (the large POST to /sap/admin with the embedded NWA POST).
• When the victim's browser renders this page, the form is automatically submitted, initiating another desynchronization attack from the victim's machine.
• This creates a recursive loop, where each compromised victim's browser becomes a new attacker, continuously launching desynchronization attacks without further attacker interaction. This significantly amplifies the attack's reach and impact.

Use-After-Free and Persistent Cache Poisoning

The second demonstration focused on the use-after-free (CVE-2023-0017) leading to persistent cache poisoning.

• A Python script was used to orchestrate a race condition involving two worker threads: one controlled by the attacker to establish the UAF, and another simulating a victim.
• The attacker's thread sends a large, pipelined request, creating the UAF condition where it retains a dangling pointer to a freed MPI buffer.
• The script then rapidly sends requests from the "victim" thread to a target endpoint (e.g., /start_page).
• Through careful timing and repeated attempts (due to the probabilistic nature of race conditions and heap allocation), the script eventually manages to:

1. Have the victim's response allocated into the attacker's freed MPI buffer.
2. Tamper with this response in memory, injecting a malicious SAP-Cache-Control header and arbitrary JavaScript (e.g., <script>alert('Poisoned!');</script>).

• Once successful, the ICM's Cache Handler sees the SAP-Cache-Control header and stores the attacker's malicious response for /start_page in its persistent cache.
• Subsequent requests to /start_page from any client (including a simple browser refresh) then receive the poisoned response, executing the injected JavaScript. This demonstrates a persistent and widespread compromise of a legitimate application resource.

Defensive Implications

▶ Watch: Q&A: Feasibility of Remote Code Execution (47:00)

The vulnerabilities disclosed by Martin Doyhenard have significant defensive implications for organizations running SAP systems, especially given the critical nature and widespread deployment of the ICM.

1. Patching is Paramount: The most immediate and crucial defensive action is to apply the security notes released by SAP. These vulnerabilities affect all SAP products, making comprehensive patching across the entire SAP landscape non-negotiable. Organizations must ensure that their ICM components are updated to versions that address CVE-2023-0016 and CVE-2023-0017.

1. Detection and Verification: Onapsis, Doyhenard's company, developed a detection tool to identify vulnerable systems. Organizations should leverage such tools or internal scanning mechanisms to verify that their SAP installations are no longer susceptible to these specific vulnerabilities. Given that over 20,000 internet-facing SAP systems were exposed, proactive scanning is essential.

1. Network Segmentation and Least Privilege: While patching is primary, robust network architecture remains a critical layer of defense. Segmenting SAP systems from the broader corporate network and the internet, wherever possible, reduces the attack surface. Implementing strict firewall rules to limit direct access to ICM ports (typically HTTP/HTTPS) to only necessary clients and trusted proxies can mitigate the impact of any unpatched or future vulnerabilities.

1. HTTP Proxy/WAF Configuration: Although the talk highlighted that standard proxies might not detect the desynchronization payload, a well-configured Web Application Firewall (WAF) or advanced HTTP proxy might offer some additional protection against general HTTP smuggling techniques. Organizations should review their proxy configurations and consider implementing stricter parsing rules if available, though this vulnerability's stealth makes it challenging for generic solutions.

1. Monitoring and Logging: Enhanced monitoring of SAP ICM logs for unusual HTTP request patterns, large requests to administrative endpoints, or unexpected redirects can help detect attempted exploitation. While the attack is subtle, anomalies might appear in detailed logs.

1. Beyond SAP ICM: Doyhenard emphasizes that the underlying concepts—exploiting low-level IPC and memory management in HTTP servers—are not unique to SAP. Similar vulnerabilities could exist in other proprietary or custom HTTP servers (e.g., Microsoft IIS, or other application-specific servers) that use internal memory sharing or inter-process communication for business logic. Security teams should consider these findings as a case study for scrutinizing similar critical components in their own environments.

1. Understanding Attack Chaining: Defenders need to recognize that low-level memory corruption vulnerabilities, often difficult to exploit directly, can be powerfully leveraged when combined with higher-level application logic flaws (like the NWA endpoint's open redirect and parameter reflection) or HTTP desynchronization techniques. A holistic security assessment must consider how different vulnerabilities can be chained for maximum impact.

Key Takeaways

• SAP ICM is a Critical and Universal Attack Surface: The Internet Communication Manager (ICM) is a default and essential component in all SAP installations, handling external communication. Its ubiquity (over 400,000 installations, 90% of Fortune 500) makes it a high-value target.
• Proprietary IPC Introduces Unique Vulnerabilities: SAP's proprietary Memory Pipe Interface (MPI) for shared memory communication between the ICM and worker processes, while efficient, introduced complex memory management flaws.
• HTTP Request Desynchronization (CVE-2023-0016, CVSS 10.0) is Stealthy and Impactful: A large request resolved by an internal handler can leave data on the socket, which the ICM misinterprets as a new request. This desynchronization is difficult for proxies to detect and can be used for session hijacking and malicious redirects.
• Use-After-Free (CVE-2023-0017, CVSS 8.1) Enables Powerful Attacks: A flaw in MPI buffer freeing for pipelined requests creates a UAF, allowing attackers to tamper with other clients' requests or responses in shared memory.
• UAF Leads to Persistent Cache Poisoning and RCE Potential: The UAF can be leveraged to inject malicious content and SAP-Cache-Control headers into responses, persistently poisoning the ICM's cache. This can further be escalated to a heap buffer overflow by corrupting cache metadata, opening a path to remote code execution (though RCE is complex and unstable).
• Cross-Domain Impact and Botnet Potential: The desynchronization attack, combined with SAP's NWA endpoint, allows for cross-site request forgery (CSRF) and can be weaponized into a self-propagating "botnet" using simple HTML forms, continuously reinfecting victims.

About the Speaker(s)

Martin Doyhenard is a Security Researcher at Onapsis, a company specializing in ERP (Enterprise Resource Planning) security and critical business application security. His work focuses on uncovering vulnerabilities in the software and systems that manage essential business processes, particularly within SAP's extensive ecosystem. Doyhenard's research, as demonstrated in this talk, involves deep technical analysis and reverse engineering of core enterprise components to identify and exploit low-level flaws with significant real-world impact.