perltidy insecure temporary file usage

2014.03.04
Risk: Medium
Local: Yes
Remote: No
CVE: N/A
CWE: N/A

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


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top