Last Thrursday EMC released the ESA-2016-034 security bulletin. This is related to a Documentum D2 vulnerability (CVE-2016-0888). As reported in the bulletin by EMC:
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.
The severity is high. EMC recommends that all customers should upgrade to D2 4.6 at the earliest opportunity. There is no patch and you have to plan a D2 upgrade to the latest version. The affected versions are all D2 products, from version very old version 3.1 to the more recent version 4.5.
Every upgrade should be planned carefully and you can decide to upgrade your D2 environment later. I strongly advice to complete the D2 upgrade sooner. In next paragraphs I will explain why.
Documentum D2 is an interesting way to create document management applications based on Documentum, just using configurations. D2 is very, very powerful: it provides many configuration points. With these, a business users can create complex document/content management applications just combining configuration points, virtually without to write a single line of code.
My company released some Documentum D2 based applications and we really liked this approach because we configure very complex applications and make our customers satisfied, with a reasonable budget.
The D2 data model, before the version 4.6
One of the easiest ways to learn a new product is to understand how it is implemented. When I started my first Documentum D2 project, I tried to understand the D2 data model and how that works. So, I learned that EMC used a lot of custom object types. I mean, a lot! No wonder: this is a way to work although more than one hundred of custom object types is really a big number!
Most of the D2 and the D2 Plus pack custom object types do not have a supertypeor are not dm_sysobject subtype:
- This is good because this is an easy way to not inherit useless metadata;
- This could be really bad, because instances of a custom object type with no supertype cannot be protected using standard ACL.
To create a new custom object type an authenticated user should have a CREATE TYPE privilege or should be a Sysadmin or a Superuser. Only a superuser can create new custom object types with no supertype.
Apart that, every authenticated user could potentially execute DQL queries and discover important information stored in the instances of a object type with no superytpe. Moreover, any authenticated user can execute arbitrary CREATE OBJECT, UPDATE OBJECT or a DELETE OBJECT statements and change what other users created/modified.
One of the most important D2 object types is the d2_documentset_switch: this is the object type that is used to model the configuration matrix where a Documentum D2 developer defines new D2 applications just using a GUI, the Documentum D2 Config application. With Documentum D2 Config, the D2 developer can modify, change the application behavior, adding or removing functionalities to a group of users or for more detailed D2 contexts.
The d2_documentset_switch is an example of an object type that has no supertype: instances of this object type cannot be protected with an ACL; every authenticated user can update or delete d2_documentset_switch instances. That has a tremendous security impact: with a simple DELETE d2_documentset_switch OBJECT every user can delete your Documentum D2 applications in few milliseconds. Ok, one can argue that if that happens it will be easy to restore D2 configurations (if the developer exported/saved, of course…). But it is not easy to understand if someone completed one or more more insidious UPDATE d2_documentset_switch OBJECT (…).
The d2_documentset_switch object type is just one of the more than 100 D2 object types and most of them have no supertype or are not a dm_sysobject subtype, so here the problem is the same for all those object types.
The new D2 data model
The solution to this vulnerability is just one: the D2 4.6 upgrade. A migration tool provided by EMC will help Documentum administrators to migrate the existing data model to the new one. This upgrade is not exactly cheap but you have to consider it as soon as possible. Until then Documentum D2 administrator have only one choice to mitigate this vulnerability: prevent the DQL queries execution by standard users. That is not impossible and this vulnerability could be a business justification to start and complete a Documentum hardening.
Btw, do you have a copy of all D2 configurations?