Mobile Systems and Smartphone Security�(MOBISEC 2020)

Prof: Yanick Fratantonio�EURECOM

1

Vulnerability Analysis�and Exploitation

Last class...

• We explored what an attacker would like to do...

​

• List of possible malicious behaviors assuming an attacker has arbitrary code execution and arbitrary privileges

2

This class

• We explore the "how" an attacker can do what she wants

​

• How can an attacker bypass security protections?

​

• This class is all about security vulnerabilities

3

Security Vulnerability

• What is a "security vulnerability" (aka "security bugs")?

​

• A weakness that allows an attacker to perform actions that
• 1. were not meant to be possible
• 2. has some negative security repercussions

​

​

​

​

4

Not all vulns are the same

• Some vulns are much more important than others

​

• Multiple aspects to take into account

​

• Skills to acquire:
• Understand how to "classify" a vuln and determine its severity
• "I should fear vuln X, but I should not fear vuln Y"
• "I should not fear vuln Z, as long as property P holds"
• "Users of type A should fear vuln X, users of type B shouldn't care much"

5

Threat Model

6

Key Concept: Threat Model

• A "threat model" outlines what it is assumed an attacker can do and cannot do
• Weaker requirements are implicitly included
• Stronger requirements are implicitly excluded

​

• E.g., "Attacker can install & run a malicious app as root"
• You can assume the attacker can get all permissions
• You can assume the attacker cannot run code in TEE

​

• Also known as "attacker model"

7

Key Concept: Threat Model

• Keeping the threat model in mind is of critical importance when discussing attacks and defense systems

​

• Attack X is possible under threat model T
• Without knowing T, all attacks could be trivial / impossible

​

• Defense system Y is effective under threat model T
• Without knowing T, all defense systems could be safe / vulnerable

8

Threat Modelling for Attacks

• "I can write arbitrary files assuming I have code execution as third-party app"
• She shouldn't be able to do it! ⇒ Interesting attack!

​

• "I can write arbitrary files assuming I have root access"
• Of course you can... ⇒ Useless attack

9

Threat Modelling for Attacks

​

• Rule of thumb to judge usefulness of a "new" attack:
• If assuming threat model T, you knew how to achieve goal G already (without using the new info) ⇒ not interesting
• Example: "assuming root attacker, I can read 'private' app files"

​

• There are exceptions: if the new attack shows a completely new technique, then it could still be interesting!
• E.g.,: "Something we already knew was possible via different bug X"
• E.g.,: "Something we already knew was 'conceptually' possible but practically tricky"

10

Threat Modelling for Defense Systems

• E.g., "App sandbox is effective to protect against attacks starting with unprivileged local code execution"

​

• App sandbox is useless when attacker is root

​

• A defense system may not be able to protect from all attackers, but if it protects from "frequent" threat models, then it's useful nonetheless

11

Threat Modelling for Defense Systems

• If defense doesn't restrict anything an attacker could do without it and in any scenario ⇒ useless
• Example: encrypt 'private' app files with a key stored within the app
• 1) If an attacker has access to encrypted private files, she can get the key ⇒ useless
• 2) If an attacker does NOT have access to encrypted files ⇒ the attacker would not have access to the unencrypted files as well ⇒ defense is useless
• Not always true: defense in depth!
• App sandboxing and selinux policies sometimes enforce similar security boundaries, but they are still useful
• Why? Because they are different mechanisms, implemented via different techniques ⇒ it's less likely to find a bug affecting both!

12

Threat Models

• There are many possible threat models, some are useful

​

• Examples
• If a threat model describes "frequent" scenarios ⇒ useful
• "My attack works if I have root on device and user's name is Peppa" ⇒ Super rare scenario ⇒ not very useful
• "My TM assumes an attacker who can arbitrary modify the hardware of the device" ⇒ not very reasonable assumption ⇒ not very useful

​

• Even though not very useful, they are "valid" nonetheless

13

Common Threat Models

• Malicious app on victim's device with
• arbitrary permissions
• permission X and Y
• zero permission

​

• Type of permission X (e.g., "normal" vs. "dangerous") is very important for risk assessment
• How easy is it for an attacker to get permission X?
• Requirement for user's "permission acceptance" makes everything more complicated
• How feasible is this attack to pull off? Should we be concerned?

​

14

Common Threat Models

• Assuming fact X also implies additional basic facts Y & Z

​

• Example
• App with zero permissions ⇒ it can 1) display arbitrary content, 2) send intents to other apps, 3) attempt to launch root exploits, etc.
• Attacker with code execution in the kernel can invoke arbitrary syscalls

15

Common Threat Models

• Attacker knows victim's phone number
• (And she can call her / send her text messages...)

​

• Attacker can lure the victim to visit an arbitrary URL
• By either 1) assuming an app using HTTP traffic or 2) by luring the user to click on a link
• The URL could then host a malicious website (that can attempt to exploit bugs in the web browsers)

16

Common Threat Models

• Attacker is on the same "network" of the victim

​

• Implication: the attacker can do network MITM
• Usual goal: Sniff / hijack HTTP traffic
• The net effect sometimes overlaps with "visit malicious URL" scenario
• Just wait for an unrelated HTTP connection ⇒ inject your payload there

17

Common Threat Models

• Attacker can run code as a privileged user (root, system)

​

• Attacker can run code in the kernel

​

• Attacker can run code in a Trusted App (TEE userspace)

​

• Attacker can run code as within the TEE OS

​

• Attacker can run code within the baseband processor

​

18

Common Threat Models

• Attacker has physical access to the device

​

• Implications
• she can "play" with the lock screen
• she can plug a USB cable
• she can initiate NFC transactions
• she can attempt to tamper with the hardware
• she can tamper with hardware security modules

​

19

Common Threat Models: Three classes (ref)

• Remote attacker
• Attacker can lure victim to visit web page, reading email, receive SMS
• Attacker can send a message to WhatsApp, Messenger, etc.

​

• Proximal attacker
• Attacker is "physically" nearby the victim
• Same WiFi network, can send malformed WiFi / BlueTooth packets

​

• Local attacker
• Attacker can run code on the victim's device (via installed app)
• Attacker has physical access to the device

​

20

Attack Surface

• The threat model determines the attack surface

​

• Attack surface
• "The attack surface is the sum of the different points (the "attack vectors") where an unauthorized user (the "attacker") can try to enter data to or extract data from an environment." (wiki)

​

• E.g., "remote attacker" can't use "send intent" vector

21

Why attackers like vulns?

• There is usually a gap between "threat model" and "what the attacker wants to do"

• Vulnerabilities allow attackers to move from one threat model to another (more advantageous) one

22

Threat Model /�Assumptions

What the attacker wants to do

Technical Gap

Security Vulnerabilities

Vulnerability Characterization

23

The "type"

• The "type" aka "what kind of bugs?" aspect

​

• High-level "type" categories
• EOP, RCE, DOS, ID, ...

24

The "type"

• EOP: Elevation of Privilege

​

• Examples
• Attacker with code execution with app's sandbox ⇒ "system user" / root
• Attacker with code execution with app's sandbox ⇒ "write arbitrary file"
• Attacker with root code execution ⇒ Trusted App / TEE OS code exec
• "Remote attacker" ⇒ "local attacker"

25

The "type"

• "Remote attacker" ⇒ "local attacker"

​

• Very important case: Remote Code Execution (RCE)
• Some of the most powerful bugs

​

• From "victim visits a webpage" / "receives an SMS" to "code execution"
• The code execution may be constrained, but it's a powerful first step
• Vulns can be chained!

26

The "type"

• ID: Information Disclosure
• It affects the 'confidentiality' aspect

​

• Vuln that allows victim's information to be stolen
• File content, memory content, ...

​

• It could be seen as a particular case of EOP

27

The "type"

• DOS: Denial-of-Service: it affects the 'availability' aspect

​

• The vuln allows an attacker to make the device (or parts of it) inoperative

​

• Examples: vulns that allow an attacker to
• crash a privileged component
• force-reboot the device
• brick the device (i.e., there is no way to fix the device)

28

The "type"

• More systematic characterization of DOS

​

• Different degrees of 'denial'
• Completely permanent DOS (i.e., "bricked")
• Device requires re-flashing the OS
• Device requires factory reset
• Device hangs or reboots (but you can safe reboot & disable the bad app)
• Privileged app hangs / reboots (which could cause device hang/reboot)
• Unprivileged app hangs / reboots

29

The "where"

• Vulns are more/less important depending on which device hardware/software component is affected
• I.e., the "where is the bug?"

​

• Depending on "where"
• Vuln may allow for privileged code execution
• Vuln may be easier to reach

​

• Examples
• OS media library, OS network stack, Selinux enforcement, secure boot
• System apps / apps (network-related, Intent-related, resource-related)

30

The "where"

• A number of relevant process types (ref)
• Constrained process (process more limited than a normal application)
• Unprivileged process (third-party app)
• Privileged process
• Trusted Computing Base (TCB)
• kernel, has capability to load scripts into a kernel component, baseband
• kernel-equivalent user services (init, ueventd, vold)
• Bootloader
• Trusted Execution Environment (TEE)

31

The "where"

• Two aspects of the "where"
• In which component is the bug?
• Is this component privileged?
• In which part of such component is the bug?
• Input processing?
• Can the attacker reach it?
• If yes: great!
• If no: no matter what the bug is, it may be useless

32

Type + Where

• The combination of the "type" of bug and "where" it is (i.e., which component is affected) determines its severity and relevance

​

• How "easy" is it to "exploit" and how much "powerful"?

33

Vulnerability Exploitation

• Exploitation is the process of "taking advantage" (i.e., "exploiting") a vulnerability so that an attacker can perform unintended actions

​

• Specific vulns may be exploited only by specific attackers
• E.g., vuln to abuse app's permissions may be relevant for local attacker, but it may not be usable by a remote attacker

​

• Threat model analysis tells us "which types of attackers can exploit which vulns"

34

Vulnerability Severity

• Severity == "ease of exploitation" x "damage"

​

• Ease of exploitation
• Which types of attackers can exploit the vuln?
• Which threat models are relevant for this vuln?
• How easy is it to satisfy the requirements for exploitation?
• Requirements for remote attacker are much easier to satisfy than local attacker's
• This is when threat modeling becomes helpful

​

• Damage of a vuln also depends on the type of victim
• Vuln to steal my personal emails ⇒ nobody cares
• Vuln to steal emails of an activist ⇒ potentially life-threatening

35

Severity Score

• Google assigns a "severity" score to each bug
• Low, Moderate, High, Critical

​

• The score is assigned depending on the combination of
• type of bug / what the attacker can achieve
• which component is affected
• under which condition it can be exploited

​

• The score determines how Google prioritizes its fix and deployment of the patch

36

Severity Score

• Many different possibilities
• Conceptually, a severity can be assigned to each combination of the relevant aspect
• See Android's full list here

​

• More generic alternative (but of dubious utility)
• CCVS: Common Vulnerability Scoring System (wiki)
• Numeric score from 0 to 10
• Several metrics are combined via a numeric expression
• Access vector, attack complexity, authentication, impact vs. CIA triad, ...

37

Vulnerability Chaining

• Attackers can take different bugs and "chain" them

​

• Example of a chain
• RCE bug to go from "remote attacker" ⇒ "code exec in an unpriv app"
• EOP bug in kernel ⇒ root code exec
• EOP bug in a TEE's interface only visible to root ⇒ TEE code exec

​

• Chainspotting: Building Exploit Chains with Logic Bugs
• Chain of 11 bugs across 6 unique applications
• Net effect: remote attacker can install + run arbitrary APK

38

Vulnerability Tracking

• Thousands of bugs are discovered every year

​

• Important to track them + convenient way to address them
• To reference specific vulns when discussing about their details
• To describe which vulns are fixed in a security update of an affected component
• To distinguish between similar (but different) vulns affecting the same component

39

Vulnerability Tracking: CVE numbers

• Common Vulnerabilities and Exposures (CVE) system provides a reference for known security vulns

​

• They are in the CVE-<year>-<id> format
• Example: CVE-2015-3864
• The CVE is assigned during the vuln disclosure / fixing process

​

• Several databases that systematize available information
• https://cve.mitre.org

40

Android Security Bulletins

• You now know everything you need to fully understand Android monthly security bulletins

​

• CVE, type, component affected, severity (and its rationale), relevant threat models, attack vectors

41

Classes of vulnerabilities

42

Classes of vulnerabilities

• There are many classes of vulnerabilities

​

• Here we discuss the ones related to mobile devices
• The list is not exhaustive...

​

• We will discuss them by "attack surface"

43

Attack Surface Enumeration

• There are many layers to attack

​

• From high-level to low-level
• the user
• apps (third-party apps and system apps)
• system components / operating system
• user interface
• trusted apps and TEE OS
• hardware (RAM)

44

Attacking the user

• Main attack vector against user: social engineering
• "Manipulate" the user to make her perform action X or to reveal sensitive information

​

• Two key examples
• Make user install malware app disguised as benign app
• This can be enough to satisfy "local attacker" requirements
• Phishing attack: lure the victim to insert her credentials (or CC) info into a seemingly legitimate app / website
• More on this when we discuss UI attacks

45

Attacking apps

• Many things can go wrong in many different ways

​

• Two main aspects
• What
• Attacker may abuse sensitive resource/permission the app has access to
• Attacker may leak sensitive information the victim app has access to
• How
• How can an attacker interact with a target app?
• Entry point enumeration

46

App ⇔ Network backend

• App connects to network backend
• HTTP vs. HTTPS?
• Can the attacker see what's sent and received?
• Credentials? Auth cookies?
• Can the attacker do MITM?
• How is the received data used? Is it blindly trusted by the app?

47

Dynamic Code Loading

• App dynamically loads additional code
• Common scenario: code downloaded from the network
• Pitfalls
• Code is downloaded via HTTP (instead of HTTPS)
• Attacker can alter the payload on-the-fly
• Downloaded code is stored on the SDcard
• Attacker can modify the file at rest (Fortnite bug)
• Integrity checks
• If integrity check is missing ⇒ attacker can modify it and execute code within the app
• If integrity is checked, there may still be a TOCTOU vulnerability

48

Execute This! Analyzing Unsafe and Malicious Dynamic Code Loading in Android Applications (NDSS'14)

Cryptographic Vulnerabilities

• The cryptographic APIs themselves are usually OK
• The vulns usually lie in 1) how these APIs are (mis)used, 2) the developers don't even attempt to use them (no encryption case)

​

• Examples
• Common misuage of crypto APIs: An Empirical Study of Cryptographic Misuse in Android Applications, CCS'13
• Common problems for SSL pinning: Rethinking SSL Development in an Appified World, CCS'13

49

Confused Deputy Problem

• Consider app A
• it has access to sensitive information
• it contains functionality using sensitive permissions

​

• Confused Deputy Problem arises when App A doesn't properly protect such sensitive aspects from other apps

50

Confused Deputy Problem

51

Confused Deputy Problem

52

Confused Deputy Problem

53

Component Hijacking

• Component Hijacking (CH) attacks aim at gaining unauthorized access to protected resources of an app through its exported components
• CH vulns are vulnerabilities that make these attacks possible

​

• Generic class: read sensitive data / write inside the app
• "CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities" CCS'12

54

Permission/Capability Leak

• Permission Leak
• Instance of confused deputy problem

​

• Example: app B can "use" permission X via app A

​

• Systematic Detection of Capability Leaks in Stock Android Smartphones, NDSS'12
• Permission leaked: wipe out user data, send out SMS messages, record user conversation (without asking any permission)

55

Content Leaks & Pollution

• Content providers are wrappers around databases

​

• What if these databases allow "too much" access to external apps?
• Leak: disclose various types of private in-app data
• Pollute: manipulate security-sensitive in-app settings or configurations

56

Content Leaks & Pollution

• "Detecting Passive Content Leaks and Pollution in Android Applications", NDSS'13

​

• Leak
• SMS messages, contacts, private IM info, user login creds (vuln app stores FB token), browser history & bookmarks, call logs

​

• Pollute
• Block SMS / phone calls from certain numbers (blacklist)
• Download apps in background + popup for installation

57

Overpermissioning

• Overpermissioning
• App requires permission X even if it does not need it

​

• Not a bug per-se, but it represents an unnecessary risk
• If affected by confused deputy problem, permission X could be abused
• Against the "principle of least privilege"

58

Zip Path Traversal

• Many libraries/frameworks are affected by�a "unsafe unzip path traversal" problem

​

• A zip file can contain a relative ../../evil.sh file path
• When unzipped, it can overwrite files in different directories
• ⇒ File write to code execution via cached DEX overwrite

​

• Concrete examples
• Remote Code Execution on Samsung Keyboards
• Zip Slip Vulnerability

59

Zip Path Traversal

• Remote Code Execution on Samsung Keyboard

GET http://skslm.swiftkey.net/samsung/downloads/v1.3-USA/az_AZ.zip

← 200 application/zip 995.63kB 601ms

root@kltevzw:/data/data/com.sec.android.inputmethod/app_SwiftKey/az_AZ # ls -l

-rw------- system system 606366 2015-06-11 15:16 az_AZ_bg_c.lm1

-rw------- system system 1524814 2015-06-11 15:16 az_AZ_bg_c.lm3

-rw------- system system 413 2015-06-11 15:16 charactermap.json

-rw------- system system 36 2015-06-11 15:16 extraData.json

-rw------- system system 55 2015-06-11 15:16 punctuation.json

$ unzip -l evil.zip

Archive: evil.zip

Length Date Time Name

--------- ---------- ----- ----

5 2014-08-22 18:52 ../../../../../../../../data/payload

--------- -------

5 1 file

Zip Path Traversal

• Remote Code Execution on Samsung Keyboard

Tech details: https://www.nowsecure.com/blog/2015/06/16/remote-code-execution-as-system-user-on-samsung-phones/

root@kltevzw:/data/dalvik-cache # /data/local/tmp/busybox find . -type f -group 1000

./system@framework@colorextractionlib.jar@classes.dex

./system@framework@com.google.android.media.effects.jar@classes.dex

./system@framework@com.google.android.maps.jar@classes.dex

./system@framework@VZWAPNLib.apk@classes.dex

./system@framework@cneapiclient.jar@classes.dex

./system@framework@com.samsung.device.jar@classes.dex

./system@framework@com.quicinc.cne.jar@classes.dex

./system@framework@qmapbridge.jar@classes.dex

./system@framework@rcsimssettings.jar@classes.dex

./system@framework@rcsservice.jar@classes.dex

./system@priv-app@DeviceTest.apk@classes.dex

Critical: the keyboard app could NOT be uninstalled

This is code!

Native Code

• Apps can have native code components, written in C/C++

​

• C/C++ code can be vulnerable to a number of memory corruption vulnerabilities
• Buffer overflows, dangling pointers, use after free, type confusion, etc.
• This is one of the key topics of SYSSEC

​

• If an attacker's input can "reach" these components...
• ⇒ then these vulns come into play

62

More apps' vulns

• We have seen many more potential vuln patterns during the course!

​

• To name a few:
• unintentionally exported components, problems with pending intent, javascript bridge, command injection, custom permissions

​

• Given API X, it's likely there is a way to misuse it...

63

Attacking the system

• Bugs can affect the Android framework / OS itself

​

• There are many: tens of vulns every month!

​

• They can affect different components
• Framework, media framework, system, kernel components, Qualcomm components

64

Unsafe Self-Update

• Android updating mechanism affected by PileUp flaws

​

• An application requires a permission that does not exist yet

​

• Privilege escalation through OS updating

65

L. Xing, X. Pan, R. Wang, K. Yuan, and X. Wang. Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating. In IEEE Symposium on Security and Privacy, 2014.

​

​

Attacking the system

• Vulns in some components usually lead to higher severity

​

• Example: the Media framework
• The Media framework processes, among many things, images
• Bugs are often in media parsing
• Media parsing is often "triggerable" remotely
• MMS, email, visiting a website
• The mere fact that these code components can be reachable by a remote attacker is already enough to make these bugs more dangerous

66

Stagefright bug

• Stagefright (August 2015)
• Main Android’s media processing library

​

• Several critical vulnerabilities in media parsing
• End result: remote code execution by sending an MMS

​

• Biggest security vulnerability in Android at that point
• This is the bug that pushed Google to create monthly security bulletins

Stagefright bug

status_t MPEG4Source::parseChunk(off64_t *offset) {

uint64_t chunk_size = ntohl(hdr[0]); // attacker-controlled!

size_t size = 0;

​

if (!mLastTrack->meta->findData(

kKeyTextFormatData, &type, &data, &size)) {

size = 0;

}

​

uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size];

[...]

​

if (size > 0) {

memcpy(buffer, data, size);

}

}

uint64_t

size_t

The parameter of the “new” operator has type size_t

Stagefright bug

status_t MPEG4Source::parseChunk(off64_t *offset) {

uint64_t chunk_size = ntohl(hdr[0]); // attacker-controlled!

size_t size = 0;

​

if (!mLastTrack->meta->findData(

kKeyTextFormatData, &type, &data, &size)) {

size = 0;

}

​

uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size];

[...]

​

if (size > 0) {

memcpy(buffer, data, size);

}

}

uint64_t

size_t

• On 32-bit architectures, “size + chunk_size” may be truncated (because size_t is 32-bit)

​

The parameter of the “new” operator has type size_t

Stagefright bug

status_t MPEG4Source::parseChunk(off64_t *offset) {

uint64_t chunk_size = ntohl(hdr[0]); // attacker-controlled!

size_t size = 0;

​

if (!mLastTrack->meta->findData(

kKeyTextFormatData, &type, &data, &size)) {

size = 0;

}

​

uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size];

[...]

​

if (size > 0) {

memcpy(buffer, data, size);

}

}

uint64_t

size_t

• On 32-bit architectures, “size + chunk_size” may be truncated (because size_t is 32-bit)
• On 64-bit architectures, “size + chunk_size” may overflow

Buffer overflow!

sizeof(buffer) < sizeof(data)

The parameter of the “new” operator has type size_t

Baseband vulnerabilities

• A walk with Shannon: A walkthrough of a pwn2own baseband exploit - Amat Cama

​

• Memory corruption that
• Can be triggered by a phone connecting to a malicious base station
• Leads to remote code execution in the baseband processor
• Remote ~ Proximal attacker

71

Bootloader vulnerabilities

• Bootloader is a program, and it can contain bugs as well!

​

• Bootloader bugs can lead to
• Execute arbitrary code (as part of the bootloader)
• Bypass of secure boot ⇒ bypass of chain of trust
• Permanent denial-of-service

​

• Examples:
• BootStomp: On the Security of Bootloaders in Mobile Devices USENIX'17
• checkm8 iOS bootrom bug: https://github.com/axi0mX/ipwndfu

72

TEE-related bugs

• Case study: Boomerang flaws, NDSS'17

​

• Net result: user-space apps could read arbitrary kernel-space memory via confused deputy in the TEE

73

74

PTR are addresses

They must be converted to physical addresses so that both NSW / SW understand them

They must be converted to physical addresses so that both NSW / SW understand them

Flaw #2: TA does not know which UA started this transaction

Flaw #1: it's possible to "hide" a PTR so that it does not go through the VA ⇒ PA conversion

Instance of confused deputy problem!

Net result: TA will read from an attacker-chosen kernel address

Attacking the hardware

• Bugs can also be in hardware components

​

• One very popular class of hw bugs: rowhammer

75

Rowhammer bug

• Problem affecting DRAM cells
• Memory cells leak their charges (when properly "stimulated")
• Net effect: a bit flips in memory

76

Rowhammer bug

77

Image from wiki

Rowhammer bug

78

Image from wiki

Rowhammer bugs

• Rowhammer exploitation:
• the attacker actively tries to cause bit flips...
• ... in specific parts of the memory so to obtain an advantage...
• ... which usually consists in getting root privileges

​

• Usual trick: push the OS to allocate a page table entry in a vulnerable location
• Page table entries contain "virtual address ⇒ physical address" maps
• If an attacker can tweak one, she can point a given VA to what she wants

79

Rowhammer bugs

• Rowhammer bugs have been exploited in many contexts and with many goals

​

• Examples
• Escaping native client sandbox
• Escaping javascript browser sandbox
• Cross-VM exploitation
• Drammer, rowhammer for ARM mobile platforms

80

Drammer

• "Drammer: Deterministic Rowhammer Attacks on Mobile Platforms", CCS'16 (October 2016)
• Threat model: local attacker (no permissions)
• Steps
• Find vulnerable bits (that are susceptible to rowhammer effect)
• Allocate memory via DMA (Direct Memory Access) to bypass cache
• Massage memory so that the system allocates a page table exactly where we can flip a bit
• We now have write access to a page table entry ⇒ by modifying it we obtain arbitrary write

81

Drammer's "fix"

• Google attempted to fix this with a patch that made its exploitation more difficult, but not impossible

​

• Follow up work: RAMPage (June 2018) that bypasses Google's patch

​

• "Design" bug difficult to fix

82

"Traditional" bugs vs. design bugs

• Not all bugs are as easy to fix

​

• Traditional memory corruption bugs are "easy" to fix
• Very well oiled pipeline to go from report to fix

​

• Design bugs are much more difficult to fix
• Design bug: the design itself is broken, not just a small impl. detail
• No standardized process: it's more difficult to report and get fixed
• The fix may cause a significant code rewrite...
• ... which may also introduce overhead / backward compatibility problems / new bugs
• ⇒ devs don't like it

83