Skip Menu |
 
Report information
Id: 87336
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: mmartinec <Mark.Martinec [at] ijs.si>
Cc:
AdminCc:

Operating System: freebsd
PatchStatus: (no value)
Severity: medium
Type: core
Perl Version: 5.12.3
Fixed In: (no value)



CC: Mark.Martinec [...] ijs.si
Subject: Function lc() is laundering tainted data in newer perls, contrary to docs
Date: Wed, 30 Mar 2011 17:30:45 +0200 (CEST)
To: perlbug [...] perl.org
From: Mark.Martinec [...] ijs.si
This is a bug report for perl from Mark.Martinec@ijs.si, generated with the help of perlbug 1.39 running under perl 5.12.3. ----------------------------------------------------------------- [Please describe your issue here] The current perlsec 5.13 man page still claims that "Laundering data using regular expression is the only mechanism for untainting dirty data", or by "using them as keys in a hash" - yet functions lc() and uc() are unwarrantedly laundering data too. This holds true for v5.10.1, v5.12.3 and v5.13.10; but not for v5.8.8. Example: using perl 5.12.3: $ perl -Te 'use Scalar::Util qw(tainted); $t=$0; $u=lc($t); printf("%d,%d\n",tainted($t),tainted($u))' 1,0 using perl 5.8.8: $ perl -Te 'use Scalar::Util qw(tainted); $t=$0; $u=lc($t); printf("%d,%d\n",tainted($t),tainted($u))' 1,1 [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=medium --- Site configuration information for perl 5.12.3: Configured by mark at Tue Mar 29 22:06:10 CEST 2011. Summary of my perl5 (revision 5 version 12 subversion 3) configuration: Platform: osname=freebsd, osvers=8.2-release, archname=amd64-freebsd uname='freebsd neli.ijs.si 8.2-release freebsd 8.2-release #0: fri feb 25 17:19:30 cet 2011 mark@neli.ijs.si:usrobjusrsrcsysneli amd64 ' config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.12.3/mach -Dprivlib=/usr/local/lib/perl5/5.12.3 -Dman3dir=/usr/local/lib/perl5/5.12.3/perl/man/man3 -Dman1dir=/usr/local/man/man1 -Dsitearch=/usr/local/lib/perl5/site_perl/5.12.3/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.12.3 -Dscriptdir=/usr/local/bin -Dsiteman3dir=/usr/local/lib/perl5/5.12.3/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dcc=cc -Duseshrplib -Dinc_version_list=none -Dccflags=-DAPPLLIB_EXP="/usr/local/lib/perl5/5.12.3/BSDPAN" -Doptimize=-O2 -pipe -fno-strict-aliasing -Ui_gdbm -Dusethreads=n -Dusemymalloc=n -Duse64bitint' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.12.3/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include', optimize='-O2 -pipe -fno-strict-aliasing', cppflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.12.3/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.2.1 20070719 [FreeBSD]', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -Wl,-E -fstack-protector -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lgdbm -lm -lcrypt -lutil perllibs=-lm -lcrypt -lutil libc=, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-R/usr/local/lib/perl5/5.12.3/mach/CORE' cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib -fstack-protector' Locally applied patches: --- @INC for perl 5.12.3: /usr/local/lib/perl5/5.12.3/BSDPAN /usr/local/lib/perl5/site_perl/5.12.3/mach /usr/local/lib/perl5/site_perl/5.12.3 /usr/local/lib/perl5/5.12.3/mach /usr/local/lib/perl5/5.12.3 . --- Environment for perl 5.12.3: HOME=/home/mark LANG (unset) LANGUAGE= LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/kde4/bin/:/usr/local/kde4/sbin:/usr/X11R6/bin PERL_BADLANG (unset) SHELL=/usr/local/bin/bash
Subject: Re: [perl #87336] Function lc() is laundering tainted data in newer perls, contrary to docs
Date: Wed, 30 Mar 2011 20:10:17 -0600
To: perl5-porters [...] perl.org, jesse <jesse [...] fsck.com>
From: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 1.1k
On 03/30/2011 09:31 AM, Mark Martinec (via RT) wrote: Show quoted text
> # New Ticket Created by Mark Martinec > # Please include the string: [perl #87336] > # in the subject line of all future correspondence about this issue. > #<URL: http://rt.perl.org/rt3/Ticket/Display.html?id=87336> > > > This is a bug report for perl from Mark.Martinec@ijs.si, > generated with the help of perlbug 1.39 running under perl 5.12.3. > > > ----------------------------------------------------------------- > [Please describe your issue here] > The current perlsec 5.13 man page still claims that "Laundering data > using regular expression is the only mechanism for untainting dirty > data", or by "using them as keys in a hash" - yet functions lc() and > uc() are unwarrantedly laundering data too. > > This holds true for v5.10.1, v5.12.3 and v5.13.10; > but not for v5.8.8. > > Example: > using perl 5.12.3: > $ perl -Te 'use Scalar::Util qw(tainted); $t=$0; $u=lc($t); printf("%d,%d\n",tainted($t),tainted($u))' > 1,0 > > using perl 5.8.8: > $ perl -Te 'use Scalar::Util qw(tainted); $t=$0; $u=lc($t); printf("%d,%d\n",tainted($t),tainted($u))' > 1,1
Is this security-related issue important enough to be a 5.14 blocker?
CC: perl5-porters [...] perl.org, jesse <jesse [...] fsck.com>
Subject: Re: [perl #87336] Function lc() is laundering tainted data in newer perls, contrary to docs
Date: Thu, 31 Mar 2011 12:42:41 +0200
To: Karl Williamson <public [...] khwilliamson.com>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 1.3k
On 31 March 2011 04:10, Karl Williamson <public@khwilliamson.com> wrote: Show quoted text
> On 03/30/2011 09:31 AM, Mark Martinec (via RT) wrote:
>> >> # New Ticket Created by  Mark Martinec >> # Please include the string:  [perl #87336] >> # in the subject line of all future correspondence about this issue. >> #<URL: http://rt.perl.org/rt3/Ticket/Display.html?id=87336> >> >> >> This is a bug report for perl from Mark.Martinec@ijs.si, >> generated with the help of perlbug 1.39 running under perl 5.12.3. >> >> >> ----------------------------------------------------------------- >> [Please describe your issue here] >> The current perlsec 5.13 man page still claims that "Laundering data >> using regular expression is the only mechanism for untainting dirty >> data", or by "using them as keys in a hash" - yet functions lc() and >> uc() are unwarrantedly laundering data too. >> >> This holds true for v5.10.1, v5.12.3 and v5.13.10; >> but not for v5.8.8. >> >> Example: >> using perl 5.12.3: >> $ perl -Te 'use Scalar::Util qw(tainted); $t=$0; $u=lc($t); >> printf("%d,%d\n",tainted($t),tainted($u))' >> 1,0 >> >> using perl 5.8.8: >> $ perl -Te 'use Scalar::Util qw(tainted); $t=$0; $u=lc($t); >> printf("%d,%d\n",tainted($t),tainted($u))' >> 1,1
> > Is this security-related issue important enough to be a 5.14 blocker?
IMO yes. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
CC: Karl Williamson <public [...] khwilliamson.com>, perl5-porters [...] perl.org
Subject: Re: [perl #87336] Function lc() is laundering tainted data in newer perls, contrary to docs
Date: Thu, 31 Mar 2011 20:53:57 +0800
To: demerphq <demerphq [...] gmail.com>
From: Jesse Vincent <jesse [...] fsck.com>
At least for now, I've made it a 5.14 blocker, so a fix for it is 100% ok. :)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 173b
On Thu Mar 31 05:54:26 2011, jesse wrote: Show quoted text
> At least for now, I've made it a 5.14 blocker, so a fix for it is 100% > ok. :) >
I’ve just fixed it with commit 539689e74a.
CC: perl5-porters [...] perl.org
Subject: Re: [perl #87336] Function lc() is laundering tainted data in newer perls, contrary to docs
Date: Fri, 15 Apr 2011 19:12:24 +0100
To: Father Chrysostomos via RT <perlbug-comment [...] perl.org>
From: Dominic Hargreaves <dom [...] earth.li>
On Thu, Mar 31, 2011 at 06:29:59AM -0700, Father Chrysostomos via RT wrote: Show quoted text
> On Thu Mar 31 05:54:26 2011, jesse wrote:
> > At least for now, I've made it a 5.14 blocker, so a fix for it is 100% > > ok. :) > >
> > I’ve just fixed it with commit 539689e74a.
Are there any plans to push this update to maint-5.12 or maint-5.10 (although the latter is probably dead already in practice)? It looks like it would be worth applying. For context, I'm looking at fixing this in the Debian perl packages: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622817>. It looks like Redhat have already pushed out an update for 5.12 in Fedora 14. I've attached the patch extracted from <http://mirror.ox.ac.uk/sites/download.fedora.redhat.com/pub/fedora/linux/updates/14/SRPMS/perl-5.12.3-143.fc14.src.rpm> (thanks Marcela!) and would appreciate any comments. That file applies cleanly to our perl 5.10 tree, although I haven't tested it yet. Thanks, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
CC: Father Chrysostomos via RT <perlbug-comment [...] perl.org>, perl5-porters [...] perl.org
Subject: Re: [perl #87336] Function lc() is laundering tainted data in newer perls, contrary to docs
Date: Sat, 16 Apr 2011 12:55:46 +0100
To: Jan Lieskovsky <jlieskov [...] redhat.com>, Tom spot Callaway <tcallawa [...] redhat.com>
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 1.9k
Hi Jan Lieskovsky, Please could you also mail perl5-security-report@perl.org when requesting a CVE for an issue in Perl 5? On Fri, Apr 15, 2011 at 07:12:24PM +0100, Dominic Hargreaves wrote: Show quoted text
> On Thu, Mar 31, 2011 at 06:29:59AM -0700, Father Chrysostomos via RT wrote:
> > On Thu Mar 31 05:54:26 2011, jesse wrote:
> > > At least for now, I've made it a 5.14 blocker, so a fix for it is 100% > > > ok. :) > > >
> > > > I???ve just fixed it with commit 539689e74a.
> > Are there any plans to push this update to maint-5.12 or maint-5.10 > (although the latter is probably dead already in practice)? > It looks like it would be worth applying. > > For context, I'm looking at fixing this in the Debian perl packages: > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622817>. It looks > like Redhat have already pushed out an update for 5.12 in Fedora 14. > > I've attached the patch extracted from > <http://mirror.ox.ac.uk/sites/download.fedora.redhat.com/pub/fedora/linux/updates/14/SRPMS/perl-5.12.3-143.fc14.src.rpm> > (thanks Marcela!) and would appreciate any comments. That file applies > cleanly to our perl 5.10 tree, although I haven't tested it yet.
Well, it's not quite clear what side of EOL maint-5.10 is. The current "discussion" is this 2 message thread: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-04/msg00352.html as to maint-5.12, the current thoughts from Jesse was: : On Fri, Apr 08, 2011 at 03:59:35AM -0700, Nicholas Clark via RT wrote: : > We probably should backport this fix to maint-5.12 ready for 5.12.4 : > How is 5.12.4? : : I suspect "on hold as we try to get 5.14 out" - I think we'll be doing : 5.14 maint releases a little differently based on what we've learned : from 5.12. (in http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-04/msg00344.html ) Now that we *belatedly* learn that this bug has CVE, and a published CVE at that, it's rather pulled the rug from under us. Nicholas Clark
CC: Jan Lieskovsky <jlieskov [...] redhat.com>, Tom spot Callaway <tcallawa [...] redhat.com>, perl5-porters [...] perl.org
Subject: Re: [perl #87336] Function lc() is laundering tainted data in newer perls, contrary to docs
Date: Sat, 16 Apr 2011 13:21:23 +0100
To: Nicholas Clark <nick [...] ccl4.org>
From: Nicholas Clark <nick [...] ccl4.org>
On Sat, Apr 16, 2011 at 12:55:46PM +0100, Nicholas Clark wrote: Show quoted text
> On Fri, Apr 15, 2011 at 07:12:24PM +0100, Dominic Hargreaves wrote:
> > On Thu, Mar 31, 2011 at 06:29:59AM -0700, Father Chrysostomos via RT wrote:
> > > On Thu Mar 31 05:54:26 2011, jesse wrote:
> > > > At least for now, I've made it a 5.14 blocker, so a fix for it is 100% > > > > ok. :) > > > >
> > > > > > I???ve just fixed it with commit 539689e74a.
Show quoted text
> Now that we *belatedly* learn that this bug has CVE, and a published CVE > at that, it's rather pulled the rug from under us.
It's a valid bug, but I don't even think that this bug *should* be a CVE. We never advertise tainting as an input validation system. No program should be relying on taint exceptions as a form of input validation. Tainting is a safety net designed to spot bugs in end user programs. Any program that relies on tainting as part of its design is ITSELF BUGGY. Not Perl for having a small hole in its safety net. Report CVEs in those programs, if they exist. Nicholas Clark
Download (untitled) / with headers
text/plain 168b
On Sat Apr 16 05:21:59 2011, nicholas wrote: Show quoted text
> It's a valid bug, but I don't even think that this bug *should* be a CVE.
Agree, but for the record: it's CVE-2011-1487.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org