mattr has asked for the wisdom of the Perl Monks concerning the following question:

Does anyone know how secure garbage collection is in perl?

I am specifically thinking of:
1. CGI Environment on shared servers (perl 5.00503/5.6.1/5.8 on linux/freebsd)
2. perl gui app on windows (i.e. wxperl)

Can perl's garbage collection leave sensitive data hanging around in memory long after the program (i.e. CGI environment) has finished execution? If so, would a paranoid DESTROY routine which fills in this data with same-length junk before undefining the object be sufficient to stop that from happening?

I know you can probably snoop on a running program, my question is about after it's been run whether memory or disk might have wrongly persisting copies of variables. Presumably perl depends on the OS to reuse memory?

Consider WinPT, a GPG windows frontend. I'm guessing they have taken care of this issue from the start. But it might be quite difficult to write a simplified frontend in perl since even if you could remove perl variables from memory completely the C-based gui libraries might I suppose be less kind. Looked for memory scanners but just found something for games.

Replies are listed 'Best First'.
Re: security of garbage collection
by Elian (Parson) on Mar 16, 2003 at 15:58 UTC
    Perl, generally speaking, isn't set up to deal with security on quite that level. It will make sure it doesn't expose garbage data in allocated strings and such, but it won't zero out freed memomry or anything of the sort, so... It is definitely possible that XS (or nasty unpack tricks) could dance through a process' own memory and find sensitive stuff.

    The solution to this, if you need it, is to either recompile with perlmalloc and change perl's free call to zero freed memory, or to link against a custom malloc library that did the same thing.

[reply]
Re: security of garbage collection
by jand (Friar) on Mar 16, 2003 at 16:20 UTC
    On Windows you should be more worried about the security of putting a password into a standard edit control. In Windows versions prior to Win2K, any other Windows application could retrieve the password by sending a WM_GETTEXT message to the control.

    It looks like there is a new exploit that will work even with Win2k/XP: Postmessage API security flaw.

[reply]
Re: security of garbage collection
by toma (Vicar) on Mar 16, 2003 at 19:10 UTC
    In linux this it is easy to get at memory if you are the root user, on my machine at least.

    As root: 

    cp /dev/mem /tmp/mem
strings /tmp/mem | grep keyword

    [download]
    This will print all the strings in memory that include the word 'keyword'. It would be easy to create a regular expression to look for credit card numbers or other sensitive data this way.

    As root, you can also change memory with similar techniques. For example, root can change a running copy of any program to make it less secure.

    If someone has a hack to work with memory directly as a regular user, this is probably a hack of sufficient strength to gain root priviledges.

    It should work perfectly the first time! - toma

[reply]
[d/l]
Re: security of garbage collection
by PodMaster (Abbot) on Mar 16, 2003 at 16:42 UTC
    Consider WinPT, a GPG windows frontend. I'm guessing they have taken care of this issue from the start.

    Do you have any concrete information either way? (guessing is not specific enough ;)

    How can one test this? (that is, how can one dump memory to check this out)

    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
    ** The Third rule of perl club is a statement of fact: pod is sexy.

[reply]
      Sorry I do not have any concrete information.

      However, I think I trust gpg and it links to winpt. Also I noticed an old version of winpt used to decrypt a window to itself so its text would automatically become readable. With the latest version installed it seems to only decrypt to the clipboard. The Edit Clipboard dialog has a Clear button. Also the passphrase input prompt does print bullets instead of the letters you type, FWIW.

      Possibly if someone is running virtualpc on a linux box they could scan the memory of the emulated windows machine by grepping /dev/mem as below.

      Thank you all for your thoughts on this.

      I just confirmed that in linux you can read much of the contents of an array after the program has ended, but that filling it with junk works. Well sort of proven it since I think I did find the test string in the source code and interpreted bits.. 

      #!/usr/bin/perl
$a="snoopy";
$x="XXXXXX";
for (0..1000) {
  push(@s,"$a$_ " x 100);
}
exit 0;
for (0..1001) {
  @s[$_] = "$x$_ " x 100);
}
@s = ();

      [download]
      As toma suggests, 
      perl testmem
cp /dev/mem /tmp/mymem
grep -a snoopy /tmp/mymem | more
reset (you will need this)

      [download]
      Of course you should use strings instead, I can't because I am using a half-recovered trashed system to do this, yours should have the strings program.

      Comment out the exit 0 line to test. Haven't tried undef $a but I figure it is similar. You will have to change your test string as your memory gets dirtier the more times you run this. :|

[reply]
[d/l]
[select]
        You're putting your worry in the wrong place. To accomplish what you're concerned about needs having access that has already completely compromised the machine.

        While there are scenarios where this is an issue, you're not working on one of them. (If you were, you wouldn't have to be asking here... :)

[reply]

Back to Seekers of Perl Wisdom