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:

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