1185096 - Lockscreen passcode bypass

Status: RESOLVED DUPLICATE of bug 1173284

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[sjw]

I tested this many times on Flame running Firefox OS 3.0/2.5 and was able to reproduce after a factory reset (even when USB access and Dev-Mode were disabled).
Current Build-ID: 20150715010202 (Commit c6ef0896)

STR:
- Set a code for the lockscreen, that should requested immediately (default).
- lock your screen and make sure that your code works
- (you can optional lock you screen again now)
- reboot the device
- immediately after you're back on your lockscreen, swipe to unlock

What happens?
A few seconds after reboot you are able to unlock the device without being asked for a code.

What I expect:
Pass code is required to unlock the device.


I think it's because the device is busy right after restart starting all services in background.
The scary thing is, that it takes me just a minute to bypass someones pass code, without having a computer, a magic adapter or similar. But of course the data on the Flame are not encrypted anyway.

Comment 1

[Daniel Veditz [:dveditz]]

Is this an issue with Flame specifically (a driver, perhaps) or a strictly Gaia cross-device issue?

Comment 3

[sjw]

Sadly, I have no other device to test and I can't reproduce in simulator.

Comment 5

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Happens on Aries as well.  I believe that this bug is a dup of bug 1173284

Comment 6

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

After speaking with Matt W. earlier today, it lead me to do some more testing for myself.
FYI, I'm able to reproduce this bug on 2.0, 2.1, 2.2, 2.5/3.0

I tried with a 1.3 version on flame release and it doesn't occur.  
I'm not sure about 1.3T, 1.4, 2.0M.  

Al, can you have someone check those versions?  I think 1.3T and 1.4 might be safe, I think 2.0M aren't. 

We'll also have to follow up with our partners in regards to this bug.  It basically means that anyone can break into a locked device.

Comment 7

[Al Tsai [:atsai]]

Cannot reproduce this on woodduck (2.0M). (0/5)

Comment 8

[Christiane Ruetten [INACTIVE]]

Al, I found that it's easier to exploit the race condition when I have the device booked into an encrypted wireless network before the reboot which seems to make the CPU more busy during Settings init, giving me a tad more time to swipe. Does that help?

Comment 9

[Christiane Ruetten [INACTIVE]]

Please move discussion to bug 1173284.

Comment 10

[Al Tsai [:atsai]]

Yes. I can reproduce that with increasing CPU load method. It's reproducible on Woodduck v2.0m.

BTW, I cannot see bug 1173284. cr, could you add me to the cc list? thanks.

Comment 11

[Christiane Ruetten [INACTIVE]]

You're in.