full-disclosure - Re: Apple iOS v6.1 (10B143) - Code Lock Bypass Vulnerability #2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 18 Feb 2013 02:47:56 -0800
From: andfarm <andfarm@...il.com>
To: Vulnerability Lab <research@...nerability-lab.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Apple iOS v6.1 (10B143) - Code Lock Bypass
	Vulnerability #2

On 2013-02-17, at 17:21, Vulnerability Lab <research@...nerability-lab.com> 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/