[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] Apple iOS v6.1 (10B143) - Code Lock Bypass Vulnerability #2
- To: Vulnerability Lab <research@xxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [Full-disclosure] Apple iOS v6.1 (10B143) - Code Lock Bypass Vulnerability #2
- From: andfarm <andfarm@xxxxxxxxx>
- Date: Mon, 18 Feb 2013 02:47:56 -0800
On 2013-02-17, at 17:21, Vulnerability Lab <research@xxxxxxxxxxxxxxxxxxxxx>
wrote:
> A code lock bypass vulnerability via iOS as glitch is detected in the
> official Apple iOS v6.1 (10B143) for iPad & iPhone.
Did you actually test the exploit on the iPad? I'm guessing you didn't, because
the iPad has no emergency call function (nor, for that matter, any phone
functionality at all).
> The vulnerability allows an attacker with physical access to bypass via a
> glitch in the iOS kernel the main device code lock (auth).
What makes you think the kernel is involved? Springboard seems a much more
likely candidate, seeing as how it's what actually handles the passcode lock
screen.
Also, the term you are looking for here is "passcode lock". Not "code lock",
nor "auth".
> The vulnerability is located in the main login module of the mobile iOS
> device (iphone or ipad)
Wait a minute, now it's an issue with the "main login module", not the kernel?
Can you identify what application or framework this module is part of?
OK, let's just be honest here. Did you actually locate any code which is
responsible for allowing this exploit to work, or are you just guessing?
> The vulnerability can be exploited by local attackers with physical device
> access without privileged iOS account or required user interaction.
Oh boy, this one is giving me hives.
1. A "local attacker" is usually implied to have physical access, *especially*
to a handheld device. If they didn't, they'd be a remote attacker.
2. iOS doesn't really have accounts, let alone "privileged" ones.
3. The exploit is composed entirely of user interactions. Saying that "the
vulnerability can be exploited [...without...] required user interaction" is
completely, utterly, totally wrong.
Hell, this whole sentence says almost nothing. It's all implied by a
non-logorrheic description of the exploit, like "we found a way to get an
iPhone to sync with a computer without entering the passcode".
I haven't tested the exploit myself yet, but the first step makes me wonder:
> 0. Connect your device with itunes and the appstore to make sure the code
> lock is activated
If you've previously connected the phone to the computer, you don't need to
unlock the device to sync it. Am I misreading this step, or do all the
following steps just lead up to a perfectly ordinary sync?
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/