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.
pgpjqdz6GZWAH.pgp
Description: PGP signature
------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________ Courier-imap mailing list Courier-imap@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
