[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Mosquitto / CVE-2017-7653



Just looking at CVE-2017-7653, were it is claimed that some clients -
such as Eclipse Paho java client will disconnect if receiving a topic
that is not valid UTF8.

Looks like the Python Paho client doesn't have this issue. If using with
Python 2, it will ignore the error. If using with Python 3 it will log a
message, but otherwise continue.

        # Handle topics with invalid UTF-8
        # This replaces an invalid topic with a message and the hex
        # representation of the topic for logging. When the user attempts to
        # access message.topic in the callback, an exception will be raised.
        if sys.version_info[0] >= 3:
            try:
                print_topic = topic.decode('utf-8')
            except UnicodeDecodeError:
                print_topic = "TOPIC WITH INVALID UTF-8: " + str(topic)
        else:
            print_topic = topic

https://github.com/eclipse/paho.mqtt.python/blob/master/src/paho/mqtt/client.py#L2471

Looking at the Java Client, I see:

https://github.com/eclipse/paho.mqtt.java/blob/75594f0b226b14911f397b69059c18a50eaabb54/org.eclipse.paho.client.mqttv3/src/main/java/org/eclipse/paho/client/mqttv3/MqttTopic.java#L152
https://github.com/eclipse/paho.mqtt.java/blob/78de39a52c7c6fef972e258bd58c17bcf9c36ba1/org.eclipse.paho.ui/org.eclipse.paho.ui.core/src/org/eclipse/paho/mqtt/ui/core/model/Topic.java#L92

Presumably each file is for a different protocol version. However as of
yet, I can't see any code that validates UTF-8.

Oh, I see, the mqttv3 file has this logic:

		try {
			topicLen = topicString.getBytes("UTF-8").length;
		} catch (UnsupportedEncodingException e) {
			throw new IllegalStateException(e.getMessage());
		}

https://github.com/eclipse/paho.mqtt.java/blob/75594f0b226b14911f397b69059c18a50eaabb54/org.eclipse.paho.client.mqttv3/src/main/java/org/eclipse/paho/client/mqttv3/MqttTopic.java#L157

I am guessing that the IllegalStateException exception must somehow
trigger a disconnect.

Personally wondering how big a deal this is. I can't actually imagine
allowing untrusted clients to connect to a MQTT broker...

It does seem strange behaviour of the client to completely disconnect
from the broker, even if this "is a common action in MQTT 3.1.1 for
protocol errors".
-- 
Brian May <bam@debian.org>


Reply to: