Re: [Courier-imap] Ubuntu bugs: pop3 and imap tls plaintext command injection

[Sam V. <mr...@co...>]

Jakob Bohm writes:

> Which is why I ask the simple question of what the POP3 and IMAP4
> standards say about how the server is supposed to handle bytes that
> arrive after the LF that follows the STLS/STARTTLS command.
>
> Is the server supposed to parse those bytes as anything but TLS
> handshake messages?

RFC 2595 says:

3. IMAP STARTTLS extension

   When the TLS extension is present in IMAP, "STARTTLS" is listed as a
   capability in response to the CAPABILITY command.  This extension
   adds a single command, "STARTTLS" to the IMAP protocol which is used
   to begin a TLS negotiation.

3.1. STARTTLS Command

   Arguments:  none

   Responses:  no specific responses for this command

   Result:     OK - begin TLS negotiation
               BAD - command unknown or arguments invalid

      A TLS negotiation begins immediately after the CRLF at the end of
      the tagged OK response from the server.  Once a client issues a
      STARTTLS command, it MUST NOT issue further commands until a
      server response is seen and the TLS negotiation is complete.

      The STARTTLS command is only valid in non-authenticated state.
      The server remains in non-authenticated state, even if client
      credentials are supplied during the TLS negotiation.  The SASL
      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
      client credentials are successfully exchanged, but servers
      supporting the STARTTLS command are not required to support the
      EXTERNAL mechanism.

4. POP3 STARTTLS extension

   The POP3 STARTTLS extension adds the STLS command to POP3 servers.
   If this is implemented, the POP3 extension mechanism [POP3EXT] MUST
   also be implemented to avoid the need for client probing of multiple
   commands.  The capability name "STLS" indicates this command is
   present and permitted in the current state.

      STLS

         Arguments: none

         Restrictions:
             Only permitted in AUTHORIZATION state.

         Discussion:
             A TLS negotiation begins immediately after the CRLF at the
             end of the +OK response from the server.  A -ERR response
             MAY result if a security layer is already active.  Once a
             client issues a STLS command, it MUST NOT issue further
             commands until a server response is seen and the TLS
             negotiation is complete.


There's no mention of what the server should or should not do, just what the  
client can do.

This was written long before the underlying issue came up.