Marius Schwarz <cyborg2@???> (Fr 06 Sep 2019 23:20:42 CEST):
> sorry to interrupt, but in what way does the existence of the sni var reflect the internal problem the exploit is using???
The problem arises when reading the -H files back from the spool.
There is a simple parser, parsing these '-<key> <value>' lines
If such line ends with a backslash, we get a problem.
-tls_sni and -tls_peer_dn are the lines that are controllable by the
attacker and not checked in any other way. (The other strings like
sender or recipient address or cipher modes have to pass several other
stages and are considered to be clean.)
> @heiko: the var could be added later, after the sni feature had been introduced to exim. Therefor the problem could be older than the introduction date.
The problem is there since the SNI and the peer DN are read from the spool, and this should match
the introduction of $tls_sni and $tls_peerdn (later renamed to
$tls_in_sni, $tls_in_peerdn).
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 ------------ -
