IZ80870: REPLACING THE ILLEGAL UTF8 BYTE SEQUENCES WITH \UFFFD.
Closed as program error.
Error Message: Behaviour difference between IBM and Sun while handling the illegal UTF8 byte sequences. In case of IBM,illegal byte sequences used to be skipped while in case of SUN, it use to get replcaed by \uFFFD's. . Stack Trace: N/A . 1. Replacing any character in the url path with a overly long UTF-8 equivalent. If you have a valid page "http://host/ctx/index.html" requesting "http://www/ctx/index%c0%aehtml" will result in the same page. 2. Adding an invalid UTF-8 characters in the url path are encoded to the empty sting. '../index.%c1%bfj%c1%bfs%c1%bfp%c1%bf' will decode this to ".../index.jsp". As per customer, this works with or without the plugin between you and WebSphere. The browser may alter the request so if it doesn't work verify with a sniffer (tcpdump, wireshark) that the url actually sent in the request was correct. The vulnerability is when .JSPs are being secured by filtering. In the examples provided, both urls would make it past filters.
The problem seems to be happening the way our code use to handle the illegal byte sequences. It use to get ignored/skipped whenever the input is MalformedInput.
The feature introduces a new utility class to replace Malformed input with \uFFFD's. . Also, introduced a new system property "com.ibm.IgnoreMalformedInput" to revert back to the old JDK behavior. . By default the value of this property is false i.e. the Malformed input will be replaced by \uFFFD's. . If you wish to revert to the old behaviour of ignoring the malformed input, then the property needs to be set to true. This defect will be fixed in: 5.0.0 SR12
ZE FIX ERROR IV06610 11/10/20
Reported component name
JAVA 5 CLASS LI
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
JAVA 5 CLASS LI
Fixed component ID
Applicable component levels
Translate this page: