Pegasus iOS exploit & Kernel Memory Corruption

Question

I'm currently reading about Pegasus, the malware on iOS that uses 3 zero-days, in the Lookout Blogpost.

Blog Post about Pegasus

I'm a cs student in the first year and I understand that the malware needs to gain access of the kernel priveliges to get full control of the system but I dont understand how the process works. I'm really curious and thought about specializing in Information Security later on in my studies.

In particular:

1. How does Pegasus (which is apperantly running on a website in some way? Sorry, I never did webdevelopment) from safari into the kernel? Does it use malicious javascript code or how should I imagine that? So how does it corrupt the memory of the webkit and why gives me that the memory location?

2. Why is it bad that a program / an attacker knows the memory location of the kernel? I thought the kernel memory is protected?

3. How does corrupting the memory of the kernel lead to the jailbreak? Memory corruption, as far as I understand it, is just overriding the memory which is used by another program, right? Why should the kernel execute the new code in the memory location?

Thanks in advance!

Answer 1

The exploit uses a combination of three vulnerabilities. Each vulnerability is a bug in an iOS component that allows the attacker to do things that are not supposed to be possible.

Stage 1 (CVE-2016-4657) is a bug in WebKit, a library of code used to render web pages. WebKit code is executed in the context of the Safari web browser of iOS. No details have been released yet, only the description as a “memory corruption issue was addressed through improved memory handling”. This could be a buffer overflow, a use-after-free, or some other similar type of bug. The general idea of memory corruption bugs is that the attacker passes inconsistent data (here, some web page content — could be HTML, CSS, JavaScript, etc.) and instead of detecting the inconsistency the program behaves in an inconsistent way and ends up overwriting some of its own instructions with data supplied by the attacker. This allows the attacker to execute the code of their choice in Safari.

Stage 3 (CVE-2016-4656) is also a memory corruption bug about which no details have been released, but this time in the kernel. This bug allows an iOS application to corrupt some data structures in the kernel and either execute code in the kernel or (I suspect given the description) at least elevate the privileges of the calling application so that it can do things that applications aren't supposed to do, such as installing programs that bypass normal iOS permissions and so allow e.g. installing spyware that won't be shown in the list of installed applications because it masquerades as part of the basic operating system.

Stage 2 (CVE-2016-4655) is an enabler for stage 3. Normally it shouldn't matter that the program know how the kernel maps its memory. And if the attacker is able to cause the kernel to execute arbitrary code then the game is lost. But it can happen (and this is probably the case here) that the attacker doesn't have much room in which to play. For example, maybe there's a size check that's present but slightly off, so the attacker is only able to overwrite a few bytes after the place where the injected data is located. In such cases, the attacker may need to know exactly what to put in that location, otherwise they won't be able to cause any interesting effects. If the location they can overwrite is a pointer, they need to know what to put there to cause the kernel to use valid but wrong data, rather than an invalid pointer that would just cause a crash. For example, change a pointer to a list of capabilities to the address of a place in memory that's known to contain what looks like a list containing some key system capabilities. For that, knowing where the kernel maps its data lets the attacker calculate the right pointer value.

Just to be clear, I'm just giving examples of plausible attack methods that fit the one-line descriptions that have been released at this time.

The best way to get a feel for how this works is to write a few exploits yourself. Get some old versions of software (preferably open-source) with known exploitable vulnerabilities, and go and write an exploit. You may also want to play some CTF.