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]

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

I was not trivializing it. As you well know Perl is a memory pig and optimized for speed. Part of this optimization is the over allocation of memory for scalars (as the test case shows). In fact Perl over allocates memory for just about all its data types. The reason is simple optimisation. If you don't have to reallocate memory simply to add an extra few bytes to a string, or add an extra element to an array you avoid the memory allocation and copy costs. I can't see a good reason why the gnomes should change this behaviour other than to save memory. I can't see ANY reason why overwriting the value in a scalar with the same number of bytes should EVER change to the situation where Perl is reallocating memory and doing a copy every time. This would be inefficient and is completely unnecessary.

As noted before physically securing the box is to my mind far more important. Just look at the banks for example. How many root kits are there that let you escalate user level privilege to root whereby you can just read the script/config without having to go to the extent of trawling through memory?

package Config;

$key = 'hello';

package Foo;

use Devel::Peek;

my $str = 'the key is:';
Dump($Config::key);
decrypt( $str, $Config::key );

$Config::key = 'x'x19;
Dump($Config::key);
decrypt( $str, $Config::key );

$Config::key = 'x'x20;
Dump($Config::key);
decrypt( $str, $Config::key );

sub decrypt{ warn "Got: @_\n" }

__DATA__
SV = PV(0x15d5284) at 0x1a454a0
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x15dd0ac "hello"\0
  CUR = 5
  LEN = 6
Got: the key is: hello
SV = PV(0x15d5284) at 0x1a454a0
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x15dd0ac "xxxxxxxxxxxxxxxxxxx"\0 <--- Same Pointer == overwrit
+e
  CUR = 19
  LEN = 20
Got: the key is: xxxxxxxxxxxxxxxxxxx
SV = PV(0x15d5284) at 0x1a454a0
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x1a48edc "xxxxxxxxxxxxxxxxxxxx"\0 <--- Reallocation has occurr
+ed
  CUR = 20
  LEN = 21
Got: the key is: xxxxxxxxxxxxxxxxxxxx
[download]

cheers

tachyon

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

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.