Re: Spawn milter access to Verified Sender database
Dear Postfix users,
I'm really grateful to Wietse who thankfully raised concerns regarding
Perl querying the verified senders database using postmap via the shell
as there was a real chance the sender (easily faked) could carry out
evil. My use of 'backticks' was a very bad idea as it turns out. I
managed to escape the script myself so very easy to professional
exploiters to do so. Lesson learned the Wietse way, not the way that
ends up with flames and spilt tears!
I think(?) that I have found the solution courtesy of
https://www.w3.org/Security/faq/.back/wwwsf5.html and perldocs.org (open).
I modified one of the W3C examples and shoved it into my function :
sub postmap
{
my $sender=shift;
$senderchk=$sender;
$senderchk =~ s/[\$#~!&*{}()\[\];,:?^ `\\\/]+//g; # check for undesirable
chars even if legal
if($sender ne $senderchk) { return "9:0:0:Database not probed. Suspect characters
detected in sender address.)" }
my $sf ="lmdb:/var/lib/postfix/verified_senders_2021";
$vsresult="";
$perlfork = open(POSTMAP,"-|"); die "Couldn't open perl fork" unless
defined($perlfork);
exec "/usr/sbin/postmap", "-fq", "$sender", "$sf", or die "Couldn't execute
postmap" if $perlfork == 0;
while () { $vsresult= "$_"; }
close POSTMAP;
return "$vsresult";
}
I'm hoping this will be that last on this subject but I'll put it out to
you who have a superior knowledge of security. Is this method now safe?
Please, if anyone can see any security issues, do let me know. Apologies
to the Perl purists. I'm pretty sure I could have done better there, but
it does work .My main concern is if its safe.
Many thanks to you all,
Best wishes,
Mick.
Re: Spawn milter access to Verified Sender database
On Sun, Nov 28, 2021 at 11:11:55PM +, M Champion
wrote:
> Dear Postfix users,
>
> I'm really grateful to Wietse who thankfully raised concerns regarding Perl
> querying the verified senders database using postmap via the shell as there
> was a real chance the sender (easily faked) could carry out evil. My use of
> 'backticks' was a very bad idea as it turns out. I managed to escape the
> script myself so very easy to professional exploiters to do so. Lesson
> learned the Wietse way, not the way that ends up with flames and spilt
> tears!
>
> I think(?) that I have found the solution courtesy of
> https://www.w3.org/Security/faq/.back/wwwsf5.html and perldocs.org (open).
> I modified one of the W3C examples and shoved it into my function :
>
> sub postmap
> {
> my $sender=shift;
> $senderchk=$sender;
> $senderchk =~ s/[\$#~!&*{}()\[\];,:?^ `\\\/]+//g; # check for undesirable
> chars even if legal
> if($sender ne $senderchk) { return "9:0:0:Database not probed. Suspect
> characters detected in sender address.)" }
> my $sf ="lmdb:/var/lib/postfix/verified_senders_2021";
> $vsresult="";
> $perlfork = open(POSTMAP,"-|"); die "Couldn't open perl fork" unless
> defined($perlfork);
> exec "/usr/sbin/postmap", "-fq", "$sender", "$sf", or die "Couldn't execute
> postmap" if $perlfork == 0;
> while () { $vsresult= "$_"; }
> close POSTMAP;
> return "$vsresult";
> }
>
>
> I'm hoping this will be that last on this subject but I'll put it out to you
> who have a superior knowledge of security. Is this method now safe? Please,
> if anyone can see any security issues, do let me know. Apologies to the Perl
> purists. I'm pretty sure I could have done better there, but it does work
> .My main concern is if its safe.
>
> Many thanks to you all,
>
>
> Best wishes,
> Mick.
That looks good (exec with argument list rather than interpolated string).
Minor Perl quibbles (Sorry, couldn't help myself):
The comma before "or die" can be removed.
Instead of the global file handle POSTMAP, it might be better to use "my
$postmapfh"
(user-defined global file handles might disappear in a future version of
Perl).
Just checking:
Is each line of output from POSTMAP supposed to replace any previous output,
or should it append to it?
cheers,
raf
Re: Spawn milter access to Verified Sender database
Hi raf,
Replies in-line ;
Dear Postfix users,
I'm really grateful to Wietse who thankfully raised concerns regarding Perl
querying the verified senders database using postmap via the shell as there
was a real chance the sender (easily faked) could carry out evil. My use of
'backticks' was a very bad idea as it turns out. I managed to escape the
script myself so very easy to professional exploiters to do so. Lesson
learned the Wietse way, not the way that ends up with flames and spilt
tears!
I think(?) that I have found the solution courtesy of
https://www.w3.org/Security/faq/.back/wwwsf5.html and perldocs.org (open).
I modified one of the W3C examples and shoved it into my function :
sub postmap
{
my $sender=shift;
$senderchk=$sender;
$senderchk =~ s/[\$#~!&*{}()\[\];,:?^ `\\\/]+//g; # check for undesirable
chars even if legal
if($sender ne $senderchk) { return "9:0:0:Database not probed. Suspect characters
detected in sender address.)" }
my $sf ="lmdb:/var/lib/postfix/verified_senders_2021";
$vsresult="";
$perlfork = open(POSTMAP,"-|"); die "Couldn't open perl fork" unless
defined($perlfork);
exec "/usr/sbin/postmap", "-fq", "$sender", "$sf", or die "Couldn't execute
postmap" if $perlfork == 0;
while () { $vsresult= "$_"; }
close POSTMAP;
return "$vsresult";
}
I'm hoping this will be that last on this subject but I'll put it out to you
who have a superior knowledge of security. Is this method now safe? Please,
if anyone can see any security issues, do let me know. Apologies to the Perl
purists. I'm pretty sure I could have done better there, but it does work
.My main concern is if its safe.
Many thanks to you all,
Best wishes,
Mick.
On 28/11/2021 23:40, raf wrote:
That looks good (exec with argument list rather than interpolated string).
Phew! Thanks for the vote of confidence.
Minor Perl quibbles (Sorry, couldn't help myself):
I don't mind one bit. I only speak for myself mind you.
The comma before "or die" can be removed.
I will remove it.
Instead of the global file handle POSTMAP, it might be better to use "my
$postmapfh"
I will test that out tomorrow (er, today) in the afternoon after some
sleep. I'd rather future poof it now, than have to work out what went
wrong later later. Thank you for the tip.
Just checking: Is each line of output from POSTMAP supposed to replace
any previous output, or should it append to it?
Postmap only outputs one line per query. Either it replies with a result
or NULL. Maybe
while () { $vsresult= "$_"; }
could be replaced with
$vsresult= "$_";
?? I will test. No real point in looping if only one line is returnd.
Thanks,
Mick.
Logging silence
I feel like I'm missing something really obvious here... :( Multiple RedHat8 servers, Postfix configured on all of them for internal network mail server (primarily server log updates, etc. to admin). On all of them bar one, I get relevant logging in /var/log/maillog. On the one - maillog remains empty, even though mail is being sent OK. I've diff-compared main.cf, master.cf and rsyslog.conf on one that logs to maillog and the one that doesn't. Main.cf has a different hostname specified, master.cf is identical. Both rsyslogd.conf have the following setup for mail: *.info;mail.none;authpriv.none;cron.none/var/log/messages mail.* -/var/log/maillog Yet nothing gets logged to /var/log/maillog on ONE of them. Mail is getting sent and received from the server. Logging is working for other services. journalctl -u postfix shows (at the end): Jan 09 03:43:06 emp80.simonandkate.lan postfix/pickup[3162096]: 35E30201E928: uid=0 from= Jan 09 03:43:06 emp80.simonandkate.lan postfix/cleanup[3169954]: 35E30201E928: message-id=<20210108174306.35e30201e...@emp80.simonandkate.lan> Jan 09 03:43:06 emp80.simonandkate.lan postfix/qmgr[1989]: 35E30201E928: from=, size=102096, nrcpt=1 (queue active) Jan 09 03:43:06 emp80.simonandkate.lan postfix/smtp[3169963]: 35E30201E928: to=, relay=192.168.1.235[192.168.1.235]:25, delay> Jan 09 03:43:06 emp80.simonandkate.lan postfix/qmgr[1989]: 35E30201E928: removed -- Reboot -- Jan 18 02:05:45 emp80.simonandkate.lan postfix/qmgr[1958]: warning: backward time jump detected -- slewing clock Jan 18 02:11:25 emp80.simonandkate.lan postfix/qmgr[1958]: warning: backward time jump recovered -- back to normality -- Reboot -- Jan 25 03:04:36 emp80.simonandkate.lan postfix/qmgr[1968]: warning: backward time jump detected -- slewing clock Jan 25 03:08:02 emp80.simonandkate.lan postfix/qmgr[1968]: warning: backward time jump recovered -- back to normality -- Reboot -- Mar 07 05:35:51 emp80.simonandkate.lan postfix/qmgr[1965]: warning: backward time jump detected -- slewing clock Mar 07 05:39:01 emp80.simonandkate.lan postfix/qmgr[1965]: warning: backward time jump recovered -- back to normality -- Reboot -- Apr 11 05:04:12 emp80.simonandkate.lan postfix/qmgr[2009]: warning: backward time jump detected -- slewing clock Apr 11 05:11:53 emp80.simonandkate.lan postfix/qmgr[2009]: warning: backward time jump recovered -- back to normality -- Reboot -- Jun 07 22:40:56 emp80.simonandkate.lan postfix/qmgr[1975]: warning: backward time jump detected -- slewing clock Jun 07 22:49:31 emp80.simonandkate.lan postfix/qmgr[1975]: warning: backward time jump recovered -- back to normality -- Reboot -- Nov 04 17:58:53 emp80.simonandkate.lan postfix/qmgr[2047]: warning: backward time jump detected -- slewing clock Nov 04 18:00:01 emp80.simonandkate.lan postfix/qmgr[2047]: warning: backward time jump recovered -- back to normality ...where as can be seen it was logging OK in January, then it stopped. Permissions on the log file: -rw--- 1 root root0 Nov 28 03:27 maillog What am I missing?? -- Simon Wilson
Re: Logging silence
> "Simon" == Simon Wilson writes: Simon> I feel like I'm missing something really obvious here... :( Simon> Multiple RedHat8 servers, Postfix configured on all of them for Simon> internal network mail server (primarily server log updates, Simon> etc. to admin). Have you restarted syslog (or syslog-ng, or rsyslog, etc) on the problematic server? Simon> On all of them bar one, I get relevant logging in /var/log/maillog. On Simon> the one - maillog remains empty, even though mail is being sent OK. Simon> I've diff-compared main.cf, master.cf and rsyslog.conf on one that Simon> logs to maillog and the one that doesn't. Main.cf has a different Simon> hostname specified, master.cf is identical. Both rsyslogd.conf have Simon> the following setup for mail: Simon> *.info;mail.none;authpriv.none;cron.none/var/log/messages Simon> mail.* -/var/log/maillog Simon> Yet nothing gets logged to /var/log/maillog on ONE of them. Mail is Simon> getting sent and received from the server. Simon> Logging is working for other services. Simon> journalctl -u postfix shows (at the end): Simon> Jan 09 03:43:06 emp80.simonandkate.lan postfix/pickup[3162096]: Simon> 35E30201E928: uid=0 from= Simon> Jan 09 03:43:06 emp80.simonandkate.lan postfix/cleanup[3169954]: Simon> 35E30201E928: Simon> message-id=<20210108174306.35e30201e...@emp80.simonandkate.lan> Simon> Jan 09 03:43:06 emp80.simonandkate.lan postfix/qmgr[1989]: Simon> 35E30201E928: from=, size=102096, nrcpt=1 Simon> (queue active) Simon> Jan 09 03:43:06 emp80.simonandkate.lan postfix/smtp[3169963]: Simon> 35E30201E928: to=, Simon> relay=192.168.1.235[192.168.1.235]:25, delay> Simon> Jan 09 03:43:06 emp80.simonandkate.lan postfix/qmgr[1989]: Simon> 35E30201E928: removed Simon> -- Reboot -- Simon> Jan 18 02:05:45 emp80.simonandkate.lan postfix/qmgr[1958]: warning: Simon> backward time jump detected -- slewing clock Simon> Jan 18 02:11:25 emp80.simonandkate.lan postfix/qmgr[1958]: warning: Simon> backward time jump recovered -- back to normality Simon> -- Reboot -- Simon> Jan 25 03:04:36 emp80.simonandkate.lan postfix/qmgr[1968]: warning: Simon> backward time jump detected -- slewing clock Simon> Jan 25 03:08:02 emp80.simonandkate.lan postfix/qmgr[1968]: warning: Simon> backward time jump recovered -- back to normality Simon> -- Reboot -- Simon> Mar 07 05:35:51 emp80.simonandkate.lan postfix/qmgr[1965]: warning: Simon> backward time jump detected -- slewing clock Simon> Mar 07 05:39:01 emp80.simonandkate.lan postfix/qmgr[1965]: warning: Simon> backward time jump recovered -- back to normality Simon> -- Reboot -- Simon> Apr 11 05:04:12 emp80.simonandkate.lan postfix/qmgr[2009]: warning: Simon> backward time jump detected -- slewing clock Simon> Apr 11 05:11:53 emp80.simonandkate.lan postfix/qmgr[2009]: warning: Simon> backward time jump recovered -- back to normality Simon> -- Reboot -- Simon> Jun 07 22:40:56 emp80.simonandkate.lan postfix/qmgr[1975]: warning: Simon> backward time jump detected -- slewing clock Simon> Jun 07 22:49:31 emp80.simonandkate.lan postfix/qmgr[1975]: warning: Simon> backward time jump recovered -- back to normality Simon> -- Reboot -- Simon> Nov 04 17:58:53 emp80.simonandkate.lan postfix/qmgr[2047]: warning: Simon> backward time jump detected -- slewing clock Simon> Nov 04 18:00:01 emp80.simonandkate.lan postfix/qmgr[2047]: warning: Simon> backward time jump recovered -- back to normality Simon> ...where as can be seen it was logging OK in January, then it stopped. Simon> Permissions on the log file: Simon> -rw--- 1 root root0 Nov 28 03:27 maillog Simon> What am I missing?? Simon> -- Simon> Simon Wilson
Re: Spawn milter access to Verified Sender database
On Mon, Nov 29, 2021 at 12:20:15AM +, M Champion
wrote:
> Hi raf,
>
> Replies in-line ;
>
>
> > > Dear Postfix users,
> > >
> > > I'm really grateful to Wietse who thankfully raised concerns regarding
> > > Perl
> > > querying the verified senders database using postmap via the shell as
> > > there
> > > was a real chance the sender (easily faked) could carry out evil. My use
> > > of
> > > 'backticks' was a very bad idea as it turns out. I managed to escape the
> > > script myself so very easy to professional exploiters to do so. Lesson
> > > learned the Wietse way, not the way that ends up with flames and spilt
> > > tears!
> > >
> > > I think(?) that I have found the solution courtesy of
> > > https://www.w3.org/Security/faq/.back/wwwsf5.html and perldocs.org (open).
> > > I modified one of the W3C examples and shoved it into my function :
> > >
> > > sub postmap
> > > {
> > >my $sender=shift;
> > >$senderchk=$sender;
> > >$senderchk =~ s/[\$#~!&*{}()\[\];,:?^ `\\\/]+//g; # check for
> > > undesirable chars even if legal
> > >if($sender ne $senderchk) { return "9:0:0:Database not probed. Suspect
> > > characters detected in sender address.)" }
> > >my $sf ="lmdb:/var/lib/postfix/verified_senders_2021";
> > >$vsresult="";
> > >$perlfork = open(POSTMAP,"-|"); die "Couldn't open perl fork" unless
> > > defined($perlfork);
> > >exec "/usr/sbin/postmap", "-fq", "$sender", "$sf", or die "Couldn't
> > > execute postmap" if $perlfork == 0;
> > >while () { $vsresult= "$_"; }
> > >close POSTMAP;
> > >return "$vsresult";
> > > }
> > >
> > >
> > > I'm hoping this will be that last on this subject but I'll put it out to
> > > you
> > > who have a superior knowledge of security. Is this method now safe?
> > > Please,
> > > if anyone can see any security issues, do let me know. Apologies to the
> > > Perl
> > > purists. I'm pretty sure I could have done better there, but it does work
> > > .My main concern is if its safe.
> > >
> > > Many thanks to you all,
> > >
> > >
> > > Best wishes,
> > > Mick.
>
>
> > On 28/11/2021 23:40, raf wrote:
> > That looks good (exec with argument list rather than interpolated string).
>
> Phew! Thanks for the vote of confidence.
Yes, avoiding the need to use /bin/sh is a big win.
> > Minor Perl quibbles (Sorry, couldn't help myself):
> I don't mind one bit. I only speak for myself mind you.
>
>
>
> >The comma before "or die" can be removed.
>
> I will remove it.
>
>
> >Instead of the global file handle POSTMAP, it might be better to use "my
> > $postmapfh"
>
> I will test that out tomorrow (er, today) in the afternoon after some sleep.
> I'd rather future poof it now, than have to work out what went wrong later
> later. Thank you for the tip.
>
>
>
> > Just checking: Is each line of output from POSTMAP supposed to replace
> > any previous output, or should it append to it?
>
> Postmap only outputs one line per query. Either it replies with a result or
> NULL. Maybe
Of course. I was being dumb.
> while () { $vsresult= "$_"; }
>
> could be replaced with
>
> $vsresult= "$_";
>
> ?? I will test. No real point in looping if only one line is returnd.
Actually, postmap will output zero lines if the lookup
fails, or one line if it succeeds, so the loop does do
something. If the lookup fails, the while loop body
won't execute, and the function will return "". If the
lookup succeeds, the while loop body will execute, and
the function will return the lookup result. So it's
good as it is.
One last bit of advice, add "use strict;" and "use
warnings;" to the script and add "my" before the first
use of each variable. You know you want to. :-)
> Thanks,
> Mick.
cheers,
raf
Re: Logging silence
- Message from John Stoffel - Date: Sun, 28 Nov 2021 21:37:12 -0500 From: John Stoffel Subject: Re: Logging silence To: si...@simonandkate.net Cc: postfix-users@postfix.org "Simon" == Simon Wilson writes: Simon> I feel like I'm missing something really obvious here... :( Simon> Multiple RedHat8 servers, Postfix configured on all of them for Simon> internal network mail server (primarily server log updates, Simon> etc. to admin). Have you restarted syslog (or syslog-ng, or rsyslog, etc) on the problematic server? Yes, the server has been rebooted *many* times, and I have also tried restarting rsyslog. Simon - End message from John Stoffel - ___ Simon Wilson M: 0400 12 11 16
Re: Logging silence
> "Simon" == Simon Wilson writes: Simon> - Message from John Stoffel - Simon>Date: Sun, 28 Nov 2021 21:37:12 -0500 Simon>From: John Stoffel Simon> Subject: Re: Logging silence Simon> To: si...@simonandkate.net Simon> Cc: postfix-users@postfix.org Simon> "Simon" == Simon Wilson writes: Simon> I feel like I'm missing something really obvious here... :( Simon> Multiple RedHat8 servers, Postfix configured on all of them for Simon> internal network mail server (primarily server log updates, Simon> etc. to admin). Simon> Have you restarted syslog (or syslog-ng, or rsyslog, etc) on the Simon> problematic server? Simon> Yes, the server has been rebooted *many* times, and I have also Simon> tried restarting rsyslog. selinux running on there? Is it impossible to just clone one of the good systems and replace this problematic one? Compare the installed packages between the systems, along with the 'systemctl' output to look for differences. More details would help us help you. John
Re: Spawn milter access to Verified Sender database
On 11/28/21 22:04, raf wrote: One last bit of advice, add "use strict;" and "use warnings;" to the script and add "my" before the first use of each variable. You know you want to. :-) Better yet, separately declare your variables in their proper scope before you use them. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
Re: Logging silence
- Message from John Stoffel - Date: Sun, 28 Nov 2021 22:58:01 -0500 From: John Stoffel Subject: Re: Logging silence To: si...@simonandkate.net Cc: John Stoffel , postfix-users@postfix.org "Simon" == Simon Wilson writes: Simon> - Message from John Stoffel - Simon> Date: Sun, 28 Nov 2021 21:37:12 -0500 Simon> From: John Stoffel Simon> Subject: Re: Logging silence Simon> To: si...@simonandkate.net Simon> Cc: postfix-users@postfix.org Simon> "Simon" == Simon Wilson writes: Simon> I feel like I'm missing something really obvious here... :( Simon> Multiple RedHat8 servers, Postfix configured on all of them for Simon> internal network mail server (primarily server log updates, Simon> etc. to admin). Simon> Have you restarted syslog (or syslog-ng, or rsyslog, etc) on the Simon> problematic server? Simon> Yes, the server has been rebooted *many* times, and I have also Simon> tried restarting rsyslog. selinux running on there? Is it impossible to just clone one of the good systems and replace this problematic one? Compare the installed packages between the systems, along with the 'systemctl' output to look for differences. More details would help us help you. John I worked it out. journald.conf was set to MaxLevelStore=notice, so it wasn't just postfix not logging, just that was the symptom picked up. I really was missing something obvious. Now I need to work back to see how / who changed that. Thank you for support. Simon ___ Simon Wilson
