Re: [exim] [oss-security] Sv: CVE-2019-15846: Exim - local o…

On 2019-09-06 at 20:50 +0200, Sebastian Nielsen wrote:
> Shouldn't this be in connect ACL?
> How would the deny in MAIL FROM prevent the exploit? What I have understand is that there is exploit in the SNI of the TLS negotiation, thus the whole connect attempt must be rejected right?

The connect ACL won't protect you against STARTTLS usage, which is far
more common for email than TLS-on-connect.

I myself use the HELO ACL.

Blocking in the MAIL ACL is safe. The problem is not in the TLS SNI
itself. The problem relates to safely storing the SNI in spool files
for messages and what happens when Exim reads those values back later.

Unless and until an email is spooled, there is no security hole.

Some time back, the TLS SNI would be written unescaped to the spool
files. That meant that a newline in SNI would let attackers introduce
arbitrary metadata into the spool (which includes ACL variables,
commonly subject to expansion, so ${run ...} could be injected). So I
fixed it, by escaping the SNI when writing it to the spool file and
unescaping when reading it back.

I remember sighing wistfully because I'm not fond of escaping/quoting
and much prefer using DJB netstrings, but didn't fancy rewriting all of
Exim's spool file handling, so just used the escape/unescape functions
we had.

I missed that the escape function didn't escape everything which the
unescape function would unescape, and that this provided a means to mess
up Exim's internal state. Qualys were able to prove out that yes, this
is exploitable.

AFAIK that's the first remote execution exploitable security hole I've
ever introduced to a project. :(

-Phil