User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041223 Firefox/1.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041223 Firefox/1.0 (I need to upload a testcase first - I have one but I want to test it here on bugzilla) Reproducible: Always
OK it does. This is a really big bug, which is caused by having firefox fill in passwords on every form on a subdomain. The testcase will get your bugzilla password if it was remembered (and it might simply hide the form and submit it to a webpage, too!) because its also on bugzilla.mozilla.org. Imagine someone uploading an attachment like this on some forum, or maybe with some webmail providers!
Attachment #172914 - Attachment description: testcase - unsure if it works → testcase - works
note that the bugzilla team is already aware of this problem. given that you filed this bug about firefox and that as is, it did not affect my seamonkey browser, i'm not going to cc any bugzilla devs.
Timeless: it definitely works against the Suite, too. *** This bug has been marked as a duplicate of 38862 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
Whiteboard: [sg:dupe 38862]
What is the status of bug #38862?
arg. well, it would seem it doesn't work if you don't have mozilla set to remember your password :) reporter: were you complaining about firefox or bugzilla? the bug dveditz picked is a bug about bugzilla and its status is that it's open. if you were trying to file a bug against the bugzilla product, then you really failed to file it in the right product.
It is a bug against the Firefox product, the testcase relates to bugzilla as it only works on the same domain as where the password was remembered for. Again: what was the status of bug #38862? I do not have enough permissions to view it.
reopening. the reporter clearly is filing this bug against firefox. the bug in question is a bug against bugzilla.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: a malicious attachment might allow someone to retrieve stored passwords → [testcase] malicious attachment might allow someone to retrieve stored passwords
Summary: [testcase] malicious attachment might allow someone to retrieve stored passwords → malicious attachment might allow someone to retrieve stored passwords
Short of turning off the password manager entirely (which the user can do), or the user not saving passwords for sites that display user-entered content, do you have any suggestions? The only thing that comes to mind is replaying the password only for the specific URL from which it was captured. Or perhaps if the path doesn't match then treat it as the multiple login case and make the user choose first.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:dupe 38862]
A few suggestions: * Save the password per-page and not for the whole domain. The password can only be captured by hacking the original page then, but that's not an issue. * Ask for user interaction to fill in a password (confirmation, clicking a button, filling in the first letter of the username.
Of course a temporary workaround is disabling the password manager.
Making password manager per-URL rather than per-(protocol,host,port) would not prevent XSS holes such as the ones mentioned in comment 2 and comment 13 from being used to steal passwords stored with password manager. The attacker would just have to open the URL of the login form in a frame and then get the password from the frame. Wontfix, dup of bug 38862, or dup of bug 263387. But it should probably stay security-sensitive until bug 38862 is fixed.
Hmm true. Then the only solution to treat all forms like multi-username forms or having the user click a button/confirmation.
> As I stated before, this bug can work for theoretically every site, especially > sites everyone can upload files to (forums, bugzilla, webmail services). Most webmail services avoid having this kind of hole by keeping attachments at a different hostname or by scrubbing HTML attachments. > Another method to exploit this is using the 'write contents of the string on the > site' method, like http://www.somesite.com/error.php?error=<h1>404</h1>. It is true that many sites have holes like this, but I don't think a change to password manager (like in bug 263387) is the correct solution. There are several other ideas for solutions in this bug, which could turn into new bugs blocking bug 301375. I'd prefer for that discussion to not take place in this bug, because this bug discusses a security hole in Bugzilla that is still hidden.
Status: NEW → RESOLVED
Last Resolved: 14 years ago → 14 years ago
Resolution: --- → WONTFIX
Summary: malicious attachment might allow someone to retrieve stored passwords → Firefox fills in passwords on malicious Bugzilla attachment
Whiteboard: [keep hidden until bug 38862 is fixed]
Assignee: bugs → nobody
Component: Form Manager → Password Manager
QA Contact: form.manager → password.manager
You need to log in before you can comment on or make changes to this bug.