Uploaded image for project: 'Qpid Proton'
  1. Qpid Proton
  2. PROTON-1509

Proton C allows malframed AMQP without complaint

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • proton-c-0.17.0
    • None
    • proton-c
    • None
    • qpid-dispatch master (before DISPATCH-784) and qpid-proton master

    Description

      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

          list-item (str8-utf8): 0123456789
      

      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.

      Attachments

        1. 623-0.8.x-2-router-framing-issue.txt
          10 kB
          Charles E. Rolke
        2. 623-map-size-error.txt
          7 kB
          Charles E. Rolke

        Activity

          People

            Unassigned Unassigned
            chug Charles E. Rolke
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: