Skip to main content

Sensitive strings sent using SSL are still visible in Memory Dump of Orbix process

  • May 17, 2013
  • 0 replies
  • 0 views

Summary
Article Number 25970
Environment Orbix 3.x C on Windows
Question/Problem Description An Orbix user may send data such as passwords as plain text over SSL.
SSL will ensure that the packet on the network is encrypted, so no hacking can happen at this point.
If there is a concern that the memory of the client or server process can be dumped to a string, then there is still an issue if the password is passed to Orbix unencrypted.
This article details why this is not an issue in Orbix, but is rather a security concern in the user application.
Clarifying Information
Error Message
Defect/Enhancement Number
Cause
Resolution When a remote call is made to a CORBA service using Orbix a CORBA::Request object is created to invoke the Orbix runtime. This stores the parameters into a CDR (Common Data Representation) encoded buffer. This buffer is then stored internally in Orbix to allow the memory to be reused without any expensive calls to new.

Take an example where an IDL may look like this:

struct logindata {
  char user[4];
  char pass[4];
};
interface bank {
  void login(in logindate user);
  void deposit(in long amount);
};


The C client code to send something like this might look like:

logindata user;
user.user[0] = 'U'; user.user[1] = 'S'; user.user[2] = 'R'; user.user[3] = '\\0'; 
user.pass[0] = 'P'; user.pass[1] = 'W'; user.pass[2] = 'D'; user.user[3] = '\\0'; 
proxy->login(user);


After the login has been called the string PWD will be stored in three seperate areas.
1. In the logindata object created in user code.
2. In the CORBA::Request object created in the Orbix stub code.
3. In the CDR buffer used by Orbix for performance improvement.

A user may clear the data in the logindata object and the CORBA::Request object will be delete so the memory will be marked as free, however the CDR buffer will still have a copy of this string in its buffer pool. It is not possible to clear this.

For this reason if a string is considered sensitive and if the application might be hacked in such a way as its memory would be dumped then the string should never be passed unencrypted to Orbix.
A true secure solution in this case would be for the client to encrypt the string using a private key, which the server could then compare to an unencrypted string using a public key. Such security patterns are outside the scope of Orbix support, but would avoid any possible security attacks as described above.
Workaround
Notes
Attachment
Created date: 20 October 2011
Last Modified: 13 February 2013
Last Published: 12 May 2012
First Published date: 20 October 2011

#Orbix
#KnowledgeDocs