Note 1800603 was updated by note 2074889 in November 2014.
Topics:
SAP published two HotNews security notes about the kernel in February 2013.
Note 1785761 - Missing authorization check in RFC
CVSS Base Score: 9.0
CVSS Base Vector: AV:N/AC:L/AU:S/C:C/I:C/A:C
Note 1800603 - Potential remote code execution in Message Server
CVSS Base Score: 10.0
CVSS Base Vector: AV:N/AC:L/AU:N/C:C/I:C/A:C
This note 1800603 was updated by note 2074889 in November 2014.
This documentations shows best-practices about preparing and implementing the corrections.
Stay tuned to receives updates as we are going to extend this document from time to time.
Please register yourself as security contact for your organization in the SAP Service Marketplace database.
https://service.sap.com/securitycontacts
As such SAP knows that you are a dedicated contact for security-related news and you will receive Ad-hoc SAP Product Security Notifications. Those are send out for very important security-related news.
There are two ways of registering yourself as security contact:
SAP Super Administrators can remove their security contact role once they nominate another user as security contact.
You can cover both notes by upgrading the Kernel (disp+work and msg_server) at least to following patch levels:
SAP KERNEL 7.20 patch 402 620
SAP KERNEL 7.21 patch 42 318
SAP KERNEL 7.38 patch 7
SAP KERNEL 8.04 patch 27
Keep in mind that both system types, ABAP and Java, contain a message server and are therefore affected.
If you are still running a kernel or message server on release 7.00, 7.01, 7.10, or 7.11 SAP strongly recommend to upgrade the kernel to release 7.20. Note 1636252 describes how to install the downward-compatible kernel:
Note 1636252 Installing a 7.20 kernel in SAP Web AS 7.00/7.01/7.10/7.11
Use document "Rolling Kernel Switch - Updating the SAP Kernel Without System Downtime" to reduce downtime.
Older release up and including 6.40 are not affected by the issue.
SAP treats this vulnerability as very critical (CVSS Base Score = 10, Priority = HotNews) mainly because of the following:
To solve the issue it is sufficient to update the message server file msg_server.exe (Windows) respective msg_server (others) !
Keep in mind that both system types, ABAP and Java, contain a message server and are therefore affected.
It does not matter which path (via ABAP or via Java) you follow on the Service Marketplace (http://service.sap.com/swdc) to find the patch file SAPEXE.SAR containing the message server. Just check to get the right version (for release 7.20: patch >= 402 620).
Here is an example for the direct link for ABAP:
-> … ->
SAPEXE_700-10007259.SAR Kernel Part I (for Basis 720/702)
The info file should show the notes:
[...]
( 0.401) VMC: check shared GC number during cloning (note 1793845)
( 0.401) ALV Gridview: signal 8, division by zero (note 1807939)
( 0.402) Potential remote code execution in Message Server (note 1800603)
( 0.402) Rolling Kernel Switch: endless loop in message server (note 1810932)
[...]
( 0.620) Potential remote code execution in Message Server (note 1800603) (*)
[...]
(*) This line might be missing, therefore validate the result after applying the patch using transaction SMMS as described below.
You can use the message server from 7.20 for a system with a kernel running on 7.00, 7.01, 7.10, or 7.11, however, although this will work from a technical point of view it is not officially supported by SAP.
If you just update the message server keeping the main part of the kernel, the application System Recommendations will keep on showing an alert for ABAP systems concerning note 1800603 or 2074889. Unfortunately the application System Recommendations can only check the patch of the main part of the kernel (disp+work) but not the patch of the message server (msg_server). The tool simply assumes, that both parts are on the same level.
Show patch level of main part of Kernel (disp+work):
Transaction SM51 -> Goto -> Server Name -> Information -> Release Notes
Another option is to execute disp+work.exe -v on operation system level (or in report RSBDCOS0).
Show patch level of Message Server (msg_server):
Transaction SMMS -> -> Goto -> Release Notes
Another options are to submit report RSMONREL_ALV or to execute msg_server.exe -v on operation system level (or in report RSBDCOS0).
Result on a system running the Kernel on release 7.20:
patch comments
[...]
( 25) ( 0.324) Message server crash (note 1782391)
( 26) ( 0.410) Potential remote code execution in Message Server (note 1800603)
( 27) ( 0.413) Rolling Kernel Switch: endless loop in message server (note 1810932)
( 28) ( 0.418) Potential denial of service in message server (note 1822472)
[...]
( 39) ( 0.618) Rdisp/TRACE_RESOLUTION in message server (note 2034177)
( 40) ( 0.620) MS: correct reading of SSL-Daten when reading fragmented (note 2036751)
( 41) ( 0.620) Potential remote code execution in Message Server (note 1800603)
( 42) ( 0.710) Potential denial of service in Message Server (note 1851789)
[...]
Show patch level of Gateway (not relevant here, just to be complete):
Transaction SMGW -> Goto -> Release Notes
SAP treats this vulnerability as very critical (CVSS Base Score = 9, Priority = HotNews) mainly because of the following:
A system is only affected if the ABAP software component SAP_BASIS has release 7.00 or 7.01 and the kernel (disp+work) runs on 7.20 or 7.21.
There is no workaround: To solve the issue you have to update the kernel.
The correction restores the normal authorization check for remote access based on authorization object S_RFC.
The note is mainly important if you have implemented a strong authorization concept concerning S_RFC – which is strongly recommended by SAP.
On the other hand: If you have been lazy concerning S_RFC in the past, e.g. if all or most employees have full access anyway (S_RFC with FUGR=*), that you first should do your homework on the authorization concept.
SAP recommends careful testing of RFC scenarios because the following could have happened: Let’s assume you are using the affected combination of ABAP and kernel for while now. If you have implemented new RFC scenarios in the meantime, this could mean that you don’t have provided proper authorizations for S_RFC without noticing it. With the upgrade of the kernel these remote scenarios could fail.
You find more information about RFC security in the next chapter including tips and tricks how to use the workload statistics to analyze RFC calls before (to validate the authorizations for S_RFC) and after the upgrade of the kernel.
Remote access via RFC is controlled by authorization object S_RFC on the server side and by authorization object S_ICF on the client side (if this is an ABAP system).
In addition to the normal usage of stored credentials (userid and password) you can use Trusted RFC to get rid of the stored password in some scenarios. Trusted RFC is controlled by authorization object S_RFCACL on the server side.
You can encrypt the communication channel using Secure Network Communication (SNC).
Using Transaction SUIM you can search users (report RSUSR002), roles (report RSUSR070), or profiles (report RSUSR020) having full authorizations concerning authorization object S_RFC.
Enter S_RFC for field "Authorization Object" and use the value #* (which represents authorization field value *) for field "RFC_NAME". Dont use wrong values like * or '*' or #**.
Tipp: If you don't get a result this way you should look out for correction notes about RSUSR002, e.g. note 1654478.
Here is a collection of useful blogs and presentation about securing RFC:
Whitepaper:
Securing Remote Function Calls (RFC) (November 2014)
Online help:
Creating an Authorization Concept for RFC
Authorization Object S_ICF - Controlling Access to RFC Destinations
Blog:
Securing RFC Connections (2004)
Blog:
How to get RFC call traces to build authorizations for S_RFC for free!
This Blog references to the report ZRFC_STATRECS_SUMMARY which can be used to analyze RFC connections and RFC authorizations.
Presentation from Teched 2012:
SIS264 Securing Remote Access within SAP NetWeaver AS ABAP including SNC and SSL
In addition to the security vulnerability solved by note 1800603 and 2074889 we like to point your attention to the security configuration options of the message servers.
The message server is used for two distinct scenarios:
To prevent unwanted clients pretending to the message server to be application servers, you can use parameter rdisp/msserv_internal as described in note 1421005 "Secure configuration of the message server".
Online help:
Monitoring and Administration of the SAP Message Server
Security Settings for the SAP Message Server
Mit freundlichen Grüßen / Kind regards
Frank Buchholz
Active Global Support - Security Services
mailto:securitycheck@sap.com
Security Optimization Service
https://service.sap.com/sos
Security Patch Process FAQ
https://scn.sap.com/community/security/blog/2012/03/27/security-patch-process-faq
Security Notes
https://service.sap.com/securitynotes
System Recommendations for Security Notes
https://service.sap.com/sysrec
Configuration Validation
http://wiki.sdn.sap.com/wiki/display/TechOps/ConfVal_Home
Community / Forum / Blogs @ SCN
Security
http://scn.sap.com/community/security
Identity Management
http://scn.sap.com/community/netweaver-idm
Governance, Risk, and Compliance
http://scn.sap.com/community/grc
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
5 | |
5 | |
3 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 |