Mailing List Archive: CVE-2018-11805 fix and sa-exim

CVE-2018-11805 fix and sa-exim

Dec 18, 2019, 6:57 AM

Post #1 of 4 (446 views)

I'm still using sa-exim in my servers:

https://sourceforge.net/projects/sa-exim/
https://packages.debian.org/search?keywords=sa-exim

recently i've upgraded spamassassin with the fix to CVE-2018-11805, and
suddenly i've started to receive:

Dec 16 10:04:53 vdmpp1 spamd[15196]: rules: failed to run GREYLIST_ISWHITE test, skipping:
Dec 16 10:04:53 vdmpp1 spamd[15196]: (Insecure dependency in eval while running with -T switch at /usr/share/perl5/Mail/SpamAssassin/Plugin/Greylisting.pm line 76.
Dec 16 10:04:53 vdmpp1 spamd[15196]: )

Currently in local.cf i use sa-exim with:

ifplugin Greylisting
header GREYLIST_ISWHITE eval:greylisting("( 'dir' => '/var/spool/sa-exim/tuplets'; 'method' => 'dir'; 'greylistsecs' => '1800'; 'dontgreylistthreshold' => 10; 'connectiphdr' => 'X-SA-Exim-Connect-IP'; 'envfromhdr' => 'X-SA-Exim-Mail-From'; 'rcpttohdr' => 'X-SA-Exim-Rcpt-To'; 'greylistnullfrom' => 1; 'greylistfourthbyte' => 0 )")
describe GREYLIST_ISWHITE The incoming server has been whitelisted for this recipient and sender
score GREYLIST_ISWHITE -1.5
priority GREYLIST_ISWHITE 99999
endif # Greylisting

Looking at the plugin code, the culprit come from:

$optionhash =~ s/;/,/g;
# This is safe, right? (users shouldn't be able to set it in their config)
%option=eval $optionhash;

So seems to me that the CVE fix 'broke' the options handling of the
plugin ('eval' is not permitted anymore?!). If i substitute the former with:

#$optionhash =~ s/;/,/g;
# This is safe, right? (users shouldn't be able to set it in their config)
#%option=eval $optionhash;
%option = ('dir' => '/var/spool/sa-exim/tuplets',
'method' => 'dir',
'greylistsecs' => '1800',
'dontgreylistthreshold' => 10,
'connectiphdr' => 'X-SA-Exim-Connect-IP',
'envfromhdr' => 'X-SA-Exim-Mail-From',
'rcpttohdr' => 'X-SA-Exim-Rcpt-To',
'greylistnullfrom' => 1,
'greylistfourthbyte' => 0 );
$self->{'rangreylisting'}=1;

the plugin works as expected.

Probably, in these years, SA changed a bit the way options are passed
to the plugin, and finally CVE-2018-11805 broke the old method.

I've tried to look at other plugin, to try to understand how options
works now, but iknow little perl and i get puzzled.

Someone can help me to fix the plugin? Thanks.

--
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
Associazione ``La Nostra Famiglia'' http://www.lanostrafamiglia.it/
Polo FVG - Via della Bont?, 7 - 33078 - San Vito al Tagliamento (PN)
marco.gaiarin(at)lanostrafamiglia.it t +39-0434-842711 f +39-0434-842797

Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
http://www.lanostrafamiglia.it/index.php/it/sostienici/5x1000
(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)

Re: CVE-2018-11805 fix and sa-exim [ In reply to ]

hege at hege

Dec 18, 2019, 7:30 AM

Post #2 of 4 (446 views)

Permalink

On Wed, Dec 18, 2019 at 03:57:44PM +0100, Marco Gaiarin wrote:
>
> Looking at the plugin code, the culprit come from:
>
> $optionhash =~ s/;/,/g;
> # This is safe, right? (users shouldn't be able to set it in their config)
> %option=eval $optionhash;
>
> So seems to me that the CVE fix 'broke' the options handling of the
> plugin ('eval' is not permitted anymore?!).

No, SA actually fixed what was broken before. Evaling an unchecked string
is extremely dangerous. If someone can change that string or is able to add
a new eval:greylisting rule somewhere, they are free to run any perl code or
system commands they like.

"This is safe, right?" - one should never even write something like this.
Atleast don't publish stuff like that for others to use. Yes it's from
2006, but still..

> If i substitute the former with:
> #$optionhash =~ s/;/,/g;
> # This is safe, right? (users shouldn't be able to set it in their config)
> #%option=eval $optionhash;
> %option = ('dir' => '/var/spool/sa-exim/tuplets',
> 'method' => 'dir',
> 'greylistsecs' => '1800',
> 'dontgreylistthreshold' => 10,
> 'connectiphdr' => 'X-SA-Exim-Connect-IP',
> 'envfromhdr' => 'X-SA-Exim-Mail-From',
> 'rcpttohdr' => 'X-SA-Exim-Rcpt-To',
> 'greylistnullfrom' => 1,
> 'greylistfourthbyte' => 0 );
> $self->{'rangreylisting'}=1;
>
> the plugin works as expected.

It has always been required to use untaint_var to untaint things.

$optionhash = Mail::SpamAssassin::Util::untaint_var($optionhash);

This should be used _after_ the string is sanitized and verified as safe to
use. But in this case, using eval is most unneeded and horrid way of
reading configuration, so it should not be used. I suggest you leave your
changes as is and maybe look for modern plugins or ways to do your
greylisting..

Re: CVE-2018-11805 fix and sa-exim [ In reply to ]

hege at hege

Dec 18, 2019, 9:34 AM

Post #3 of 4 (446 views)

Permalink

On Wed, Dec 18, 2019 at 05:30:38PM +0200, Henrik K wrote:
> On Wed, Dec 18, 2019 at 03:57:44PM +0100, Marco Gaiarin wrote:
> >
> > Looking at the plugin code, the culprit come from:
> >
> > $optionhash =~ s/;/,/g;
> > # This is safe, right? (users shouldn't be able to set it in their config)
> > %option=eval $optionhash;
> >
> > So seems to me that the CVE fix 'broke' the options handling of the
> > plugin ('eval' is not permitted anymore?!).
>
> No, SA actually fixed what was broken before. Evaling an unchecked string
> is extremely dangerous. If someone can change that string or is able to add
> a new eval:greylisting rule somewhere, they are free to run any perl code or
> system commands they like.
>
> "This is safe, right?" - one should never even write something like this.
> Atleast don't publish stuff like that for others to use. Yes it's from
> 2006, but still..
>
> > If i substitute the former with:
> > #$optionhash =~ s/;/,/g;
> > # This is safe, right? (users shouldn't be able to set it in their config)
> > #%option=eval $optionhash;
> > %option = ('dir' => '/var/spool/sa-exim/tuplets',
> > 'method' => 'dir',
> > 'greylistsecs' => '1800',
> > 'dontgreylistthreshold' => 10,
> > 'connectiphdr' => 'X-SA-Exim-Connect-IP',
> > 'envfromhdr' => 'X-SA-Exim-Mail-From',
> > 'rcpttohdr' => 'X-SA-Exim-Rcpt-To',
> > 'greylistnullfrom' => 1,
> > 'greylistfourthbyte' => 0 );
> > $self->{'rangreylisting'}=1;
> >
> > the plugin works as expected.
>
> It has always been required to use untaint_var to untaint things.
>
> $optionhash = Mail::SpamAssassin::Util::untaint_var($optionhash);
>
> This should be used _after_ the string is sanitized and verified as safe to
> use. But in this case, using eval is most unneeded and horrid way of
> reading configuration, so it should not be used. I suggest you leave your
> changes as is and maybe look for modern plugins or ways to do your
> greylisting..

I've reported this to atleast Debian and Ubuntu along with a proper fix.

Re: CVE-2018-11805 fix and sa-exim [ In reply to ]

marco.gaiarin at lanostrafamiglia

Dec 19, 2019, 2:35 AM

Post #4 of 4 (444 views)

Permalink

Riprendo quanto scritto nel suo messaggio del 18/12/2019...

> I've reported this to atleast Debian and Ubuntu along with a proper fix.

Many thanks!!!

--
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
Associazione ``La Nostra Famiglia'' http://www.lanostrafamiglia.it/
Polo FVG - Via della Bont?, 7 - 33078 - San Vito al Tagliamento (PN)
marco.gaiarin(at)lanostrafamiglia.it t +39-0434-842711 f +39-0434-842797

Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
http://www.lanostrafamiglia.it/index.php/it/sostienici/5x1000
(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)