Hi again.
On Thu, Jan 16, 2020 at 02:30:35PM +0300, Evgeniy Berdnikov via Exim-users wrote:
> On Thu, Jan 16, 2020 at 11:05:47AM +0000, Jeremy Harris via Exim-users wrote:
> > On 16/01/2020 10:30, Evgeniy Berdnikov via Exim-users wrote:
> > > Maybe some variation of this approach have chances to survive, say,
> > > special pools with "untainted" strings and special functions to put
> > > a string to such pool after all checks (other strings should be
> > > considered as "tainted").
> >
> > Oddly enough, that is exactly what is implemented for the "slow"
> > version of taint-tracking.
>
> Well, ater recompilation with -DTAINT_CHECK_SLOW (as Andreas Metzler
> suggested) my test copy of Exim runs 2 days inside Linux LXC container
> without problems. I belive this is a right way. Thank you.
Yesterday I tried new debian build -- packages exim4-*_4.93-9 with a patch
74_22-Taint-hybrid-checking-mode.patch, commented as:
JH/22 Taint checking: move to a hybrid approach for checking. Previously, one
of two ways was used, depending on a build-time flag. The fast method
relied on assumptions about the OS and libc malloc, which were known to
not hold for the BSD-derived platforms, and discovered to not hold for
32-bit Linux either. In fact the glibc documentation describes cases
where these assumptions do not hold. The new implementation tests for
the situation arising and actively switches over from fast to safe mode.
I've got many failure records in panic.log: "Taint mismatch, Ustrncpy:
rewrite_one_header 611".
After rollback from 4.93-9 to previously mentioned self-compiled version
4.93-5 with -DTAINT_CHECK_SLOW all my relays are running fine.
Just to remind: the problem arises from rewrite rule
*@XXX.msk.ru ${lookup{$0}wildlsearch{/path/to/maps/XXX.msk.ru.map}{$value}{${sg{$local_part}{_}{.}}@???}} Fcbtrf
which have $local_part inside expression.
--
Eugene Berdnikov
