Bug 559719

Summary: Bug in mosquittos MQTT password file parser allows adversaries to modify the loaded password file instance and authenticate as another client.
Product: Community Reporter: Panagiotis Vasilikos <panagiotis.vasilikos>
Component: BugzillaAssignee: Eclipse Webmaster <webmaster>
Status: RESOLVED MOVED QA Contact:
Severity: critical    
Priority: P3 Keywords: security
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
URL: https://github.com/eclipse/mosquitto
Whiteboard:

Description Panagiotis Vasilikos CLA 2020-01-30 11:48:38 EST
Hi,

There is a bug in the function used to parse the password file in the MQTT implementation. The function is pwfile__parse(...) and it appears in the file security_default.c .

The bug could allow an adversary to modify the loaded instance of the password file, authenticate as another client or create a DoS.

Adversary's Model:
In order for the adversary to exploit the bug she needs to be able to provide her credentials to the administrator of the broker. This could be done in case there is a service which is used to register new clients.

Bug Details:
The problem lies in the following lines of code

             while(!feof(pwfile)){
		if(fgets(buf, 256, pwfile)){
                 ...



used to iterate over the username:passwords pairs in the password file. This implementation assumes that each pair has length maximum 256 bytes which is not a requirement from the MQTT standard. 

In case the parser finds a pair with length longer than 256 bytes (e.g. 300), it will read the first 256 bytes, and at the next iteration it will read the rest (e.g. 44). This is the way fgets(...) works.

This allows an adverary to inject in his username (or password) another username:password pair.

Example 1 (without TLS): For instance, in case the broker is not using TLS the following password file:

john:BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBadmin:mypass
admin:1234

has an injection in the password of the malicious user john (i.e. BBBBB....BBBBadmin:mypass). The parser will load the pairs:
  
              john:BBBB.....BBBBB
              admin:mypass
              admin:1234

which allows john to authenticate as admin providing mypass as password.

Example 2 (with TLS): A similar problem can occur when the broker has configured with TLS. However, this time the injection needs to occur at the username. For instance the following username

BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBadmin:$6$Z0CpPwNLEKDcDNKe$7WuqsJTu45uQDXsSWJKJes4iLEij1muwZjPHmJZgtlNcd9t/o74xGrZ5yGxQm4hCNR2fYBBXhA0VOqP2yTMXRw==

has injected the pair 

admin:$6$Z0CpPwNLEKDcDNKe$7WuqsJTu45uQDXsSWJKJes4iLEij1muwZjPHmJZgtlNcd9t/o74xGrZ5yGxQm4hCNR2fYBBXhA0VOqP2yTMXRw==

On load, the parser will read the first 256 bytes (B...BBB) and then will load the injected pair, which again permits the adversary to log in as admin.

Best,
Panagiotis
Comment 1 Eclipse Webmaster CLA 2020-01-31 08:45:21 EST
Mosquitto uses Github Issues rather than this bugzilla.  As such I've created: https://github.com/eclipse/mosquitto/issues/1584 containing this report.

-M.