Extra paranoia around STARTTLS-with-data-in-buffer.

diff --git a/doc/doc-txt/ChangeLog b/doc/doc-txt/ChangeLog
index 2b3ec8573b68cd2fcfb9eb77354c5e94c5ee8705..37c7f216ffe0cfd81f6be85b82ed04bda776a742 100644 (file)
--- a/doc/doc-txt/ChangeLog
+++ b/doc/doc-txt/ChangeLog
@@ -18,6 +18,8 @@ PP/04 New "dns_use_edns0" global option.
 PP/05 Don't segfault on misconfiguration of ref:name exim-user as uid.
       Bugzilla 1098.
 
+PP/06 Extra paranoia around STARTTLS-with-data-in-buffer.
+
 
 Exim version 4.75
 -----------------

diff --git a/src/src/smtp_in.c b/src/src/smtp_in.c
index 2ef6977024d543a459be6d72fc5be17ba138922a..500000be446a0c0dec2333d9675a42c819e25fca 100644 (file)
--- a/src/src/smtp_in.c
+++ b/src/src/smtp_in.c
@@ -3844,6 +3844,23 @@ while (done <= 0)
     toomany = FALSE;
     cmd_list[CMD_LIST_STARTTLS].is_mail_cmd = FALSE;
 
+    /* There's an attack where more data is read in past the STARTTLS command
+    before TLS is negotiated, then assumed to be part of the secure session
+    when used afterwards; we use segregated input buffers, so are not
+    vulnerable, but we want to note when it happens and, for sheer paranoia,
+    ensure that the buffer is "wiped".
+    Pipelining sync checks will normally have protected us too, unless disabled
+    by configuration. */
+
+    if (receive_smtp_buffered())
+      {
+      DEBUG(D_any)
+        debug_printf("Non-empty input buffer after STARTTLS; naive attack?");
+      if (tls_active < 0)
+        smtp_inend = smtp_inptr = smtp_inbuffer;
+      /* and if TLS is already active, tls_server_start() should fail */
+      }
+
     /* Attempt to start up a TLS session, and if successful, discard all
     knowledge that was obtained previously. At least, that's what the RFC says,
     and that's what happens by default. However, in order to work round YAEB,