Community
Participate
Working Groups
From the security@eclipse.org inbox: Dear Eclipse Security Team, We are a security research group. Recently we found a security vulnerbility in Eclipse Mosquitto. An attacker is able to publish messages to the topic he does not have access to. Steps to Reproduce (on Linux) 1. Create a ACL file as follows: topic read a/a topic write a/a 2. Start mosquitto broker using this ACL file. That is, clients can publish and read messages on the topic "a/a". 3. Use a MQTT client to subscribe messages from topic 'a/a'. For example, you can use the command "mosquitto_sub -t 'a/a' ". We call this client as ClientA. 4. Use another client to publish a retained message to the topic 'a/a'. We call this client as ClientB. 5. Delete the line "topic write a/a" in ACL file and send SIGHUP signal to mosquitto for reloading the configuration. 6. Reconnect ClientA and subscribe to topic 'a/a'. The message retained by ClientB is published, which violates the access control policy of ClientB. Because no client can publish message to 'a/a' now since step5. Impact We believe the impact of the problem is wide since the ownership change of a smart IoT device is fairly common.And many IoT projects are based on MQTT. For example, many hotels and apartments are using smart locks which can be controlled by the smart phone through cloud (https://www.remotelock.com/smart-locks-airbnb-hosts). Utilizing the attack illustrated above, in this scenario, an attacker who stayed in a hotel room or apartment once can set a timer (in retained message) to unlock the same room door when other guests live in the room later. Suggestion Mosquitto should check the source of every retained message, because the source client may do not have the WRITE permission when this message is to be sent. Please feel free to let us know if you need any further information. Best, Yan Jia School of Cyber Engineering, Xidian University National Computer Network Intrusion Protection Center, University of Chinese Academy of Sciences Indiana University
Could a CVE please be issued for this. I see the point they are making. On one hand it could be considered to be incorrect because at the point the message is published by the client it is allowed to do so, however that isn't reasonable for some applications when retained messages are available. CVSS v2: https://nvd.nist.gov/vuln-metrics/cvss/v2-calculator?vector=(AV:N/AC:M/Au:S/C:P/I:P/A:N/E:ND/RL:OF/RC:C) CVSS v3: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N/E:X/RL:O/RC:X Short description: If a client publishes a retained message to a topic, then has its access to that topic revoked, the retained message will still be published to clients that subscribe to that topic in the future. In some applications this may result in clients being able cause effects that would otherwise not be allowed. Effected versions 1.0 to 1.5.5 inclusive. Do we have any contact details for the submitters?
Any chance of that CVE being assigned?
(In reply to Roger Light from comment #2) > Any chance of that CVE being assigned? CVE-2018-12546
Thanks Wayne.
(In reply to Roger Light from comment #1) > Could a CVE please be issued for this. > > I see the point they are making. On one hand it could be considered to be > incorrect because at the point the message is published by the client it is > allowed to do so, however that isn't reasonable for some applications when > retained messages are available. > > CVSS v2: > https://nvd.nist.gov/vuln-metrics/cvss/v2-calculator?vector=(AV:N/AC:M/Au:S/ > C:P/I:P/A:N/E:ND/RL:OF/RC:C) > > CVSS v3: > https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:L/ > UI:N/S:C/C:L/I:L/A:N/E:X/RL:O/RC:X > > Short description: > > If a client publishes a retained message to a topic, then has its access to > that topic revoked, the retained message will still be published to clients > that subscribe to that topic in the future. In some applications this may > result in clients being able cause effects that would otherwise not be > allowed. > > Effected versions 1.0 to 1.5.5 inclusive. > > Do we have any contact details for the submitters? Hi Roger Light, Thanks for your response. I'm Yan Jia, the submitter. We also implement a defense prototype based on mosquitto. In particular, we save the context of the message sender in the struct mosquitto_msg_store when dealing with retained message in the file handle_publish.c. And in subs.c, when the retained message is going to be sent to the client, the permission of the sender is checked. In addition, we plan to submit a paper about this issue on 15 Feb. The issue won't be disclosed publicly before the paper is published. If you have any questions, please let me know. We're happy to help.
I need a CWE, please. I've added some help to the documentation: https://www.eclipse.org/projects/handbook/#vulnerability-cve I think that I can piece together everything else from what you have here.
cwe: CWE-284: Improper Access Control https://cwe.mitre.org/data/definitions/284.html
