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

Post by Fernando Gozalo
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.

Jakob Bohm

2013-10-21 14:00:06 UTC

Post by Fernando Gozalo
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

Sam Varshavchik

2013-10-21 23:07:40 UTC

Post by Fernando Gozalo
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
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

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.

Jakob Bohm

2013-10-22 02:06:08 UTC

Post by Fernando Gozalo
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.

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.

Post by Sam Varshavchik
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.

Post by Sam Varshavchik
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.
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.

Post by Sam Varshavchik
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.

Post by Sam Varshavchik
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

Sam Varshavchik

2013-10-22 02:27:15 UTC

Post by Sam Varshavchik
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.

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.

Post by Jakob Bohm
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.

Post by Jakob Bohm
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.

Post by Sam Varshavchik
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.

Jakob Bohm

2013-10-22 12:49:18 UTC

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.

Post by Sam Varshavchik
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.

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".

Post by Sam Varshavchik
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.

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.

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

Sam Varshavchik

2013-10-24 00:23:36 UTC

Post by Jakob Bohm
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.

Jakob Bohm

2013-10-28 20:15:07 UTC

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.

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
Only permitted in AUTHORIZATION state.
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

Sam Varshavchik

2013-10-28 23:16:28 UTC