Closed Bug 1185096 Opened 5 years ago Closed 5 years ago

Lockscreen passcode bypass

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1173284

People

(Reporter: sjw, Unassigned)

References

Details

(Keywords: sec-high)

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.
Is this an issue with Flame specifically (a driver, perhaps) or a strictly Gaia cross-device issue?
Keywords: sec-high
Duplicate of this bug: 1184875
Sadly, I have no other device to test and I can't reproduce in simulator.
Happens on Aries as well.  I believe that this bug is a dup of bug 1173284
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.
Flags: needinfo?(atsai)
Group: b2g-core-security
Cannot reproduce this on woodduck (2.0M). (0/5)
Flags: needinfo?(atsai)
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?
Flags: needinfo?(atsai)
Please move discussion to bug 1173284.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: CVE-2015-8511
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.
Flags: needinfo?(atsai) → needinfo?(cr)
You're in.
Flags: needinfo?(cr)
Group: core-security → core-security-release
Group: b2g-core-security, core-security-release
You need to log in before you can comment on or make changes to this bug.