From dom@idealx.com

Created by dom@idealx.com

Tainting is able to contaminate special variable $^O that is only
read, when a tainted value and $^O are both evaluated as conditions of
the same "if" construct​:

  use strict;
  use Taint;
  my $tainted="blah"; Taint​::taint($tainted);
  if (!defined $tainted) {
  } elsif ($^O eq "blah") {
  };

  die if Taint​::tainted($^O);'

Tested on 5.6.1 (this bug report) and also 5.8.0 on Debian/testing (on
which perl5db.pl contains such a construct, so this bug actually
prevents the debugger from running under taint mode).

Temporary fix in perl5db.pl 5.8.0 :

--- /etc/perl/perl5db.pl        2003-12-16 12:29:59.000000000 +0100
+++ /usr/share/perl/5.8.0/perl5db.pl    2003-06-05 16:37:24.000000000 +0200
@@ -510,14 +510,12 @@
   parse_options($ENV{PERLDB_OPTS});
 }
 
-# This is really weird... This block of code taints $^O! dom@idealx.com
 if ( not defined &get_fork_TTY and defined $ENV{TERM} and $ENV{TERM} eq 'xterm'
      and defined $ENV{WINDOWID} and defined $ENV{DISPLAY} ) { # _inside_ XTERM?
     *get_fork_TTY = \&xterm_get_fork_TTY;
 } elsif ($^O eq 'os2') {
     *get_fork_TTY = \&os2_get_fork_TTY;
 }
-$^O =~ m/^(.*)$/; $^O=$1; # dom@idealx.com
 
 # Here begin the unreadable code.  It needs fixing.
 

Flags:
    category=core
    severity=medium

Site configuration information for perl v5.6.1:

Configured by root at Sun Aug 10 01:12:15 UTC 2003.

Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
  Platform:
    osname=linux, osvers=2.4.20-7um, archname=i386-linux
    uname='linux (none) 2.4.20-7um #1 smp fri aug 8 18:30:28 edt 2003 i686 unknown '
    config_args='-Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.6.1 -Darchlib=/usr/lib/perl/5.6.1 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.6.1 -Dsitearch=/usr/local/lib/perl/5.6.1 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Duseshrplib -Dlibperl=libperl.so.5.6.1 -Dd_dosuid -des'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
  Compiler:
    cc='cc', ccflags ='-DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-DDEBIAN -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='2.95.4 20011002 (Debian prerelease)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lgdbm -ldb -ldl -lm -lc -lcrypt
    perllibs=-ldl -lm -lc -lcrypt
    libc=/lib/libc-2.2.5.so, so=so, useshrplib=true, libperl=libperl.so.5.6.1
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.6.1:
    /usr/local/lib/perl/5.6.1
    /usr/local/share/perl/5.6.1
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.6.1
    /usr/share/perl/5.6.1
    /usr/local/lib/site_perl
    .


Environment for perl v5.6.1:
    HOME=/home/dom
    LANG=français
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/sbin:/usr/sbin:/sbin:/home/dom/bin:/usr/local/lib/cdk/bin:/usr/X11R6/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From @rgs

Dominique Quatravaux (via RT) wrote​:

Tainting is able to contaminate special variable $^O that is only
read, when a tainted value and $^O are both evaluated as conditions of
the same "if" construct​:

use strict;
use Taint;
my $tainted="blah"; Taint​::taint($tainted);
if (!defined $tainted) {
} elsif ($^O eq "blah") {
};

die if Taint​::tainted($^O);'

Confirmed with bleadperl. Simpler test case pasted below :

#!perl -l
use Scalar​::Util qw/tainted/;
print tainted $^O ? "not ok 1" : "ok 1";
if (!$^X) { } elsif ($^O eq 'bar') { }
print tainted $^O ? "not ok 2" : "ok 2";
__END__

altough I'm not 100% sure yet it's a bug.

Tested on 5.6.1 (this bug report) and also 5.8.0 on Debian/testing (on
which perl5db.pl contains such a construct, so this bug actually
prevents the debugger from running under taint mode).

Temporary fix in perl5db.pl 5.8.0 :

--- /etc/perl/perl5db.pl 2003-12-16 12​:29​:59.000000000 +0100
+++ /usr/share/perl/5.8.0/perl5db.pl 2003-06-05 16​:37​:24.000000000 +0200

I applied your temporary fix as change #21940 to bleadperl, thanks.

From @iabyn

On Sun, Dec 21, 2003 at 05​:04​:41PM +0100, Rafael Garcia-Suarez wrote​:

Dominique Quatravaux (via RT) wrote​:

Tainting is able to contaminate special variable $^O that is only
read, when a tainted value and $^O are both evaluated as conditions of
the same "if" construct​:

use strict;
use Taint;
my $tainted="blah"; Taint​::taint($tainted);
if (!defined $tainted) {
} elsif ($^O eq "blah") {
};

die if Taint​::tainted($^O);'

Confirmed with bleadperl. Simpler test case pasted below :

#!perl -l
use Scalar​::Util qw/tainted/;
print tainted $^O ? "not ok 1" : "ok 1";
if (!$^X) { } elsif ($^O eq 'bar') { }
print tainted $^O ? "not ok 2" : "ok 2";
__END__

altough I'm not 100% sure yet it's a bug.

Eh? I can't get that to fail on any of the copies of 5.8.x and bleed that I
have lying about ????

--
Technology is dominated by two types of people​: those who understand what
they do not manage, and those who manage what they do not understand.

From @iabyn

On Sun, Jan 04, 2004 at 08​:48​:34PM +0000, Dave Mitchell wrote​:

On Sun, Dec 21, 2003 at 05​:04​:41PM +0100, Rafael Garcia-Suarez wrote​:

Dominique Quatravaux (via RT) wrote​:

Tainting is able to contaminate special variable $^O that is only
read, when a tainted value and $^O are both evaluated as conditions of
the same "if" construct​:

use strict;
use Taint;
my $tainted="blah"; Taint​::taint($tainted);
if (!defined $tainted) {
} elsif ($^O eq "blah") {
};

die if Taint​::tainted($^O);'

Confirmed with bleadperl. Simpler test case pasted below :

#!perl -l
use Scalar​::Util qw/tainted/;
print tainted $^O ? "not ok 1" : "ok 1";
if (!$^X) { } elsif ($^O eq 'bar') { }
print tainted $^O ? "not ok 2" : "ok 2";
__END__

altough I'm not 100% sure yet it's a bug.

Eh? I can't get that to fail on any of the copies of 5.8.x and bleed that I
have lying about ????

[ Rafael privately pointed out to me that I needed the -T flag. Sometimes
I find just breathing too complicated ;-) ]

I think it is a bug. Either the OS name should be considered dangerous,
in which case $^O should always be tainted, or not and never.
Currently magic_get() for $^O does sv_setpv(sv, PL_osname), which
causes SV to get tainted if the expression involving $^O happens to be
tainted. I think this assignment should be followed by an unconditional
SvTAINT_on/off depending on whether we think to OS name is to be
considered dodgy. (And my vote is that it isn't dodgy).

Second opinion, anyone?

(I presume similar stuff will apply to some of the other $^FOO vars)

Dave.

--
The perl5 internals are a complete mess. It's like Jenga - to get the
perl5 tower taller and do something new you select a block somewhere in
the middle, with trepidation pull it out slowly, and then carefully
balance it somewhere new, hoping the whole edifice won't collapse as a
result.
  - Nicholas Clark.

From @rgs

Dave Mitchell wrote​:

I think it is a bug. Either the OS name should be considered dangerous,
in which case $^O should always be tainted, or not and never.
Currently magic_get() for $^O does sv_setpv(sv, PL_osname), which
causes SV to get tainted if the expression involving $^O happens to be
tainted. I think this assignment should be followed by an unconditional
SvTAINT_on/off depending on whether we think to OS name is to be
considered dodgy. (And my vote is that it isn't dodgy).

Second opinion, anyone?

I agree.
The osname is available from %Config anyway, where it's not tainted.

From @rspier

Second opinion, anyone?
I agree.
The osname is available from %Config anyway, where it's not tainted.

I was going to argue against this, because...

this feels like a taint leakage bug. Because of how magic works,
a variable that should not get tainted, is getting tainted. There's a
bigger picture issue...

BUT --

  since the value in %Config and the value in $^O should always be
  the same (unless you've modified one or the other), my argument
  doesn't hold much water.

  ($^O is PL_osname which is initialized from OSNAME, which is
  defined in config.h)

  Also, config.h says​:

* This symbol contains the name of the operating system, as determined
* by Configure. You shouldn't rely on it too much; the specific
* feature tests from Configure are generally more reliable.

-R

From @lizmat

At 00​:53 -0800 1/5/04, Robert Spier wrote​:

Second opinion, anyone?
I agree.
The osname is available from %Config anyway, where it's not tainted.

I was going to argue against this, because...

this feels like a taint leakage bug. Because of how magic works,
a variable that should not get tainted, is getting tainted. There's a
bigger picture issue...

BUT --

since the value in %Config and the value in $^O should always be
the same \(unless you've modified one or the other\)\, my argument
doesn't hold much water\.

\($^O is PL\_osname which is initialized from OSNAME\, which is
defined in config\.h\)

Also\, config\.h says​:

* This symbol contains the name of the operating system, as determined
* by Configure. You shouldn't rely on it too much; the specific
* feature tests from Configure are generally more reliable.

Maybe a crazy idea, but when running under taint, $^O should get its
value from %Config rather than from PL_osname. And keep it untainted
at all times?

<paranoid mode=on>
On the other hand, I would think that Config.pm being a "normal"
source-file, is more prone to being changed than some string living
in the middle of an executable.
</paranoid>

Liz

From @rgs

Elizabeth Mattijsen wrote​:

Maybe a crazy idea, but when running under taint, $^O should get its
value from %Config rather than from PL_osname. And keep it untainted
at all times?

And load Config.pm behind the scenes ? no.

On the other hand, $^O isn't read-only, and I see few benefits in
assigning to it.

If it were made read-only, magic could be removed from it, and it could
be turned into a regular read-only SV.

From @lizmat

At 10​:03 +0100 1/5/04, Rafael Garcia-Suarez wrote​:

Elizabeth Mattijsen wrote​:

Maybe a crazy idea, but when running under taint, $^O should get its
value from %Config rather than from PL_osname. And keep it untainted
at all times?
And load Config.pm behind the scenes ? no.

I agree. But I wanted it said nonetheless. ;-)

On the other hand, $^O isn't read-only, and I see few benefits in
assigning to it.

If it were made read-only, magic could be removed from it, and it could
be turned into a regular read-only SV.

That makes much _more_ sense to me.

Liz

From @pjcj

Elizabeth Mattijsen said​:

At 10​:03 +0100 1/5/04, Rafael Garcia-Suarez wrote​:

On the other hand, $^O isn't read-only, and I see few benefits in
assigning to it.

If it were made read-only, magic could be removed from it, and it could
be turned into a regular read-only SV.

That makes much _more_ sense to me.

Assigning to $^O can be very useful. Admittedly, primarily as a way to
work around bugs or deficient APIs, but Perl does have something of a
history in that regard.

A couple of examples spring to mind.

- One of the first Windows ports used to identify itself as IRIX, I think.
- Consider the testing of code designed to work on multiple platforms.

Just something to think about,

--
Paul Johnson - paul@​pjcj.net
http​://www.pjcj.net

From @rgs

Paul Johnson wrote​:

Assigning to $^O can be very useful. Admittedly, primarily as a way to
work around bugs or deficient APIs, but Perl does have something of a
history in that regard.

A couple of examples spring to mind.

- One of the first Windows ports used to identify itself as IRIX, I think.
- Consider the testing of code designed to work on multiple platforms.

OK :)

Thinking about this, and since PL_osname is not used for another purpose
than being accessed by the magical $^O, we could get rid of the global PL_osname
and of the magic on $^O altogether. A minor cleanup. XS code that want to
get the osname value could fetch directly the SvPV of $^O. That would be
backwards-incompatible, of course.

From @lizmat

At 10​:48 +0100 1/5/04, Paul Johnson wrote​:

Elizabeth Mattijsen said​:

At 10​:03 +0100 1/5/04, Rafael Garcia-Suarez wrote​:

On the other hand, $^O isn't read-only, and I see few benefits in
assigning to it.

If it were made read-only, magic could be removed from it, and it could
be turned into a regular read-only SV.

That makes much _more_ sense to me.
Assigning to $^O can be very useful. Admittedly, primarily as a way to
work around bugs or deficient APIs, but Perl does have something of a
history in that regard.

A couple of examples spring to mind.
- One of the first Windows ports used to identify itself as IRIX, I think.
- Consider the testing of code designed to work on multiple platforms.

I think this can be easily circumvented by using another variable, eg. $OSNAME​:

if ($DEBUG) {
  $OSNAME = $^O; # $OSNAME is assignable
} else {
  *OSNAME = \$^O; # $OSNAME is _not_ assignable
}

Just something to think about,

Indeed, I hadn't thought about that. But I never assumed that you
_could_ change $^O, so I have always used workarounds such as the one
above.

Liz

From @hvds

Rafael Garcia-Suarez <rgarciasuarez@​free.fr> wrote​:
:Thinking about this, and since PL_osname is not used for another purpose
:than being accessed by the magical $^O, we could get rid of the global PL_osname
:and of the magic on $^O altogether. A minor cleanup. XS code that want to
:get the osname value could fetch directly the SvPV of $^O. That would be
:backwards-incompatible, of course.

An alternative approach would be to do the mandatory SvTAINTED_off on get,
but also to croak on set if the result would be tainted. That restricts
the backwards incompatibility to catching a potentially unsafe case rather
than requiring XS changes for anyone that's used PL_osname.

Hugo

From stas@stason.org

Paul Johnson wrote​:

Elizabeth Mattijsen said​:

At 10​:03 +0100 1/5/04, Rafael Garcia-Suarez wrote​:

On the other hand, $^O isn't read-only, and I see few benefits in
assigning to it.

If it were made read-only, magic could be removed from it, and it could
be turned into a regular read-only SV.

That makes much _more_ sense to me.

Assigning to $^O can be very useful. Admittedly, primarily as a way to
work around bugs or deficient APIs, but Perl does have something of a
history in that regard.

A couple of examples spring to mind.

- One of the first Windows ports used to identify itself as IRIX, I think.
- Consider the testing of code designed to work on multiple platforms.

Just something to think about,

And there is at least one module that relies on $^O being writable,
Devel​::FakeOSName​:
http​://search.cpan.org/search?query=FakeOSName&mode=all
Handy, when you need to debug a module on a platform that you don't have an
access to (to a limited extend of course).

__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http​://stason.org/ mod_perl Guide ---> http​://perl.apache.org
mailto​:stas@​stason.org http​://use.perl.org http​://apacheweek.com
http​://modperlbook.org http​://apache.org http​://ticketmaster.com

From @lizmat

At 10​:26 -0800 1/5/04, Stas Bekman wrote​:

A couple of examples spring to mind.

- One of the first Windows ports used to identify itself as IRIX, I think.
- Consider the testing of code designed to work on multiple platforms.

Just something to think about,
And there is at least one module that relies on $^O being writable,
Devel​::FakeOSName​:
http​://search.cpan.org/search?query=FakeOSName&mode=all
Handy, when you need to debug a module on a platform that you don't
have an access to (to a limited extend of course).

I would say this is an extra reason to make $^O read-only​: if you
really want to fake in that case, I've no doubt there will be another
way to do it. With XS. With a source-filter. Whatever.

Any user code that directly sets $^O will bypass whatever you do in
Devel​::FakeOSName. Or am I missing something here?

Liz

From @rgs

Elizabeth Mattijsen wrote​:

At 10​:26 -0800 1/5/04, Stas Bekman wrote​:

A couple of examples spring to mind.

- One of the first Windows ports used to identify itself as IRIX, I think.
- Consider the testing of code designed to work on multiple platforms.

Just something to think about,
And there is at least one module that relies on $^O being writable,
Devel​::FakeOSName​:
http​://search.cpan.org/search?query=FakeOSName&mode=all
Handy, when you need to debug a module on a platform that you don't
have an access to (to a limited extend of course).

I would say this is an extra reason to make $^O read-only​: if you
really want to fake in that case, I've no doubt there will be another
way to do it. With XS. With a source-filter. Whatever.

With Internals​::SvREADONLY() :)

FWIW I've no problem with Devel​::* modules messing with the internals :
but should it be *so* easy to shoot oneself in the foot ?

That said, I like Hugo's suggestion -- prevent from assigning tainted data
to $^O.

From dom@idealx.com

Second opinion, anyone?
I agree.
The osname is available from %Config anyway, where it's not tainted.

I was going to argue against this, because...

this feels like a taint leakage bug.

  This is a taint leakage bug beyond all doubt - in my test case $^O
is not modified, only read, but it does get tainted.

--
Dominique QUATRAVAUX Ingénieur senior
01 44 42 00 08 IDEALX

From @iabyn

On Mon, Jan 05, 2004 at 12​:10​:07PM +0000, hv@​crypt.org wrote​:

An alternative approach would be to do the mandatory SvTAINTED_off on get,
but also to croak on set if the result would be tainted. That restricts
the backwards incompatibility to catching a potentially unsafe case rather
than requiring XS changes for anyone that's used PL_osname.

Change 22071 by davem@​davem-percy on 2004/01/05 22​:17​:04

  [perl #24674]
  stop $^O getting tainted on read access, and disallow tainted
  assignment to it

Affected files ...

... //depot/perl/mg.c#292 edit
... //depot/perl/t/op/taint.t#61 edit

Differences ...

==== //depot/perl/mg.c#292 (text) ====

@​@​ -648,8 +648,10 @​@​
  sv_setsv(sv, &PL_sv_undef);
  break;
  case '\017'​: /* ^O & ^OPEN */
- if (*(mg->mg_ptr+1) == '\0')
+ if (*(mg->mg_ptr+1) == '\0') {
  sv_setpv(sv, PL_osname);
+ SvTAINTED_off(sv);
+ }
  else if (strEQ(mg->mg_ptr, "\017PEN")) {
  if (!PL_compiling.cop_io)
  sv_setsv(sv, &PL_sv_undef);
@​@​ -2091,8 +2093,10 @​@​
  if (*(mg->mg_ptr+1) == '\0') {
  if (PL_osname)
  Safefree(PL_osname);
- if (SvOK(sv))
+ if (SvOK(sv)) {
+ TAINT_PROPER("assigning to $^O");
  PL_osname = savepv(SvPV(sv,len));
+ }
  else
  PL_osname = Nullch;
  }

==== //depot/perl/t/op/taint.t#61 (xtext) ====

@​@​ -124,7 +124,7 @​@​

my $TEST = catfile(curdir(), 'TEST');

-print "1..220\n";
+print "1..223\n";

# First, let's make sure that Perl is checking the dangerous
# environment variables. Maybe they aren't set yet, so we'll
@​@​ -1034,4 +1034,14 @​@​
  test 219, !tainted($1);
  ($r = $TAINT) =~ /($TAINT)/;
  test 220, tainted($1);
+
+ # [perl #24674]
+ # accessing $^O shoudn't taint it as a side-effect;
+ # assigning tainted data to it is now an error
+
+ test 221, !tainted($^O);
+ if (!$^X) { } elsif ($^O eq 'bar') { }
+ test 222, !tainted($^O);
+ eval '$^O = $^X';
+ test 223, $@​ =~ /Insecure dependency in/;
}

From abe@ztreet.demon.nl

Op een druilerige winterdag (Monday 05 January 2004 13​:10), schreef
hv@​crypt.org​:

Rafael Garcia-Suarez <rgarciasuarez@​free.fr> wrote​:
:Thinking about this, and since PL_osname is not used for another purpose
:than being accessed by the magical $^O, we could get rid of the global
: PL_osname and of the magic on $^O altogether. A minor cleanup. XS code
: that want to get the osname value could fetch directly the SvPV of $^O.
: That would be backwards-incompatible, of course.

An alternative approach would be to do the mandatory SvTAINTED_off on get,
but also to croak on set if the result would be tainted. That restricts
the backwards incompatibility to catching a potentially unsafe case rather
than requiring XS changes for anyone that's used PL_osname.

(sorry, know nowt about internals, but still, I use some $^O assignments and
rely on the fact that $^O is rw)
does this mean that "untainted assignments" to $^O will render untainted $^O​:

  local $^O = 'Generic'; # $^O untainted

and "tainted assignments" wouldn't​:

  local $^O = `some_os_getting_command`; # $^O tainted

If so I'd be in faviour, as I don't want to loose the ability to assign to $^O
(must agree with Paul here, mostly used for testing purposes)!

Good luck,

Abe
--
Either I need more coffee... or the "self-resume" code is somewhat
unlikely to be run, unless our script is called baron_munchausen.pl.
  -- Jarkko Hietaniemi on p5p @​ 2002-01-21

From @iabyn

On Tue, Jan 06, 2004 at 12​:28​:39AM +0100, Abe Timmerman wrote​:

Op een druilerige winterdag (Monday 05 January 2004 13​:10), schreef
hv@​crypt.org​:

Rafael Garcia-Suarez <rgarciasuarez@​free.fr> wrote​:
:Thinking about this, and since PL_osname is not used for another purpose
:than being accessed by the magical $^O, we could get rid of the global
: PL_osname and of the magic on $^O altogether. A minor cleanup. XS code
: that want to get the osname value could fetch directly the SvPV of $^O.
: That would be backwards-incompatible, of course.

An alternative approach would be to do the mandatory SvTAINTED_off on get,
but also to croak on set if the result would be tainted. That restricts
the backwards incompatibility to catching a potentially unsafe case rather
than requiring XS changes for anyone that's used PL_osname.

(sorry, know nowt about internals, but still, I use some $^O assignments and
rely on the fact that $^O is rw)
does this mean that "untainted assignments" to $^O will render untainted $^O​:

local $^O = 'Generic'; \# $^O untainted

yep

and "tainted assignments" wouldn't​:

local $^O = \`some\_os\_getting\_command\`; \# $^O tainted

run-time error

--
My get-up-and-go just got up and went.

p5p@spam.wizbit.be - Status changed from 'open' to 'resolved'