[
https://issues.apache.org/jira/browse/ARTEMIS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957952#comment-15957952
]
Timothy Bish commented on ARTEMIS-826:
--------------------------------------
I took a look quickly as this rang a bell from an issue for ActiveMQ from way
back. The trouble here seems to be that the protocol detection code in Artemis
is expecting the layout of the CONNECT packet to always be the same but that
isn't the case in MQTT. The CONNECT command consists of a Fixed header,
followed by an encoded value which indicates the remaining length of the packet
and then the variable length header plus a possible payload section. The bit
that is not taken into account here is the 'remaining length' portion which can
be up to four bytes in length to indicate the length of the variable header +
the payload.
In the simpler cases Artemis receives a packet that looks something like "[16,
36, 0, 4, 77, 81, 84, 84]" where the last four bytes are "MQTT" (or MQIs for
3.1). However, if the password + username + everything else is large the value
of the remaining length gets bigger and spills over into more bytes at the
start of the command and you might see something like "[16, -126, 3, 0, 4, 77,
81, 84]" which breaks the current protocol checks.
It gets worse though in that if the length value reaches the four byte max then
you might see something like "[16, -126, -126, -126, 10, 0, 4, 77]" in which
case you can't decide if the protocol is MQTT 3.1.1 or 3.1 and really you can't
even tell it's MQTT at that point.
> MQTT with a long password field causes NPE exception
> ----------------------------------------------------
>
> Key: ARTEMIS-826
> URL: https://issues.apache.org/jira/browse/ARTEMIS-826
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 1.4.0, 1.5.0
> Reporter: luca capra
> Assignee: Martyn Taylor
> Priority: Critical
> Labels: mqtt
> Fix For: 2.next
>
>
> Hi
> I'm using mqtt.js and Paho (java) as client for MQTT protocol.
> The issue can be replicated both on (my embed) version pointing at master
> (1.5.0-SNAPSHOT) and with a clean install of 1.4.0 release
> Happens by using a long password (a jwt token in my case) which causes this
> exception on both versions
> Example password:
> eyJhbGciOiJIUzUxMiJ9.eyJjcmVhdGVkIjoxNDc3NDg1NDc5OTEzLCJleHAiOjE0Nzc0ODcyNzksInV1aWQiOiI2NmVkNDc3Mi0wNDg5LTRlOTYtYmI2NS01NDhiMmVkMmM3MWQifQ.LbOAr8pPApDlVBLi32JWtCjmCa80ByAJYq9BnTnWQgh4SWka4WzykMU0D_atE5tYtgICj2QOg-OFglv2ZqLLNw
> Exception:
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:185)
> [artemis-server-1.4.0.jar:1.4.0]
> Looking at the source Artemis receive a different set of bytes ("M"QTT starts
> at array[5])
> https://github.com/apache/activemq-artemis/blob/master/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTProtocolManager.java#L131
> ---
> MQTT spec on password length (0 to 65535 bytes of binary data + 2bytes for
> length)
> http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc385349246
> Client code is here:
> https://gist.github.com/muka/df7cac712a645b9f1895274adcbe3670
> Embed artemis code is here:
> https://github.com/muka/raptor/tree/master/raptor-broker
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
