Bug 975949 - max-negotiate-time feature breaks AMQP 1.0 (and arguably doesn't achieve the desired objective anyway)
max-negotiate-time feature breaks AMQP 1.0 (and arguably doesn't achieve the ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
2.2
Unspecified Unspecified
high Severity high
: 3.0
: ---
Assigned To: Andrew Stitcher
Zdenek Kraus
:
Depends On:
Blocks: 1010399
  Show dependency treegraph
 
Reported: 2013-06-19 12:22 EDT by Gordon Sim
Modified: 2014-09-24 11:08 EDT (History)
6 users (show)

See Also:
Fixed In Version: qpid-cpp-0.22-6.el6, qpid-cpp-mrg-0.22-6.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-24 11:08:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
trivial 'malicious' client that could cause the DoS that was supposedly fixed (1.67 KB, text/x-c++src)
2013-06-19 12:22 EDT, Gordon Sim
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Apache JIRA QPID-4854 None None None Never

  None (edit)
Description Gordon Sim 2013-06-19 12:22:47 EDT
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):

2.2

How reproducible:

Easily

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

Actual results:

The connection is timed out inspite of having gone through connection handshake for 1.0.

Expected results:

Connection should not be timed out.
Additional info:
Comment 1 Gordon Sim 2013-06-19 12:25:18 EDT
I believe https://bugzilla.redhat.com/show_bug.cgi?id=609685 was the original issue.
Comment 3 Andrew Stitcher 2013-06-24 12:50:33 EDT
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:

3a897c593b6b49bbfc8ebabe37cebeb9b63802de
8001b8b2fdbd7cb5fc3abfee53abaf5d31a2ae91
a7ed6021b032906851e3fdf202124ef1b4a583df
36b93a14e9325a466bb4b231aa2bf4d9b68ecd5b

But you should check.

You will probably need to apply this change for QPID-4905 first
d9e3b01aec28603542d0a9d12cf348a5e67a751e

As I think the QPID-4854 changes depend on the changes in here.
Comment 12 Zdenek Kraus 2014-01-06 07:16:22 EST
This was tested on RHEL 6.5 i686, x86_64 with following packages:

qpid-cpp-server-0.22-30.el6
qpid-cpp-server-xml-0.22-30.el6
qpid-proton-debuginfo-0.6-1.el6
qpid-cpp-debuginfo-0.22-30.el6
qpid-jca-0.22-1.el6
qpid-jca-xarecovery-0.22-1.el6
qpid-qmf-devel-0.22-25.el6
qpid-tools-0.22-7.el6
qpid-proton-c-0.6-1.el6
qpid-qmf-0.22-25.el6
python-qpid-qmf-0.22-25.el6
qpid-proton-c-devel-0.6-1.el6
qpid-java-example-0.22-5.el6
python-qpid-0.22-9.el6
qpid-cpp-client-0.22-30.el6
qpid-cpp-client-ssl-0.22-30.el6
qpid-cpp-server-devel-0.22-30.el6
qpid-java-client-0.22-5.el6
qpid-cpp-server-ssl-0.22-30.el6
qpid-java-common-0.22-5.el6
qpid-cpp-client-devel-0.22-30.el6
qpid-cpp-server-store-0.22-30.el6
qpid-cpp-client-devel-docs-0.22-30.el6

fix work as expected.
Comment 13 errata-xmlrpc 2014-09-24 11:08:23 EDT
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.

http://rhn.redhat.com/errata/RHEA-2014-1296.html

Note You need to log in before you can comment on or make changes to this bug.