Eli5: How are Zero-click exploits even possible?

582 views

Like if nobody “asks” a piece of software to execute how does it get downloaded to my phone or PC and then execute it self ? I can understand attacks e.g where you download a jpeg and then click to open it and the jpeg had some extra malicious code in it etc, but without anybody “authorizing” anything how does the kernel allow the code to be run by the cpu etc ?

**EDIT** I am talking about forced entry zero click software like the one pegasus created for iphones

In: 190

20 Answers

Anonymous 0 Comments

Your browser and other systems (e.g., your OS’ networking stack) frequently have vulnerabilities (bugs defects in their logic) and they are constantly processing untrusted input from over the internet. Just visiting a website, the website sends your browser tons of data it needs to process to create the end result page you see. You’re asking about a specific type of exploit called RCE, or remote code execution.

There are many ways to get RCE, but a popular theme across many apps throughout time has always been memory bugs (type confusion, use-after-free, double-free, etc.) in software.

Imagine by visiting a website it could gain full control over your computer. How is this possible?

At its most basic, RCE is possible because computers intermingle (1) *control flow* data with (2) *data* data, and (2) is often within a user’s control or influence, even if only partially. Attackers can get very clever and insert data that programmers never intended and to subvert control flow by overwriting control flow data and thereby hijack control of the program.

Here’s an analogy. Suppose you were handed a piece of paper that read:

“`
Follow each step and then proceed to the next step, unless instructed otherwise:

1. Print “Hello, what is your name?” to the screen.
2. Listen for user input, and whatever they type, write everything down, starting at the beginning of the blank line below:
3. _____________ (space for 32 characters)
4. Take what you see on line 3, and print “Hello, <whatever is on line 3>!” to the screen.
5. Exit.
“`

You are the CPU, and you execute these instructions one by one, *precisely* as you find them.

Now what if a clever attacker gave you an input that overflowed the space available on line 3, and you, being a good follower of instructions, just kept on writing and writing, writing *over* the ink on lines 4 and 5, so that after you’re done transcribing their input to the paper, line 4 read “Delete all the files on this computer.” When you come to the next line, you will execute it as you find it.

This is grossly oversimplifying it, but the general, high level idea is it’s the intermingling of control flow data (which the CPU uses to determine what instructions to execute next) and and attacker controlled data *combined with* bugs like buffer overflows (where data overruns a buffer and overwrites other stuff nearby, like a return address on a stack, or a vtable pointer) that enable you to overwrite that control flow data.

Nowadays, the most common bugs in browsers are use-after-frees, which can be devastating if an attacker can spray the heap, eventually causing a used-after-freed vtable pointer to be followed to execute shellcode.

The most common practice is to try to mitigate bugs by making full control flow hijacking difficult to achieve through hardening techniques like:

– Stack cookies
– ASLR
– Non-executable stack / heap (more accurately, preventing a memory page from ever being both writable and executable at the same time)
– Control flow integrity
– Pointer authentication

Each of these makes bugs very hard to exploit. Even if you had a write-what-where primitive, you may not be able to subvert control flow. But attackers have gotten very clever and used all sorts of techniques to overcome each:

– Stack cookies can be overcome by memory disclosure bugs that leak stack contents
– ASLR can be overcome by memory disclosure bugs that leak addresses, as well as to an extent setting up NOP sleds and spraying the heap
– W^X pages can be bypassed by ROP (reusing pieces of code belonging to the program against it) or abusing processes where pages need to be writable and executable (such as JIT compiler processes like JavaScript)
– Pointer auth can be overcome with the use of signing gadgets in existing code (once again reusing code that already exists in the program to trick it into signing a pointer)

You are viewing 1 out of 20 answers, click here to view all answers.