A bit of real security best practice

Actually, this blog is one big best practice security guide, but I have never written about things, which are unknown or subtle for Documentum programmers or administrators. I’m talking about C programming language and Operating System. Though last time I coded in C at 2000 and I can’t say that I used to be a good programmer but I still remember some important things. When working with sensitive data you must follow two widely known rules:

  • disable the creation of dump files
  • use memset (or more secure analogue) to erase sensitive data in memory

It seems that EMC coders know neither setrlimit nor memset.

setrlimit

Instead of disabling the creation of dump files Content Server tries to increase RLIMIT_CORE:

 bin]$ . dm_set_server_env.sh
 bin]$ strace -f ./documentum \
> -docbase_name ssc_dev \
> -security acl \
> -init_file /u01/documentum/cs/dba/config/ssc_dev/server.ini \
> 2>&1 | grep rlimit| grep RLIMIT_CORE
getrlimit(RLIMIT_CORE, {rlim_cur=-4294967296, rlim_max=281474831589136}) = 0
setrlimit(RLIMIT_CORE, {rlim_cur=RLIM_INFINITY, rlim_max=281474831589136}) = 0

On my development server I found following dump files:

find $DM_HOME -name "core.*" -exec file {} \;
./bin/core.18122: ... from './documentum -docbase_name ...'
./bin/core.31925: ... from './documentum -docbase_name ...'
./bin/core.18200: ... from 'dmbasic -f./dm_event_sender.ebs ...'
./bin/core.1419: ... from 'dmbasic -f./dm_event_sender.ebs ...'

Let’s try to figure out what information we can extract from dump files

memset

passwords

Creating user with recognizable password:

API> create,c,dm_user
...
1101fd088002a900
API> set,c,l,user_name
SET> secretuser
...
OK
API> set,c,l,user_login_name
SET> secretuser
...
OK
API> set,c,l,user_password
SET> supersecretpasswordforuser
...
OK
API> set,c,l,user_source
SET> inline password
...
OK
API> save,c,l
...
OK

Connecting by previously created user:

 ~]$ iapi ssc_dev -Usecretuser -Psupersecretpasswordforuser

...

Connected to Documentum Server running Release 6.7.2220.0213  Linux.Oracle
Session id is s0
API> apply,c,,SHOW_SESSIONS
...
q0
API> next,c,q0
...
OK
API> dump,c,q0
...
USER ATTRIBUTES

  root_start                      : 2/21/2015 08:40:33
  root_pid                        : 6365
  shared_mem_id                   : 1839628298
  semaphore_id                    : 1171161113
  session                      [0]: 0101fd088017cd04
  db_session_id                [0]: 291
  typelockdb_session_id        [0]: -1
  tempdb_session_ids           [0]: -1
  pid                          [0]: 8570
  user_name                    [0]: secretuser
  user_authentication          [0]: Password

Acquiring dump of documentum process (pid = 8570):

~]$ gdb -p 8570
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
Copyright (C) 2010 Free Software Foundation, Inc.

...

(gdb) generate-core-file
Saved corefile core.8570
(gdb) q
A debugging session is active.

        Inferior 1 [process 8570] will be detached.

Quit anyway? (y or n) y
Detaching from program: documentum, process 8570

Surprise – Content Server does not erase user’s password from memory after successful authentication (it worth to mention that DFC does not erase users’ passwords too, so accessing heap dumps gives attacker a lot of information):

 ~]$ strings core.8570 | grep supersecret
supersecretpasswordforuser
 ~]$
AEK

Before checking whether dump files contain AEK key we need to get unencrypted key from AEK file:

groovy:000> import com.documentum.fc.client.impl.crypto.*
===> com.documentum.fc.client.impl.crypto.*
groovy:000> cryptoUtil = CryptoUtils.getInstance()
===> com.documentum.fc.client.impl.crypto.CryptoUtils@19d7af3
groovy:000> cryptoUtil.dump()
===> <com.documentum.fc.client.impl.crypto.CryptoUtils@19d7af3 
          m_aek=null 
          m_aekLocation=null 
          m_version=0 
          m_algorithmId=0 
          m_cipherName=null
      >
groovy:000> cryptoUtil.initCrypto()
===> null
groovy:000> cryptoUtil.dump()
===> <com.documentum.fc.client.impl.crypto.CryptoUtils@19d7af3 
           m_aek=javax.crypto.spec.SecretKeySpec@b069a19e 
           m_aekLocation=/u01/documentum/cs/dba/secure/aek.key 
           m_version=1 
           m_algorithmId=1 
           m_cipherName=DESede/CBC/PKCS5Padding
     >
groovy:000> cryptoUtil.m_aek.dump()
===> <javax.crypto.spec.SecretKeySpec@b069a19e 
            key=[120, 103, 74, -27, -48, 25, 92, 
                 -28, 69, -116, -58, -87, 58, 53, 
                 -12, -41, 82, 25, -62, 110, -4, 
                 111, 124, -72] 
            algorithm=DESede
     >
groovy:000>

So the key is “120, 103, 74, -27, -48, 25, 92, -28, 69, -116, -58, -87, 58, 53, -12, -41, 82, 25, -62, 110, -4, 111, 124, -72” or 78674ae5d0195ce4458cc6a93a35f4d75219c26efc6f7cb8 in HEX, now let’s try to find it in dump file:

 ~]$ od -x < core.8570 | grep -A1 -B1 "6778 e54a 19d0"
72076320 d2b8 09bc 0000 0000 0020 0000 0021 0000
72076340 6778 e54a 19d0 e45c 8c45 a9c6 353a d7f4
72076360 1952 6ec2 6ffc b87c d668 09bc 0051 0000
 ~]$

Oops, let’s check old ones:

 ~]$ cd $DM_HOME/bin
 bin]$ od -x < core.18122 | grep -A1 -B1 "6778 e54a 19d0"
4526200 7373 5f63 6562 0065 57f8 09ec 0000 0000
4526220 0020 0000 0021 0000 6778 e54a 19d0 e45c
4526240 8c45 a9c6 353a d7f4 1952 6ec2 6ffc b87c
 bin]$ od -x < core.31925 | grep -A1 -B1 "6778 e54a 19d0"
4526200 7373 5f63 6562 0065 57f8 09ec 0000 0000
4526220 0020 0000 0021 0000 6778 e54a 19d0 e45c
4526240 8c45 a9c6 353a d7f4 1952 6ec2 6ffc b87c
 bin]$

Oops, may best practice help us?

 dba]$ dm_crypto_change_passphrase -newpassphrase 123456

Please wait, this will take a few seconds
Successfully changed passphrase for AEK located at 
     /u01/documentum/cs/dba/secure/aek.key
 dba]$ dm_crypto_boot -passphrase 123456

Please wait, this will take a few seconds..
Setting up the key at location 
    /u01/documentum/cs/dba/secure/aek.key 
    in the shared memory region..
Operation succeeded
 dba]$ ./dm_start_ssc_dev
starting Documentum server for repository: [ssc_dev]
with server log: [/u01/documentum/cs/dba/log/ssc_dev.log]
server pid: 15929
 dba]$ gdb -p 15929
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)

...

(gdb) generate-core-file
Saved corefile core.15929
(gdb) q
A debugging session is active.

        Inferior 1 [process 15929] will be detached.

Quit anyway? (y or n) y
Detaching from program: documentum, process 15929
 dba]$ od -x < core.15929 | grep -A1 -B1 "6778 e54a 19d0"
72077100 0000 0015 e8c8 0926 e878 0926 0021 0000
72077120 6778 e54a 19d0 e45c 8c45 a9c6 353a d7f4
72077140 1952 6ec2 6ffc b87c 0000 0000 0081 0000

Oops…

Conclusion

This is not a good idea to speculate over non-existing best practices đŸ™‚

One thought on “A bit of real security best practice

  1. Pingback: Encryption madness | 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