Dmitriy Matrosov via Exim-users <exim-users@???> (Sa 07 Sep 2019 10:39:20 CEST):
> >
> > And, if your Exim is linked against GnuTLS there is no $tls_sni variable
> > at all. But - to my knowledge - the exploitable string is written to the
> > -H spool file anyway (and read back).
>
> On Debian 7, 8, 9 (exim is linked against gnutls) and there is $tls_sni
> option. On Debian 8, 9 also there is $tls_in_sni option (as expected).
Thank you for pointing out. I should have been more specific. If you do
not have a $tls_in_sni, check if $tls_sni exists. Otherwise you may have
an Exim version not supporting this *variable*. This does not imply,
that you're not vulnerable.
The existence of this variable seems to have changed over the time,
in 4.80 it existed, in 4.84 it didn't exist for GnuTLS, in 4.89 it was
there again.
exim-4_80:src/src/expand.c
#ifdef SUPPORT_TLS
{ "tls_sni", vtype_stringptr, &tls_sni },
#endif
exim-4_84:src/src/expand.c
#if defined(SUPPORT_TLS) && !defined(USE_GNUTLS)
{ "tls_in_sni", vtype_stringptr, &tls_in.sni },
#endif
…
#if defined(SUPPORT_TLS) && !defined(USE_GNUTLS)
{ "tls_sni", vtype_stringptr, &tls_in.sni }, /* mind the alphabetical order! */
#endif
exim-4_89:src/src/expand.c
#if defined(SUPPORT_TLS)
{ "tls_in_sni", vtype_stringptr, &tls_in.sni },
#endif
…
#if defined(SUPPORT_TLS)
{ "tls_sni", vtype_stringptr, &tls_in.sni }, /* mind the alphabetical order! */
#endif
I checked the original source, and didn't check the versions in between.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
