[
https://issues.apache.org/jira/browse/PROTON-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066475#comment-16066475
]
Chuck Rolke commented on PROTON-1509:
-------------------------------------
I was too hasty declaring this to be a problem on AMQP.Net Lite. In an
up-to-date client the Lite library throws when it sees the bad message
{noformat}
Exception Amqp.AmqpException: The format code '10' at frame buffer offset
'243' is invalid.
{noformat}
> 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]
