Thread: [Courier-imap] Ubuntu bugs: pop3 and imap tls plaintext command injection
Brought to you by:
mrsam
|
From: Fernando Gozalo <fg...@cs...> - 2013-10-15 12:42:11
|
Hi, Searching in Google I have found this url https://bugs.launchpad.net/ubuntu/+source/courier/+bug/1194892 ¿Is there something to worry about? -- Un saludo. Fernando. --------------------------------------------------------------- Fernando Gozalo Rodrigo - Analista de Sistemas Centro de Sistemas Informáticos Universidad Nacional de Educación a Distancia --------------------------------------------------------------- Por favor, no envíe adjuntos de WORD, EXCEL o POWERPOINT Vea http://www.gnu.org/philosophy/no-word-attachments.es.html --------------------------------------------------------------- |
|
From: Sam Varshavchik <mr...@co...> - 2013-10-15 23:48:40
|
Fernando Gozalo writes: > Hi, > > Searching in Google I have found this url > https://bugs.launchpad.net/ubuntu/+source/courier/+bug/1194892 > > ¿Is there something to worry about? No. Just another case of automatically putting one's brain in park, and blindly reading meaningless spewage from an automated "vulnerability" tester. |
|
From: Jakob Bohm <jb-co...@wi...> - 2013-10-21 14:27:36
|
On 16-10-2013 01:48, Sam Varshavchik wrote: > Fernando Gozalo writes: > >> Hi, >> >> Searching in Google I have found this url >> https://bugs.launchpad.net/ubuntu/+source/courier/+bug/1194892 >> >> ¿Is there something to worry about? > > No. Just another case of automatically putting one's brain in park, > and blindly reading meaningless spewage from an automated > "vulnerability" tester. > Reading through the manual test run in that bug report, the key claim in the bug report seems to be: If someone sends a valid IMAP/POP command between STARTTLS and the actual TLS handshake, the valid response will be sent as the first thing inside the TLS session. I think this is only a real problem if one of the following is a real problem: A: Because the stuff before the TLS handshake can be spoofed by a MITM, there may or may not be an opportunity to thus inject known plaintext into the start of the TLS session, which may or may not make it easier to exploit any chosen plaintext vulnerabilities in TLS to break the encryption and listen in on the real users encrypted mail downloads. This does require an additional TLS vulnerability though. B: Because the stuff before the TLS handshake can be spoofed by a MITM, this may be an opportunity to make a broken client handle the unexpected replies to IMAP/POP commands it did not send itself. Any well-written client will already be dealing with that risk for unencrypted connections, but well written e-mail programs are getting rarer these days. I am not sure what the IMAP and POP3 standards have to say about this behavior. How should servers respond to commands received between STARTTLS and the actual TLS handshake. Should they ignore them, respond before the handshake, respond after the handshake or abort the connection as badly corrupted? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded |
|
From: Sam Varshavchik <mr...@co...> - 2013-10-21 23:07:49
|
Jakob Bohm writes: > On 16-10-2013 01:48, Sam Varshavchik wrote: > > Fernando Gozalo writes: > > > >> Hi, > >> > >> Searching in Google I have found this url > >> https://bugs.launchpad.net/ubuntu/+source/courier/+bug/1194892 > >> > >> ¿Is there something to worry about? > > > > No. Just another case of automatically putting one's brain in park, > > and blindly reading meaningless spewage from an automated > > "vulnerability" tester. > > > Reading through the manual test run in that bug report, the key claim in > the bug > report seems to be: > > If someone sends a valid IMAP/POP command between STARTTLS and the > actual TLS > handshake, the valid response will be sent as the first thing inside > the TLS > session. > > I think this is only a real problem if one of the following is a real > problem: Once you have a hostile attacker that's capable of hijacking TCP/IP connections you're done. Game over. You can simply pick up your toys, and go home. The hostile attacker can now do anything. The hostile attacker can simply suppress the server's advertisement of STARTTLS, and force the client to fallback to a plain text connection, since the client will not see that the server is capable of TLS. The MITM attacker does not need to do something this arcane, in order to screw things up. This obviously addresses your point B as well. I can only see one possible situation where this theoretical vulnerability can be possibly exploited in any way to do something that the hostile attacker that's capable of hijacking TCP/IP could not do otherwise. A) The client and the server are configured to use not just TLS, but authenticate using SSL certificates. The client will require TLS, and authenticate using a client-side certificate. B) The hostile attacker injects "x AUTH EXTERNAL\n". The server processes it, and logs on to the mailbox. The hostile attacker has no means of reading the contents of the mailbox, of course. The damage is limited to the attacker being able only to theoretically inject additional commands to delete or alter mail, basically. But: Courier-IMAP flushes its input as soon as it enters authenticated state. This is due to the way that the server works. Entering authenticating state involves exec()ing a new executable, which automatically discards anything that the original process has buffered. So, we're done here. The client and the server are still out of sync, at that point, and the IMAP session is basically broken. However, as I pointed out, the hostile attacker with the capability to compromise TCP/IP connections does not need to do this, to interfere with the client/server connection, so this does not really do anything that the attacker could not do, otherwise. So, the sum total here, basically, is a big, fat, zero. All the over-analysis of this vulnerability completely misses the mark that the hostile attacker with a MITM capability is already capable of messing up the connection between the client and the server. So, the claim is that these means of injecting plaintext messes up the connection between the client and the server. Well, duh. Using SSL does /not/ protect you from being affected by MITM attacks. All that SSL does, is protect information disclosure, from a passively-monitored communication channel, and a means of spoofing the other party, by requiring the other party to produce a valid certificate. |
|
From: Jakob Bohm <jb-co...@wi...> - 2013-10-22 02:06:44
|
On 22-10-2013 01:07, Sam Varshavchik wrote: > Jakob Bohm writes: > >> On 16-10-2013 01:48, Sam Varshavchik wrote: >> > Fernando Gozalo writes: >> > >> >> Hi, >> >> >> >> Searching in Google I have found this url >> >> https://bugs.launchpad.net/ubuntu/+source/courier/+bug/1194892 >> >> >> >> ¿Is there something to worry about? >> > >> > No. Just another case of automatically putting one's brain in park, >> > and blindly reading meaningless spewage from an automated >> > "vulnerability" tester. >> > >> Reading through the manual test run in that bug report, the key claim in >> the bug >> report seems to be: >> >> If someone sends a valid IMAP/POP command between STARTTLS and the >> actual TLS >> handshake, the valid response will be sent as the first thing inside >> the TLS >> session. >> >> I think this is only a real problem if one of the following is a real >> problem: > > Once you have a hostile attacker that's capable of hijacking TCP/IP > connections you're done. Game over. You can simply pick up your toys, > and go home. The hostile attacker can now do anything. The hostile > attacker can simply suppress the server's advertisement of STARTTLS, > and force the client to fallback to a plain text connection, since the > client will not see that the server is capable of TLS. The MITM > attacker does not need to do something this arcane, in order to screw > things up. > Most clients I know remember the use of STARTTLS as part of their configuration and refuse to talk to a server that suddenly stops advertising it. The whole point of TLS is to secure the connection against those who can manipulate the unencrypted TCP/IP connections. > This obviously addresses your point B as well. > > I can only see one possible situation where this theoretical > vulnerability can be possibly exploited in any way to do something > that the hostile attacker that's capable of hijacking TCP/IP could not > do otherwise. > > A) The client and the server are configured to use not just TLS, but > authenticate using SSL certificates. The client will require TLS, and > authenticate using a client-side certificate. Actually, no. And you really should know this before coding a widely used TLS server. TLS with just a server certificate protects against MITM because now the client knows if it has a private TCP connection to the real server (the one that has the private key matching a certificate with the right name in it), and the server can expect the client not to authenticate until this condition has been checked. > B) The hostile attacker injects "x AUTH EXTERNAL\n". The server > processes it, and logs on to the mailbox. The hostile attacker has no > means of reading the contents of the mailbox, of course. The damage is > limited to the attacker being able only to theoretically inject > additional commands to delete or alter mail, basically. > > But: > > Courier-IMAP flushes its input as soon as it enters authenticated > state. This is due to the way that the server works. Entering > authenticating state involves exec()ing a new executable, which > automatically discards anything that the original process has > buffered. So, we're done here. I was not suggesting any effect of commands passing across the authentication step. I was suggesting that the original complainant (not me) might (possibility A) be concerned that IF TLS itself has a chosen plaintext vulnerability (i.e. a vulnerability where by forcing the server to encrypt specific bytes at a specific position in the encrypted byte stream, an attacker can figure out the encryption keys), THEN the ability to change what the server sends right at the start of the TLS session becomes a way in for such an attack. And once the keys are known, then the whole encryption goes away and the attacker can eavesdrop on any mails the real user downloads after authenticating. > > The client and the server are still out of sync, at that point, and > the IMAP session is basically broken. However, as I pointed out, the > hostile attacker with the capability to compromise TCP/IP connections > does not need to do this, to interfere with the client/server > connection, so this does not really do anything that the attacker > could not do, otherwise. So, the sum total here, basically, is a big, > fat, zero. See above for limits to what attackers can do with just TCP/IP hijacking, you overestimate what can be done with just TCP/IP hijacking and thus underestimate the relevance of additional attacks. Getting the client and server out of sync was itself possible concern B, and the question was how the standards and real world clients respond to being out of sync like this. For instance do the standards specify if the first bytes sent after STARTTLS\r\n are allowed to be anything but TLS handshake bytes, thus requiring the server not to parse those bytes as commands. Or do the standards require the observed behavior. > > All the over-analysis of this vulnerability completely misses the mark > that the hostile attacker with a MITM capability is already capable of > messing up the connection between the client and the server. So, the > claim is that these means of injecting plaintext messes up the > connection between the client and the server. Well, duh. > > Using SSL does /not/ protect you from being affected by MITM attacks. > All that SSL does, is protect information disclosure, from a > passively-monitored communication channel, and a means of spoofing the > other party, by requiring the other party to produce a valid certificate. > Wrong, SSL/TLS, if done properly, DOES precisely and specifically protect against MITM attacks. It's design feature #1 of the whole thing. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded |
|
From: Sam Varshavchik <mr...@co...> - 2013-10-22 02:27:23
|
Jakob Bohm writes: > On 22-10-2013 01:07, Sam Varshavchik wrote: > > > > A) The client and the server are configured to use not just TLS, but > > authenticate using SSL certificates. The client will require TLS, and > > authenticate using a client-side certificate. > Actually, no. And you really should know this before coding a > widely used TLS server. TLS with just a server certificate > protects against MITM because now the client knows if it has a > private TCP connection to the real server (the one that has the > private key matching a certificate with the right name in it), > and the server can expect the client not to authenticate until > this condition has been checked. Again, that's completely irrelevant. An attacker that wants to disrupt a connection between the client and the server can go right ahead and simply intercept and hijack a connection before TLS is initiated. An attacker that wants to covertly subvert a TLS connection will not be able to do it with this laughable so-called "exploit". The attacker will be detected, because all that the so-called "exploit" does is break the connection. That's all that the attacker can accomplish, unless the attacker can, somehow, also succesfully authenticate and actually do damage to the authenticated mailbox. Unless the attacker can accomplish that, all that the attacker will accomplish is break and interfere with the connection. And the attacker does not need this "explit" to do that, by the virtue of the attacker's capability to hijack the connection. You do not need to be an SSL expert to understand this simple logic. > I was not suggesting any effect of commands passing across the > authentication step. I was suggesting that the original complainant > (not me) might (possibility A) be concerned that IF TLS itself has a > chosen plaintext vulnerability (i.e. a vulnerability where by forcing If that true, the attacker does not need to inject anything at all. The attacker knows both what the request and the response is going to be: the IMAP login sequence. In fact, if there were a plaintext vulnerability in TLS, then it's the attacker's benefit not to inject any plaintext at all, since the first couple of bytes in both the client's command and the server's response are identical, in the login sequence. That provides more context than an induced response from the server. > Getting the client and server out of sync was itself possible > concern B, and the question was how the standards and real world > clients respond to being out of sync like this. For instance do > the standards specify if the first bytes sent after STARTTLS\r\n > are allowed to be anything but TLS handshake bytes, thus requiring > the server not to parse those bytes as commands. Or do the > standards require the observed behavior. This is irrelevant. In the exploit scenario, normal SSL/TLS negotiation takes place, then the server is induced to read the injected, buffered, attacker-sourced message. > > Using SSL does /not/ protect you from being affected by MITM attacks. > > All that SSL does, is protect information disclosure, from a > > passively-monitored communication channel, and a means of spoofing the > > other party, by requiring the other party to produce a valid certificate. > > > Wrong, SSL/TLS, if done properly, DOES precisely and specifically > protect against MITM attacks. It's design feature #1 of the whole > thing. We are simply having different definitions of MITM. A party that's capable of interposing itself between two other parties, unbeknownst to them, has succesfully completed an MITM exploit, by the virtue of it being there. |
|
From: Jakob Bohm <jb-co...@wi...> - 2013-10-22 12:49:54
|
On 22-10-2013 04:27, Sam Varshavchik wrote: > Jakob Bohm writes: > >> On 22-10-2013 01:07, Sam Varshavchik wrote: >> > >> > A) The client and the server are configured to use not just TLS, but >> > authenticate using SSL certificates. The client will require TLS, and >> > authenticate using a client-side certificate. >> Actually, no. And you really should know this before coding a >> widely used TLS server. TLS with just a server certificate >> protects against MITM because now the client knows if it has a >> private TCP connection to the real server (the one that has the >> private key matching a certificate with the right name in it), >> and the server can expect the client not to authenticate until >> this condition has been checked. > > Again, that's completely irrelevant. An attacker that wants to disrupt > a connection between the client and the server can go right ahead and > simply intercept and hijack a connection before TLS is initiated. An > attacker that wants to covertly subvert a TLS connection will not be > able to do it with this laughable so-called "exploit". The attacker > will be detected, because all that the so-called "exploit" does is > break the connection. That's all that the attacker can accomplish, > unless the attacker can, somehow, also succesfully authenticate and > actually do damage to the authenticated mailbox. Unless the attacker > can accomplish that, all that the attacker will accomplish is break > and interfere with the connection. > There is a difference between "known plaintext" attacks on crypto and "chosen plaintext" attacks. In a chosen plaintext attack, the attacker gets to choose a message that makes it easier to solve the math problem of breaking the encryption, in "known plaintext", the attacker has to make do with the message that is there. > And the attacker does not need this "explit" to do that, by the virtue > of the attacker's capability to hijack the connection. > > You do not need to be an SSL expert to understand this simple logic. You again miss the whole point of SSL. With proper, working, non-buggy SSL, the attacker is limited to stopping the connection through the SSL (as if he cut the cable), even if the attacker has full MITM powers over the raw TCP connection. > >> I was not suggesting any effect of commands passing across the >> authentication step. I was suggesting that the original complainant >> (not me) might (possibility A) be concerned that IF TLS itself has a >> chosen plaintext vulnerability (i.e. a vulnerability where by forcing > > If that true, the attacker does not need to inject anything at all. > The attacker knows both what the request and the response is going to > be: the IMAP login sequence. This is just "known plaintext", not "chosen plaintext". > > In fact, if there were a plaintext vulnerability in TLS, then it's the > attacker's benefit not to inject any plaintext at all, since the first > couple of bytes in both the client's command and the server's response > are identical, in the login sequence. That provides more context than > an induced response from the server. > >> Getting the client and server out of sync was itself possible >> concern B, and the question was how the standards and real world >> clients respond to being out of sync like this. For instance do >> the standards specify if the first bytes sent after STARTTLS\r\n >> are allowed to be anything but TLS handshake bytes, thus requiring >> the server not to parse those bytes as commands. Or do the >> standards require the observed behavior. > > This is irrelevant. In the exploit scenario, normal SSL/TLS > negotiation takes place, then the server is induced to read the > injected, buffered, attacker-sourced message. Exactly, and the effect is that the client sees a response to an additional command it did not send. It takes a careful study of both standards and client code from every client out there to determine what that will do to the connection. For IMAP this is further complicated by the rules allowing unsolicited server responses in some situations. 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? If not, then the test should result in the TLS negotiation failing and the connection getting aborted long before the commands elicit any other reaction. > >> > Using SSL does /not/ protect you from being affected by MITM attacks. >> > All that SSL does, is protect information disclosure, from a >> > passively-monitored communication channel, and a means of spoofing the >> > other party, by requiring the other party to produce a valid >> certificate. >> > >> Wrong, SSL/TLS, if done properly, DOES precisely and specifically >> protect against MITM attacks. It's design feature #1 of the whole >> thing. > > We are simply having different definitions of MITM. A party that's > capable of interposing itself between two other parties, unbeknownst > to them, has succesfully completed an MITM exploit, by the virtue of > it being there. > Yes he has, but a working SSL should make this useless to the attacker, as he can not understand the encrypted data and not change anything because of the cryptographic checksums on everything. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded |
|
From: Sam Varshavchik <mr...@co...> - 2013-10-24 00:23:45
|
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.
|
|
From: Jakob Bohm <jb-co...@wi...> - 2013-10-28 20:15:25
|
Summary: It is a protocol violation for an IMAP4/POP3 client to send an extra command between STARTTLS/STLS and the actual TLS negotiation. There is thus no standard for what a server should do if it receives such commands. While the Postel principle suggests that somehow accepting such commands may be the nice thing to do, it weakens the security barrier between the potentially insecure raw TCP connection and the supposedly secure TLS tunnel to issue responses to such unexpected commands inside the TLS tunnel, while it violates the basic protocol sequencing to do so outside the tunnel. Currently Courier implementations of IMAP4/POP3 follow the Postel principle and issues such responses inside the TLS tunnel. However the author of the Nessus test and the poster of the Ubuntu bug (presumably two different people) believe this to be /potentially/ insecure. I have tried to explain their concerns based on my understanding of the protocols, but have not formed a firm opinion on the reality of these concerns. That said, I think it would be slightly safer, just in case the issue becomes real, for courier to treat this particular protocol violation as fatal and abort the connection before or during the TLS negotiation. However this since this is mostly a hypothetical problem at this stage, I don't think it warrants an out-of-schedule security update or advisory, just something to tweak later. On 10/24/2013 2:23 AM, Sam Varshavchik wrote: > 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. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded |
|
From: Sam Varshavchik <mr...@co...> - 2013-10-28 23:16:39
|
Jakob Bohm writes: > That said, I think it would be slightly safer, just in case the issue > becomes real, for courier to treat this particular protocol violation > as fatal and abort the connection before or during the TLS negotiation. > > However this since this is mostly a hypothetical problem at this stage, > I don't think it warrants an out-of-schedule security update or > advisory, just something to tweak later. That's pretty much the same conclusion I reached. This is not an issue at present. Nothing can be accomplished by exploiting it that an attacker in position to exploit it cannot already accomplish via other means. This is something that can be addressed at some convenient time later. I wouldn't abort it, just flush it away. That's what other implementations picked to do. |