[closed] Security Vulnerablility NOT resolved by CLM 4.0.6??
Robin Parker (326●3●37●39)
| asked Mar 06 '14, 7:09 a.m.
closed Jan 03 '20, 4:00 a.m. by Krzysztof Kaźmierczyk (7.5k●4●80●103)
Hi all,
I was emailed about a Security Bulletin today: http://www-01.ibm.com/support/docview.wss?uid=swg21664566 If you follow the various links in the Remediation/Fixes section you eventually get to this page: How to block the Install URL from being accessed with CLM I tested our 4.0.5 server using the Verification Testing section of this second page and confirmed that we weren't getting the 403 error. I decided I'd best kick off the upgrade to 4.0.6 process a.s.a.p. I upgraded our test server from 4.0.5 to 4.0.6 and noticed that when I performed the Verification Testing again on the upgraded 4.0.6 server I still wasn't getting the 403 error as expected. Does this mean that in fact the vulnerability exists in 4.0.6 as well? Can anyone else with a 4.0.6 confirm that this is the case for them? I performed the steps in the second page for updating the web.xml files on the upgraded 4.0.6 server and I now get the expected 403 error. I'm just not sure whether that's necessary. Perhaps the web.xml files update is a quick fix and the real fix is already protecting the server? Many Thanks, Robin |
The question has been closed for the following reason: "Current product version is no longer supported." by krzysztofkazmierczyk Jan 03 '20, 4:00 a.m.
Accepted answer
Ralph Schoon (63.4k●3●36●46)
| answered Mar 06 '14, 7:15 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Mar 06 '14, 7:50 a.m.
Robin, my understanding was that the code in the 4.0.6 is fixed to remove the vulnerability. The modification in the web.xml is only a "hot fix" needed to protect other versions of the tool that have the vulnerability and that can not immediately be upgraded to a fixed version. It removes the ability to get to the pages that expose the vulnerability.
So the modification in the web.xml is not required in 4.0.6 as far as I understand it. Robin Parker selected this answer as the correct answer
Comments Ralph is right.
Robin Parker
commented Mar 06 '14, 8:35 a.m.
ok - thanks guys. I guess I got my wires crossed a bit. Given that the test was to go to the url
https://<server>:<port>/<application>/install
and get a blank page if you were vulnerable and a 403 if you were not, I was expecting something other than a blank page with the 4.0.6 version ...
Sterling Ferguson-II
commented Mar 06 '14, 10:16 a.m.
Robin,
I may be reading this wrong as well...
Verification Testing
To ensure the above steps were successful, navigate to the following URL for each application. You should receive a 403 HTTP error. This will either indicate a "Forbidden" error, or "Access is precluded by configuration." https://<server>:<port>/<application>/install
So in 4.0.6, are you supposed to get a blank page or the 403 error?
2
Yes, in 4.0.6 you will see a blank page if you browse to https://<server>:<port>/<application>/install .
The code change is more granular than the workaround. It does not block all requests with a 4.0.3, as the workaround does, but removes the vulnerability.
Ruby
2
The tech note about blocking URLs has been updated to give some more information about the exact vulnerability and the behavior in 4.0.6:.
|