Back to list
HTTP session poisoning in EMC Documentum WDK-based applications causes arbitrary code execution and privilege elevation
Jul 04 2016 06:22AM
Andrey B. Panfilov (andrew panfilov tel)
Product: Documentum WDK-based applications, all versions
Security impact: high
All EMC Documentum WDK-based applications (Taskspace, Webtop, Documentum Administrator,
EPFM) contain extremely dangerous web component â?? API Tester. The â??API Testerâ? component
wanâ??t designed with security in mind and allows authenticated users to execute arbitrary
code on application server or elevate privileges on underlying Content Server.
Below are the demonstrations of â??API Testerâ? capabilities:
1. Path traversal - authenticated user may upload arbitrary file from application server
to underlying Content Server and then download that file using standard web interface.
The sequence of API commands is following:
setfile,c,l,<path to file on application server>,crtext
2. Arbitrary code execution - authenticated user may craft malicious JSP, upload it into
underlying Content Server using standard web interface and then download that JSP onto
application server filesystem. The sequence of API commands is following:
getfile,c,<object id>,<path to file on application server>
3. Privilege elevation on underlying Content Server - if authenticated user issues
API command with â??__REQUESTED_PROTECTED_ROLES,S,dcs_privileged_usersâ? argument, that
command is executed on underlying Content Server with superuser privileges.
The first attempt to mitigate security issues described above was performed by vendor
in 2014: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0629 - the description
is completely misleading, but the gist of remediation was to limit access to API Tester
component to superusers only. The problem is WDK applications get information about
privileges of authenticated user from HTTP Session, and all WDK applications contain
servlet (/wdk5-appletresultsink) which allows to poison HTTP Session.
I discovered this vulnerability on February 2016 and on June 2016 vendor announced
the remediation for it - https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-0914
(Un)fortunately the fix announced by vendor in CVE-2016-0914 does remediate nothing.
Andrey B. Panfilov
[ reply ]
Copyright 2010, SecurityFocus