So, at this time the STARTTLS-with-extra-data-in-input-buffer
vulnerability does not apply to Exim, because we switch to a new input
buffer when we enable TLS; any extra data read will have been left in
the plaintext input buffer and will be ignored for the rest of the
lifetime of this process. Exim does not support ending TLS and
continuing SMTP in plaintext.
Nonetheless, having attack data lingering in a buffer for which pointers
are valid doesn't seem like a good idea; perhaps one day someone will
decide that we *should* be able to end TLS within an SMTP session and
continue on.
The simple fix is:
http://git.exim.org/users/pdp/exim.git/commit/da80c2a8ed49427334af613c00df65ae301cacdd
which debug-logs that something hinky is going on and resets buffer
pointers, effectively discarding the data from the input stream.
One concern: since this is a buffer which holds attacker-supplied data
and one which is going to linger untouched after TLS is negotiated,
might it be a tempting target to leave shell-code in, for another
exploit to jump to, at a predictable address?
Should we also just memset() the plaintext buffer to fill it with \0
content at the point that TLS is started, always? After all, even
without a data-past-TLS, a pipelined NOOP command with attack-code as
its parameter, immediately followed by STARTTLS as the terminal of the
pipeline would also leave shellcode in an available buffer. Fortunately
the input buffer is malloc()d, so not fixed in location; however, with
many systems using OS distribution configs, the memory allocations might
be semi-predictable, leaving a common set of candidate locations.
Thoughts?
-Phil
