-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Several protocol violations or bugs in NanoMQ #1782
Comments
According to the specification of MQTTv3.1.1:
Replay such packet:
The unintended behavior is that NanoMQ returns a CONNACK message where the return code is SUCCESS. |
According to the specification of MQTTv3.1.1:
Replay:
The expected behavior is to reject such erroneous packets, but NanoMQ received and responded correctly. |
According to the specification of MQTTv5.0:
However, if we send such packet like:
I debugged and found that NanoMQ returns PUBREC messages unintentionally and there is no check in the code for the contents of the response topic. |
According to the specification of MQTTv5.0:
But we unexpectedly received CONNACK, replay such packet:
|
According to the specification of MQTTv5.0:
Replay packet
NanoMQ sends the corresponding CONNACK with the success code to the client unexpectedly. |
According to the specification of MQTTv5.0:
But strangely, NanoMQ returned two CONNACKs for such requests, and the expected behavior should be to only return the first CONNACK.
|
According to the specification of MQTTv5.0:
If we send the follow CONNECT packet (the content type contains "0xff")
Unexpectedly, the server returned a successful response message and saved such properties. |
According to the specification of MQTTv5.0:
In testing, it was found that if NanoMQ returns a CONNACK message (where the Topic Alias MAX value is 46512) and the client continues to send a PUBLISH message with a Topic Alias value of 65391, NanoMQ will still parse it correctly and respond, but the expectation is that it should treat such a message as an error.
|
According to the specification of MQTTv5.0:
But it seems that NanoMQ did not check this rule and consider it valid.
|
According to the specification of MQTTv5.0:
After testing, NanoMQ violates this rule.
|
According to the specification of MQTTv5.0: [MQTT-3.6.1-1] Bits 3,2,1 and 0 of the Fixed Header in the PUBREL packet are reserved and MUST be set to 0,0,1 and 0 respectively. The Server MUST treat any other value as malformed and close the Network Connection.
The expected behavior was considered illegal and the network connection was closed, but the corresponding request was unexpectedly received. |
According to the specification of MQTTv5.0:
If we send a Connect (the value of Resequest Problem Information is set to 2), FlashMQ returns the CONNACK with successful code unexpectedly.
|
According to the specification of MQTTv5.0:
Replay:
NanoMQ unexpectedly returns CONNACK with the success code. |
According to the specification of MQTTv5.0:
However, NanoMQ does not verify that the value of this attribute is UTF-8 encoded, and then responds with a CONNACK. |
Similarly,
However, NanoMQ does not verify that the value of this attribute is UTF-8 encoded, and then responds with a CONNACK.
|
According to the specification of MQTTv5.0:
But we send a CONNECT (the Request Response Information is set to 50), NanoMQ did not reject such packet.
|
According to the specification of MQTTv5.0:
Replay:
I also found this is labeled as TODO in source code. |
According to the specification of MQTTv3.1.1:
Replay such packet:
|
According to the specification of MQTTv5.0:
But if we send a packet containing too large values of the Subscription Identifier, the expectation is to reject such packets, but NanoMQ processes them normally.
|
According to the specification of MQTTv5.0:
However, if we transmit a PUBACK packet containing an invalid reason code that is not specified in Table 3-4, such as 0x01, the expected behavior would be to treat this request as erroneous, yet NanoMQ seemingly handles it without issue. Upon examining the code within the function nni_mqtt_pubres_decode(), it appears that no validation is performed to ensure the reason_code's validity.
|
You really have a deep look of MQTT protocol |
You really have a deep look of the MQTT protocol. |
Return PUBREC is expected since you send QOS2, but ignoring wildcard is definitely a flaw |
Indeed, but we leave the topic verify for client SDK for now, will fix this later |
Client sends CONNACK which is considered as a malformed packet. |
same issue as response_topic, nanomq doesnt verify it for now, leave it to client. |
Cool, I dont think we should limit the maximum topic alias number. so I simply make it max. |
well, nanomq doest support Authentication yet. |
Hi bug hunter, most issues here are not critical, I will come by later to fix them |
I prefer to leave reason code as it is, I believe community deserve better reasoncode definition, we gonna make our own. |
Hi @JaylinYu. I do agree with all of your thoughts above, protocol specifications are not always absolute, and if there is a better solution it is worth pushing for it. Also thanks for the affirmation of our fuzzing tool. |
Cool, I have wrapped fix in 0.21.10, happily to get feedback from you |
Just realize that you are sending a UTF-8 str pair; the length field is located before str. |
Hi, there are some other bugs related to the above that I missed unreported before, I'll update them here. |
One interesting issue is that NanoMQ seems to be parsing the PUBLISH attribute field and instead of effectively stopping such a message when it encounters a malformed attribute value, it receives it and allows it to be forwarded to other subscribers, but this poses a risk to other subscribing clients.
|
Then, another is NanoMQ ACL Flaw. When we turn on NanoMQ's Privilege Access Control to disable all users from subscribing to system topics that begin with $SYS, the acl.conf configuration file looks like this. Now, theoretically any request from a subscribed client that subscribes to $SYS/ will be blocked, but we can get around it with a wildcard theme: the
You can see that the information about the $SYS topic was successfully obtained. In fact, the MQTT specification refers to scenarios such as.
|
Some issues are not critical to fix. will revisit it soon |
According to this description, when the Payload Format Indicator in the PUBLISH message is set to 1, the payload in the PUBLISH message must be UTF-8 encoded. However, it appears that NanoMQ does not validate this. PoC:
|
Similarity,
According to this description, when the Payload Format Indicator in the CONNECT message is set to 1, the will message in the CONNECT message must be UTF-8 encoded. However, it appears that NanoMQ does not validate this. POC:
|
But if we send a packet that the Payload Format Indicator is set to 32 to broker, NanoMQ will not reject it. Packet:
|
But if we sen such an invalid packet that the will flag is set to 0 and the will qos is set to 1, the broker will not reject it.
|
In MQTT 5.0, the requester can specify an expected Response Topic in the request message. After taking appropriate action based on the request message, the responder publishes a response message to the Response Topic carried in the request. If the requester has subscribed to that Response Topic, it will receive the response. Ref 1: https://www.emqx.com/en/blog/mqtt5-request-response In MQTT 5.0, I believe this property field should not be allowed to be empty, because it will play a role in message transmission in some scenarios. Packet:
|
This comment was marked as resolved.
This comment was marked as resolved.
I think it does and is likely the cause of the errors I listed here: Hope they are able to fix these inconsistencies and bugs. |
Although the issue you mentioned is indeed related to inconsistencies and bugs, I made a mistake in this case. |
You have reported this before, however I received more security complaints after I pushed a fix... also, I assume some of your issue shall be addressed by SDK from the first place, such as response topic. |
nanomq/nanomq#1782 will qos & will flag Signed-off-by: jaylin <jaylin@emqx.io>
nanomq/nanomq#1782 will qos & will flag Signed-off-by: jaylin <jaylin@emqx.io>
Signed-off-by: jaylin <jaylin@emqx.io>
Describe the bug
Hi, I found something on the NanoMQ that is contrary to the protocol specification description (protocol violation or logic bug).
For tracking purposes, I will report all results under this Issue.
Environment Details
Client SDK
If possible include the mqtt sdk you used to connect to nanomq
Minimal C test cases are perferred.
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: