*35C3 preroll music*
Herald-Angel: All right, let's start with our next talk in the security track of the
chaos communication congress. The talk is called jailbreaking iOS from past to
present. Done by tihmstar. He spoke at the 32nd C3 already and researched on several
jailbreaks like the Phoenix or the jelbrekTime for the Apple Watch and he's
gonna talk about the history of jailbreaks. He's going to familiarize you
with the terminology of jailbreaking and about exploit mitigations and how you can
circumvent these mitigations. Please welcome him with a huge round of applause.
*Applause*
tihmstar: Thank you very much. So hello room, I'm tihmstar, and as already said I
want to talk about jailbreaking iOS from past to present and the topics I'm going
to cover "what is jailbreaking?". I will give an overview in general. I'm going to
introduce you to how jailbreak started, how they got into the phone at first and
how all of these progressed. I'll introduce you to the terminology which is
"tethered", "untethered", "semi-tethered", "semi-untethered" jailbreaks. Stuff you
probably heard but some of you don't know what that means. I'm gonna talk a bit
about hardware mitigations which were introduced by Apple which is KPP, KTRR and
a little bit about PAC. I'm going to talk about the general goals of... About the
technical goals of jailbreaking and the kernel patches and what you want to do
with those and brief overview how jailbreaking could look like in the future.
So who am I? I'm tihmstar. I got my first iPod touch with iOS 5.1 and since
then I pretty much played with jailbreaks and then I got really interested into that
and started doing my own research. I eventually started doing my own
jailbreaks. I kinda started with downgrading – so I've been here two years
ago with my presentation "iOS Downgrading: From past to present". I kept hacking
since then. So back then I kind of talked about the projects I made and related to
downgrading which was tsschecker, futurerestore, img4tool, you probably have
heard of that. And since then I was working on several jailbreaking tools
ranging from iOS 8.4.1 to 10.3.3, among those 32bit jailbreaks, untethered
jailbreaks, remote jailbreaks like jailbreak.me and the jailbreak for the
Apple Watch. So, what is this jailbreaking I am talking about? Basically, the goal is
to get control over a device you own. You want to escape the sandbox which the apps
are put in. You want to elevate the privileges to root and eventually to
kernel, you want to disable code signing because all applications on iOS are code-
signed and you cannot run unsigned binaries. You pretty much want to disable
that to run unsigned binaries. And the most popular about people on jailbreak is
to install tweaks! And also a lot of people install a jailbreak or jailbreak
their devices for doing security analysis. For example if you want to pentest your
application and see how an attack goes foot – you want to debug that stuff and
you want to have a jailbroken phone for that. So what are these tweaks? Tweaks are
usually modifications of built-in userspace programs, for example one of the
programs is springboard. Springboard is what you see if you turn on your phone.
This is where all the icons are at. And usually you can install tweaks to, I don't
know, modify the look, the behavior or add functionality, just this customization,
this is how it started with jailbreaking. What is usually bundled when you install a
jailbreak is Cydia. So you install dpkg and apt which is the Debian package
manager and you also get Cydia which is a user-friendly graphical user interface for
the decentralized or centralized package installer system. I'm saying centralized
because it is pretty much all in one spot, you just open the app and you can get all
your tweaks and it's also decentralized because you can just add up your own repo,
you can make your own repo, you can add other repos and you're not kinda tied to
one spot where you get the tweaks from, like from the App Store you can only download
from the App Store. But with Cydia you can pretty much download from everywhere.
You're probably familiar with Debian and it's pretty much the same. So this talk is
pretty much structured around this tweet: the "Ages of jailbreaking". So as you can
see we get the Golden Age, the BootRom, the Industrial Age and The Post-
Apocalyptic age. And I kind of agree with that. So this is why I decided to
structure my talk around that and walk you through the different ages of
jailbreaking. So starting with the first iPhone OS jailbreak – then it was actually
called iPhone OS not iOS – it was not the BootROM yet. So the first was a buffer
overflow and the iPhone's libTitt library. And this is an image parsing library.
It was exploited through Safari and used as an entry point to get code execution.
It was the first time that non-Apple software was run on an iPhone and people installed
applications like Installer or AppTapp which were stores similar to Cydia back
then and those were used to install apps or games because for the first iPhone OS
there was no way to install applications anyhow, as the App Store got introduced
with iOS 2. So then, going to the Golden Age, the attention kind of shifted to the
BootROM; people started looking at the boot process and they found this device
firmware upgrade mode which is a part of ROM. So the most famous BootROM exploit
was limera1n by geohot. It was a bug in hardware and it was unpatchable with
software. So this bug was used to jailbreak devices up to the iPhone 4.
There were also several other jailbreaks – we didn't rely on that one – but this one,
once discovered, you can use it over and over again and there's no way to patch
that. So this was later patched in a new hardware revision which is the iPhone 4s.
So with that BootROM bug –
This is how kind of tethered jailbreaks became a thing. So limera1n exploits a bug
in DFU mode which allows you to load unsigned software through USB. However
when you reboot the device a computer was required to re-exploit and again load your
unsigned code. And then load the bootloaders, load the patched kernel and
thus the jailbreak was kind of tethered to the computer because whenever you shut
down you need to be back at a computer to boot your phone up. So historically a
tethered jailbroken phone does not boot without a computer at all. And the reason
for that is because the jailbreaks would modify the kernel and the bootloaders on
the file system for performance reasons, so when you do the actual tether boot you
would need to upload a very tiny payload via USB which then in turn would load
everything else from the file system itself. But this results in a broken chain
of trust. When the normal boot process runs and the bootloader checks the
signature of the first-stage bootloader that would be invalid so the bootloader
would refuse to boot that and it would end up in DFU mode so basically a phone won't
boot. Sometime around then, the idea for semi-tethered jailbreak came up and the
idea behind that is very simple: just don't break the chain of trust for
tethered jailbreaks. So, what you would do differently is you do not modify the
kernel on the file system, don't touch the bootloaders at all and then when you
would boot tethered, you would need to upload all the bootloaders like the first
stage bootloader, then the second stage bootloader which is iBoot and then the
kernel via USB to boot into jailbroken mode. However when you reboot you could
boot all those components from the file system so you could actually boot your
phone into non-jailbroken mode. If you don't install any tweaks or modifications
which modify critical system components because if you tamper with, for example,
the signature of the mount binary the system obviously cannot boot
in non-jailbroken mode.
So, this is kind of the Golden age. So let's continue with the Industrial age.
So with the release of the iPhone 4s and iOS 5, Apple fixed the
BootROM bug and essentially killed limera1n. They also introduced APTickets
and nonces to bootloaders, which I'm just mentioning because it's kind of a
throwback for downgrading: before that you can have a phone if you update to the
latest firmware and before you save your SHSH blobs you could just downgrade and
then jailbreak again which wasn't a big deal but with that they also added
downgrade protection so jailbreaking became harder. If you wanted to know more
about how the boot process works, what SHSH blobs are, what APTickets are, you
should check out my talk from two years ago, I go in-depth on how all of that
works. So, I'm skipping that for this talk. So the binaries the phone boots are
encrypted so the bootloaders are encrypted and until recently the kernel used to be
encrypted as well. And the key encryption key is fused into the devices and it is
impossible to get through hardware attacks. At least there's no public case
where somebody actually got that recovered at keys so it's probably impossible,
nobody has done it yet. So old boot files are decrypted at boot by the previous
bootloader. And before the iPhone 4s you could actually just talk to the hardware
iOS engine as soon as you got kernel-level code execution. But with the iPhone 4s
they introduced a feature where before the kernel would boot they would shut off the
iOS engine by hardware, so there is no way to decrypt bootloader files anymore so
easily unless you got code execution in the bootloader itself. So decrypting
bootloaders is a struggle from now on. So I think kind of because of that the
attention shifted to userland and from now the jailbreaks kind of had to be
untethered. So untethered here means that if you jailbreak your device, you turn it
off, you boot it again, then the device is still jailbroken, and this is usually
achieved through re-exploitation at some point in the boot process. So you can't
just patch the kernel on file system because that would invalidate signatures,
so instead you would, I don't know, add some configuration files to some demons
which would trigger bugs and then exploit. So jailbreaks then chained many bugs
together, sometimes six or more bugs to get initial code execution, kernel code
execution and persistence. This somewhat changed when Apple introduced free
developer accounts around the time they released iOS 9. So these developer
accounts allow everybody who has an Apple ID to get a valid signing certificate for
seven days for free. So you can actually create an XCode project and run your app
on your physical device. Before that that was not possible, so the only way to run
your own code on your device was to buy a paid developer account which is 100$ per
year if you a buy personal developer account. But now you can just get that for
free. And after seven days the certificate expires, but you can just, for free,
request another one and keep doing that. Which is totally enough if you develop
apps. So this kind of led to semi- untethered jailbreaks because initial code
execution was not an issue anymore. Anybody could just get that free
certificate, sign apps and run some kind of code that was sandboxed. So jailbreak
focus shifted to more powerful kernel bugs which were reachable from sandbox. So we
had jailbreaks using just one single bug or maybe just two bugs and the jailbreaks
then were distributed as an IPA, which is an installable app people would download,
sign themselves, put on the phone and just run the app. So semi-untethered means
you can reboot into non-jailbroken mode, however you can get to jailbroken mode
easily by just pressing an app. And over the years Apple stepped up its game
constantly. So with iOS 5 they introduced ASLR address space layer randomisation,
with iOS 6 they added kernel ASLR, with the introduction of the iPhone 5, as they
added 64bit CPUs, which isn't really a security mitigation, it just changed a bit
how you would exploit. So the real deal started to come with iOS 9, where they
first introduced Kernel Patch Protection, an attempt to make the kernel immutable
and not patchable. And they stepped up that with the iPhone 7 where they introduced
Kernel Text Readonly Region, also known as KTRR. So with iOS 11 they removed 32bit
libraries, which I think has very little to no impact on exploitation; it's mainly
in the list because up to that point Cydia was compiled as a 32bit binary and that
stopped working, that's why that had to be recompiled for 64bit, which took someone
to do until you could get a working Cydia on 64bits iOS 11. So with the iPhone Xs
which came out just recently they introduced Pointer Authentication Codes,
and I'm gonna go more in detail into these hardware mitigations in the next few
slides. So let's start with Kernel Patch Protection. So when people say KPP, they
usually refer to what Apple calls watchtower. So watchtower, as the name
suggests, watches over the kernel and panics when modifications are detected,
and it prevents the kernel from being patched. At least that's the idea of it.
It doesn't really prevent it because it's broken but when they engineered it, it
should prevent you from patching the kernel. So how does it work? Watchtower is
a piece of software which runs in EL3 which is the ARM exception level 3.
So exception levels are kind of privilege separations while 3 is the highest and 0
is the lowest. And you can kind of trigger an exception to call handler code in
higher levels. So the idea of watchtowers that recurring events which is FPU usage
trigger Watchtower inspection of the kernel, and you cannot really turn it off
because you do need the FPU. So if you picture how it looks like, we have the
Watchtower to the left (which totally looks like a lighthouse) and the
applications at the right. So in the middle, in EL1, we have the kernel and
recent studies revealed that this is exactly how the XNU kernel looks like. So
how can we be worse? An event occurs from time to time which is from using userland
application, for example JavaScript makes heavy use of floating points, and the
event would then go to the kernel and the kernel would then trigger Watchtower as it
tries to enable the FPU. Watchtower would scan the kernel and then if everything is
fine it would transition execution back into the kernel which then in turn would
transition back into userspace which can then use the FPU. However with a modified
kernel, when Watchtower scans the kernel and detects modification, it would just
panic. So the idea is that the kernel is forced to call Watchtower because the FPU
is blocked otherwise. But the problem at the same time is that the kernel is in
control before it calls watchtower. And this thing was fully defeated by qwerty in
yalu102. So how qwerty's KPP bypass works: The idea is: you copy the kernel in memory
and you mody the copied kernel. Then you would modify the page tables to use the
patched kernel. And whenever the FPU triggers a Watchtower inspection, before
actually calling Watchtower you would switch back to the unmodified kernel and
then let it run, let it check the unmodified kernel when that returns you
would go back to the modified kernel. So this one it looks like: we copy the kernel
in memory, we patch the modified copy, we switch the page tables to actually use the
modified copy and when we have the FPU event it would just switch the page tables
back, forward the call to Watchtower, make then watch tower scan the unmodified
kernel and after the scan we would just return to the patched kernel. So the
problem here is: Time of check – Time of Use, the classical TOCTOU. And this works
on the iPhone 5s, the iPhone 6 and the iPhone 6s and it's not really patchable.
However, with the iPhone 7, Apple introduced KTRR, which kind of proves that
and they really managed to do an unpatchable kernel. So how does KTRR work?
So Kernel Text Readonly Region, I'm going to present as described by Siguza in his
blog, adds an extra memory controller which is the AMCC which traps all writes to
the read-only region. And there's extra CPU registers which mark and executable range
which are the KTRR registers and they obviously mark a subsection of the
read-only region, so you have hardware enforcement at boot time for read-only
memory region and hardware enforcement at boot-time for an executable memory region.
So this the CPU. This is the memory at the bottom. You would set the read-only region
at boot and since that's enforced by the hardware memory controller everything
inside that region is not writable and everything outside that region is
writable. And the CPU got KTRR registers which mark begin and end. So the
executable region is a subsection of the read-only region. Everything outside there
cannot be executed by the CPU. Everything inside the read-only region cannot be
modified. And this has not been truly bypassed yet. There's been a bypass but
that actually targeted how that thing gets set up. But that's fakes and now it's
probably setting up everything and so far it hasn't been bypassed. So jailbreaks are
still around. So what are they doing? Well, they just walk around kernel patches
and this is when KPP jailbreaks evolved. Which means, they just don't patch
the kernel. But before we dive into that, let's take a look what previous jailbreaks
actually did patch in the kernel. So the general goals are to disable code signing
to disable the sandbox to make the root file system writable to somehow make
tweaks work which involves making mobile substrate or libsubstitute work which is
the library for hooking. And I was about to make a list of kernel patches which you
could simply apply, however, the techniques and patches vary across
individual jailbreaks so much that I couldn't even come up with the list of
kernel patches among the different jailbreaks I worked on. So there's no
general set of patches, some prefer to do it that way, some prefer to do it that
way. So instead of doing a kind of full list, I'll just show you what the Helix
jailbreak does patch. So the Helix jailbreak first patches the
i_can_has_debugger, which is a boot arc. It's a variable in the kernel and if you
set that to true that would relax the sandbox. So to relax the sandbox or to
disable code signing usually involves multiple steps. Also since iOS 7 you need
to patch mount because there's actual hardcoded that the root filesystem cannot
be mounted as read-write. Since iOS 10.3, there is also hardcoded that you cannot
mount the root filesystem without the nosuid flag, so you probably want to patch
that out as well. And then if you patch both these you can remount the root
filesystem as read-and-write, however you cannot actually write to the files on the
root filesystem unless you patch Light- Weight Volume Manager which you also only
need to do in iOS 9 up to iOS 10.3. Later when they switched to APFS you don't
actually need that anymore. Also there's a variable called proc_enforce. You set that
to 0 to disable code signing which is one of the things you need to do to disable
code signing. Another flag is cs_enforcement_disable, set that to 1 to
disable code signing. So amfi, which is Apple mobile file integrity is a kext which
handles the code signing checks. In that kext it imports the mem-copy function.
So there's a stub and one of the patches is to patch that stub to always return 0
by some simple gadget. So what this does is, whenever it compares something in a
code, it would just always compare… say that the compare succeeds and is equal.
I'm not entirely sure what it does, so this patch dates back to Yalu
but like just supplying that patch helps
killing code signing, so that's why it's in there. Another thing h3lix does is, it
adds the get-task-allow entitlement to every process and this is for allowing
read/ write/executable mappings and this is what you want for a mobile substrate
tweaks. So initially this entitlement is used for debugging because
there you also need to be able to modify code at runtime for setting breakpoints
while we use it for getting tweaks to work. Since iOS 10.3 there's... h3lix also
patches label_update_execve patch... label_update_execve function. So the idea
of that patch was to fix the "process-exec denied while updating label" error message
in Cydia and several other processes. Well that seems to completely nuke the sandbox
and also break sandbox containers so this is also the reason why if you're
jailbreaking with h3lix apps would save their data in the global directory instead
of their sandbox containers. And you also kill a bunch of checks in
map_ops_policy... mac_policy_ops to relax the sandbox. So if you want to check out
how that works yourself, unfortunately h3lix itself is not open-source and I've
no plans of open-sourcing that. But there's two very very closely related
projects which are open-source which is doubleH3lix – this is pretty much exactly
the same but for 64 bit devices which does include the KPP bypass, so it also
patches the kernel – and jelbrekTime, which is the watchOS jailbreak. But h3lix
is for iOS 10 and the watchOS jailbreak is kind of the iOS 11 equivalent but it
shares like most of the code. So most of the patch code is the same if you want to
check that out. Check these out. So, KPPless jailbreaks. So the idea is, don't
patch the kernel code but instead patch the data. So for an example we go for
remounting root file system. We know we have hardcoded checks which forbid us to
mount the root file system read/write. But what we can do is in the kernel there's
this structure representing the root file system and we can patch that structure
removing the flag saying that this structure represents the root file system.
And we simply remove that and then we can call remount on the root file system and
then we put back in the flag. So we kind of bypass the hardcoded check. For
disabling code signing and disabling sandbox there are several approaches.
In the kernel there's a trust cache so usually amfi handles the code signing.
The demon in userspace handles the code signing requests. But the demon itself
also needs to be code-signed. So you have the chicken and egg problem. That's why in
the kernel there is a list of hashes of binaries which are allowed to execute. And
this thing is actually writable because when you mount the developer disk image it
actually adds some debugging things to it so you can simply inject your own hash
into the trust cache making the binary trusted. Another approach taken by
jailbreakd and the latest electro jailbreak is to have a process, in this
case jailbreakd, which would patch the processes on creation, so when you spawn a
process that thing would immediately stop the process, go into the kernel, look up
the structure and remove the flags saying "kill this process when the cold
signature becomes involved" and it will invalid. And it would also add the
get-task-low entitlements. And then after it's done that it would resume the process
and then the process won't get killed any more because it's kind of already trusted.
And the third approach taken or demoed by bazad was to take over amfid and userspace
completely. So if you can get a Mac port to launchd or to amfid you can impersonate
that and whenever the kernel asks and feels that it's trusted you would reply
"Okay yeah that's trusted that's fine you can run it" so that way you don't need
to go for the kernel at all. So future jailbreaks. Kernel patches are not really
possible anymore and they're not even required. Because we can still patch the
kernel data or not go for the kernel at all. But we're still not done yet, we
still didn't go for Post-Apocalyptic or short PAC. Well actually
PAC stands for pointer authentication codes but you get the joke.
So pointer authentication codes were introduced with the iPhone Xs and if we
quote Qualcomm "This is a stronger version off stack protection". And pointer
authentication codes are similar to message authentication codes but for
pointers, if you are familiar with that. And the idea of that is to protect data in
memory in relation to context with a secret key. So the data in memory could be
the return value and the context could be the stack pointer or data in memory could
be a function pointer and the context could be a vtable. So if we take a look
how PAC is implemented. So at the left you can see function entry and like function
prologue and function epilogue without PAC and with PAC the only thing that would be
changed is when you enter a function before actually doing anything inside it,
you would normally store the return value on the stack but when doing that you would
first authenticate the pointer with the context and then kinda create the
signature and store it inside the pointer and then put it on the stack. And then
when you leave the function you would just take back the pointer, again calculate the
signature and see if these both signatures matches and if they do then just return
and if the signature's invalid you would just throw a hardware fault. So this is
how it looks like for 64-bit pointers. You don't really use all of the available bits.
So usually you use 48 bits for virtual memory which is more than enough.
If you use memory tagging you have seven bits left for putting in
the signature or if you do not use memory tagging you can use up to 15 bits for the
pointer authentication code. So the basic idea of PAC is to kill ROP like code reuse
attacks. You cannot simply smash the stack and create a ROP chain because every
return would have an instruction verifying the signature of the return value and that
means you would need to sign everything, every single of these pointers and since
you don't know the key you can't do that in advance. So you cannot modify a return
value and you cannot swap two signed values on the stack unless the stack
pointer is the same for both. Can we bypass it? Maybe. I don't know. But we can
take a look at how that thing is implemented. So if we take a look at the
ARM slides you can see that PAC is basically derived from a pointer and a
64-bit context value and the key and we put all of that in the algorithm P. And
that gives us the PAC which we store in the unused bits. So the algorithm P can
either be QARMA or it can be something completely custom. And the instructions,
the ARM instructions, kind of hide the implementation details. So if you would go
for attacking PAC, there's two ways of attack strategies. We can either try and
go straight for the cryptographic primitive like take a look what cipher it
is or how that cipher is implemented. Maybe it's weak or we can go and attack
the implementation. So if we go and attack the implementation we could look for
signing primitives, which could be like small gadgets we could jump to somehow,
somehow execute to sign a value which could be either an arbitrary context
signing gadget or maybe a fixed context signing gadget. We could also look for
unauthenticated code, for example I imagine the code which sets up PAC itself
is probably not protected by PAC because you can't sign the pointer if the key is
not set up yet. Maybe that code is still accessible. We could look for something
like that. We could also try to replace pointers which share the same context.
It's probably not feasible for return values on the stack, but maybe it's
feasible for swapping pointers in the vtable. Or maybe you come up with your own
clever idea how to bypass that. These are just like some ideas. So I want to make a
point here, that in my opinion it doesn't make much sense to try to attack the
underlying cryptography on PAC, so I think that if we go for attacking PAC it makes
much more sense to look for implementation attacks and not attacking the cryptography
and the next few slides are just there to explain why I think that. So if we take a
look at QARMA which was proposed by ARM as being one of the possible ways of
implementing PAC. PAC, uhm, QARMA is a tweakable block cipher, so it takes an
input, a tweak and gives you an output. Which kind of fits perfectly for what we
want. And then I started looking at QARMA and came up with ideas on how are you
could maybe attack that cipher. At some point I realized that practical crypto
attacks on QARMA if there will be any in the future will probably that's what I
think completely irrelevant to the PAC security. So why's that? If we define –
So just so you know, the next few slides I'm going to bore you with some math but
it's not too complex. So if we define PAC as a function which takes a 128 bit input
and a 120-bit key and maps it to 15 bits output. Or we can more realistically
define it as a function which takes 96 bits input with a 128-bit key because we
have a 48-bit pointer because the other ones we can't use because that's where we
store the signature and we're most likely using the stack pointer as a context so
that one will also only use 48-bit pointers, 48 bits. Then we have PAC as a
construct so then we define the attacker with following capabilities. The attacker
is allowed to observe some pointer and signature pairs and I assume that you can
get that through some info leaks, for example you have some bug in the code
which lets you dump a portion of the stack with a bunch of signed pointers.
This is why you can observe some, not all, but you can see some and I would also
allow to have the attacker be able to slightly modify the context and what I
mean by that is I imagine a scenario where the attacker could maybe shift the stack,
maybe through more nested function calls before executing the leak which will give
you actually two signatures for the same pointer but with a different context.
Maybe that's somewhat helpful. But still we realize that the attacker, the
cryptographic attacker, is super weak so the only other cryptographic problem there
could be is collisions. And for those of you who seen my last talk they probably
know I love collisions. So we have 48-bit pointer, 48-bit context and 128-bit key.
We sum that up and we divide that by the 15-bit of output we get from PAC which
gives us 2 to the power of 209 possible collisions because we map so many bits to
so little bits. But even if we reduce the pointers because practically probably less
than 34 bit of a pointer are really used, we still get 2 to the power 181
collisions, which is a lot of collisions but the bad thing here is random
collisions are not very useful to us unless we can predict them somehow. So
let's take a look how a cryptographically secure MAC is defined. So a MAC is defined
as following: Let p be a MAC with the following components and those are
basically Gen(), Mac() and Vrfy(). So Gen() just somehow generates a key, it's
only here for the sake of mathematical completeness. Just assume we generate the
key by randomly choosing n bits or however how much bits the key needs. And Mac() is
just a function where you put in an n-bit message called m and it gives us a
signature t. And I'm going to say signature but in reality I mean a message
authentication code. And the third function is Vrfy() and you give it a
message and a signature and that just returns true if that signature is valid
for the message or false if it's not. And when cryptographers prove that something
is secure they like to play games. So I'm gonna to show you my favorite game, which
is Mac-forge game. So the game is pretty simple you have to the left the game
master which is playing Mac-forge and to the right the attacker. So the game
starts when the Mac-forge game master informs the attacker how much bits are we
playing. So this is the first 1 to the power of n, basically means hey we're
having MAC-forge with, I don't know, 64-bit messages so the attacker knows the
size. Then the game master just generates the key and then the attacker can choose to
q messages of n-bit length and send them over to the game master and the game
master will generate signatures and send them back. So then the attacker can
observe all the messages he generated and all the matching signatures. So what the
attacker needs to do then is to choose another message which he did not send over
yet and somehow come up with a valid signature and if he can manage to do that
he sends it over and if that's actually a valid signature for the message then he
wins the game, otherwise he looses the game. So we say a Mac is secure if the
probability that an attacker can somehow win this is negligible. So I'm gonna spare
you the mathematical definition of what negligible means but like just guessing or
trying means that it's still secure if that's the best tech. So as you can see is
a MAC which is secure needs to withstand this. But for our PAC attacker we do not
even have this oracle. So our attacker for PAC is even weaker than that. So why do we
not have this oracle? Well simple if we allow the attacker to sign arbitrary
messages the attacker wouldn't even need to try to somehow get the key or forged
message because then he could just send over all the messages. All the pointers he
wants to sign get back signed pointers and you wouldn't need to bother about breaking
the crypto at all. So basically the point I'm trying to make here is that the PAC
attacker is weaker than a MAC attacker. So every secure MAC we know is also a secure
PAC, but even then an insecure MAC might still be sufficiently secure for PAC so
secure MACs have been around for a while and thus in my opinion, I think if
somebody, who knows what he's doing, designs a PAC algorithm today it will
likely be secure. So instead of going for the crypto I think we should rather go for
implementation attacks instead because those will be around forever. And by that
I mean well you can either see how the crypto itself is implemented, what I mean
especially by that is you could see how the PAC is used in the actual code. Maybe
you can find signing oracles, maybe you can find unauthenticated code. I think
this is where we need to go if wanna bypass PAC somehow. So just to recap where
we're coming from. Future iPhone hacks probably gonna not try to bypass KTRR. I
think they will not try to patch Kernel code because we can achieve pretty much
all the things we want to achieve for end user jailbreak without having to patch the
kernel so far. And I think people are going to struggle a bit. At least a bit
when exploiting with PAC because that kind will either make some bugs unexploitable
or really really hard to exploit. Also maybe we're gonna avoid the Kernel at all
as it has demoed that userland-only jailbreaks are possible. Maybe we're going
to recalculate what the low hanging fruits are. Maybe just go back to iBoot or look
for what other thing is interesting. So, that was about it, thank you very much for
your attention. *Applause*
Herald-Engel: Thank you, sir. If you would like to ask a question please line up
on the microphones in the room. We do not have a question from the Internet.
One question over there, yes please. Question: Hi. I would like to be
interested what your comment is on the statement from Zarek that basically
jailbreaking is not a thing anymore because you're breaking so much security
features that makes the phone basically more insecure than the former reasons of
doing a jailbreaking allow for. tihmstar: Well, jailbreaking -- I don't
think jailbreaking itself nowadays makes a phone really insecure. So of course if you
patched a kernel and disable all of the security features that will be less
secure. But if you take a look what we have here with the unpatchable kernel I
think the main downside of being jailbroken is the fact that you cannot go
to the latest software version because you want the box to be in there to have the
jailbreak. So I don't really think if you have like a KTRR device the jailbreak
itself makes it less secure. Just the fact that you are not on the latest firmware is
the insecure part of it. Herald: Alright, thank you.
Microphone number two, your question. Mic #2: Hi good talk. Could you go back to
the capabilities of the adversary please? Yeah. So you said you can do basically two
things right. This one, yes. Yeah you can observe some pointers and some signature
pairs. But why is this not an oracle? tihmstar: Because you cannot choose...
Mic #2: Your message yourself. tihmstar: ...your message yourself.
Mic #2: And you have also an oracle that says if the signature is valid. For a
chosen message. tihmstar: Well yeah but this is if you
take a look at the game and this game for a secure MAC the attacker can choose up to
q messages sending over... like he can do whatever he wants with that messages and
get a signature while the package hacker can see a few very limited amount of
messages and their matching signature and he has little to no influence on these
messages. Mic #2: Okay. So it's a bit weaker.
tihmstar: So yeah that's the point. Just that it's weaker.
Mic #2: Thanks. Herald-Engel: Do we have a question from
the internet? No. OK. Yes please. All right then I don't see anyone else being
lined up and... please give a lot of applause for tihmstar for his awesome
talk! *Applause*
*postroll music*
subtitles created by c3subtitles.de in the year 2020. Join, and help us!