Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
p5pRT opened this issue Mar 30, 2011 · 12 comments
Closed

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

p5pRT opened this issue Mar 30, 2011 · 12 comments

Comments

@p5pRT
Copy link

p5pRT commented Mar 30, 2011

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

Searchable as RT87336$

@p5pRT
Copy link
Author

p5pRT commented Mar 30, 2011

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
Copy link
Author

p5pRT commented Mar 31, 2011

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
Copy link
Author

p5pRT commented Mar 31, 2011

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

@p5pRT
Copy link
Author

p5pRT commented Mar 31, 2011

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
Copy link
Author

p5pRT commented Mar 31, 2011

From @obra

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

@p5pRT
Copy link
Author

p5pRT commented Mar 31, 2011

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
Copy link
Author

p5pRT commented Mar 31, 2011

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
Copy link
Author

p5pRT commented Mar 31, 2011

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

@p5pRT p5pRT closed this as completed Mar 31, 2011
@p5pRT
Copy link
Author

p5pRT commented Apr 15, 2011

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
Copy link
Author

p5pRT commented Apr 16, 2011

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
Copy link
Author

p5pRT commented Apr 16, 2011

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
Copy link
Author

p5pRT commented May 18, 2011

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant