0

According to the MQTT specification, a QoS 2 message sent by a MQTT client must follow this workflow:

enter image description here

During the various phases Mosquitto stores the message in its memory. This is also confirmed by looking at the mosquitto.db persistent storage using the db_dump tool described here.

The question is: if a malicious client PUBLISH tons of messages with QoS 2 but never sends the PUBREL message as a response to PUBREC what happens ? Mosquitto keep the messages undefinitively ? I expected some kind of configuration parameter able to get rid of such unacknowledged messages after some time but I can't find any.

Aldo
  • 550
  • 3
  • 13

1 Answers1

2

I'm not 100% sure, but I think the max_inflight_messages setting should kick in here and not allow the client to send the second QOS 2 message until the first has been completed.

This would limit each client to one malicious message at time.

There are a number of libraries that will allow you low level control over when packets are sent so building a PoC shouldn't be that hard. And if it is possible to trigger a DoS style attack, I'm sure eclipse/mosquitto would look kindly at a Pull Request with a fix.

hardillb
  • 54,545
  • 11
  • 67
  • 105
  • max_inflight_messages is interesting, despite the fact that the *per client* part is described here https://github.com/eclipse/mosquitto/blob/master/mosquitto.conf and not here (where it seems a global option) https://mosquitto.org/man/mosquitto-conf-5.html – Aldo Jul 12 '22 at 14:22
  • BTW with max_inflight_messages I see the opposite problem: if for any reason a client is not malicious but is not able to complete its part (PUBREL) of the QoS 2 handshake for few messages it is completely blocked having reached its max_inflight_messages quota. I continue to think that mosquitto should have something to get rid by its own (expiration timeout ? admin cli commands?) of QoS 2 messages living in such a "limbo" i.e. waiting for a PUBREL that will never come. – Aldo Jul 12 '22 at 14:28
  • As now, if the sender or the receiver loses a message, the other party resend it. If the sender can't get the PUBACK/PUBREL/PUBCOMP it must stop to send new messages, otherwise the receiver can be flood of messages that can't manage. – Domenico Briganti Nov 10 '22 at 09:12