Closed Bug 227100 Opened 21 years ago Closed 21 years ago

Password manager creates world-readable profiles and password files

Categories

(Toolkit :: Password Manager, defect)

defect
Not set
major

Tracking

()

VERIFIED FIXED

People

(Reporter: web-mozilla, Assigned: bryner)

References

Details

Attachments

(2 files)

User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20031129 Firebird/0.7+ Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20031129 Firebird/0.7+ I think the Summary says it all. While continuing to investigate bug 223964, I found that firebird on FreeBSD creates the .phoenix/user/profile/*.s and .phoenix/user/profile/*.w security and wallet files with 644 permissions. These files contain passwords stored by the Password Manager and form data from web forms you filled respectively. This has been confirmed to also be a problem on Mozilla 1.5 on Linux. I expect the problem is there with Windows2k/XP on NTFS (files being readable be "everybody"). Reproducible: Always Steps to Reproduce: 1. Install Mozilla 2. Go to a file wwhich required http auth an choose password (eg, bugzilla) 3. Profit! Actual Results: Bad mojo. Everyone could see my passwords. Expected Results: I understand that using one-way encryption is probably not possible for this scenario, but we should at least be using good file permissions.
has been fixed in mozilla already (after 1.5), if this is still an issue in firebird this is firebird specific
Assignee: dveditz+bmo → bryner
Product: Browser → Firebird
QA Contact: davidpjames
Version: Trunk → unspecified
Summary: Password manager creates world-readable password files, with only base64 encoded passwords → Password manager creates world-readable profiles and password files
Group: security
*** Bug 228179 has been marked as a duplicate of this bug. ***
I don't know why this is such an issue, especially on Linux. You would have to have a pretty strange set up to allow user A to view user B's home dir files, Firebird or not. Still, I can't see any good reason for 644 when 600 does the job just as well from the user's perspective. What to do about Windows is almost another problem altogether. Confirming.
Severity: critical → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Still related with bug 228179. This is a problem, not a question of unix environment. Mozilla or firebird should do this by them self. If you have a lot users organized in groups (thats a normal thing in facultys for instance) the default way of creating profile directory and files with 664 is not good, this a bad option of Firebird and Mozilla and not a question of unix environment. And by the way the base64 encryption is easy to crack :-( As I said earlier at least Mozilla allows to choose encryption for passwords....
Linux is not the only *nix OS. FreeBSD and Solaris by default create user home directories 755. I believe AIX does too. As psilva says this isn't a matter of the unix environment, but the principle that Mozilla and Firebird should be doing it right in the first place. I'm glad to hear that it's been fixed in 1.5+ (1.6?). Does this mean it is also fixed in the latest firebird or not? How can I get someone from firebird to look at this?
Regarding comment #5: Firebird does not use base64 encoding for passwords at all. It will read base64-encoded password files from Mozilla, but the next time it needs to update the password file (when an entry is added, removed, or modified), it will change it to use triple DES encryption with the master password (that is, it will use 3DES encryption even with no master password set, but if you set one, it will be more secure).
checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Regarding comment #7: Just to be sure I've erased my .mozilla and .phoenix directories in my home directory, and started from scratch. I went into a couple of pages that allowed me to store passwords and this time there was a difference, the file where the passwords where stored was called signons.txt. But has I've already said the passwords are stored in base 64!!! I runned a program to check it...
The value stored is a base64-encoded string, but if you decrypt it, you will get the 3DES ciphertext, not plaintext. It is base64 encoded so that there is not binary data in the encrypted passwords, as would otherwise happens with 3DES encryption.
In the above comment, I meant to say "if you decode it" rather than "if you decrypt it".
I hope I'm not being annoying but if you compile and run the program I've just posted with: ./a.out < .phoenix/default/xxx/singons.txt it shows you the passwords in clear text..... at least it does in mine.
> if (*line == '~') The ~ indicates a line that was written out by the old password manager, and is indeed base64 encoded cleartext. The new password manager in firebird 0.7 and later does not write out these lines. You should check to make sure you don't have libwallet.so in your components directory (that would contain the old password manager). I just created a new profile and stored my bugzilla logon. The lines for just the user id part look like this: Bugzilla_login MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECDvNWC+HoWc1BBgY+UGhgt8jHdZQkkHUVfXe4s0B8Z7OxBE=
I've found the problem! I used a tgz version from 0.7 and used without any old directories and it worked fine, the passwords where stored just like the example and not base64. So the problem is with the Mandrake mozilla-firebird-0.7-1mdk rpm I'm using :-( I removed the libwallet.so from the components directory and it started to save the passwords in 3DES, but the old ones remained in base64, I thought someone said it would change them... So this bug would just remain with the permissions problems of the passwords files that really should be 600. Mandrake does even worse, somehow the file are stored with 664 instead of 644 like the tgz version does!
v. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031212 Firebird/0.7+
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: