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.
Introduced a new utility class to address the replacement of MalformedInput with \uFFFD's. Also, introduced a new system property "com.ibm.IgnoreMalformedInput". By default the value of this property is false i.e. the MalformedInput will be replaced by \uFFFD's. If customer wishes to revert to the old behaviour of getting the MalformedInput skipped, then the property needs to be set to true. . This defect will be fixed in: 6.0.0 SR9
Reported component name
JAVA CLASS LIBS
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 CLASS LIBS
Fixed component ID
Applicable component levels