702922 - Printing password to command-line

Status: RESOLVED WONTFIX

(Firefox :: Security, defect)

Description

[Pander]

User Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111107 Ubuntu/10.10 (maverick) Firefox/3.6.24
Build ID: 20111107175754

Steps to reproduce:

Start Firefox 3.6.24 with Xmarks addon from the command-line


Actual results:

On the command-line the following is printed (username, password, hostname and path are examples):
...
no loadgroup notificationCallbacks for https://john:[e-mail]/webdav/john/xmarks.json
...


Expected results:

At least the password should not be printed on the command-line. I'm not sure if it goes via stdout or stderr but it should always be replaced by six asterisks ******

I am not ure if this is in the code of Firefox or in the code of the Xmarks addon. Please analyse this and when it is in Firefox. If it is in Xmarks, this issue should be assigned to them.

Comment 1

[Daniel Veditz [:dveditz]]

I can't find output of that message in either Firefox 3.6.x code or xmarks addon code. It was a quick look, maybe I missed it?

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

Andrew, please test this and see if you can reproduce. If you can, contact the developers and tell them we need a fix ASAP.

Comment 3

[Pander]

I can trigger it when I start firefox from the command line and go to the Xmarks preferences and initiate an upload. Note that I use my own server with webdav over https.

I understand pinpointing it might not be so easy but once you have found it, it is easy to mask the password. Once found, try also to locate similar messages that can be written to command-line that can contain password.

Comment 4

[Andrew Williamson [:eviljeff]]

I'm having trouble replicating this.

Doing a code search of the addon leads to only one place where a dump() is used -in the logWrite function in settings.jsm- but its toggled by a (hidden) debug pref called "debug-dumplog" so it leads me to believe its a issue somewhere in Firefox code.

I don't have access to a webDAV server and I've only tested on Windows 3.6.2 so far.

Comment 5

[Andrew Williamson [:eviljeff]]

(In reply to Andrew Williamson [:eviljeff] from comment #4)
> I don't have access to a webDAV server and I've only tested on Windows 3.6.2
> so far.

I've quickly tried again with 3.6.24 on Windows & Linux and the same result.

On the other hand, 
http://mxr.mozilla.org/mozilla1.9.2/search?string=\%22.*loadgroup&regexp=1&case=1&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla1.9.2

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to Pander from comment #3)
> I can trigger it when I start firefox from the command line and go to the
> Xmarks preferences and initiate an upload. Note that I use my own server
> with webdav over https.

That means that the URL https://john:[e-mail]/webdav/john/xmarks.json was something you set up in the add-on configuration, right? This sounds like a very unusual configuration, so it is unlikely to be a security problem.

I agree with Andrew's assessment that this is likely a Firefox dump and not an Xmarks dump, so there's nothing we can do there. I'd be interested in knowing if this still happens in more recent versions of Firefox, though.

Calling this WONTFIX.

Comment 7

[Pander]

Yes, I set that up in the Xmarks preferences. It is an unusual configuration but a valid configuration in which I use my own webdav solution.

Nevertheless I find it highly undesirable to have my password printed to the command-line. Suppose I am working with someone else behind the same computer when I start firefox from the command-line and that person sees my password. This a vulnerability for me but also sloppy from firefox not to mask it.

Please reconsider this issue.

Comment 8

[Pander]

If you want, I can provide you with a test account on my webdav service (via https on apache2). Just let me know and I will email you the credentials.

Comment 9

[Jorge Villalobos [:jorgev] (he/him)]

The problem is that URLs are not normally considered to be private information. Most services have learned this lesson and won't include any identifiable user info in URL strings. Knowing the URL can be very useful for debugging, so I doubt that we will remove that dump from the code. If there's any other way to access that service, other than hardcoding the user and password in the URL, I strongly recommend that you do that. If there isn't, you could contact Xmarks support and mention this problem; perhaps they can find a way around this.

I don't see how this is something that we *have* to fix, though.

Comment 10

[Pander]

Thanks for the feedback. This is now reported at Xmarks.