[chirp_devel] Security BUG: Chirp is leaking users passwords in the debug.log

[Dan Smith]

> I was working recently on a Chirp's issue and a user uploaded a debug.log for me... the debug.log has the passwords of an online service in plain text. the issue page was removed as per user request to maintain his privacy (I would had erased only the uploaded log and not the entire issue page, but I was offline at that time.) 

I was working from my phone and couldn't get it to nuke the attachment directly. The user was pretty concerned about it so I just nuked the whole issue.

> That is from any point of view a security risk and unacceptable, Chirp can't leak user's credentials.
> You can see a sample of a log (password obfuscated to "password" for security reason) in this comment: 
> https://chirp.danplanet.com/issues/5481#note-11

Yeah, this the suds library logging all the raw interaction. When I saw that, I was less concerned that it was us logging something directly. Is there anything specific in chirp code logging the credentials that you've found?

> I ask to Dan and others about the correct curse of action, as I see we have a few options:
> 
> 	• Don't log the XML data at all (this will make difficult to debug it)

We'd need to ask Tom his opinion I think. I dunno how important it is to have this information, or even if he intended to log it. It might have been added merely as a result of moving to unified python logging a couple years ago, and not squelching the sub-logger for suds. It's extremely verbose...

> 	• Parse the XML data output and remove/obfuscate the password before printing to debug.log

This isn't something we should do, IMHO, as we'd have to have a custom logger installed. I've done it, and it's a constant game of whack-a-mole that isn't fun.

> 	• #2 plus some command line switch to only log the clear text credentials by demand of the user/dev. 

This won't be accessible to most users, and would require #2 as well, as you say.

> Number 2 is the obvious option, but I don't have a online account to test not the connectivity and time to test it. 

I'm not in favor of #2 unless as a last resort.

> Who take it to fix it? Dan? Others?
> 
> Maybe I'm with the paranoia setting to high...

This only affects people with paid radioreference accounts, which is a very small subset of people, and only those which upload or otherwise expose their debug log. Thus, I don't think we need to panic here.

Personally, I'd just say we should limit suds logging to info or above. Anyone have a problem with that?

--Dan