Yet another one “nothing fixed“:

ESA-2016-069: EMC Documentum WebTop and WebTop Clients Improper Authorization Vulnerability

EMC Identifier: ESA-2016-069

CVE Identifier: CVE-2016-0914

Severity Rating: CVSS v3 Base Score: 5.0 (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L)

Affected products:
* EMC Documentum WebTop 6.8 and 6.8.1
* EMC Documentum Administrator 7.0, 7.1, 7.2
* EMC Documentum TaskSpace 6.7 SP3
* EMC Documentum Capital Projects 1.9 and 1.10

EMC Documentum WebTop and WebTop dependent products contain a fix for improper authorization vulnerability that could potentially be exploited by malicious users to compromise the affected system.
Remote authenticated WebTop and WebTop Client users may gain access to the IAPI/IDQL interface in WebTop without proper authorization. Malicious users could exploit this vulnerability to run IAPI/IDQL commands on the affected systems using their own privilege.

The following product releases contain resolution to this vulnerability:
EMC Documentum WebTop 6.8 Patch 13 and later
* EMC Documentum WebTop 6.8.1 patch 02 and later
* EMC Documentum Administrator 7.2 Patch 13 and later
* EMC Documentum Capital Projects 1.9 Patch 23 and later
* EMC Documentum Capital Projects 1.10 Patch 10 and later



Tomcat 8 vs webtop

Another Friday challenge was a dumb slowness of webtop under tomcat 8 – 80 seconds to get login page:

compare with weblogic:

What is the problem? For some weird reason when webtop is running under tomcat 8 the size of returned content is not in sync with http headers:

i.e. server reports that content size is 20K but the real size is 4K, so browser gets confused:

bash-3.2$ curl -D /dev/stderr 'http://localhost:8080/webtop/wdk/include/locate.js' \
> -H 'Pragma: no-cache' -H 'Accept-Encoding: gzip, deflate, sdch'  \
> -H 'Connection: keep-alive' -H 'Cache-Control: no-cache' --compressed > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: max-age=86400
Accept-Ranges: bytes
ETag: W/"20735-1417517700000"
Last-Modified: Tue, 02 Dec 2014 10:55:00 GMT
Content-Encoding: gzip
Content-Type: application/javascript
Content-Length: 20735
Date: Sat, 26 Sep 2015 10:42:51 GMT

23 20735   23  4948    0     0    246      0  0:01:24  0:00:20  0:01:04     0
curl: (18) transfer closed with 15787 bytes remaining to read

Who is to blame now? I believe EMC thinks ASF broke something in new tomcat, but the real reason is EMC developers do not follow documentation, check example provided by ASF (webapps/examples/WEB-INF/classes/compressionFilters/

} else {
    response.addHeader("Content-Encoding", "gzip");
    response.setContentLength(-1);  // don't use any preset content-length as it will be wrong after gzipping
    gzipstream = new GZIPOutputStream(output);

Indeed, when I put missing calls into com.documentum.web.servlet.ThresholdingDeflateOutputStream#startDeflating everything started working smoothly:

bash-3.2$ curl -D /dev/stderr 'http://localhost:8080/webtop/wdk/include/locate.js' \
> -H 'Pragma: no-cache' -H 'Accept-Encoding: gzip, deflate, sdch'  \
> -H 'Connection: keep-alive' -H 'Cache-Control: no-cache' --compressed > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: max-age=86400
Accept-Ranges: bytes
ETag: W/"20735-1417517700000"
Last-Modified: Tue, 02 Dec 2014 10:55:00 GMT
Content-Encoding: gzip
Content-Type: application/javascript
Transfer-Encoding: chunked
Date: Sat, 26 Sep 2015 11:09:14 GMT

100  4948    0  4948    0     0   362k      0 --:--:-- --:--:-- --:--:--  371k

Security through guessing

About three weeks ago I made a decision to stop posting about security vulnerabilities in Documentum, but on Friday I have faced with amusing behaviour of webtop and I was unable to leave that fact without blogpost. Nine months ago I wrote a post about how EMC fails to read documentation. Actually, I was never considering the ability to read webtop’s configuration files through HTTP requests as vulnerability because I always follow my own best practices and never put environment-specific configuration into web application, unfortunately this point is not obvious for some developers and we may get something like:

What did cause me to write this post? On Friday I was trying to merge some changes implemented in webtop 6.8 to customised webtop 6.7 and I had noticed new weird changes in web.xml:


note, that EMC added “\.xml;” to protect config files from reading:

The problem is EMC still fails to read documentation:

Silent UCF. HowTo

As was promised in previous post, I describe how make webtop customers happy.

What is the problem?

It seems that when Oracle acquired Sun it also acquired a bunch of security issues in JRE, for example, it’s pretty obvious that even if applet is signed by valid certificate it’s not enough to consider it as trusted – benign applet could be potentially used for malicious purposes (for example UCF applet is capable to launch any program on user’s machine, so attacker may exploit this capability). Security measures for this issue are obvious: just bind applet to specific website, and Oracle did it: JAR File Manifest Attributes for Security. Unfortunately these “innovations” are barely suitable for self-hosted applications – URLs vary from customer to customer, which makes it impossible to create applet suitable for every customer, though, I suppose EMC’s customers pay enough support fees to have an ability to request “custom” UCF applet from EMC, “custom” means that only manifest changes are required and such procedure could be easily automated – why do not create special service on customer portal? Instead of doing correct things EMC suggests something weird:

Actually, I double-checked Oracle’s documentation and was unable to find a place where they suggest to delegate security-related questions to business users, I suppose that EMC guys think that some posts in forums/blogs/etc have a status of official documentation, that, in fact, is not surprising: for example, IIG’s director of security prefers to get inspiration from this blog instead of performing code review:

Possible solutions

Anyway, Oracle’s suggestions related to security prompts are:

Though rule sets option is straightforward I do not think that it is helpful due to following reasons:

  • it costs money: “The JAR file must be signed with a valid certificate from a trusted certificate authority”
  • it is dangerous: “The Deployment Rule Set feature is optional and shall only be used internally in an organization with a controlled environment. If a JAR file that contains a rule set is distributed or made available publicly, then the certificate used to sign the rule set will be blacklisted and blocked in Java”, i.e. you risk to loose money spent for your certificate
  • if you already have a “valid certificate from a trusted certificate authority” why do not sign all applets in enterprise? So, this option is more suitable for cases when applets are embedded in hardware devices like KVMs, iLOs, etc and you unable to replace those applets
  • I think the best case for rule sets is enable certain known applets and block all other

Second option costs money too because it requires a “valid certificate from a trusted certificate authority”, but it’s the only disadvantage of this option. So, what did I do to disable all security prompts in previous video? Obviously, at first, we bought code-signing certificate.


Let’s take a look at security prompts raising when UCF applet gets loaded:

  • Java’s standard prompt asking whether user is going to trust applet’s certificate:
  • UCF’s prompt aimed to prevent malicious usage of applet (whitelisting):
  • Java’s prompt about not following security best practices:

For the third option EMC, as we already know, suggests to tick “Do not show this again for this app and web site” checkbox before accepting security warning. Besides the fact that delegating security-related questions to end-users is not a good idea, this options does not work properly. The problem is WDK generates special URLs for applets to prevent them from caching by JRE:

here “19gmgko28” and “98th” parts of URL are just encoded values of last modified time and size of applet file:

-bash-4.1$ stat -c "Last Modified: %Y, size: %s" \
> app/webapps/wp/wdk/system/ucfinit.jar
Last Modified: 1426684797, size: 304049
-bash-4.1$ groovysh
Groovy Shell (2.4.1, JVM: 1.6.0_45)
Type ':help' or ':h' for help.
groovy:000> import com.documentum.web.util.StringUtil
===> com.documentum.web.util.StringUtil
groovy:000> StringUtil.toUnsignedString(1426684797000,5)
===> 19gmgko28
groovy:000> StringUtil.toUnsignedString(304049,5)
===> 98th

Such behaviour of WDK has following disadvantages:

  • redeploying/updating webtop changes last modified time or/and size of applet file
  • in clustered environment it’s expected that applet file has different last modified time on different nodes

also we already know that the cornerstone of UCF troubleshooting is to delete everything related to Java and Documentum, reinstall JRE, press ctrl+alt+reset, etc – these activities obviously wipe user’s settings, it’s clear that ticking “Do not show this again for this app and web site” checkbox is just a temporary workaround, so, we decided to sign applet by our certificate. The procedure is straightforward:

  • edit META-INF/MANIFEST.MF, you should get something like (note Caller-Allowable-Codebase, Application-Library-Allowable-Codebase and Codebase headers):
    Manifest-Version: 1.0
    Built-By: dmadmin
    Application-Name: Documentum
    Created-By: 1.5.0_11-b03 (Sun Microsystems Inc.)
    Copyright: Documentum Inc. 2001, 2004
    Caller-Allowable-Codebase: docum-at-app
    Build-Date: January 17 2015 09:07 PM
    Ant-Version: Apache Ant 1.8.4
    Title: Documentum Client File Selector Applet
    Application-Library-Allowable-Codebase: docum-at-app
    Bundle-Version: 6.7.2220.0231
    Build-Version: 6.7.2220.0231
    Permissions: all-permissions
    Codebase: docum-at-app
  • remove old signature files, i.e. META-INF/DOCUMENT.RSA and META-INF/DOCUMENT.SF
  • run jarsigner to sign applet – do not forget to specify TSA URL

after that applet is ready for deployment in production. What about another two security prompts? I suppose it is obvious that whitelisting capability is now useless because now JRE performs the same checks, below is an example of security notice when applet gets loaded from non-trusted URL:

because of these considerations, I decided to disable whitelisting capability, unfortunately the only option to disable it in UCF is decompile class: methods isHostAllowed(String) and isHostAllowed(String, IHostVerifier) must always return true (I bet it doesn’t worth to mention that after replacing class in applet you must sign applet again).

And finally, to remove the first security prompt I read Deployment Configuration File and Properties article and decided that manipulating by User Level configuration files is not a good idea, but System Level configuration files could be easily distributed among users’ machines in enterprise using various deployment tools, so, I did following (note naming convention of certificate alias):

C:\Windows\system32>md C:\Windows\Sun\Java\Deployment

C:\Windows\system32>cd C:\Windows\Sun\Java\Deployment

C:\Windows\Sun\Java\Deployment>type CON > deployment.config

C:\Windows\Sun\Java\Deployment>type CON >\:\\Windows\\Sun\\Java\\Deployment\\trusted.certs

C:\Windows\Sun\Java\Deployment>keytool.exe -importcert -keystore trusted.certs -file G:\Users\andrey\work\cert.crt -alias deploymentusercert$tsflag$loc=http//docum-at-app:8280##docbase:http//docum-at-app:8280##from:http//docum-at-app:8280
Enter keystore password:
Re-enter new password:


Trust this certificate? [no]:  yes
Certificate was added to keystore

VoilĂ .

Security enhancements in Webtop 6.8

CVE-2014-4637 quote:

Open redirect vulnerability in EMC Documentum Web Development Kit (WDK) before 6.8 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via an unspecified parameter.

Real behaviour of webtop 6.8 (note how it sends login ticket to remote site):

CVE-2014-4636 quote:

Cross-site request forgery (CSRF) vulnerability in EMC Documentum Web Development Kit (WDK) before 6.8 allows remote attackers to hijack the authentication of arbitrary users for requests that perform Docbase operations.

Real behaviour of webtop 6.8: