Obfuscation of config options marked as secret needs to be more opaque

[Henry Nash]

The current code in oslo to log configuration setting honors the "secret" attribute that is available on config options. If this is set, then the value of the options is logged as a string of asterisks. However, the code actually logs a string of asterisks the same length as the actual value of the option. Knowing the length of something that is secret could aid any cracking attempt.

A better solution would be to just log a fixed length string of asterisks (e.g. "**********").

[Tristan Cacqueray (tristan-cacqueray)]

Hi, the OSSA task is set to incomplete pending additional security details.

Does configuration settings dump requires a special permissions and what is the likeliness of someone not authorized to observe the output ?

[Tristan Cacqueray (tristan-cacqueray)]

Considering "secret" should be generated with a long enough length, I don't think this represent a vulnerability as-is and might be considered as a nice to have security hardening.

Thought ?

[Henry Nash (henry-nash)]

So I agree this is a low risk security issue - although we obviously think it is important enough to avoid dumping secret values into the logs, or we won't be obfuscating in the first place. Debug logging might well be passed from customer to cloud provider, or from cloud provider to openstack vendor - and not having properly obfuscated secret values might be considered a small risk.

Here's a classic example from keystone. The default admin token ID is "ADMIN". So if you look in the log you will see it logged as "*****" (i.e. 5 characters). If I was an unscrupulous support person and I received a log file from a customer that has a 5 character "*****" as the value for the admin token, I'd make a pretty good guess that they had not changed it from the default. OK, this is obviously bad practice to not have changed it, but I think we are increasing the risk that someone will be able to take a good guess that it has not been changed. This is apart from the fact that I assume code cracking algorithms work better if you know how many characters are in the answer.

[Henry Nash (henry-nash)]

A couple of other comments:

1) For clarity, it isn't the case that there is a single option called "secret". There are a number of options that need to be obfuscated, so "secret" is an attribute supported by oslo that can be defined on any config option (Keystone alone has 4 or 5 such options)

2) The fix I am proposing is a one liner in log_opt_values() in oslo/config/cfg.py, by changing:

        def _sanitize(opt, value):
            """Obfuscate values of options declared secret."""
            return value if not opt.secret else '*' * len(str(value))

to something like:

        def _sanitize(opt, value):
            """Obfuscate values of options declared secret."""
            return value if not opt.secret else '*' * 10

[Thierry Carrez (ttx)]

I could go either way here, but since the logs are not really supposed to be public, I would tend to consider this a welcome security strengthening rather than a vulnerability fix.

[Dolph Mathews (dolph)]

Good catch, and +1 for considering it to be security hardening and opening this bug.

For UX, I'd suggest that 3 asterisks, ***, is long enough to convey that's it's a suppressed value, but short enough to not imply that the length of the plaintext value shares the same length (whereas ten asterisks, **********, might lead someone to (incorrectly) report this same bug again in the future).

[Henry Nash (henry-nash)]

Ok, I'm fine with it being considered a security hardening exercise.

[Zhongyue Luo (zyluo)]

https://review.openstack.org/#/c/111888/