| 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




