1490905 - [lockbox] Lockbox doesn't clear data when app is deleted, leading to auth bypass

Status: RESOLVED FIXED

(Lockwise Graveyard :: Security, defect)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

[NOTE: This isn't Firefox for iOS,  but Lockbox, but I don't know that we have anywhere secure yet for lockbox bugs]

I noticed that if you delete lockbox, re-add the application and then login with a different user, you can read passwords that were previously saved. I  don't know if this is a by-product of installing via buddy build, but Im filing this as a precaution.

STR:
1. Setup lockbox with an account (lets call its [e-mail]) and sync some  passwords to it
2. Choose "lock now"
3. Observe that a fingerprint (or passcode if you dont have fingerprint) is now required to open lockbox
4. Delete the lockbox app
5. Re-install the app
6. Sign-in with a different account ([e-mail])

Expected:
No passwords, since its a new account

Actual:
The passwords from the previous account are there.

An attack with physical access to a phone which  is unlocked (but who's Lockbox is locked) would be able to access lockbox passwords via this method. (re-installing an app you have installed once before doesn't need a password I think?)

Comment 1

[Daniel Veditz [:dveditz]]

Devin: can you make sure this bug makes it to the right developers

Not sure whether to rate this as sec-high because it's a way to steal/leak sensitive passwords or downgrade to sec-moderate because it requires physical unlocked acccess. Probably more the latter but it would be an embarrasing failure mode for a password manager.

Comment 2

[Devin Reams]

Agreed on the nature and general characterization. We leaned towards medium due to the physical access requirement. 

We will work on a fix to ensure the “Disconnect” more fully disconnects. 

Interestingly enough, once the app is fully backgrounded or phone restarted the test1 data is not accessible. You are forced to sign in to test2 Account again. Another slight “mitigation” I suppose...

Comment 3

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Devin Reams (dreams) from comment #2)
> Agreed on the nature and general characterization. We leaned towards medium
> due to the physical access requirement. 

That might be true in the general sense, I'm not sure I agree with that threat model for a password manager (especially one called 'lockbox'). Or rather, it would seem to undermine all the work we did to implement controls  - like fingerprint required on login. I'm probably splitting hairs here, and I know you are looking at this as a priority, but I'd be cautious of a reputational impact here. It's the type of bug you might stumble upon (I did), and there would be significant reputational impact to the product. 

> 
> We will work on a fix to ensure the “Disconnect” more fully disconnects. 
> 
> Interestingly enough, once the app is fully backgrounded or phone restarted
> the test1 data is not accessible. You are forced to sign in to test2 Account
> again. Another slight “mitigation” I suppose...

That's not the situation that I'm observing. I haven't used lockbox in a week or so (phone has been off and restarted in between). Without logging in to lockbox, I just deleted lockbox, re-installed, logged in with a new account, and it shows me signed in with the old account, not the one I just logged in with.

Comment 4

[Devin Reams]

Thanks for the additional commentary, Paul. Understood and agreed all around, I didn't mean to be dismissive if it seemed that way.

We've got this top of our list to address: https://github.com/mozilla-lockbox/lockbox-ios/issues/716

Comment 5

[Devin Reams]

This concern is addressed at https://github.com/mozilla-lockbox/lockbox-ios/pull/752 and will be code reviewed and released to the public in the next point release (within 1-2 weeks).

Paul, please feel free to re-test on the branch build via buddybuild (2046) or when it merges to master, depending on when you can get to checking it out.