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

[Jakob B. <jb-...@wi...>]

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