Closed Bug 528198 Opened 15 years ago Closed 15 years ago

Cancelling master password dialog box allows full access to the program

Categories

(Thunderbird :: Security, defect)

x86
Linux
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 35308

People

(Reporter: justhinkin2, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091112 Ubuntu/9.10 (karmic) Shiretoko/3.5.6pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091112 Shredder/3.0pre Using the nightly builds of Thunderbird 3Pre with a fresh profile I've found that cancelling out the master password dialog box allows full access to the program. Same as it would if I typed in the master password--no difference. Problem exists: -With or without extensions enabled. -In Safe Mode. -With 1 to 7 IMAP accounts added. (Have not tested with POP3) Problem also is seen with the nightly builds in Windows 7 RC as well as Ubuntu 9.10. This tells me that the bug is in the builds, not the platform. Can anyone confirm this? Reproducible: Always Steps to Reproduce: 1.Install the latest build of Thunderbird 3.0 using a fresh profile in either Ubuntu 9.10 or Windows 7 (Vista and XP bot tested) 2. Add an email account (IMAP) and set a master password. Restart TB 3.0Pre. 3.Cancel the Master password dialog box and verify full access to program. Actual Results: I have full access to program. Master password dialog box does not pop up when I attempt to access an email account or menu items. Expected Results: Cancelling out master password box should not allow me any access to email accounts or menu items without the master password dialog box appearing and forcing me to type in the password.
Correction: In "Steps to reproduce", step 1, the text in the paranthesis should read "(Vista and XP NOT tested).
Version: unspecified → Trunk
Group: core-security
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
With all due respect, this is not a duplicate of bug 318697 which involves the mail server password for a given email account. This bug is for the Master Password to the program itself which is entirely different altogether. The Master Password prevents access to Thunderbird itself, it's features and function, until the correct password is typed in.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(In reply to comment #3) > With all due respect, this is not a duplicate of bug 318697 which involves the > mail server password for a given email account. This bug is for the Master > Password to the program itself which is entirely different altogether. The > Master Password prevents access to Thunderbird itself, it's features and > function, until the correct password is typed in. No it doesn't it protect access to the mail server's password. It doesn't protect from accessing the emails - which can be accessed at the FS level anyway , just by reading into the profile directory. And If you prefer I can dup to 35308. But the issue still stays the same.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → DUPLICATE
(In reply to comment #4) > (In reply to comment #3) > > With all due respect, this is not a duplicate of bug 318697 which involves the > > mail server password for a given email account. This bug is for the Master > > Password to the program itself which is entirely different altogether. The > > Master Password prevents access to Thunderbird itself, it's features and > > function, until the correct password is typed in. > > No it doesn't it protect access to the mail server's password. It doesn't > protect from accessing the emails - which can be accessed at the FS level > anyway , just by reading into the profile directory. And If you prefer I can > dup to 35308. But the issue still stays the same. > > *** This bug has been marked as a duplicate of bug 35308 *** Ludovic - (slaps forehead) Understood. It completely slipped my mind that the master password only prevented access to the email accounts if one or more of the account password(s) were stored using the Password manager. Thanks for your patience.
I'm not sure I quite agree with duping, because this one and others like it are about UI behavior, and the other bug is about the "total security" perspective. In any event, in my experience it's not quite accurate that the 3.0 password manager and the master password don't prevent access to folders. I may have a strangely behaving profile - but normally, on a good day running 3.0, I have a profile that doesn't let me access folders unless the master PWD is provided. I just did a run of 15 or so "cancel pwd prompts" and it didn't let me in. In the error console I see Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgFolder.updateFolder]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///C:/Program%20Files/mozilla.org/TB%203.0b%20091112/modules/dbViewWrapper.js :: FolderNotificationHelper_notifyOnLoad :: line 131" data: no] this profile has several news, RSS, a pop, and a few imap accounts. My experience was the basis for declaring bug 231261 fixed by bug 239131 on 2009-04-09. It works this way on some of my other PCs as well - until one enters the master PWD one only sees the account manager. But I have just found it's not 100% consistent on this profile, which is rather disturbing. And more disturbing is others have never seen this change.
Wayne - For the matter of discussion, The old Thunderbird 3.0 profile (3 POP3, 4 IMAP) that I had for a couple of years (created when Thunderbird 3.0 was in the middle alpha stage) also did not allow any access unless the master password was entered much like in comment 6. Sometimes it had to be entered up to 3 times before it was accepted (old bug). Strangely enough this was with no account passwords stored in the password manager. I still have the old profile so I could check and see if I get anything like the error you saw in comment 6. Now that I think about it, starting Thunderbird with more than one tab did cause different behavior for example; it would cause yet another instance of having to type in the master password before I could gain access.
I don't store any account passwords - my sole reason for having the master was to testing it's capabilities with the new pwd mgr. It is possible that I didn't test enough or use it long enough on "older" builds before determining if the behavior in fact changed substantially with the new pwd mgr.
You need to log in before you can comment on or make changes to this bug.