It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,830
×10,929
×7,423
×4,706
×4,303
×3,952
×22

question asked: Mar 06 '14, 7:09 a.m.
question was seen: 5,276 times
last updated: Jan 03 '20, 4:00 a.m.

Related questions

[closed] Security Vulnerablility NOT resolved by CLM 4.0.6??

0
Robin Parker (326●3●37●38) | asked Mar 06 '14, 7:09 a.m.
closed Jan 03 '20, 4:00 a.m. by Krzysztof Kaźmierczyk (7.5k●4●79●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

3
permanent link
Ralph Schoon (63.3k●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
Krzysztof Kaźmierczyk commented Mar 06 '14, 7:47 a.m. | edited Mar 06 '14, 7:48 a.m.

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
Martha (Ruby) Andrews commented Mar 06 '14, 12:22 p.m.
JAZZ DEVELOPER

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
Martha (Ruby) Andrews commented Mar 07 '14, 12:23 p.m.
JAZZ DEVELOPER

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:.

The steps outlined in this technote work by completely blocking all access to the vulnerable URL. The actual vulnerability is only exploitable through a POST request, and so the 4.0.6 code fix is more granular and works by causing the system to respond with a 403 response only on a POST to the vulnerable URL. If you issue a GET request to a 4.0.6 system you will receive a blank page in response. If you issue a POST request to a 4.0.6 system you will see the 403 response. There are various tools and browser plug-ins available that can issue a POST request if you wish to verify your 4.0.6 system is secured.