Subject: Re:  New: Win32 removes all PATH entries

>
> A user sent this to me because he didn't want to open a BZ account.  I'd 
> appreciate it if someone could
> verify if this actually occurs, and if so, whether or not the Win32 perl 
> cares about world-writable
> directories in PATH under taint mode (in UNIX it'll terminate the process 
> for security reasons...)

I have a working path, I'm using 3.0.1 with perl 5.8.2  (NTFS drives)

debug: Current PATH is: 
C:\Perl\bin\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\S
ystem32\Wbem;C:\Program Files\ATI Technologies\ATI Control Panel;C:\Program 
File
s\Symantec\pcAnywhere\;C:\Program Files\Microsoft SQL Server\80\Tools\BINN


Could this be due to using FAT32 filesystem?  I can't test or verify this 
one (it would make a big difference as far as file permissions goes)


> "But now for the bug. It is: SA removes at start all path's which it 
> considers unsafe for some reason.
> Under Linux this may be a good thing, under Win32 it ends up in a path 
> consisting of NOTHING
> because everything which was 'world writable' ( = all ) gets removed. Of 
> course SA can't spawn any
> process like DCC then because it can't even find CMD.EXE"


If this is due to Fat32, I might suggest closing this, does anyone really 
use fat32 on servers?

Subject: Re:  Win32 removes all PATH entries

On Fri, Oct 29, 2004 at 04:46:00AM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> If this is due to Fat32, I might suggest closing this, does anyone really 
> use fat32 on servers?

SpamAssassin doesn't need to run on a server.

This is less of a SpamAssassin issue really, and more of a "how does perl
taint mode work in win32 mode" thing.  If perl taint mode doesn't work at all
due to everything being "world writable", then either we need to work around
it or document it as a known "it's a win32 perl issue, sorry" thing.  Same as
the Mac OS X perl setuid() business.

I think it should be pretty easy to turn off those taint checks on windows. 
FAT32 is still commonly used in a lot of win32 setups AFAIK...

Ok I didn't know I had to modify the spamassassin.bat file to include the -T 
switch for perl to use taint mode.  (should taint be on by default?)

Now I can confirm this is a problem:

debug: SpamAssassin version 3.0.1
debug: Score set 0 chosen.
debug: running in taint mode? yes
debug: Running in taint mode, removing unsafe env vars, and resetting PATH
debug: PATH included 'C:\Perl\bin', which is world writable, dropping.
debug: PATH included 'C:\WINNT\system32', which is world writable, dropping.
debug: PATH included 'C:\WINNT', which is world writable, dropping.
debug: PATH included 'C:\WINNT\system32\WBEM', which is world writable, 
dropping.
debug: PATH included 'D:\Program Files\Symantec\pcAnywhere', which is world 
writable, dropping.
debug: PATH included 'D:\MSSQL7\BINN', which is world writable, dropping.
debug: PATH included 'C:\Program Files\Microsoft SQL Server\80\Tools\BINN', 
which is world writable, dropping.
debug: PATH included '"C:\Program Files\Symantec\Norton Ghost 2003\"', which is 
not absolute, dropping.
debug: PATH included 'C:\Program Files\Common Files\Adaptec Shared\System', 
which is world writable, dropping.
debug: Final PATH set to:

Subject: Re:  Win32 removes all PATH entries

On Fri, Oct 29, 2004 at 12:54:38PM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> Ok I didn't know I had to modify the spamassassin.bat file to include the -T 
> switch for perl to use taint mode.  (should taint be on by default?)

It's on by default in the spamassassin perl script.  What is spamassassin.bat?

Finally I managed to activate my BZ account ;) Thanks Theo for posting the bug!
I can confirm this occurs on Fat32 (win2k) and yes, there are really servers
which still use Fat32. In case of a Mailserver this isn't actually much of a
problem and in my case, because there is still good ol' DOS installed as 2nd OS.

Theo: Spamassassin.bat is created by make install under Win32.

Subject: Re:  Win32 removes all PATH entries

On Fri, Oct 29, 2004 at 01:51:21PM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> Theo: Spamassassin.bat is created by make install under Win32.

Hrm.  Sounds like that ought to get taint mode by default.

Anyway, to get back to the issue at hand, on UNIX the problem is trivially
demonstratable:

$ perl -Te '$ENV{PATH}="/tmp"; system("uname");'
Insecure directory in $ENV{PATH} while running with -T switch at -e line 1.

Can you try something similar on the win32 perl?  Replace the '/tmp' with some
valid directory, and the 'uname' with some valid command in that directory,
preferably that returns something simple.

If it returns without complaining, it would seem like we can disable the
world writable cleansing on win32.  If the process dies with the above
"Insecure directory" issue, it's a perl issue and there's nothing we
can do about it (you're damned if you do (stuff can't run without path)
and you're damned if you don't (insecure directory errors will kill
the process)...)

I will try it ASAP but as I have already outcommented the following part:

#      elsif (($stat[2]&2) != 0) {
#      World-Writable directories are considered insecure.
#      We could be more paranoid and check all of the parent directories as well,
#      but it's good for now.
#	dbg("PATH included '$dir', which is world writable, dropping.");
#	next;
#      }

and it runs since weeks pretty stable I would assume it is safe to disable it.

In unix the spamassasin file can be installed as a perl source file with
#!/usr/bin/perl -T -w as the first line. Windows command processor doesn't use that.

The Windows install uses p2bat which sticks some lines of batch file commands to
the head of the file that invokes perl on the file, and names that spamassassin.bat.

The perl command line installed by p2bat does not enable taint mode. So
SpamAssassin on Windows does not run in taint mode.

Taint mode under Windows is tricky because it checks that no directory in PATH
is world writeable, but it is not likely that anyone running under Windows has
their directories protected like that. It is theoretically possible to have
strict access controls using NTFS, but it is not in FAT and it is rare for
somebody to configure their system to use NTFS and have secure compartmentalized
access to directories.

At least this explains how it is that people are not able to run DCC and so on
from SpamAssassin under Windows. Perhaps dealing with this will lead to someone
putting in the effort to investigate that and get them working.

The most standard way I've found for people running perl under Windows to deal
with this is to set $ENV{'PATH'} explicitly. But it does require recognizing
that Windows does not provide a secure multiuser environment, and so some taint
checks just have to be bypassed when running under it. A tricky thing would be
to figure out what to set PATH to. That might have to be a configuration option,
specifying the correct minimal PATH to use when running SpamAssassin under Windows.

I just put in a check in Util::clean_path_in_taint_mode() to skip the path
cleansing on windows-esque platforms.  r156298.

since this got fixed in 3.1, set the milestone appropriately.