Re: One true regexp for untainting windows filenames?

Checking if $^X is a valid file name doesn't make it safe. You might as well use /(.*)/s.

On the plus side, there doesn't appear to be any reason for $^X to be tainted in Windows.

use Win32::Process;

sub ErrorReport{
   print Win32::FormatMessage( Win32::GetLastError() );
}

Win32::Process::Create(
   my $child,
   'c:\\progs\\perl5100\\bin\\perl.exe',
   'evil -le"print $^X"',
   0,
   NORMAL_PRIORITY_CLASS,
   "."
)
   or die ErrorReport();

$child->Wait(INFINITE);
[download]

c:\progs\perl5100\bin\perl.exe
[download]

If you trust the perl you are running, then it looks like $^X is safe.
If you don't trust the perl you are running, then it doesn't matter if $^X safe or not.

By the way,
everything that matches qr{^[^/\0]+\z} is a valid file name in unix,
and everything that matches qr{^[^\0]+\z} is a valid file path in unix.
I don't know where you got qr{ (\A[- + @ [:word:] . / ]+)\z }x from.

Comment on Re: One true regexp for untainting windows filenames? Select or Download Code

Replies are listed 'Best First'.
Re^2: One true regexp for untainting windows filenames? by jaldhar (Vicar) on Jan 08, 2009 at 22:13 UTC
It seems that despite the length of my post I still managed to leave out some pertinent information. Sorry! I use untaint_path() to check several filenames not just $^X. It just happens that this is the first test that encountered a weird path. So the question still stands even if $^X is safe. On that topic, I am using the value of $^X in a qx// call. On Linux at least, if I don't untaint it, I get a nastygram about "insecure dependency." Should perl be a little smarter here? As for the regexps themselves, I am embarrassed to say I just copied them from existing code. Now I will use the ones from File::Basename as cdarke suggested. Thank you for your help. -- જલધર	[reply]
Re^3: One true regexp for untainting windows filenames? by ikegami (Patriarch) on Jan 09, 2009 at 05:14 UTC
I use untaint_path() to check several filenames not just $^X. To make them safe for what? Most most applications, `untaint_path` might remove the taint flag, but it doesn't make sure they're safe first. On that topic, I am using the value of $^X in a qx// call. On Linux at least, if I don't untaint it, I get a nastygram about "insecure dependency." Should perl be a little smarter here? In unix systems, it's possible to execute a binary at one path while making it think it's at a different path. `$ cat > a.c #include <stdio.h> int main(int argc, char** argv) { printf("%s\n", argv[0]); return 0; } $ gcc -o a a.c $ perl -e'exec { "a" } "evil"' evil` [download] Based on a comment in `$^X`, it looks like there's a way for processes to find out which binary is actually being executed on some systems, and Perl uses it. If the following doesn't print "`evil`" on your system, `$^X` can probably be trusted on your system. `$ perl -e'system { "perl" } "evil", "-le", "print \$^X"' /usr/bin/perl` [download]	[reply] [d/l] [select]
Re^4: One true regexp for untainting windows filenames? by jaldhar (Vicar) on Jan 09, 2009 at 19:42 UTC
To make them safe for what? Most most applications, untaint_path might remove the taint flag, but it doesn't make sure they're safe first. Safe to use in `qx//;` in taint mode Earlier, I set `$ENV{PATH}` to `q{}`. This means I need to use complete paths to every file or command I use and they need to be untainted to prevent the 'insecure dependency' error. I had forgotten about argv[0]. Now you have led me to realize that running under -T will not really buying me anything here without additional checking. Hopefully this conversation will remind others to not complacently assume untainted eq secure if nothing else. -- જલધર	[reply] [d/l] [select]
Re^5: One true regexp for untainting windows filenames? by ikegami (Patriarch) on Jan 09, 2009 at 19:59 UTC


There's more than one way to do things
	PerlMonks