Created attachment 763037 [details]
trivial 'malicious' client that could cause the DoS that was supposedly fixed
Description of problem:
The max-negotiate-time feature has assumptions based on 0-10 (and a particular pattern for 0-10 at that) built into the underlying transport code (which should be protocol agnostic). It assumes that the handshake completes after 3 network reads.
It is trivial to fool this logic with a malicious client and in any case it 'times out' legitimate AMQP 1.0 connections that are less chatty.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run e.g. the proton-c recv example against qpidd
(for the DoS side of things, run the attached 'malicious' client and observe that it doesn't get timed out inspite of never even attempting to authenticate).
The connection is timed out inspite of having gone through connection handshake for 1.0.
Connection should not be timed out.
I believe https://bugzilla.redhat.com/show_bug.cgi?id=609685 was the original issue.
Irina - any change with QPID-4854 in the change log on trunk is part of this change and should be cherry-picked to the branch for Vienna.
I think this is SHAs:
But you should check.
You will probably need to apply this change for QPID-4905 first
As I think the QPID-4854 changes depend on the changes in here.
This was tested on RHEL 6.5 i686, x86_64 with following packages:
fix work as expected.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.