Unfortunately, in most cases “non-popular” means “more buggy” and “less secure” (what do you think about inclusion such products into product stack? Is it a best practice on not?), and Thumbnail Server proves this opinion. Thumbnail Server accepts only two types of URL:

To mitigate attack described previously Thumbnail Server has an option to verify digital signature of passed url parameters (in Installation Guide this feature described in “Providing security for thumbnail requests” paragraph, note that documentation is bit outdated). Unfortunately enabling signature verification does not work properly in recent releases because of the following length requirements: full url must not exceed 300 characters and about 200 characters are required for ticket parameter, which makes described feature unusable: documentation doesn’t forces customers to enable signature verification, but enabling it causes errors in case of long (<10 characters) FQDNs, so, it's very unlikely that customers unable this feature:

The root cause of above error is a fact that when Content Server returns value of thumbnail_url it cuts off value up to 300 characters (?bytes, note DM_OBJECT_W_SET_ATTR_STRING_TOO_LONG warning message in listing). The valid value of ticket parameter in this case should be (200 characters):

Like this:

A method in the Properties service of the D2FS web service component may allow a low privileged D2 user to manipulate group permissions and obtain superuser privileges.

You can find related PoC in Second dive into D2 security. This vulnerability is also mentioned in CERT’sspreadsheet. If you were lucky and were able to download the first version of CERT’s spreadsheet (otherwise you can find it here) you can find following EMC’s comment about this vulnerability:

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.

So, besides that D2 actively uses docbase methods (which is insecure, unreliable, etc) it also does not protect its config objects from editing by regular user – I bet such weird implementation was caused by misleading performance tips from EMC:

What really happened in CVE-2015-0518? EMC fixed a PoC described in Second dive into D2 security, “new” (the previous one just truncated value of node_admin_security_group attribute in d2_options object) PoC is:

Summary
Malicious users could potentially compromise the root encryption key (also called the Application Encryption Key) in EMC Documentum Content Server when Document Content Server best practices are not followed.

Details
The root encryption key (AEK) in EMC Documentum Content Server is encrypted using a passphrase (default or user provided) and stored on the file system with operating system’s ACL protection. If best practices to change the default passphrase were not followed during or after installation, privileged users with access to IAPI/IDQL and file system could retrieve the AEK using the default passphrase and access sensitive application information.
Resolution
All customers are strongly advised to change the default passphrase that is used to encrypt AEK using dm_crypto_change_passphrase and and use dm_crypto_boot utilities at the earliest opportunity. Refer to CS Installation and Administration guides for more details on using these utilities.

Has anybody seen document named “EMC Documentum Content Server Security Best Practices”?