Bug 975949
| Summary: | max-negotiate-time feature breaks AMQP 1.0 (and arguably doesn't achieve the desired objective anyway) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Gordon Sim <gsim> | ||||
| Component: | qpid-cpp | Assignee: | Andrew Stitcher <astitcher> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Zdenek Kraus <zkraus> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 2.2 | CC: | astitcher, gsim, iboverma, jross, lzhaldyb, zkraus | ||||
| Target Milestone: | 3.0 | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| 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 15:08:23 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1010399 | ||||||
| Attachments: |
|
||||||
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: 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. 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. 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 |
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: