But! This might not be so easy, as compilers are smart. Last year, I saw an article showing some C code using this method. First a password was stored in a string, used to get some access, then the password was overwritten with spaces, and not used anymore. Or at least, the source code indicated that. However, the compiler noticed that the string had spaces put in it, and then it was no longer used. So, the compiler optimized the assignment to spaces away - it wasn't going to be used anyway.

In Perl, things are even more complex. A string isn't just a sequence of bytes terminated by a NUL with you holding a pointer to it. That sequence of bytes is there, but you aren't holding a pointer to it. I wouldn't know a pure Perl way of making sure that piece of memory gets overwritten. One could dive into the sources, and find a way that guarantees the string gets overwritten, but that may not work in another version anymore. But writing some XS code lets you get to the pointer, and then you can overwrite it.

Abigail

If you overwrite the key with a string of equivilent length then there is no logical reason for Perl to need to change the memory location. In fact you can show that it does not quite simply with Devel::Peek. The PV memory address remains constant.

While there are no guarantees this will work on every version of Perl I don't see why not, and you could easily incorporate this test into the test suite.

Note if you change the equivilent length sting 'gone!' to say $key = 'x' x 20; you WILL see the pointer value change as Perl needs to reallocate memory to fit this string in. If you make this 19 then Perl does not reallocate FWIW. Replacing one X char string with another of N chars appears to work just fine when X == N.

Abigail points out a compiler optimisation issue where the compiler sees that $key will not be used again and optimizes it out. In the test code we do use it (for the Dump and the decrypt call again) Provided you don't mind a warning there would seem to be no way the compiler could optimize out say $key='gone!'; warn $key

use Devel::Peek;

my $str = 'the key is:';
my $key = 'hello';
Dump($key);
decrypt( $str, $key );
$key = 'gone!';
# $key = 'x'x100000;   # a string that won't fit will change PV
Dump($key);
decrypt( $str, $key );

sub decrypt { warn "\nGot @_\n\n" }

__DATA__
SV = PV(0x15d529c) at 0x1a8460c
  REFCNT = 1
  FLAGS = (PADBUSY,PADMY,POK,pPOK)
  PV = 0x1a4a8ac "hello"\0
  CUR = 5
  LEN = 6

Got the key is: hello

SV = PV(0x15d529c) at 0x1a8460c
  REFCNT = 1
  FLAGS = (PADBUSY,PADMY,POK,pPOK)
  PV = 0x1a4a8ac "gone!"\0
  CUR = 5
  LEN = 6

Got the key is: gone!
[download]

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

If you overwrite the key with a string of equivilent length then there is no logical reason for Perl to need to change the memory location. In fact you can show that it does not quite simply with Devel::Peek. The PV memory address remains constant.

While there are no guarantees this will work on every version of Perl I don't see why not, and you could easily incorporate this test into the test suite.

Just as I said, you might be able to decide that overwriting works in a particular version of Perl (although it's far from clear that your example shows it will work in all cases), but there's no guarantee it'll work in a different version of Perl. Nor that your test case is sufficient.

When it comes to security on a level like this, it's a bad mistake to trivialize it with "there is no logical reason for Perl to need to change the memory location" and simple examples. You haven't even started to contemplate how you load the password in a variable in the first place, and how you're going to wipe out all the traces of doing that.

Abigail

Even if the memory address is the same to perl, there is never a guarentee that the OS didn't change the memory location. If that memory location hit the swap file, it would be diffcult to truly get rid of it (unless you're using an encrypted swap file). It should be easy to stop a casual attacker from recovering the key, and stoping a determined attacker should be possible with a little effort if they don't have physical access to the box. If a determined attacker has physical access and you didn't use an encrypted swap file, you're screwed unless you completely destroy the hard drive.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

:(){ :|:&};:

Note: All code is untested, unless otherwise stated

However, the compiler noticed that the string had spaces put in it, and then it was no longer used.

Then the author should have declared the data to be volatile (and in C++ I think you can even do std::string<char volatile>).

If it needs to be that secure there must be a good reason. Don't see why you would have such a desperate need but not the funds to have a dedicated machine that NO ONE else has access to. If it is not worth a dedicated machine it hardly seems likely that the data you ultimately want to protect is that valuable.... You also don't want anyone else to have physical access to the box as this opens up a myriad of possibilities.

Nothing is totally secure, security is all about raising the bar so that the reward is not worth the effort. If you have 'sufficient privileges' or physical access you can probably just read your code/config etc anyway.

What OS are you planning on running this widget on?

What makes perl great is that the programmer doesn't have to worry about all the housekeeping behind the scenes like memory management. But there are some situations - and this is one of them - where you want to do memory management yourself. In this case, you want to ensure that that area of your process's memory is kept *in memory* and not written to the swap partition. You then want to zero it yourself before de-allocating it. None of which you can do in perl.

This is discussed further in the gnupg manual here.

Apparently the current implementation of perl will at least overwrite your string values in memory if you have your password in a scalar and then allocate another string value of exactly the same length to that scalar. However, this behaviour is not guaranteed in future versions. The plain-text password may have also been assigned to other temporary C variables by perl and still be hanging around in memory, and so on, so it's still not safe.

Basically, if you really need to be this paranoid, don't use perl.

Apparently the current implementation of perl will at least overwrite your string values in memory if you have your password in a scalar and then allocate another string value of exactly the same length to that scalar.

Indeed you can demonstrate this. As it happens in the example given the critical point for reallocation of memory seems to be 20 bytes (19 char string + \0) - equal or less than this and the same pointer/memory is used, more than this and a different one will appear from the realloc. Overwriting with the same length string is easy enough though and you can test for the existence of the desired behaviour as shown. If it changes in the future your test suite will pick it.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

The question is, how many professionals are going to want your data?

However, in recent years, car alarms and other anti-theft devices have reached a point where even professionals are starting to be defeated, as such they've resorted to 'car jacking.' What would the equivalent be for a server?

Given how poor physical security is at so many data centres and commercial hosting buildings, there's *already* many cases of people just walking in, unplugging, and walking off with hardware. By the time the admins have taken a couple of minutes to notice that the machine is no longer responding, a few minutes to determine that it is unreachable and not responding to remote power cycling/LoM/whatever, another few minutes to phone the data centre to ask someone to have a look and for that person to get back to them and say "of course it's not responding, there's no such machine" - the machine is out of the building, in the back of a van, and disappeared.

I can attest to that... years ago while sitting around getting all of my belongings searched by guard because I didn't have a permament ID, I watched a man walk out with a handtruck stacked with Cisco gear and 4-5 laptops. Nobody challenged him because it had an ID card on his belt. He put the stuff in a Neon parked at the curb, left the handtruck on the sidewalk and drove away.

I guess it took two weeks for anyone to notice that the stuff was gone...

Don't encrypt the passwords then. One way hash them with MD4, MD5 et al plus a secret string. Don't have the secret string in plaintext anywhere, just hack the C source of one of these modules to append the secret key, compile it and destroy the source! Of course with a decent decompiler you can still see the string so build it on the fly from a number of function calls so the chars are spread all over the source/binary. Throw in some XORs, a few dummy function calls, the odd blind alley, random library calls.....all the usual tricks. Decompile the binary an have a look to make sure the compiler has not undone your good works.

Now even if I extract the secret key I am still faced with the task of brute forcing the password hashes. The only loss is that you can't send users a password reminder, you have to do a reset - but hey if they could remember the old one they would not have needed the reminder!

*nix and even M$ store passwords as hashes not reversibly encrypted strings. It just raises the bar that bit higher.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Ted

Does'nt that mean that everyone with high enough priviledges will be able to see my passphrase in plain text (if they find it) by examining the memory of the perl process?