perlsec manual states: > Laundering data using regular expression is the _only_ mechanism for > untainting dirty data, [...] However dev-lang/perl-5.12.2-r6 clears tainted flag even after lc() and uc() perl functions: $ perl -Te 'use Scalar::Util qw(tainted); printf("%d %d %d\n", tainted($0), tainted(lc($0)), tainted(uc($0)));' 1 0 0 This has been recognized by upstream as a security regression and fixed in forthcoming perl-5.14 (http://rt.perl.org/rt3/Public/Bug/Display.html?id=87336). All versions since 5.10 are affected. CVE-2011-1487 has been assigned (http://www.openwall.com/lists/oss-security/2011/04/04/35).
(In reply to comment #0) > > This has been recognized by upstream as a security regression and fixed in > forthcoming perl-5.14 > (http://rt.perl.org/rt3/Public/Bug/Display.html?id=87336). > Thank you for the report, Petr.
Fixed in dev-lang/perl-5.12.3-r1 which could be stabilized.
(In reply to comment #2) > Fixed in dev-lang/perl-5.12.3-r1 which could be stabilized. Great, thank you. Arches, please test and mark stable: =dev-lang/perl-5.12.3-r1 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
works here. amd64 ok
ppc/ppc64 stable
x86 stable
amd64 stable
Stable for HPPA.
Stable on alpha.
arm/ia64/m68k/s390/sh/sparc stable
Thanks, folks. Added to existing GLSA request.
CVE-2011-1487 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1487): The (1) lc, (2) lcfirst, (3) uc, and (4) ucfirst functions in Perl 5.10.x, 5.11.x, and 5.12.x through 5.12.3, and 5.13.x through 5.13.11, do not apply the taint attribute to the return value upon processing tainted input, which might allow context-dependent attackers to bypass the taint protection mechanism via a crafted string.
This issue was resolved and addressed in GLSA 201311-17 at http://security.gentoo.org/glsa/glsa-201311-17.xml by GLSA coordinator Sergey Popov (pinkbyte).
