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: [email protected]
For additional commands, e-mail: [email protected]
