Hello,
This was really a vulnerability which allowed running any perl code or
commands (even as root), for anyone able to write .cf files/rules.
The bug is mitigated in SpamAssassin 3.4.3, which properly taints
configuration strings, and results in Perl complaining and not running
Greylisting.pm at all.
I've made a proper patch which addresses both the vulnerability and 3.4.3
compatibility.
=====================================================================
--- Greylisting.pm.orig 2019-12-18 17:49:40.351383764 +0200
+++ Greylisting.pm 2019-12-18 22:30:03.745497552 +0200
@@ -21,6 +21,7 @@
use strict;
use Mail::SpamAssassin::Plugin;
+use Mail::SpamAssassin::Util qw(untaint_var);
our @ISA = qw(Mail::SpamAssassin::Plugin);
sub new
@@ -65,9 +66,25 @@
Mail::SpamAssassin::Plugin::dbg("GREYLISTING: called function");
- $optionhash =~ s/;/,/g;
+ #$optionhash =~ s/;/,/g;
# This is safe, right? (users shouldn't be able to set it in their config)
- %option=eval $optionhash;
+ #%option=eval $optionhash;
+
+ # ... no, evaling random strings is not safe!!!
+ # Ditch eval and parse hash string manually to maintain backwards
compatibility
+ $optionhash =~ s/^\s*\(\s*//;
+ $optionhash =~ s/\s*\)\s*$//;
+ foreach my $opt (split(/\s*;\s*/, $optionhash)) {
+ my @vals = split(/\s*=>\s*/, $opt, 2);
+ next unless defined $vals[1];
+ # Sanitize away quotes and any unneeded characters, then untaint
+ foreach (@vals) {
+ s/[^\w\/-]//gs;
+ $_ = untaint_var($_);
+ }
+ $option{$vals[0]} = $vals[1];
+ }
+
$self->{'rangreylisting'}=1;
foreach my $reqoption (qw ( method greylistsecs dontgreylistthreshold
=====================================================================
Cheers,
Henrik
