possible CVE requests: perltidy insecure temporary file usage

[Murray McAllister <mmcallis () redhat com>]

Good morning,

Jakub Wilk and Don Armstrong are discussing in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740670 1) perltidy 
creating a temporary file with default permissions instead of 0600 2) 
the use of tmpnam().

From that bug:

    my $name = "perltidy.TMP";
    if ( $^O =~ /win32|dos/i || $^O eq 'VMS' || $^O eq 'MacOs' ) {
        return $name;
    }

Would this be a separate issue on those platforms (predictable temporary 
file in current working directory, run perltidy in attacker-controlled 
directory...)? On perltidy-20090616-2.1.el6.src.rpm this was only called 
when using the "-html" option and a pod file as input, and looks to then 
possibly open it insecurely:

    else {
        $tmpfile = Perl::Tidy::make_temporary_filename();
    }
    my $fh_tmp = IO::File->new( $tmpfile, 'w' );

Trying with a much newer version on Fedora, I received errors about 
tmpnam not working and it didn't appear to be called, but haven't spent 
time debugging that yet.

Regarding other platforms:

    my $name = "perltidy.TMP";
    if ( $^O =~ /win32|dos/i || $^O eq 'VMS' || $^O eq 'MacOs' ) {
        return $name;
    }
    eval "use POSIX qw(tmpnam)";
    if ($@) { return $name }

Is the POSIX module a core part of Perl, as in, the "return $name" part 
will never be called?

Regarding the use of tmpnam, is it safe/not an issue if you open the 
resulting filename with O_CREAT and O_EXCL (as perltidy does)?

I am not sure if these 	qualify for CVEs but I believe the 
"perltidy.TMP" on Windows or Mac OS X etc would.

Thanks,

--
Murray McAllister / Red Hat Security Response Team