Remediation of CVE-2022-22536 Request smuggling and request concatenation in SAP NetWeaver, SAP Content Server and SAP Web Dispatcher

[JoeGoerlich]

Tuesday Mar 22, 2022: added info about emergency SP Stack Kernel 7.22.

Thursday Feb 24, 2022: added details to the section describing the impact of the workaround to AS Java systems.

Tuesday Feb 17, 2022: added section describing the impact of the workaround.

Wednesday Feb 16, 2022: updated section For JAVA systems behind SAP Web Dispatcher.

Monday Feb 14, 2022: updated section For ABAP or JAVA systems systems or SAP Content Server behind load balancer / reverse proxy from other vendors.

 

On 8th of February 2022, SAP Security Patch Day a vulnerability in the Internet communication manager (ICM) was disclosed.

SAP released the security note 3123396 and later on the FAQ note 3148968. The workarounds are described in note 3137885.

EDIT: On March 22, 2022 SAP released the emergency SP Stack Kernel 7.22 PL 1101.

After gathering and evaluating all current available information, I came to the following recommendation for remediating this vulnerability in the various affected scenarios:

For ABAP systems or SAP Content Server behind SAP Web Dispatcher:

1. SAP Web Dispatcher has to be patched and the parameter wdisp/additional_conn_close=TRUE has to be set in the SAP Web Dispatcher.

If a request passes through multiple SAP Web Dispatchers on its way, then this must be implemented in all SAP Web Dispatchers of this chain.

2. The SAP Kernel in all application servers and SAP Content Server has to be patched to the minimum required patch level.

3. After patching the SAP Kernel in all application servers, the parameter wdisp/additional_conn in the SAP Web Dispatcher is no longer necessary must be reverted.

For ABAP systems with integrated SAP Web Dispatcher:

1. The SAP Kernel of all application servers has to be updated. No workaround available!

For JAVA systems behind SAP Web Dispatcher:

1. When using the SAP Web Dispatcher version of SAP Note 3147927 the workaround as described in section "For ABAP systems or SAP Content Server behind SAP Web Dispatcher" can be used. With this, the same workaround applies to AS ABAP and AS Java (and DUAL stack).

No differentiation necessary any longer, which makes it easier for you if you are just about to start working on this incident after February 16th.

If you already implemented the workaround as mentioned below, go forward  - patch the SAP Kernel of AS Java and remove the workaround afterwards. There is no need to switch to the same workaround procedure as used for ABAP!

1. SAP Web Dispatcher has to be patched and the request modification rules have to be configured in the SAP Web Dispatcher in the file which is defined by parameter icm/HTTP/mod_<x> as described in SAP note 3137885 and the parameter icm/HTTP/support_http2=FALSE has to be set.

Please note: Do not set wdisp/additional_conn_close=TRUE !

If a request passes through multiple SAP Web Dispatchers on its way, then this must be implemented in all SAP Web Dispatchers of this chain.

2. The SAP Kernel in all application servers has to be patched to the minimum required patch level.

3. After patching the SAP Kernel in all application servers, both the request modification rules and the parameter icm/HTTP/support_http2 in the SAP Web Dispatcher are no longer necessary and must be reverted.

For ABAP or JAVA systems systems or SAP Content Server behind load balancer / reverse proxy from other vendors:

Note: The workaround of this scenario requires SAP Kernel versions >= 7.53 PL 30 or 7.49 PL >= 410 in the ABAP or Java system.
The workaround cannot be implemented in configurations where profile parameter icm/HTTP/auth_<n> with sub-parameter AUTHFILE is configured.
For SAP Kernel versions 7.49 and 7.53, the following statements must not be present in any icm/HTTP/mod_<n> files: RegRedirectUrl, RegIRedirectUrl, RegGoneURL, RegIGoneURL.

1. The SAP Kernel in all application servers and SAP Content Server has to be patched to the minimum required patch level (in this case steps 2. and 3. are to be omitted) or

the request modification rules have to be configured in the ABAP/JAVA system and SAP Content Server in the file which is defined by parameter icm/HTTP/mod_<x> as described in SAP note 3137885.

2. The SAP Kernel in all application servers and SAP Content Server has to be patched to the minimum required patch level.

3. After patching the SAP Kernel in all application servers and SAP Content Server, the request modification rules are no longer necessary and must be reverted.


You may consider to apply the last one also to directly accessible systems, depending on your risk appetite.

For each scenario, point 1. should be performed as soon as possible.

 

 

Impact of the workaround to AS Java:

By default, http 1.1 keeps connections between client and server alive so that they can be reused for further requests.

In contrast to that, http 1.0 closes connections after each request. With this, each request needs a new 3-way handshake for TLS which adds some overhead.

The parameter wdisp/additional_conn_close=TRUE seems to change the behavior of http 1.1 to close connections after requests with a tampered content-length header. For AS Java, this may create a performance impact for POST requests or cause ephemeral TCP port exhaustion. So please make sure to remove the parameter after patching the SAP Web Dispatcher and the SAP Kernel of all backend systems.