Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: TSQLConnection Params Leaves password in the memory which is vulnerable



Permlink Replies: 6 - Last Post: Jul 8, 2017 2:04 AM Last Post By: Peter Below
Guest
TSQLConnection Params Leaves password in the memory which is vulnerable
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 4, 2017 6:18 AM
Hi All,

I am using deIphi 2009. I am securing my password in the memory and decrypt only when required and after that I remove it from memory using ZeroMemory API. All works fine I take the dump of the process and it does not show any plain password. When i connect my application to SQL database I decrypt the password and add as parameter to the TSQLConnection object as

TSQLCOnenction.Params.Add('PASSWORD='MyPasswordPlain');

When connection is established after that I take the dump again and now the dump has password in process memory which is vulnerable and it indicates that it is in the params string. How can I solve this issue does delphi provide any mechanism in new version or this version so that we can pass secure string like .NET has in ADO .NET ? Any help in this context is appreciated.

Regards,
Imtiaz

Peter Below

Posts: 1,227
Registered: 12/16/99
Re: TSQLConnection Params Leaves password in the memory which is vulnerable
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 4, 2017 10:30 AM   in response to: Guest in response to: Guest
Imtiaz Hussain wrote:

Hi All,

I am using deIphi 2009. I am securing my password in the memory and
decrypt only when required and after that I remove it from memory
using ZeroMemory API. All works fine I take the dump of the process
and it does not show any plain password. When i connect my
application to SQL database I decrypt the password and add as
parameter to the TSQLConnection object as

TSQLCOnenction.Params.Add('PASSWORD='MyPasswordPlain');

When connection is established after that I take the dump again and
now the dump has password in process memory which is vulnerable and
it indicates that it is in the params string. How can I solve this
issue


Once the database connection has been established (logon succeeded) you
should be able to overwrite the password element of the Params
collection with some garbage value.


--
Peter Below
TeamB

Guest
Re: TSQLConnection Params Leaves password in the memory which is vulnerable
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 5, 2017 1:04 AM   in response to: Peter Below in response to: Peter Below
Peter Below wrote:
Imtiaz Hussain wrote:

Hi All,

I am using deIphi 2009. I am securing my password in the memory and
decrypt only when required and after that I remove it from memory
using ZeroMemory API. All works fine I take the dump of the process
and it does not show any plain password. When i connect my
application to SQL database I decrypt the password and add as
parameter to the TSQLConnection object as

TSQLCOnenction.Params.Add('PASSWORD='MyPasswordPlain');

When connection is established after that I take the dump again and
now the dump has password in process memory which is vulnerable and
it indicates that it is in the params string. How can I solve this
issue


Once the database connection has been established (logon succeeded) you
should be able to overwrite the password element of the Params
collection with some garbage value.


--
Peter Below
TeamB


I have set the value to some Junk Value using following code after setting the connected property = true

TSQLCOnenction.Connected := True;
TSQLCOnenction.Params.Values['Password'] := 'Some Junk Value';

It reduces the occurrence but still the dump shows Password =MyPasswordPlain. Not sure might be internally delphi database units still hold password or might be delphi creates copy of string instead of overwriting it. Any idea on that?
Peter Below

Posts: 1,227
Registered: 12/16/99
Re: TSQLConnection Params Leaves password in the memory which is vulnerable
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 5, 2017 11:25 PM   in response to: Guest in response to: Guest
Imtiaz Hussain wrote:

Peter Below wrote:
Imtiaz Hussain wrote:

Hi All,

I am using deIphi 2009. I am securing my password in the memory
and decrypt only when required and after that I remove it from
memory using ZeroMemory API. All works fine I take the dump of
the process and it does not show any plain password. When i
connect my application to SQL database I decrypt the password and
add as parameter to the TSQLConnection object as

TSQLCOnenction.Params.Add('PASSWORD='MyPasswordPlain');

When connection is established after that I take the dump again
and now the dump has password in process memory which is
vulnerable and it indicates that it is in the params string. How
can I solve this issue


Once the database connection has been established (logon succeeded)
you should be able to overwrite the password element of the Params
collection with some garbage value.


--
Peter Below
TeamB


I have set the value to some Junk Value using following code after
setting the connected property = true

TSQLCOnenction.Connected := True;
TSQLCOnenction.Params.Values['Password'] := 'Some Junk Value';

It reduces the occurrence but still the dump shows Password
=MyPasswordPlain. Not sure might be internally delphi database units
still hold password or might be delphi creates copy of string instead
of overwriting it. Any idea on that?

Your assignment boils down internally to replacing one string reference
with another one. The old string memory is returned to the memory
manager, but it does not get overwritten with zeros or such.

Unfortunately the only way to get around that is to replace the memory
manager itself with a customized one that does clear memory blocks
returned to it in some way.


--
Peter Below
TeamB

Guest
Re: TSQLConnection Params Leaves password in the memory which is vulnerable
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 6, 2017 6:49 AM   in response to: Peter Below in response to: Peter Below
Peter Below wrote:
Imtiaz Hussain wrote:

Peter Below wrote:
Imtiaz Hussain wrote:

Hi All,

I am using deIphi 2009. I am securing my password in the memory
and decrypt only when required and after that I remove it from
memory using ZeroMemory API. All works fine I take the dump of
the process and it does not show any plain password. When i
connect my application to SQL database I decrypt the password and
add as parameter to the TSQLConnection object as

TSQLCOnenction.Params.Add('PASSWORD='MyPasswordPlain');

When connection is established after that I take the dump again
and now the dump has password in process memory which is
vulnerable and it indicates that it is in the params string. How
can I solve this issue


Once the database connection has been established (logon succeeded)
you should be able to overwrite the password element of the Params
collection with some garbage value.


--
Peter Below
TeamB


I have set the value to some Junk Value using following code after
setting the connected property = true

TSQLCOnenction.Connected := True;
TSQLCOnenction.Params.Values['Password'] := 'Some Junk Value';

It reduces the occurrence but still the dump shows Password
=MyPasswordPlain. Not sure might be internally delphi database units
still hold password or might be delphi creates copy of string instead
of overwriting it. Any idea on that?

Your assignment boils down internally to replacing one string reference
with another one. The old string memory is returned to the memory
manager, but it does not get overwritten with zeros or such.

Unfortunately the only way to get around that is to replace the memory
manager itself with a customized one that does clear memory blocks
returned to it in some way.


--
Peter Below
TeamB


Thanks it means there is no workaround that can be done easily :(
Peter Below

Posts: 1,227
Registered: 12/16/99
Re: TSQLConnection Params Leaves password in the memory which is vulnerable
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 6, 2017 10:51 PM   in response to: Guest in response to: Guest
Imtiaz Hussain wrote:

Your assignment boils down internally to replacing one string
reference with another one. The old string memory is returned to
the memory manager, but it does not get overwritten with zeros or
such.

Unfortunately the only way to get around that is to replace the
memory manager itself with a customized one that does clear memory
blocks returned to it in some way.


--
Peter Below
TeamB


Thanks it means there is no workaround that can be done easily :(

Don't give up so easily :-). The required modification may just be a
few lines of code, not a complete replacement of the memory manager. I
don't have time at the moment but will try to look at it over the
weekend.


--
Peter Below
TeamB

Peter Below

Posts: 1,227
Registered: 12/16/99
Re: TSQLConnection Params Leaves password in the memory which is vulnerable
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 8, 2017 2:04 AM   in response to: Guest in response to: Guest
Imtiaz Hussain wrote:


Thanks it means there is no workaround that can be done easily :(

Depends on how you define "easy". Save the following code to a
ClearMemoryManagerU.pas file and add this unit to your project DPr file
USes clause as the very first unit:

unit ClearMemoryManagerU;

interface

uses system.Types;

implementation

var
LOldFreeMem: function(P: Pointer): Integer;

function ClearFreeMem(P: Pointer): integer;
begin
// we can assume that P will point to at least 8 bytes of memory
PInt64(P)^ := 0;
Result := LOldFreeMem(P);
end;

procedure ReplaceMemoryManager;
var
LMem: TMemoryManagerEx;
begin
GetMemoryManager(LMem);
LOldFreeMem := LMem.FreeMem;
LMem.FreeMem:= ClearFreeMem;
SetMemoryManager(LMem);
end;

initialization
ReplaceMemoryManager;

end.

Unfortunately there seems to be no document way to get the allocated
size of a memory block if you just have the pointer to it, but the
standard memory manager uses a minimum allocated size of 8 bytes, so we
can at least work on that assumption. Anything more would involve use
of implementation details of the memory manager. That is available
(getmem.inc), but I have not taken the time to dive down into the
details there.


--
Peter Below
TeamB

Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02