Closed Bug 539608 Opened 16 years ago Closed 15 years ago

Master password vulnerability to RAM dump

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: drgigguls, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 I'll just post the steps to cracking it below. Reproducible: Always Steps to Reproduce: RAM dump 1. Generating Random pass: 2349utyuioejhfgpo 2. Setting... 3. closing FF 4. opening FF... 5. entering password... 6. FF Loaded. 7. Dumping Proccess Memory... 8. Searching for 2349utyuioejhfgpo as CHAR* 9. FAIL 10. Searching for 32 00 33 00 34 00 39 00 75 00 74 00 79 00 75 00 69 00 6F 00 65 00 6A 00 68 00 66 00 67 00 70 00 6F 00 00 00 00 11. COMPLETED! Address: 1c2c150 Changing master password... 1. generating new: wekhntgqejoho234urhfwdjghweofwrkljheljhfqwdkt34ujhwdg 2. restarting... 3. dumping... 4. finding wekhntgqejoho234urhfwdjghweofwrkljheljhfqwdkt34ujhwdg ... FOUND: 0x04bc8a88 CONCLUSION: Master password is visible! Actual Results: CONCLUSION: Master password is visible! And in the interval between 0x01000000 and 0x0400000. I still can't figure how to pin point it but I might be able to do that soon (after all, it's 3:23am here right now).
I'm unclear what the vulnerability you're reporting is. Yes, the master password is kept in memory in order to decrypt the stored passwords as they are needed. If we did not keep the master password in memory, we would either have to keep it on disk or prompt the user for it each time we wanted to access the password store. Am I missing something?
Whiteboard: [sg:needinfo]
Well, there are approaches we could take here that would lead to less disclosure (e.g. using the password to decrypt the passwords and form data in memory, throwing the password away, expiring the tables after N minutes). On the other hand, we have never made security claims about robustness in the face of an attacker with local, debug-level access to the user's machine. At that point, it seems rather simpler and more profitable to just install a keylogger, I'd think?
I believe NSS has support for timing out a master password (to require reentry after N minutes), but we don't expose it. SeaMonkey might. TBH, I suspect all that's being found here is the user's input before GC has run. I don't think softtoken actually keeps the string value around, but rather an intermediate PBKDF value.
I have no idea how to hide it and I am not a Firefox developer so I don't think it's my job to figure it out. I just had to report it.
If the master password is actually "the user's input before GC has run", as opposed to something we actually need to keep in memory to decrypt passwords, we could theoretically fix it by overwriting the variables in question. This might be hard enough that it's not worth it, though, especially if the string values are garbage-collected. On the other hand, we have to keep *something* in memory that grants access to the users' web site passwords, which is probably more interesting to an attacker than the master password itself. (I wouldn't want to rely on GC because conservative GC doesn't guarantee much.)
Group: core-security
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Whiteboard: [sg:needinfo]
You need to log in before you can comment on or make changes to this bug.