Channel state contains un-obfuscated user data

[lukebakken]

Related to #3803

See https://groups.google.com/g/rabbitmq-users/c/Toq7BRq2Npk

The mailing list user reports a case where an LDAP password is logged as part of mfargs to rabbit_channel:start_link.

It appears that the impl field of the #auth_user record could be obfuscated to prevent scenarios like this.

In addition, the user information is stored in the channel state which could be logged at some point -

https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/rabbit_channel.erl#L531

[SimonUnge]

Hi. I have started looking into this issue.

I hope a simple closure(fun wrapper) might suffice?

[michaelklishin]

Maybe. We use a separate library in several other places such as Federation links and Shovels.

[SimonUnge]

Ah, ok yes that might be even better then! Thanks @michaelklishin

[SimonUnge]

Since 'impl' seem to be of type any(), and the rabbit_authz_backend requirement is only that it is returned, my assumption is that I update all modules that implement the modules (and uses the impl value), and obfuscate/de-obfuscate the field.

Since it can be of type any(), it is up to the module to decide how it wants the field obfuscated, but for simplicity I could
A) use the creddentials_obfuscation lib on the term, regardless of its type (i.e credentials_obfuscation:encrypt(term_to_binary(Imp)) and wise versa, or
B) wrap the value in a fun.

Are those options viable?

[michaelklishin]

They are both viable but we only have real world experience with option A. Which has its own issues: the library has to be started before first client connects and it has to be seeded correctly during cluster operations, in particular addition of new nodes.

[SimonUnge]

I will start with using a wrapper then, as there will be no issues in terms of apps started in the right order etc. But can easily switch if there is a feeling it is not safe enough?

Wrapper is usually what I've gone with in the past when we want to avoid secrets in stack traces. Also, recommended by EEF Security WG - https://erlef.github.io/security-wg/secure_coding_and_deployment_hardening/sensitive_data.html