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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
