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
| [reply] [d/l] |
| [reply] |
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..
| [reply] |
> (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. | [reply] [d/l] |
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"'
| [reply] [d/l] |
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. | [reply] [d/l] [select] |