Bug#527862: libmilter1.0.1: dkim-milter and milter-greylist segfault in libmilter
Hello, Sebastian Wiesinger wrote: Package: libmilter1.0.1 Version: 8.14.3-5 Followup-For: Bug #527862 There's a but in Lenny libmilter 1.0.1. You shall : * Apply the patch appearing in the bug web page * get and install the patched libmilter at : http://www.j-chkmail.org/download/libmilter/libmilter-workers-8.14.3-1.tgz JM -- --- Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr Ecole des Mines de Paris 60, bd Saint Michel 75272 - PARIS CEDEX 06 mailto:jose-marcio.mart...@mines-paristech.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527862: libmilter: Remote DoS? All milters on multiple servers segfaulting
Bjørn Mork wrote: Jose-Marcio Martins da Cruz jose-marcio.mart...@mines-paristech.fr writes: ... I'm afraid I don't know how many connections were open when the milters crashed, but the mail statistics does not show any unusual activity. And these servers are very lightly loaded (less than 1 message per minute on average). Well... There are still something which intrigates me. The original version of the pool of works is running for more than two years on a Debian etch, which was upgraded to Lenny some time ago. But the MTA is postfix, not sendmail. An not a single crash... A possible explanation is the timeouts set up on sendmail side. This bug only generates a crash when an inactive connection was detected by libmilter (not by the MTA). So, if the MTA timeout for inactive connections is less than two hours, the connection will be closed by the MTA and the filter will never crash. I'm wondering if some of the default timeouts set by debian can't be bigger than two hours... Can you tell me what are your timeout values ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527862: libmilter: Remote DoS? All milters on multiple servers segfaulting
Hello,
Bjørn Mork wrote:
tags 527862 + patch security
thanks
The last few days I've had both clamav-milter and spamass-milter segfault on
two separate servers both running Debian lenny:
Jul 13 04:59:53 canardo kernel: [9021793.803024] spamass-milter[22767]:
segfault at 130 ip 7f94da384900 sp 429190e0 error 4 in
libmilter.so.1.0.1[7f94da379000+f000]
Jul 13 05:00:33 canardo kernel: [9021863.827618] clamav-milter[22887]: segfault
at 130 ip 7f7aaa945900 sp 4234b0f0 error 4 in
libmilter.so.1.0.1[7f7aaa93a000+f000]
Jul 13 05:55:57 huey kernel: [4728098.560126] spamass-milter[20935]: segfault
at 130 ip 7fa1b92d1900 sp 4178a0e0 error 4 in
libmilter.so.1.0.1[7fa1b92c6000+f000]
This might be because they are handling mail for some of the same
domains, and that a single buggy mail server is bringing them both down.
But I believe it is still a somewhat serious security issue, as it is
obviously possible to bring down virus and spam filtering by a remote
connection.
I'm now testing a modified version of the patch attached to this bug,
and this seems to fix the problem. Please consider adding this to Lenny
as a security fix. Thanks.
I'm attaching the last version of worker.c I'm using. Ther's a little
difference.
But I have some comments :
I'm the author of the pool of workers patch, but I'm not from sendmail. This last patch
will be integrate in the next release of sendmail. While it's not out, I'll probably put
it available for download at my web site.
I'm running the original patch on my mail servers for around 5 years without problems.
These servers are under Solaris, FreeBSD or Debian Etch or Lenny... The bug which were
talking about affects only a particular situation when very old stale connections are
closed by libmilter : connections inactive for more than 2 hours. So, it may be hard to
detect if your patch solves the problem or not.
There may be some confusion about the errors. And maybe the reason your milters are
crashing may not be this bug. There is a situation where it's possible to do a DoS and
very most milters crash (but not all). This is related to the number of file descriptors
in use. Do you know how many connections the milter is handling when it crashes ??? If
there are some hundreds the reason maybe this other problem, which is a bug of most
milters, not libmilter.
/*
* Copyright (c) 2003-2004, 2007 Sendmail, Inc. and its suppliers.
* All rights reserved.
*
* By using this file, you agree to the terms and conditions set
* forth in the LICENSE file which can be found at the top level of
* the sendmail distribution.
*
* Contributed by Jose Marcio Martins da Cruz - Ecole des Mines de Paris
* jose-marcio.mart...@ensmp.fr
*/
#include sm/gen.h
SM_RCSID(@(#)$Id: worker.c,v 8.10 2007/12/03 22:06:05 ca Exp $)
#include libmilter.h
#if _FFR_WORKERS_POOL
typedef struct taskmgr_S taskmgr_T;
#define TM_SIGNATURE 0x23021957
struct taskmgr_S
{
long tm_signature; /* has the controller been initialized */
sthread_t tm_tid; /* thread id of controller */
smfi_hd_T tm_ctx_head; /* head of the linked list of contexts */
int tm_nb_workers; /* number of workers in the pool */
int tm_nb_idle; /* number of workers waiting */
int tm_p[2]; /* poll control pipe */
smutex_t tm_w_mutex; /* linked list access mutex */
scond_t tm_w_cond; /* */
};
static taskmgr_T Tskmgr = {0};
#define WRK_CTX_HEAD Tskmgr.tm_ctx_head
#define RD_PIPE (Tskmgr.tm_p[0])
#define WR_PIPE (Tskmgr.tm_p[1])
#define PIPE_SEND_SIGNAL() \
do\
{\
char evt = 0x5a; \
int fd = WR_PIPE; \
if (write(fd, evt, sizeof(evt)) != sizeof(evt)) \
smi_log(SMI_LOG_ERR,\
Error writing to event pipe: %s, \
sm_errstring(errno)); \
} while (0)
#ifndef USE_PIPE_WAKE_POLL
# define USE_PIPE_WAKE_POLL 1
#endif /* USE_PIPE_WAKE_POLL */
/* poll check periodicity (default 1 - 10 s) */
#define POLL_TIMEOUT 1
/* worker conditional wait timeout (default 10 s) */
#define COND_TIMEOUT 10
/* functions */
static int mi_close_session __P((SMFICTX_PTR));
static void *mi_worker __P((void *));
static void *mi_pool_controller __P((void *));
static int mi_list_add_ctx __P((SMFICTX_PTR));
static int mi_list_del_ctx __P((SMFICTX_PTR));
/*
** periodicity of cleaning up old sessions (timedout)
** sessions list will be checked to find old inactive
** sessions each DT_CHECK_OLD_SESSIONS sec
*/
#define DT_CHECK_OLD_SESSIONS 600
#ifndef OLD_SESSION_TIMEOUT
# define OLD_SESSION_TIMEOUT ctx-ctx_timeout
#endif /* OLD_SESSION_TIMEOUT */
/* session states - with respect to the pool of workers */
#define WKST_INIT 0 /* initial state */
#define WKST_READY_TO_RUN 1 /* command ready do be read */
#define WKST_RUNNING 2 /* session running on a worker */
#define WKST_READY_TO_WAIT 3 /* session just finished by a worker */
#define WKST_WAITING 4 /* waiting for new command */
#define WKST_CLOSING 5 /* session finished */
#ifndef MIN_WORKERS
Bug#527862: libmilter: Remote DoS? All milters on multiple servers segfaulting
Bjørn Mork wrote: Jose-Marcio Martins da Cruz jose-marcio.mart...@mines-paristech.fr writes: I'm running the original patch on my mail servers for around 5 years without problems. These servers are under Solaris, FreeBSD or Debian Etch or Lenny... With nfd = 0 inside the for (;;) loop? Strange. I could not get that to handle anything at all. As long as rebuild_set was always true, nfd will be set to a correct value, each time the loop was run. The bug which were talking about affects only a particular situation when very old stale connections are closed by libmilter : connections inactive for more than 2 hours. So, it may be hard to detect if your patch solves the problem or not. Yes, I understand that. But does that mean that the bug can be triggered by connecting to a server running milters and leaving the connection open for more than 2 hours? If so, it should be fairly easy both to test and, unfortunately, to use this for a DoS attack... This is one condition, but not the only one. I'm afraid I don't know how many connections were open when the milters crashed, but the mail statistics does not show any unusual activity. And these servers are very lightly loaded (less than 1 message per minute on average). Another hint pointing at libmilter, is the fact that both clamav-milter and spamass-milter crashed at the same time Both subjects are related to libmilter. The second one is related to the number of file descriptors in use. There were many messages in comp.mail.sendmail newsgroup many years ago. It's up to milters to control the number of file descriptors in use, not to libmilter. So although it's related to libmilter, it's not a libmilter bug. But when it happens, libmilter logs something at some syslog file. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527862: libmilter: Remote DoS? All milters on multiple servers segfaulting
Jose-Marcio Martins da Cruz wrote: I'm attaching the last version of worker.c I'm using. Ther's a little difference. This last patch will be integrated in the next release of sendmail. While it's not out, I'll probably put it available for download at my web site. While sendmail-8.14.4 isn't out, the patched version of libmilter can be downloaded here : http://j-chkmail.ensmp.fr/libmilter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527862: Libmilter patch
In debian 5.0, _FFR_WORKERS_POOL is enabled by default. I'm running this for many years on
some OSs, including Debian Etch and Lenny. There is a bug in the WORKERS_POOL feature
which can segfaults and kill the filter when old staled connections are closed.
I'm attaching a patch which corrects this bug and also some other minor
harmless bugs.
This patch will be included in the next release of sendmail.
--- worker.c.org2007-12-03 23:06:05.0 +0100
+++ worker.c2009-06-12 19:46:17.0 +0200
@@ -328,6 +328,7 @@
int dim_pfd = 0;
bool rebuild_set = true;
int pcnt = 0; /* error count for poll() failures */
+ time_t lastcheck;
Tskmgr.tm_tid = sthread_get_id();
if (pthread_detach(Tskmgr.tm_tid) != 0)
@@ -345,12 +346,12 @@
}
dim_pfd = PFD_STEP;
+ lastcheck = time(NULL);
for (;;)
{
SMFICTX_PTR ctx;
- int nfd, rfd, i;
+ int nfd = 0, rfd, i;
time_t now;
- time_t lastcheck;
POOL_LEV_DPRINTF(4, (Let's %s again..., WAITFN));
@@ -364,20 +365,20 @@
/* check for timed out sessions? */
if (lastcheck + DT_CHECK_OLD_SESSIONS now)
{
- SM_TAILQ_FOREACH(ctx, WRK_CTX_HEAD, ctx_link)
+ ctx = SM_TAILQ_FIRST(WRK_CTX_HEAD);
+ while (ctx != SM_TAILQ_END(WRK_CTX_HEAD))
{
+ SMFICTX_PTR ctx_nxt;
+
+ ctx_nxt = SM_TAILQ_NEXT(ctx, ctx_link);
if (ctx-ctx_wstate == WKST_WAITING)
{
if (ctx-ctx_wait == 0)
- {
ctx-ctx_wait = now;
- continue;
- }
-
- /* if session timed out, close it */
- if (ctx-ctx_wait + OLD_SESSION_TIMEOUT
-now)
+ else if (ctx-ctx_wait +
OLD_SESSION_TIMEOUT
+ now)
{
+ /* if session timed out, close
it */
sfsistat (*fi_close)
__P((SMFICTX *));
POOL_LEV_DPRINTF(4,
@@ -389,10 +390,9 @@
(void) (*fi_close)(ctx);
mi_close_session(ctx);
- ctx =
SM_TAILQ_FIRST(WRK_CTX_HEAD);
- continue;
}
}
+ ctx = ctx_nxt;
}
lastcheck = now;
}
@@ -465,6 +465,7 @@
}
}
}
+ rebuild_set = false;
}
TASKMGR_UNLOCK();
Bug#524562: libmilter - bug 524562
The proposed patch isn't correct as it's defining a new variable in a context external to the one where the variable is uninitialized. So, the unitialized variable remains uninitialized. The correct patch is below. *** --- worker.c.org2007-12-03 23:06:05.0 +0100 +++ worker.c2009-06-10 13:51:59.0 +0200 @@ -352,6 +352,7 @@ time_t now; time_t lastcheck; + lastcheck = time(NULL); POOL_LEV_DPRINTF(4, (Let's %s again..., WAITFN)); if (mi_stop() != MILTER_CONT) *** -- --- Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr Ecole des Mines de Paris 60, bd Saint Michel 75272 - PARIS CEDEX 06 mailto:jose-marcio.mart...@mines-paristech.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
