SA 3.3.0 spamassassin taint issue

[R P Herrold <he...@owlriver.com>]

I have not gotten this into the bugzilla, but ... as it appeas 
a 3.3 release is imminent, I though I should mention seeing 
this in my log files:

I am getting this:

Jan 20 18:17:40 vm049244181 spamd[14023]: spamd: Insecure dependency in chown 
while running with -T switch at 
/usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin.pm line 1934, <GEN16> line 
2.

which is:

       if (($< == 0) && ($> == 0) && defined($user)) { # chown  it
         my ($uid,$gid) = (getpwnam($user))[2,3];
         unless (chown($uid, $gid, $fname)) {
           warn "config: couldn't chown $fname to $uid:$gid for $user: $!\n";
         }


sort of a sketchy test for 'root' here also

I searched the bugzilla, but nothing relevant found with:

https://issues.apache.org/SpamAssassin/buglist.cgi?quicksearch=spamassassin+taint


-------------------------------

it looks like a prior similar fix here:

http://mail-archives.apache.org/mod_mbox/spamassassin-commits/200909.mbox/%3C20090917234411.9D6E223888E8@eris.apache.org%3E

        #
        # If vpopmail config enabled then set $userdir to virtual homedir
        #
-      no re 'taint';
-      my $username_untainted = ( $username =~ /^([-:,.=+A-Za-z0-9_@~]+)$/ ? $1 
: undef );
-      use re 'taint';
+      my $username_untainted;
+      $username_untainted =
+        untaint_var($username)  if $username =~ /^[-:,.=+A-Za-z0-9_\@~]+\z/;


-- Russ herrold

Re: SA 3.3.0 spamassassin taint issue

[Mark Martinec <Ma...@ijs.si>]

Russ,

> I have not gotten this into the bugzilla, but ... as it appears 
> a 3.3 release is imminent, I though I should mention seeing 
> this in my log files:
>
> I am getting this:
>   Jan 20 18:17:40 vm049244181 spamd[14023]: spamd:
>   Insecure dependency in chown while running with -T switch
>   at /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin.pm
>   line 1934,
>
> which is:
>       if (($< == 0) && ($> == 0) && defined($user)) { # chown  it
>         my ($uid,$gid) = (getpwnam($user))[2,3];
>         unless (chown($uid, $gid, $fname)) {
>           warn "config: couldn't chown $fname to $uid:$gid for $user: $!\n";
>         }

The issue is now tracked as:
  https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6313

and a patch is available there. Thanks for your report!

  Mark

Re: SA 3.3.0 spamassassin taint issue

[Mark Martinec <Ma...@ijs.si>]

Russ,

> I have not gotten this into the bugzilla, but ... as it appeas
> a 3.3 release is imminent, I though I should mention seeing
> this in my log files:
> 
> I am getting this:
> 
> Jan 20 18:17:40 vm049244181 spamd[14023]: spamd: Insecure dependency in
>  chown while running with -T switch at
> /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin.pm line 1934, <GEN16>
>  line 2.
> 
> which is:
> 
>        if (($< == 0) && ($> == 0) && defined($user)) { # chown  it
>          my ($uid,$gid) = (getpwnam($user))[2,3];
>          unless (chown($uid, $gid, $fname)) {
>            warn "config: couldn't chown $fname to $uid:$gid for $user:
>  $!\n"; }
> 
> 
> sort of a sketchy test for 'root' here also
> 
> I searched the bugzilla, but nothing relevant found with:
> 
> https://issues.apache.org/SpamAssassin/buglist.cgi?quicksearch=spamassassin
> +taint
> 
> 
> -------------------------------
> 
> it looks like a prior similar fix here:
> 
> http://mail-archives.apache.org/mod_mbox/spamassassin-commits/200909.mbox/%
> 3C20090917234411.9D6E223888E8@eris.apache.org%3E
> 
>         #
>         # If vpopmail config enabled then set $userdir to virtual homedir
>         #
> -      no re 'taint';
> -      my $username_untainted = ( $username =~ /^([-:,.=+A-Za-z0-9_@~]+)$/
>  ? $1
> 
> : undef );
> 
> -      use re 'taint';
> +      my $username_untainted;
> +      $username_untainted =
> +        untaint_var($username)  if $username =~
>  /^[-:,.=+A-Za-z0-9_\@~]+\z/;


Please open a bugzilla bug report.

I can see where a problem might be, but can't reproduce it:
usually spamd either changes its uid before running on behalf
of a real user, or runs nonprivileged. For the problem described
here, it must still have effective and real uid 0, and must
be allowed to create user's config files for new users.
Is your setup with 'virtual' users? SQL? LDAP? vpop?
Please describe it (in the bug report), and show command line
options of your spamd process.

> if (($< == 0) && ($> == 0) && defined($user))
> sort of a sketchy test for 'root' here also

Why do you think it is sketchy? (again, followups to the bug report)

  Mark