You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Chuck Rolke (JIRA)" <ji...@apache.org> on 2017/06/23 15:41:00 UTC

[jira] [Created] (PROTON-1509) Proton C allows malframed AMQP without complaint

Chuck Rolke created PROTON-1509:
-----------------------------------

             Summary: Proton C allows malframed AMQP without complaint
                 Key: PROTON-1509
                 URL: https://issues.apache.org/jira/browse/PROTON-1509
             Project: Qpid Proton
          Issue Type: Bug
          Components: proton-c
    Affects Versions: 0.17.0
         Environment: qpid-dispatch master (before DISPATCH-784) and qpid-proton master
            Reporter: Chuck Rolke
         Attachments: 623-0.8.x-2-router-framing-issue.txt, 623-map-size-error.txt

qpid-dispatch was generating mal-framed AMQP due to a coding error. However, if by chance or by design the mis-coded fields were crafted carefully the mal-formed AMQP is passed blissfully through the system.

This issue is pandemic in nature in that many widely varied AMQP parsers handle the AMQP message without complaint: qpid-proton proton-c, qpid-dispatch, wireshark, and amqpnetlite.

Attached file 623-0.8.x-2-router-framing-issue.txt illustrates the issue. The test setup is a two-router network. Router A listens for sender packets on port 5672. Router A talks to Router B on port 21000. Router B delivers packets to receivers on port 5674.

In the trace Frame 180 is the user packet arriving on port 5672. This packet triggers DISPATCH-784 by including the 12-byte empty Delivery-Annotations map in message bytes 0x7F..0x9A.  The packet also has ten user Message-Annotations.

Frame 181 is the packet being delivered between Routers A and B. The issue in DISPATCH-784 has created the mal-framed packet. Essentially the Message-Annotations are moved 12 bytes forward in the message payload buffer. Then 12 bytes of the original buffer exposed and transmitted again. By chance the 12 bytes are a well-framed string. Wireshark displays 
{noformat}
    list-item (str8-utf8): 0123456789
{noformat}
in the packet details. This is the part of the AMQP message that is malformed: payload bytes 0x192..0x19D are illegal at this point in the message. 

Frame 184 is the message being delivered to the proton c++ client simple_recv. The client does not flag the str8-utf8 in the message where Message-Properties should be. Instead the client accepts the message, parses over the bad field, and prints the payload 'abc'. A client written for AMQP.Net Lite does the same thing and happily accepts the message.

File 623-map-size-error.txt is another example. Here a whole bunch of strings and lists are slipped in between Message-Annotations and Message-Properties. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org