Qiang has asked for the wisdom of the Perl Monks concerning the following question:

Dear monks,

I need to upgrade our perl 5.6.1 on solaris 8 due to the Perl Unspecified Insecure Temporary File Creation Vulnerability however, I couldn't find any patch for this on Sun, neither on cpan, or rt.perl.org

since we have many apps depends on 5.6.1, I am trying to patch the current perl or upgrade to a perl version that is as close as to the current one.

there is a debian patch posted on perl5porter though.

without much experience on upgrading perl, esp security issue (many time upgrading a module ending up upgrading perl, yuck!), my question is, does perl release patch,if so where do i find one? or I have to wait for my distro come up with the fix?

UPDATE: re-rearrange the last sentence.

Replies are listed 'Best First'.
Re: security patch for perl 5.6.1
by kutsu (Priest) on Jan 28, 2005 at 21:41 UTC

    This issue is likely due to a design error that causes the application to fail to verify the existance of a file before writing to it.

    This isn't an error, and is easily avoidable, with two different methods, like this:

    if (-e '/path/to/somefile') #method one (perldoc -f -X) { #method two (die statements, see perldoc -f open) open(OUTFILE, ">>/path/to/somefile") or die "can't open file: $!"; #or open(INFILE, "/path/to/somefile") or die "can't open file: $!"; }

    Update: Added reference to filetest (-X) perldoc

    "Cogito cogito ergo cogito sum - I think that I think, therefore I think that I am." Ambrose Bierce

      I havn't taken time to read various related holes. but if the fix is that easy as you stated, I am willing to do it by myself.

      otherwise, it looks like I have to upgrade to the latest perl.

Re: security patch for perl 5.6.1
by hsinclai (Deacon) on Jan 30, 2005 at 04:57 UTC
    I'm neither smarter, nor more awake than anyone here :) but I'll throw in a couple of ideas for you:

    First of all as kutsu mentioned reworking any code to fail properly and thereby probably nullify any attempt to exploit the vulnerability is the easy way to go, and as you mention, since you're willing to do it, go for it. It should not be that hard if you don't have too many files to go through.

    If you look at the docs a little more in depth you'll see that not all vendors released an upgrade of Perl for this, or acknowledged it as a serious hole. Second you'll see it's a local only exploit (not remotely exploitable) so assess the risk on a system by system basis - e.g. there'll be much less risk on an application server with few if any local users. Third by the time you see any vulnerability on SecurityFocus or Regis and Kathy Lee, it's been around for ages in the wild..

    It seems that in this particular case it's more important to clean up code and lock down filesystem access, and monitor your systems for unusal patterns and unauth access, along with a per-system code and user assessment, than rushing out to upgrade Perl everywhere..

Re: security patch for perl 5.6.1
by jbrugger (Parson) on Jan 29, 2005 at 20:13 UTC
    > (many time upgrading a module ending up upgrading perl, yuck!)
    Is that so under Solaris? this is new to me, i mostly use the
    perl -MCPAN -e shell install module::name
    methods, and don't need to upgrade perl in any way.

      CPANPLUS is much nicer about this, and won't try to upgrade your core Perl distribution on you.

      Also, there's an easier way to do what you're doing in two step (and you can automate it, modulo any modules failing their tests):

      perl -MCPAN -e 'install "Acme::Toaster"'

Re: security patch for perl 5.6.1
by Qiang (Friar) on Jan 31, 2005 at 21:50 UTC
    thanks, hsinclai. that's all good advices.

    anyway, here is what I have pulled together about the vulnerabilities for future reference. (below is from debian perl_5.6.1-8.8.diff.gz). I am not so sure if that applies my solaris system though.

    this from debian

    + * SECURITY [CAN-2004-0452]: use less permissive chmods in rmtree. + * SECURITY [CAN-2004-0976]: patches from Trustix for insecure temp + file usage (thanks to Joey Hess for analysis). + - Some unsafe examples in the DB_File POD + - Use of hard coded temp file name in ext/IO/t/io_unix.t + - Hardcoded tmp file in ext/ODBM_File/ODBM_File.xs + - Some potentially unsafe examples in POSIX pod + - Hardcoded tmp file path in example of Socket.pm + - Example in Cookie.pm that uses /usr/tmp + - An example in MakeMaker.pm that suggets setting PREFIX=/tmp/myp +erl5 + - Insecure use of /tmp file in ExtUtils/inst + - Insecure use of /tmp file in docs of Shell.pm + - Insecure use of /tmp file in docs of dotsh.pl + - Insecure use of /tmp file in setterm() function of lib/perl5db. +pl + - Insecure use of /tmp file in mpeix/nm + - Insecure use of /tmp file in perly.fixer + - Insecure use of /tmp file in perldbmfilter.pod, perldebug.pod + - Various fixes in the FAQ + - perlfunc.pod, ditto + - perlipc.pod, ditto + - perllexwarn.pod, ditto + - perlobj.pod, ditto + - perlop.pod, ditto + - perlopentut.pod, ditto + - Insecure use of /tmp in utils/c2ph.PL, utils/perlbug.PL
    searching around, this url from ubuntu linux appears helpful.
    the detailed solution for first one:

    + * SECURITY UPDATE: fix information/file leakage in File::Path::rmtr +ee() + * lib/File/Path.pm, rmtree(): use chmod 700/600 instead of 777/666 +before + removing files/directories; this will not leave world-readable/wr +iteable + directories and files behind if rmdir/unlink fails somehow and av +oid race + conditions + * References: + CAN-2004-0452
    the second one :

    + * SECURITY UPDATE: multiple insecure temporary file usages + (Warty bug #2771) + * added patch 03_safe_tmpfiles.patch: + - ext/Devel/PPPort/PPPort.pm: use safe method of create temporary + file + - lib/ExtUtils/instmodsh: use File::Temp to create temporary file + safely + - lib/Memoize/t/{tie.t,tie_gdbm.t,tie_ndbm.t,tie_sdbm.t,tie_stora +ble.t}, + ext/DB_File/t/db-recno.t: create temporary files in current dir +ectory, not + /tmp; these test scripts are only used during package build, so + this + should be safe + * References: + CAN-2004-0976
    for some reason, the second one doesn't cover all that mentioned in debian. maybe because of different distro that's better than nothing, but I am not that confident enough to create a patch base on them and test it all out. I am not keep on doing code assessment because this will create redundency and lot of work if future exploit happens.

    overall, without patch,we decided to go for the latest perl because we are going to test it all out anyway in either above cases.