Карточка уязвимости
Характеристики уязвимости
Уровень опасности
Оценка CVSS
Производитель ПО
Наименование ПО
SAP Support Packages
(SAPKB46C49, SAPKB46C50, SAPKB46C51, SAPKB46C52, SAPKB46C53, SAPKB46C54, SAPKB46C55, SAPKB46C56, SAPKB46C57, SAPKB46C58, SAPKB46C59, SAPKB46C60, SAPKB46C61, SAPKB46C62, SAPKB46C63, SAPKB46C64, SAPKB46C65, SAPKB46C66, SAPKB46C67, SAPKB46C68, SAPKB46D37, SAPKB46D38, SAPKB46D39, SAPKB46D40, SAPKB46D41, SAPKB46D42, SAPKB46D43, SAPKB46D44, SAPKB46D45, SAPKB46D46, SAPKB46D47, SAPKB46D48, SAPKB46D49, SAPKB46D50, SAPKB46D51, SAPKB46D52, SAPKB46D53, SAPKB46D54, SAPKB46D55, SAPKB46D56, SAPKB61042, SAPKB61043, SAPKB61044, SAPKB61045, SAPKB61046, SAPKB61047, SAPKB61048, SAPKB61049, SAPKB61050, SAPKB61051, SAPKB61052, SAPKB61053, SAPKB61054, SAPKB61055, SAPKB61056, SAPKB61057, SAPKB61058, SAPKB61059, SAPKB61060, SAPKB61061, SAPKB62010, SAPKB62011, SAPKB62012, SAPKB62013, SAPKB62014, SAPKB62015, SAPKB62016, SAPKB62017, SAPKB62018, SAPKB62019, SAPKB6202, SAPKB62020, SAPKB62021, SAPKB62022, SAPKB62023, SAPKB62024, SAPKB6203, SAPKB62030, SAPKB62032, SAPKB62033, SAPKB62034, SAPKB62035, SAPKB62036, SAPKB62037, SAPKB62038, SAPKB62039, SAPKB6204, SAPKB62041, SAPKB62043, SAPKB62045, SAPKB62046, SAPKB62047, SAPKB62049, SAPKB6205, SAPKB62050, SAPKB62051, SAPKB62052, SAPKB62053, SAPKB62054, SAPKB62055, SAPKB62056, SAPKB62057, SAPKB62058, SAPKB62059, SAPKB6206, SAPKB62060, SAPKB62061, SAPKB62062, SAPKB62063, SAPKB62064, SAPKB62065, SAPKB62066, SAPKB62067, SAPKB62068, SAPKB6207, SAPKB6208, SAPKB6209, SAPKB64010, SAPKB64012, SAPKB64013, SAPKB64014, SAPKB64015, SAPKB64016, SAPKB64017, SAPKB64018, SAPKB64019, SAPKB6402, SAPKB64020, SAPKB64021, SAPKB64022, SAPKB64023, SAPKB64024, SAPKB64025, SAPKB64026, SAPKB64027, SAPKB64028, SAPKB64029, SAPKB6403, SAPKB64030, SAPKB64031, SAPKB6404, SAPKB6405, SAPKB6406, SAPKB6407, SAPKB6408, SAPKB6409, SAPKB46C48, SAPKB46D36, SAPKB61039, SAPKB61040, SAPKB61041, SAPKB62001, SAPKB62004, SAPKB62029, SAPKB62031, SAPKB62040, SAPKB62042, SAPKB62044, SAPKB62048, SAPKB64001, SAPKB64011)
SAP Notes
(508300-106)
Описание
ICM Patch Collection (I)
contains the following changes:
New connections are no longer accepted by the network in a capacity overload situation, but are left in the "listen queue" of the operating system.
All MPI blocks are now released after an ICM crash.
ICM Patch Collection (II)
contains the following changes:
New user-configurable ICM HTTP error templates: See the documentation for the parameter: icm/HTTP/error_templ_path. The help portal (http://help.sap.com)">http://help.sap.com">http://help.sap.com) contains detailed documentation under:
SAP Web Application Server 6.20
mySAP Technology Components -> SAP Web Application Server
-> Client/Server Technology -> SAP Web AS Architecture
-> Components of the SAP Web AS -> ICM -> Error handling by ICM.
Note 617483 was created due to errors in the documentation of the HTTP error templates for 6.20. This note describes the correct definition of error templates.
ICM Patch Collection (III)
contains the following changes:
If large datasets were previously sent by an external partner to the server (for example, during an HTTP upload), the work process may have been occupied and therefore blocked in the application server while the data was being transferred. If large datasets are transferred via a low-speed modem connection, the work process may be terminated because the rdisp/max_wprun_time value was reached. The data transfer is therefore cancelled as a result.
Solution:
The context is automatically rolled from the work process after 15 seconds (the duration can be adjusted using the icm/wp_roll_timeout = <duration in seconds> profile parameter), the work process is free again for other tasks. If the data for the context is then available for processing again (at least 5 MPI buffers - can be configured with the icm/wp_mpi_available parameter), the context will be rolled into a work process again. This will prevent a low-speed data connection from blocking a work process for a long period of time.
ICM Patch Collection (IV)
contains the following changes:
The ICM tries to terminate the long-running program in the back end (work process) if the response can no longer be sent to the client. As a result of some missing plausibility checks, processing another action may be terminated in the work process. This patch corrects this incorrect behavior.
ICM Patch Collection (V)
contains the following changes:
When you use the SAP Web Application Server as an HTTP client, the data transfer may have previously been blocked because there was no longer sufficient MPI memory available (resource bottleneck). The error only occurred with large datasets.
Solution: In the event of a resource bottleneck, the recipient of the data (in this case, the work process) is initiated so that free memory is available again.
Uploading data from the browser to the server through SSL could cause a timeout because the server could not accept any more data.
ICM Patch Collection (VI)
contains the following changes:
Optimization when new connections are accepted
A timeout is no longer generated for sessions that are dealt with in the debugger in the SAP Web Application Server.
ICM Patch Collection (VII)
contains the following changes:
During communication using HTTPS, the last piece of data may be lost because the SSL buffers were not read in full. The error resulted in a communication block followed by a timeout (uploading data via SSL).
During communication with the J2EE server, the incorrect log is transferred for SSL (HTTP instead of HTTPS).
Improved encryption of the session ID
CRM Portal integration: The session ID in the URI overrides the cookie.
Configured services that cannot be bound at startup now appear as inactive in the smicm.
Binding program icmbnd: sockets are now transferred more rapidly to the ICM and the trace entries in "dev_icmbnd" were corrected.
Errors corrected during the acceptance of new connections. The use of icmbnd when connecting a service is a prerequisite for this error. The error appears as follows in the dev_icm trace file:
*** ERROR => NiBufIn: message length 1347375956 exceeds max (8388608)
*** ERROR => HttpParseRequestHeader: illegal method [htst_plg.c 2934]
ICM Patch Collection (VIII)
contains the following changes:
SAP WebDispatcher can now be started as a service on Windows NT.
The same port can now be connected to different IP addresses of a host.
ICM Patch Collection (IX)
contains the following changes:
Different clients (browsers) send additional characters (\r\n = \0d\0a) following a POST request using HTTP 1.1 to the server. These characters caused an error in the ICM:
*** ERROR => illegal characters (0xd) in request - SSL request on wrong port?
This patch ignores additional characters.
ICM Patch Collection (X)
contains the following changes:
Host names that are longer than 32 characters are no longer truncated when transferred to the Message Server.
Supporting several virtual hosts on the same port with SMTP. To allow the correct virtual host to be selected, the IP addresses to which the port is bound must differ from one another. For virtual hosts with HTTP, only the host name must be different (for example, using aliases in the network configuration).
Although the J2EE Server was not active, it was displayed as active in Transaction smicm.
ICM Patch Collection (XI)
contains the following changes:
In the case of outbound requests (SAP Web Application Server as a client), the server may insert an HTTP header with the OK code 100 (continue) before the actual response. This header was previously forwarded to the application server but it does not contain any application-relevant information.
To ensure that all applications do not have to test this special case, these response headers with the OK code 100 are filtered out from the ICM as of Patch Collection XI.
HTTP client requests from a work process that was in the PRIV mode could cause a blockade in this work process.
(Additional technical remark: In the dispatcher, HTTP requests for the ICM could not be transferred from the DIA to the NOWP queue).
ICM Patch Collection (XII)
contains the following changes:
An error with the following warning in dev_icm was eliminated:
IcmHandleOOBData: OOB on 2nd MPI not received
This message that signals in the HTTP-expect header field that it expects a HTTP-100 header is now delivered to a client.
Security has been improved for the trace output.
If the SAP WebDispatcher uses the external "icmbnd" binding program to bind ports, this may result in a blocked process. This error was eliminated.
If you stop/start a SAP Web AS frequently, sockets may disappear in the SAP Web Dispatcher.
With HTTP from the Web AS to an external HTTP/SMTP server, useful error messages are now returned to the initiator if connection errors or timeouts occur.
If the wdisp/ssl_auth parameter was not set in the profile, it could crash with a trace level higher than 1 when you started the SAP Web Dispatcher. This behavior depends on the operating system (the error was detected on SUN).
If a connection cannot be set up from the Web AS to an external partner, the ICM now releases the occupied memory buffer. The client object in the ABAP can now be used again.
As of this patch, the HTTP(S) and SMTP plug-ins are no longer delivered as independent files. Since Release 6.20, the plug-in functions are contained in the icman program. The icm/plugin_<*> parameter is now obsolete for HTTP(S) and SMTP and must no longer be specified.
ICM Patch Collection (XIII)
contains the following changes:
If an ICM or SAP WebDispatcher is dynamically restarted and later completed threads (up to icm/max_threads), sockets were not released again at operating system level. After some time, this could lead to the "Too many open files" runtime error.
If a request using the ICM results in a context (stateful) being generated in the application server but the context information cannot be sent to the client because the client ended the network connection, the context in the application server is now released again.
A large number of initial and inaccessible contexts have been observed in the application server (particularly in the BW/portal environment).
In rare cases, the ICM server cache returned a "304 not modified" HTTP response to the client even though no "if-modified-since" header field was set in the request. This could result in screens missing from the browser.
Input/output optimization under Windows NT for the latent period measurement of the request processing.
ICM Patch Collection (XIV)
contains the following changes:
As of ICM Patch Collection XII (patch level 692), port 0 is unintentionally ignored for outbound requests (particularly for SMTP mails). This patch collection reactivates the original semantics.
Transaction SMICM displays the J2EE server ports for HTTP and HTTPS again in the display for the "Application server status".
ICM Patch Collection (XV)
contains the following changes:
When you use ICM as a dispatcher for the ABAP and J2EE Engine, the ICM may crash if requests are to be forwarded alternately by a client (browser) to the ABAP Engine and the J2EE Engine.
With outbound requests (SAP Web Application Server as a client), problems may occur in the context management of the SAP WebAS (ABAP stack) if the mode was manually deleted after the request was sent and additional requests were sent in a new mode (with the same mode number).
If this error occurs, you may find the following entries in the trace file of the dev_w? work processes:
M ***LOG R13=> ThReceive, no previous return () [thxxhead.c 6303]
M in_ThErrHandle: 1
HTTP chunked responses resulted in errors with the SAP WebDispatcher.
Screens could be missing and objects (larger than 64 KB) could be truncated with HTTP/1.1 using the SAP WebDispatcher.
ICM Patch Collection (XVI)
contains the following changes:
If the client closes the connection to the server before it has received all data, the ICM behaves incorrectly and tries to read data again from the connection that has already been closed. The following entries exist in the trace (dev_icm):
[Thr 1] *** ERROR => IcmHandleNetRead(id=1/1): IcmWriteToConn failed
[Thr 1] *** ERROR => NiRawRead: invalid handle (-1) [nixx_mt.c 410]
[Thr 1] *** ERROR => IcmReadFromConn(id=1/231): read failed (rc = -8)
[Thr 1] *** ERROR => IcmHandleNetRead(id=1/231): IcmReadFromConn failed
ICM errors on Windows IA64 (UNICODE only). The following entries appear in the trace file (dev_icm):
[Thr 1] *** ERROR => IcmWorkerThread: IcmGetNextRequest failed (rc=-1)
The date parser for the "expiry date" cookie is enhanced.
The "SAPHTTP" internal log is no longer permitted in customer systems.
Long-running programs with a context in the back end (stateful requests) can now be cancelled by the client (browser). The application must be adjusted for this purpose (the functions in the BW environment are used).
In the SAP WebDispatcher, closing of the back-end link by the server was not forwarded correctly to the client (browser). Instead, an error page was transferred to the client.
Connection administration for the back-end system in the SAP WebDispatcher is optimized.
ICM Patch Collection (XVII)
contains the following changes:
You can now use SSL to safeguard the certificate transfer from ICM to the J2EE Engine. Refer to the documentation for the icm/HTTP/j2ee_<*> parameter.
Arguments on the command line (for example, the profile name) can now contain blank characters.
The "Expect" HTTP header with the "100-continue" value is now ignored with HTTP/1.0. Since this header is not defined for HTTP/1.0, an error was previously returned to the calling program and the following entries were written into the trace file:
[Thr 1] *** ERROR => HttpParseRequestHeader: 100 continue and Version < HTTP/1.1 [http_plg.c 3263]
The icm/host_name_full profile parameter was ignored by the ICM as of patch level 692 (ICM Patch Collection XII).
You can now only start the SAP WebDispatcher if you specified a profile.
The SAP WebDispatcher is now delivered with the Central Services of SAP Web AS.
If there is a heavy load on the operating system and if the operating system is quickly reassigning socket numbers, the SAP WebDispatcher may exhibit error behavior. In this case, the program goes into an endless loop and only writes trace entries of the following form into the trace file:
[Thr 1] *** ERROR => NiBufSelect: NiISelect (rc=-1) [nibuf_r.c 1762]
[Thr 2] *** ERROR => IcmWatchDogThread: NiSelSelect (rc=-1) [icxxthr.c
Once this error occurs, you must shut down and restart the SAP WebDispatcher. There is no workaround for this error. You require the kernel patch.
ICM Patch Collection (XVIII)
contains the following changes:
In the case of HTTP client requests from SAP Web AS to another HTTP server, chunked responses are not correctly processed by this server. Since the end of the response is not recognized, the client waits until the timeout for more data from the server. This may lead to performance problems.
ICM Patch Collection (XIX)
contains the following changes:
Terminations could occur if HTTP Version 1.1 was used for HTTPS client requests from the SAP Web AS to another HTTP server with certificate authentication. The terminations do not occur with HTTP/1.0.
Errors corrected in the HTTP log handler:
An incorrect format specified in the "icm/HTTP/logging" parameter could cause crashes.
Predefined formats can now be specified as arguments of "LOGFORMAT". By specifying LOGFORMAT=CLF, the system creates a Common Logfile format (default), whereas specifying LOGFORMAT=SAP specifies a format that measures response times in milliseconds ("%t %a %u - \"%r1\" %s %b %L")
When "%r" was specified in the format, the form fields were not displayed.
The following new format specifications are now supported:
%r: Method - Original path of the client with form fields - HTTP version
%r0: Method - Original path of the client with form fields - HTTP version
%r1: Method - Original path of the client without form fields - HTTP version
%r2: Method - Translated path of the client without form fields - HTTP version
%p0: Original path of the client with form fields (= %U)
%p1: Original path of the client without form fields
%p2: Translated path - without parentheses and without form fields (=%f)
%h1: If the HTTP header field is set to "x-forwarded-for", the value of this field is used, otherwise the name of the deleted host is used as with the %h specification.
The log file could become much larger than specified in the MAXSIZEKB value. The initial size of the file was not taken into account if it was attached to an existing log file.
ICM Patch Collection (XX)
contains the following changes:
The ICM now releases blocked threads in SSL actions after 80 seconds.
The search for contexts with external SessionIDs was unreliable.
The SAP WebDispatcher can now use more than 2,048 sockets. The number of sockets can be increased with the icm/max_sockets = n parameter (default 8192). Maximum value is 16384. The maximum value is 16384. Two sockets are required for each link using the SAP WebDispatcher.
When you use the " -auto_restart" option with the SAP WebDispatcher, the watchdog now writes immediately from the start to the "dev_webdisp_watchdog" trace file, while the Webdispatcher process writes to the "dev_webdisp" trace file.
You can now define an error template for dispatching errors of the SAP WebDispatcher. The error type is called "EDISPATCHERR" (see also Note 617483).
The SAP WebDispatcher can now insert the following header fields in HTTP requests:
x-forwarded-for: <IP address or host name of the WebDisp service>
clientprotocol: http or https
These two header fields can be used in the application server to generate absolute URLs.
This function can be activated with the following parameters:
wdisp/add_xforwardedfor_header = 1
wdisp/add_clientprotocol_header = 1
ICM Patch Collection (XXI)
contains the following changes:
When CLF was specified as a HTTP log file format, the specified format fields of a request were not written into the log file.
Specifying SWITCHTF for the HTTP log file handler (icm/HTTP/logging) was only done up to the highest numeric value, that is, up to 24.00 hours for "hour", up to the last day of the month for "day" and up to the December of a calendar year for "month".
The SessionID is also accepted as a format field with the name sapsessionid.
The termination of a current query in the work process is only sent once more. Previously, several Cancel requests could be sent.
ICM Patch Collection (XXII)
contains the following changes:
When you used virtual host names (SAPLOCALHOST) with the application server, the dispatcher could not connect to the ICM.
Following an adjustment for AS/400 in kernel patch 1168, ICM crashes can occur in the HttpPlugInWriteErrorText function.
You can use the icm/HTTP/max_request_size_KB parameter to protect the application server against a denial of service attack with large requests. If the parameter value is not -1, the Internet Communication Manager already checks whether the length (content-length) of the request exceeds the specified parameter value. If this is the case, the request is not transferred to the application server, instead an error message is returned to the caller (ICMEPROTERROR). The parameter is valid for HTTP and HTTP using SSL (HTTPS) and is also observed by the SAP WebDispatcher.
This patch eliminates various problematic areas in relation to cross site scripting attacks (XSS) in the ICM and SAP WebDispatcher.
The file access handler and the handler for generating error messages are affected.
ICM Patch Collection (XXIII)
contains the following changes:
Previously, a thread waited up to 2000 ms for a follow-up request (on HTTP/1.1, for example) and was blocked during this time. If there is a heavy load on the server, this is very unfavorable. On HTTP/1.1, the thread is only occupied if a follow-up request already exists.
The error with the text: "ERROR => IcmServDecrRefCount: serv_ref_count is 0, but deleted flag not set" has been corrected.
The following errors were eliminated during communication with the J2EE Engine:
The dev_icm trace file contains the entries: "ERROR getbuf failed: -15"
The ICM may crash during fragmentation of the HTTP request. You may also find the following entries in the dev_icm trace file: *** ERROR => CM is not open
You can no longer use the previously used threads (1-n) after you restart the SAP WebDispatcher (started with the -auto_restart option).
The FileAccess and Redirect Handler were deactivated in the Web Dispatcher; that is, the icm/file_access_<*> and icm_redirect_<*> parameters were ignored in the Web Disp.
ICM Patch Collection (XXIV)
contains the following changes:
This patch collection corrects two errors that caused the ICM or Web Dispatcher to crash with incorrect HTTP requests. This error is security-related, since it can be used for an HTTP attack.
When you use icmbnd on UNIX with root authorizations, files with /tmp/.sapstream<pid> names are created in the /tmp directory. These belonged to the root owner and could not be deleted by <sid>adm. As of this patch, the files are created for the <sid>adm user.
With a large load on the application server, HTTP requests may hang, since the context was not rolled again onto a work process. The requests then run into a timeout.
With the SSL re-encryption of requests in the Web Dispatcher, connections were not released. The trace file contains the following entry:
*** ERROR => IcmConnPoolReleaseEntry: entry 0038A360 not from specified pool 0036E420 [icxxpool.c 980]
Changes in the kernel layer of the Internet Communication Framework (see note 682778):
Improved load-balancing statistics
Correct load-balancing in J2EE-only environments
Errors in the parsing and re-serialization of cookies and multipart documents
ICM Patch Collection (XXV)
contains the following changes:
Very high HTTP loads could result in the work process being blocked. This error was corrected by improving the synchronization between ICM and work process.
Very large client requests (more than 50 MB) from the SAP WebAS to a HTTP server could result in the work process being blocked. In this context, the last entry in the dev_icm trace file is:
*** WARNING => Connection request from (tid/uid/0) to host: xxx, service: yyy failed
You can use transaction sm04 to determine tid and uid.
The SAP Web Dispatcher crashed with the "-shm_attach_mode 5" call parameter
Improved use of the connection pool in the SAP Web Dispatcher. In the case of an error following entries can be found :
[Thr 4000] IcmConnPoolNewEntry: upper limit of desc in pool reached (used=50/max=50)
[Thr 4652] IcmIConnPoolAllocEntry: try to create new entry for pool 0223 D6D8
ICM Patch Collection (XXVI)
contains the following changes:
As a client, the ICM now supports the HTTPS proxy authentication.
With a high load, the number of retained TCP connections is reduced for HTTP and HTTPS: If more than 85% of the available connections (icm/max_conn) are being used, the HTTP keepalive is deactivated.
This applies to ICM and SAP Web Dispatcher.
ICM Patch Collection (XXVII)
contains the following changes:
If initial connections to the J2EE Engine could not be opened, this was considered to be a serious error and no requests were sent to the J2EE Engine. Errors that occur during the initial connection setup are ignored as of this patch.
the following error entries appear directly in the dev_icm when you start the J2EE engine:
*** ERROR => IcmReadFromConn: AppServer context already released [icxxth
*** ERROR => IcmHandleNetRead(id=1/2): IcmReadFromConn failed (rc = -1)
This patch corrected these display errors.
The ICM crashes when it is started if the HTTP logging is configured and the trace level is increased, but no value was specified for the LOGFORMAT field for the icm/HTTP/logging_ parameter.
Termination of long-running programs in BW with the "cancel2" opcode
Error corrections in the SAP Web Dispatcher:
In the case of SSL re-encryption, the threads were blocked until the response was received.
Behavior of the wdisp/add_xforwardedfor_header parameter corrected:
The parameter determines whether the IP address of the client is added to the x-forwarded-for header field in the SAP Web Dispatcher. The application in the application server can therefore read the route taken by the request. If the parameter has the value false, the Web Dispatcher leaves the header field unchanged.
If you start the WebDispatcher with the "-auto_restart" option, client requests may already be included again after you restart the WebDispatcher without the instance list and the URL prefixes being updated. With this Support Package, client requests are only included if all the required information is available.
With the wdisp/HTTPS/check_for_stickyness parameter, you can deactivate the monitoring of the client IP table (the default value for the parameter is "TRUE") for the "ROUTER" log (End-to-End SSL). If the value is set to "FALSE", all requests are considered to be stateless and are therefore subject to load balancing.
contains the following changes:
New connections are no longer accepted by the network in a capacity overload situation, but are left in the "listen queue" of the operating system.
All MPI blocks are now released after an ICM crash.
ICM Patch Collection (II)
contains the following changes:
New user-configurable ICM HTTP error templates: See the documentation for the parameter: icm/HTTP/error_templ_path. The help portal (http://help.sap.com)">http://help.sap.com">http://help.sap.com) contains detailed documentation under:
SAP Web Application Server 6.20
mySAP Technology Components -> SAP Web Application Server
-> Client/Server Technology -> SAP Web AS Architecture
-> Components of the SAP Web AS -> ICM -> Error handling by ICM.
Note 617483 was created due to errors in the documentation of the HTTP error templates for 6.20. This note describes the correct definition of error templates.
ICM Patch Collection (III)
contains the following changes:
If large datasets were previously sent by an external partner to the server (for example, during an HTTP upload), the work process may have been occupied and therefore blocked in the application server while the data was being transferred. If large datasets are transferred via a low-speed modem connection, the work process may be terminated because the rdisp/max_wprun_time value was reached. The data transfer is therefore cancelled as a result.
Solution:
The context is automatically rolled from the work process after 15 seconds (the duration can be adjusted using the icm/wp_roll_timeout = <duration in seconds> profile parameter), the work process is free again for other tasks. If the data for the context is then available for processing again (at least 5 MPI buffers - can be configured with the icm/wp_mpi_available parameter), the context will be rolled into a work process again. This will prevent a low-speed data connection from blocking a work process for a long period of time.
ICM Patch Collection (IV)
contains the following changes:
The ICM tries to terminate the long-running program in the back end (work process) if the response can no longer be sent to the client. As a result of some missing plausibility checks, processing another action may be terminated in the work process. This patch corrects this incorrect behavior.
ICM Patch Collection (V)
contains the following changes:
When you use the SAP Web Application Server as an HTTP client, the data transfer may have previously been blocked because there was no longer sufficient MPI memory available (resource bottleneck). The error only occurred with large datasets.
Solution: In the event of a resource bottleneck, the recipient of the data (in this case, the work process) is initiated so that free memory is available again.
Uploading data from the browser to the server through SSL could cause a timeout because the server could not accept any more data.
ICM Patch Collection (VI)
contains the following changes:
Optimization when new connections are accepted
A timeout is no longer generated for sessions that are dealt with in the debugger in the SAP Web Application Server.
ICM Patch Collection (VII)
contains the following changes:
During communication using HTTPS, the last piece of data may be lost because the SSL buffers were not read in full. The error resulted in a communication block followed by a timeout (uploading data via SSL).
During communication with the J2EE server, the incorrect log is transferred for SSL (HTTP instead of HTTPS).
Improved encryption of the session ID
CRM Portal integration: The session ID in the URI overrides the cookie.
Configured services that cannot be bound at startup now appear as inactive in the smicm.
Binding program icmbnd: sockets are now transferred more rapidly to the ICM and the trace entries in "dev_icmbnd" were corrected.
Errors corrected during the acceptance of new connections. The use of icmbnd when connecting a service is a prerequisite for this error. The error appears as follows in the dev_icm trace file:
*** ERROR => NiBufIn: message length 1347375956 exceeds max (8388608)
*** ERROR => HttpParseRequestHeader: illegal method [htst_plg.c 2934]
ICM Patch Collection (VIII)
contains the following changes:
SAP WebDispatcher can now be started as a service on Windows NT.
The same port can now be connected to different IP addresses of a host.
ICM Patch Collection (IX)
contains the following changes:
Different clients (browsers) send additional characters (\r\n = \0d\0a) following a POST request using HTTP 1.1 to the server. These characters caused an error in the ICM:
*** ERROR => illegal characters (0xd) in request - SSL request on wrong port?
This patch ignores additional characters.
ICM Patch Collection (X)
contains the following changes:
Host names that are longer than 32 characters are no longer truncated when transferred to the Message Server.
Supporting several virtual hosts on the same port with SMTP. To allow the correct virtual host to be selected, the IP addresses to which the port is bound must differ from one another. For virtual hosts with HTTP, only the host name must be different (for example, using aliases in the network configuration).
Although the J2EE Server was not active, it was displayed as active in Transaction smicm.
ICM Patch Collection (XI)
contains the following changes:
In the case of outbound requests (SAP Web Application Server as a client), the server may insert an HTTP header with the OK code 100 (continue) before the actual response. This header was previously forwarded to the application server but it does not contain any application-relevant information.
To ensure that all applications do not have to test this special case, these response headers with the OK code 100 are filtered out from the ICM as of Patch Collection XI.
HTTP client requests from a work process that was in the PRIV mode could cause a blockade in this work process.
(Additional technical remark: In the dispatcher, HTTP requests for the ICM could not be transferred from the DIA to the NOWP queue).
ICM Patch Collection (XII)
contains the following changes:
An error with the following warning in dev_icm was eliminated:
IcmHandleOOBData: OOB on 2nd MPI not received
This message that signals in the HTTP-expect header field that it expects a HTTP-100 header is now delivered to a client.
Security has been improved for the trace output.
If the SAP WebDispatcher uses the external "icmbnd" binding program to bind ports, this may result in a blocked process. This error was eliminated.
If you stop/start a SAP Web AS frequently, sockets may disappear in the SAP Web Dispatcher.
With HTTP from the Web AS to an external HTTP/SMTP server, useful error messages are now returned to the initiator if connection errors or timeouts occur.
If the wdisp/ssl_auth parameter was not set in the profile, it could crash with a trace level higher than 1 when you started the SAP Web Dispatcher. This behavior depends on the operating system (the error was detected on SUN).
If a connection cannot be set up from the Web AS to an external partner, the ICM now releases the occupied memory buffer. The client object in the ABAP can now be used again.
As of this patch, the HTTP(S) and SMTP plug-ins are no longer delivered as independent files. Since Release 6.20, the plug-in functions are contained in the icman program. The icm/plugin_<*> parameter is now obsolete for HTTP(S) and SMTP and must no longer be specified.
ICM Patch Collection (XIII)
contains the following changes:
If an ICM or SAP WebDispatcher is dynamically restarted and later completed threads (up to icm/max_threads), sockets were not released again at operating system level. After some time, this could lead to the "Too many open files" runtime error.
If a request using the ICM results in a context (stateful) being generated in the application server but the context information cannot be sent to the client because the client ended the network connection, the context in the application server is now released again.
A large number of initial and inaccessible contexts have been observed in the application server (particularly in the BW/portal environment).
In rare cases, the ICM server cache returned a "304 not modified" HTTP response to the client even though no "if-modified-since" header field was set in the request. This could result in screens missing from the browser.
Input/output optimization under Windows NT for the latent period measurement of the request processing.
ICM Patch Collection (XIV)
contains the following changes:
As of ICM Patch Collection XII (patch level 692), port 0 is unintentionally ignored for outbound requests (particularly for SMTP mails). This patch collection reactivates the original semantics.
Transaction SMICM displays the J2EE server ports for HTTP and HTTPS again in the display for the "Application server status".
ICM Patch Collection (XV)
contains the following changes:
When you use ICM as a dispatcher for the ABAP and J2EE Engine, the ICM may crash if requests are to be forwarded alternately by a client (browser) to the ABAP Engine and the J2EE Engine.
With outbound requests (SAP Web Application Server as a client), problems may occur in the context management of the SAP WebAS (ABAP stack) if the mode was manually deleted after the request was sent and additional requests were sent in a new mode (with the same mode number).
If this error occurs, you may find the following entries in the trace file of the dev_w? work processes:
M ***LOG R13=> ThReceive, no previous return () [thxxhead.c 6303]
M in_ThErrHandle: 1
HTTP chunked responses resulted in errors with the SAP WebDispatcher.
Screens could be missing and objects (larger than 64 KB) could be truncated with HTTP/1.1 using the SAP WebDispatcher.
ICM Patch Collection (XVI)
contains the following changes:
If the client closes the connection to the server before it has received all data, the ICM behaves incorrectly and tries to read data again from the connection that has already been closed. The following entries exist in the trace (dev_icm):
[Thr 1] *** ERROR => IcmHandleNetRead(id=1/1): IcmWriteToConn failed
[Thr 1] *** ERROR => NiRawRead: invalid handle (-1) [nixx_mt.c 410]
[Thr 1] *** ERROR => IcmReadFromConn(id=1/231): read failed (rc = -8)
[Thr 1] *** ERROR => IcmHandleNetRead(id=1/231): IcmReadFromConn failed
ICM errors on Windows IA64 (UNICODE only). The following entries appear in the trace file (dev_icm):
[Thr 1] *** ERROR => IcmWorkerThread: IcmGetNextRequest failed (rc=-1)
The date parser for the "expiry date" cookie is enhanced.
The "SAPHTTP" internal log is no longer permitted in customer systems.
Long-running programs with a context in the back end (stateful requests) can now be cancelled by the client (browser). The application must be adjusted for this purpose (the functions in the BW environment are used).
In the SAP WebDispatcher, closing of the back-end link by the server was not forwarded correctly to the client (browser). Instead, an error page was transferred to the client.
Connection administration for the back-end system in the SAP WebDispatcher is optimized.
ICM Patch Collection (XVII)
contains the following changes:
You can now use SSL to safeguard the certificate transfer from ICM to the J2EE Engine. Refer to the documentation for the icm/HTTP/j2ee_<*> parameter.
Arguments on the command line (for example, the profile name) can now contain blank characters.
The "Expect" HTTP header with the "100-continue" value is now ignored with HTTP/1.0. Since this header is not defined for HTTP/1.0, an error was previously returned to the calling program and the following entries were written into the trace file:
[Thr 1] *** ERROR => HttpParseRequestHeader: 100 continue and Version < HTTP/1.1 [http_plg.c 3263]
The icm/host_name_full profile parameter was ignored by the ICM as of patch level 692 (ICM Patch Collection XII).
You can now only start the SAP WebDispatcher if you specified a profile.
The SAP WebDispatcher is now delivered with the Central Services of SAP Web AS.
If there is a heavy load on the operating system and if the operating system is quickly reassigning socket numbers, the SAP WebDispatcher may exhibit error behavior. In this case, the program goes into an endless loop and only writes trace entries of the following form into the trace file:
[Thr 1] *** ERROR => NiBufSelect: NiISelect (rc=-1) [nibuf_r.c 1762]
[Thr 2] *** ERROR => IcmWatchDogThread: NiSelSelect (rc=-1) [icxxthr.c
Once this error occurs, you must shut down and restart the SAP WebDispatcher. There is no workaround for this error. You require the kernel patch.
ICM Patch Collection (XVIII)
contains the following changes:
In the case of HTTP client requests from SAP Web AS to another HTTP server, chunked responses are not correctly processed by this server. Since the end of the response is not recognized, the client waits until the timeout for more data from the server. This may lead to performance problems.
ICM Patch Collection (XIX)
contains the following changes:
Terminations could occur if HTTP Version 1.1 was used for HTTPS client requests from the SAP Web AS to another HTTP server with certificate authentication. The terminations do not occur with HTTP/1.0.
Errors corrected in the HTTP log handler:
An incorrect format specified in the "icm/HTTP/logging" parameter could cause crashes.
Predefined formats can now be specified as arguments of "LOGFORMAT". By specifying LOGFORMAT=CLF, the system creates a Common Logfile format (default), whereas specifying LOGFORMAT=SAP specifies a format that measures response times in milliseconds ("%t %a %u - \"%r1\" %s %b %L")
When "%r" was specified in the format, the form fields were not displayed.
The following new format specifications are now supported:
%r: Method - Original path of the client with form fields - HTTP version
%r0: Method - Original path of the client with form fields - HTTP version
%r1: Method - Original path of the client without form fields - HTTP version
%r2: Method - Translated path of the client without form fields - HTTP version
%p0: Original path of the client with form fields (= %U)
%p1: Original path of the client without form fields
%p2: Translated path - without parentheses and without form fields (=%f)
%h1: If the HTTP header field is set to "x-forwarded-for", the value of this field is used, otherwise the name of the deleted host is used as with the %h specification.
The log file could become much larger than specified in the MAXSIZEKB value. The initial size of the file was not taken into account if it was attached to an existing log file.
ICM Patch Collection (XX)
contains the following changes:
The ICM now releases blocked threads in SSL actions after 80 seconds.
The search for contexts with external SessionIDs was unreliable.
The SAP WebDispatcher can now use more than 2,048 sockets. The number of sockets can be increased with the icm/max_sockets = n parameter (default 8192). Maximum value is 16384. The maximum value is 16384. Two sockets are required for each link using the SAP WebDispatcher.
When you use the " -auto_restart" option with the SAP WebDispatcher, the watchdog now writes immediately from the start to the "dev_webdisp_watchdog" trace file, while the Webdispatcher process writes to the "dev_webdisp" trace file.
You can now define an error template for dispatching errors of the SAP WebDispatcher. The error type is called "EDISPATCHERR" (see also Note 617483).
The SAP WebDispatcher can now insert the following header fields in HTTP requests:
x-forwarded-for: <IP address or host name of the WebDisp service>
clientprotocol: http or https
These two header fields can be used in the application server to generate absolute URLs.
This function can be activated with the following parameters:
wdisp/add_xforwardedfor_header = 1
wdisp/add_clientprotocol_header = 1
ICM Patch Collection (XXI)
contains the following changes:
When CLF was specified as a HTTP log file format, the specified format fields of a request were not written into the log file.
Specifying SWITCHTF for the HTTP log file handler (icm/HTTP/logging) was only done up to the highest numeric value, that is, up to 24.00 hours for "hour", up to the last day of the month for "day" and up to the December of a calendar year for "month".
The SessionID is also accepted as a format field with the name sapsessionid.
The termination of a current query in the work process is only sent once more. Previously, several Cancel requests could be sent.
ICM Patch Collection (XXII)
contains the following changes:
When you used virtual host names (SAPLOCALHOST) with the application server, the dispatcher could not connect to the ICM.
Following an adjustment for AS/400 in kernel patch 1168, ICM crashes can occur in the HttpPlugInWriteErrorText function.
You can use the icm/HTTP/max_request_size_KB parameter to protect the application server against a denial of service attack with large requests. If the parameter value is not -1, the Internet Communication Manager already checks whether the length (content-length) of the request exceeds the specified parameter value. If this is the case, the request is not transferred to the application server, instead an error message is returned to the caller (ICMEPROTERROR). The parameter is valid for HTTP and HTTP using SSL (HTTPS) and is also observed by the SAP WebDispatcher.
This patch eliminates various problematic areas in relation to cross site scripting attacks (XSS) in the ICM and SAP WebDispatcher.
The file access handler and the handler for generating error messages are affected.
ICM Patch Collection (XXIII)
contains the following changes:
Previously, a thread waited up to 2000 ms for a follow-up request (on HTTP/1.1, for example) and was blocked during this time. If there is a heavy load on the server, this is very unfavorable. On HTTP/1.1, the thread is only occupied if a follow-up request already exists.
The error with the text: "ERROR => IcmServDecrRefCount: serv_ref_count is 0, but deleted flag not set" has been corrected.
The following errors were eliminated during communication with the J2EE Engine:
The dev_icm trace file contains the entries: "ERROR getbuf failed: -15"
The ICM may crash during fragmentation of the HTTP request. You may also find the following entries in the dev_icm trace file: *** ERROR => CM is not open
You can no longer use the previously used threads (1-n) after you restart the SAP WebDispatcher (started with the -auto_restart option).
The FileAccess and Redirect Handler were deactivated in the Web Dispatcher; that is, the icm/file_access_<*> and icm_redirect_<*> parameters were ignored in the Web Disp.
ICM Patch Collection (XXIV)
contains the following changes:
This patch collection corrects two errors that caused the ICM or Web Dispatcher to crash with incorrect HTTP requests. This error is security-related, since it can be used for an HTTP attack.
When you use icmbnd on UNIX with root authorizations, files with /tmp/.sapstream<pid> names are created in the /tmp directory. These belonged to the root owner and could not be deleted by <sid>adm. As of this patch, the files are created for the <sid>adm user.
With a large load on the application server, HTTP requests may hang, since the context was not rolled again onto a work process. The requests then run into a timeout.
With the SSL re-encryption of requests in the Web Dispatcher, connections were not released. The trace file contains the following entry:
*** ERROR => IcmConnPoolReleaseEntry: entry 0038A360 not from specified pool 0036E420 [icxxpool.c 980]
Changes in the kernel layer of the Internet Communication Framework (see note 682778):
Improved load-balancing statistics
Correct load-balancing in J2EE-only environments
Errors in the parsing and re-serialization of cookies and multipart documents
ICM Patch Collection (XXV)
contains the following changes:
Very high HTTP loads could result in the work process being blocked. This error was corrected by improving the synchronization between ICM and work process.
Very large client requests (more than 50 MB) from the SAP WebAS to a HTTP server could result in the work process being blocked. In this context, the last entry in the dev_icm trace file is:
*** WARNING => Connection request from (tid/uid/0) to host: xxx, service: yyy failed
You can use transaction sm04 to determine tid and uid.
The SAP Web Dispatcher crashed with the "-shm_attach_mode 5" call parameter
Improved use of the connection pool in the SAP Web Dispatcher. In the case of an error following entries can be found :
[Thr 4000] IcmConnPoolNewEntry: upper limit of desc in pool reached (used=50/max=50)
[Thr 4652] IcmIConnPoolAllocEntry: try to create new entry for pool 0223 D6D8
ICM Patch Collection (XXVI)
contains the following changes:
As a client, the ICM now supports the HTTPS proxy authentication.
With a high load, the number of retained TCP connections is reduced for HTTP and HTTPS: If more than 85% of the available connections (icm/max_conn) are being used, the HTTP keepalive is deactivated.
This applies to ICM and SAP Web Dispatcher.
ICM Patch Collection (XXVII)
contains the following changes:
If initial connections to the J2EE Engine could not be opened, this was considered to be a serious error and no requests were sent to the J2EE Engine. Errors that occur during the initial connection setup are ignored as of this patch.
the following error entries appear directly in the dev_icm when you start the J2EE engine:
*** ERROR => IcmReadFromConn: AppServer context already released [icxxth
*** ERROR => IcmHandleNetRead(id=1/2): IcmReadFromConn failed (rc = -1)
This patch corrected these display errors.
The ICM crashes when it is started if the HTTP logging is configured and the trace level is increased, but no value was specified for the LOGFORMAT field for the icm/HTTP/logging_ parameter.
Termination of long-running programs in BW with the "cancel2" opcode
Error corrections in the SAP Web Dispatcher:
In the case of SSL re-encryption, the threads were blocked until the response was received.
Behavior of the wdisp/add_xforwardedfor_header parameter corrected:
The parameter determines whether the IP address of the client is added to the x-forwarded-for header field in the SAP Web Dispatcher. The application in the application server can therefore read the route taken by the request. If the parameter has the value false, the Web Dispatcher leaves the header field unchanged.
If you start the WebDispatcher with the "-auto_restart" option, client requests may already be included again after you restart the WebDispatcher without the instance list and the URL prefixes being updated. With this Support Package, client requests are only included if all the required information is available.
With the wdisp/HTTPS/check_for_stickyness parameter, you can deactivate the monitoring of the client IP table (the default value for the parameter is "TRUE") for the "ROUTER" log (End-to-End SSL). If the value is set to "FALSE", all requests are considered to be stateless and are therefore subject to load balancing.
Как исправить
The patch collections are contained in Release 6.20 as of the following kernel patch levels:
I: kernel patch level 23
II: kernel patch level 75
III: kernel patch level 114
IV: kernel patch level 125
V: kernel patch level 192
VI: kernel patch level 251
VII: kernel patch level 348
VIII: kernel patch level 414
IX: kernel patch level 502
X: kernel patch level 542
XI: kernel patch level 652
XII: kernel patch level 692
XIII: kernel patch level 745
XIV: kernel patch level 759
XV: kernel patch level 822
XVI: kernel patch level 850
XVII: kernel patch level 897
XVIII: kernel patch level 937
XIX: kernel patch level 1001
XX: kernel patch level 1081
XXI: kernel patch level 1118
XXII: kernel patch level 1188
XXIII: kernel patch level 1232
XXIV: kernel patch level 1253
XXV: kernel patch level 1367
XXVI: kernel patch level 1410
XXVII: kernel patch level 1502 (refer to note above!)
XXVIII: kernel patch level 1602
XXIX: kernel patch level 1624
XXX: kernel patch level 1673
XXXI: kernel patch level 1754
XXXII: kernel patch level 1786
XXXIII: kernel patch level 1812
I: kernel patch level 23
II: kernel patch level 75
III: kernel patch level 114
IV: kernel patch level 125
V: kernel patch level 192
VI: kernel patch level 251
VII: kernel patch level 348
VIII: kernel patch level 414
IX: kernel patch level 502
X: kernel patch level 542
XI: kernel patch level 652
XII: kernel patch level 692
XIII: kernel patch level 745
XIV: kernel patch level 759
XV: kernel patch level 822
XVI: kernel patch level 850
XVII: kernel patch level 897
XVIII: kernel patch level 937
XIX: kernel patch level 1001
XX: kernel patch level 1081
XXI: kernel patch level 1118
XXII: kernel patch level 1188
XXIII: kernel patch level 1232
XXIV: kernel patch level 1253
XXV: kernel patch level 1367
XXVI: kernel patch level 1410
XXVII: kernel patch level 1502 (refer to note above!)
XXVIII: kernel patch level 1602
XXIX: kernel patch level 1624
XXX: kernel patch level 1673
XXXI: kernel patch level 1754
XXXII: kernel patch level 1786
XXXIII: kernel patch level 1812
Ссылки
