Function lc() is laundering tainted data in newer perls, contrary to docs

[p5pRT]

Migrated from rt.perl.org#87336 (status was 'resolved')

Searchable as RT87336$

[p5pRT]

From Mark.Martinec@ijs.si

Created by Mark.Martinec@ijs.si

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

Perl Info

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

[p5pRT]

From @khwilliamson

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?

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @demerphq

On 31 March 2011 04​:10, Karl Williamson <public@​khwilliamson.com> wrote​:

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/"

[p5pRT]

From @obra

At least for now, I've made it a 5.14 blocker, so a fix for it is 100%
ok. :)

[p5pRT]

From @cpansprout

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 539689e.

[p5pRT]

From [Unknown Contact. See original ticket]

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 539689e.

[p5pRT]

@cpansprout - Status changed from 'open' to 'resolved'

[p5pRT]

From @jmdh

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 539689e.

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)

[p5pRT]

From @nwc10

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​:

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 539689e.

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

[p5pRT]

From @nwc10

On Sat, Apr 16, 2011 at 12​:55​:46PM +0100, Nicholas Clark wrote​:

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 539689e.

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

[p5pRT]

From @gisle

On Sat Apr 16 05​:21​:59 2011, nicholas wrote​:

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.