CVE-2016-0914

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

Summary:
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.
Details:
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.

Resolution:
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

PoC: https://gist.github.com/andreybpanfilov/785173c085d818c4fbf913075a5ad421

Demo:

Another two D2 remote code executions. Webtop is affected

That was obvious that Apache Commons Collections is not the only vulnerable library, and on this week another two possibilities were disclosed:

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
bash-3.2$

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/CompressionResponseStream.java):

} else {
    response.addHeader("Content-Encoding", "gzip");
    response.setContentLength(-1);  // don't use any preset content-length as it will be wrong after gzipping
    response.setBufferSize(compressionBuffer);
    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