1 of 35

MiraclePtr status update

Preventing exploitation of Use-after-Free bugs

in Chromium

bartekn@ arthursonzogni@ keishi@ google.com

1

2 of 35

Impact of Use-after-Free (UaF)

2

3 of 35

Renderer sandbox

Sandbox + Site Isolation:

Renderer has no access to cross-site data

3

Web Renderer

mail.com

Web Renderer

evil.com

Browser Process

sandbox

ipc

sandbox

4 of 35

Renderer sandbox

Sandbox + Site Isolation:

Renderer has no access to cross-site data
Unless it can escape the sandbox

By attacking the OS/kernel
Or the Browser Process

4

sandbox

syscalls

Web Renderer

mail.com

Web Renderer

evil.com

Browser Process

Operating System

sandbox

ipc

5 of 35

Renderer sandbox

Sandbox + Site Isolation:

Renderer has no access to cross-site data
Unless it can escape the sandbox

By attacking the OS/kernel
Or the Browser Process�via e.g. Use-after-Free (UaF)

UaF bugs = high security severity

Assuming they can be exploited
For more details see an example from Project Zero

5

Web Renderer

mail.com

Web Renderer

evil.com

Browser Process

Operating System

sandbox

ipc

syscalls

UaF

6 of 35

High+ severity bugs impacting Stable

6

2022 figures are extrapolated from early November to the whole year

7 of 35

High+ severity bugs impacting Stable

7

8 of 35

In-the-wild 0-day exploited bugs

8

data source: Project Zero, augmented with metadata and a few more recent bugs

This is just the tip of the iceberg! (see next slide)

9 of 35

In-the-wild 0-day exploited bugs

9

10 of 35

Non-exploitable UaF bugs

What’s that?

Better not assume unless can be 100% proven.

10

11 of 35

MiraclePtr to the rescue!

11

12 of 35

A flow of a UaF attack

Attack outline:

Conjure a dangling pointer
Inject attacker-controlled data into the same memory

Disruption technique: Don’t free the memory�(as long as dangling pointers exist)

“free” is postponed, but timing of destructors is not affected

Dereference the dangling pointer

12

13 of 35

A flow of a UaF attack

Attack outline:

Conjure a dangling pointer
Inject attacker-controlled data into the same memory

Disruption technique: Don’t free the memory�(as long as dangling pointers exist)

“free” is postponed, but timing of destructors is not affected

Dereference the dangling pointer

13

This is where�we currently�focus our efforts

14 of 35

What is MiraclePtr?

BackupRefPtr algorithm:

14

Requires support from allocator (PartitionAlloc)

ref_cnt=1 in Alloc(), ++ref_cnt in raw_ptr<T> ctor
--ref_cnt in Free() & raw_ptr<T> dtor
Free(): if ref_cnt>0

quarantines memory
poisons memory

a future read might lead to a crash

the last raw_ptr<T> dtor will release memory

raw_ptr<T>

T* ptr

allocated memory

ref_cnt

T

To implement MiraclePtr, we developed an algorithm called BackupRefPtr. First of all, it requires support of the memory allocator. In Chromium’s case it’s PartitionAlloc.

When a memory allocation comes to the allocator, it allocates not only memory for the object, but also carves out a little bit of extra space for the ref-count and puts it right before the object. Whenever raw_ptr<> object is constructed or assigned a new pointer, it finds the ref-count and increments it. Similarly, whenever it is destructed or deassigned, it decrements the ref-count. Eventually, when a Free() request comes to the allocator and sees that the ref-count is greater than 0, it does *not* release the memory back to the pool to make it available for future allocations. Instead, it quarantines the memory, also also poisons it by writing trash. Lastly, when all the raw_ptr<> pointers go away, the memory is released back to the pool and made available for future allocations.

Here I want to add that MiraclePtr doesn’t prevent UaF bugs from happening, it simply disarms them. We still want to fix those bugs with high priority. But the difference is that it could be P1, as opposed to P0, and we will no longer have to move Heaven & Earth to merge the fix into Stable channel.

15 of 35

raw_ptr<T>

raw_ptr<T> does not manage the object lifetime.

Please use raw_ptr<T> in place of a raw C++ pointer T* whenever possible, but…

in class and struct fields only (no params, locals or globals)
not in Renderer-only code

Details are available in the Usage Guideline.

15

16 of 35

Clang plugin enforcement almost there…

We are developing a clang plugin that will show compiler errors when raw_ptr<T> is not used.

16

../../base/trace_event/traced_value.h(103,18): error:� [chromium-rawptr] Use raw_ptr<T> instead of a raw pointer.

TracedValue* value_;

Example of error

Example of exclusion

struct _HEAP_32 {� // `Heap` is not a raw_ptr<...>, because reinterpret_cast of uninitialized

// memory to raw_ptr can cause ref-counting mismatch.

RAW_PTR_EXCLUSION struct _HEAP_32* Heap;

};

17 of 35

Shipping progress

17

18 of 35

MiraclePtr launched on some platforms!

June: Launched in the browser process only, on Windows and Android
August: Started experiment for Linux/ChromeOS/Mac
September: Launched in all processes except renderer, on Windows and Android

18

19 of 35

Protection coverage

On supported platforms, MiraclePtr protects our users from ~60% of UaFs^[1] in non-renderer processes.

19

[1] stats based on security issues reported since April

20 of 35

Roadmap update (v1)

✅ BackupRefPtr implemented and thoroughly tested

✅ PartitionAlloc-Everywhere now almost everywhere

✅ Evaluate overhead that can't be tested via field trials (binary A/B experiments)

✅ Land the "Big Rewrite" (T* → raw_ptr<T>)

✅ Evaluate overhead that can be tested using field trials

✅ Enable MiraclePtr protection for Windows/Android

✅ Integrate with ASan

🔁 Enable clang plugin to enforce raw_ptr<T> usage

(per-pointer opt-out option available)

20

✅ done

🔁 in progress

❌ not started (but planned)

Next, let me show you our roadmap and the progress we’ve made. This is the roadmap for what we call MiraclePtr v1. Believe it or not, all of this took about 2 years!

The BackupRefPtr algorithm isn’t all that difficult, as you saw, so its implementation was only a small part of the process. The challenging part was debugging and fixing large number esoteric issues that we ran into due to interesting assumptions made in the code.

Another big chunk was shipping PartitionAlloc-Everywhere. PartitionAlloc-Everywhere makes all malloc/new calls to be routed to PartitionAlloc, which is required for MiraclePtr to become effective.

Next, rewriting T* pointers to raw_ptr<> was not an easy feast either. We developed a (mostly) automated rewriter tool, but even that approach had its challenges and limitations.

By far the vast majority of time was spent on performance evaluation. We had to be creative with our A/B tests, as certain decisions had to be made at compile-time, not run-time. And we had to go through many many iterations, so just this step took us like a year before we finally shipped to Stable on Windows & Android.

We also integrated MiraclePtr with Address Sanitizer, which can help us determine whether a particular Use-after-Free bug is disarmed.

The only thing that is left for “v1” is to enable clang plugin that enforces raw_ptr<> usage.

21 of 35

Roadmap update (beyond v1)

Increase coverage:

✅ Reference field support (raw_ref<T>)

🔁 Enable MiraclePtr protection for Linux/ChromeOS/Mac

🔁 third_party library support (🔁: PDFium; ❌: ANGLE, SwiftShader, Skia, Dawn, …)

🔁 Renderer process support

❌ Pointers inside templated collections (Collection<raw_ptr<T>>)

❌ raw_ptr<const char>

Increase debuggability:

🔁 Dangling Pointer Detector

🔁 MTE-like algorithm

21

✅ done

🔁 in progress

❌ not started (but planned)

This is our roadmap beyond v1 and we’re making a good progress.

We have implemented raw_ref<> to support reference fields and you can already see it being used in code.

As already mentioned we’re in the middle of evaluating MiraclePtr for Linux, Chrome OS and Mac.

Furthermore, we’ve begun working on 3rd party libraries to bring them the MiraclePtr goodness. The first in line is PDFium.

We are also working on enabling MiraclePtr protection for the renderer process, which is very performance-sensitive.

Another area we put a big focus on, is increasing debuggability. MiraclePtr’s primary feature isn’t to detect UaFs, but merely to disarm them. But we still want to detect them early and fix them proactively. For that, we have an algorithm that mimics ARM’s Memory Tagging Extension in software, as well as Dangling Pointer Detector. And Arthur is gonna talk extensively about the latter in a few minutes.

22 of 35

Performance

22

23 of 35

Performance overhead

Performance regressions of BRP enabled for non-renderer processes (shipping) vs disabled^[2]

23

Memory.Browser.PrivateMemoryFootprint

50P: +5.12% ◆◆◆◆

95P: +5.04% ◆◆◆◆

99P: +4.68% ◆◆◇◇

Memory.Browser.PrivateMemoryFootprint

50P: +5.25% ◆◆◆◆

95P: +5.40% ◆◆◆◆

99P: +6.39% ◆◆◆◆

Memory.Gpu.PrivateMemoryFootprint

50P: +1.07% ◆◆◆◆

95P: +2.11% ◆◆◆◆

99P: +2.14% ◆◆◆◆

Memory.Total.PrivateMemoryFootprint

50P: +3.04% ◆◆◆◆

95P: +1.94% ◆◆◆◆

99P: +1.32% ◆◆◆◇

Browser.Responsiveness.JankyIntervalsPerThirtySeconds^[3]

50P: +0.67% ◆◆◆◆

95P: +3.77% ◆◆◆◆

99P: +3.86% ◆◆◆◆

WebVitals.FirstContentfulPaint3

50P: +0.45% ◆◆◆◇

WebVitals.LargestContentfulPaint2

50P: +0.40% ◆◆◆◇

Graphics.Smoothness.PercentDroppedFrames3.AllSequences

99P: +0.16% ◆◆◇◇

EventLatency.GestureScrollUpdate.Touchscreen.TotalLatency

99P: +0.43% ◆◆◇◇

Startup.Android.Cold.TimeToFirstVisibleContent

50P: +0.90% ◆◆◆◆

Windows

Android

[2] data from M107, showing metrics with more than ◆◆

(number of ◆ shows the level of statistical significance)

Android

[3] main thread contention

Here are the latest performance overhead measurements collected from the wild. First, you can see there is memory overhead. Memory usage increased by about 5-6% in the browser process, less so in the GPU process, and it all kinda fades away when looking at the total memory footprint. As for responsiveness, the only metric that regressed by more than 1% is the jank metric, which tells us we have an increase in “main thread contention”.

The decision was that the regressions were acceptable, and impact to the user would be small, especially since MiraclePtr is not adding new long tasks, just making the existing ones a bit longer.

I do want to emphasize that the PartitionAlloc-Everywhere project, that I briefly mentioned earlier, gave us performance gains that far surpass these regressions, which gave us budget that we could spend on security.

Google-internal links:

24 of 35

Memory overhead

There are three sources of memory overhead

Quarantined memory (<0.01% PMF)�Memory referenced by a dangling pointer is “quarantined”, meaning it is reserved even after free()
Fragmentation caused by splitting the main PartitionAlloc partition (~1% PMF)�Because we have to enable MiraclePtr for just the browser process, we had to prepare a separate partition for allocations before a bit of process initialization.
Ref count added to each allocation (the rest)

24

25 of 35

CPU overhead

raw_ptr<T> incurs additional runtime overhead for initialization, destruction, and assignment.

Find ref-count and increment/decrement it (atomics)
We had keep some pointers as T*, to keep the overhead down

No overhead when dereferencing or extracting a pointer

25

26 of 35

Memory overhead

Ref count added to each allocation

We tried two ways of storing the ref count.

“before alloc” is the naive solution of having the ref count at the beginning of the allocation. Ref count is 4 bytes, but due to alignment, we need to add 16 bytes to every allocation.

“prev slot” places the ref count in the padding of the previous slot. Because PartitionAlloc is a bucket-based memory allocator, allocations often have wasted padding space at the end. “Prev slot” uses that space when available.

26

27 of 35

Memory overhead

Ref count added to each allocation

Prev slot puts ref count in the wasted padding space so we didn’t think this would be so big.

But it turned out this is the majority of overhead.

There are a lot of small allocations.
There are a lot of allocations that have a size of exactly power of two.

27

BackupRefPtr disabled

BackupRefPtr enabled

28 of 35

Dangling Pointer Detector (DPD)

28

Previously, Bartek presented MiraclePtr. MiraclePtr doesn't really prevent UAF

bugs from happening. We will continue to have bugs in Chrome where free and

delete are called prematurely. However, it disarms those bugs. They can no

longer by exploited by attacker, and the severity of the bug can be lowered from

P0 to P1. We still need to work on fixing the bug, but we can do it at our own

peace.

This is very nice, but still, it would be a shame not to use the refcount, for

something else than reducing severity. We know precisely when pointers become

dangling. MiraclePtr is currently a tool to mitigate the severity of UAF, but it

can also become a tool to help developers avoid unsafe patterns early on.

There is catch: A UAF implies there was a dangling pointer, but the opposite is

not always true. You can have a dangling pointer that is never used. In some

rare cases, there is no good ways to refactor code to completely avoid a

easily dangling pointers.

So, what we built is a tool to ban by default dangling pointer. At the same

time, we would like to allow some exceptions. Those exception must necessarily

be visible in the code.

29 of 35

What is Dangling Pointer Detector?

BackupRefPtr algorithm:

DanglingPtrDetector algorithm:

29

raw_ptr<T>

T* ptr

allocated memory

ref_cnt

T

allocated memory

ref_cnt

T

raw_ptr<T>

T* ptr

ref_cnt

raw_ptr<T, DisableDanglingPointerDetector>

T* ptr

About the implementation, the idea is quite simple.

We start from the BackupRefPtr implementation: Every allocations have a

refcount.

We now want two flavor of raw_ptr. One allowed to dangle, and one not allowed.

To use the one allowed to dangle, the "DisableDanglingPointerDetector"

annotation must be used.

In the allocator, to differentiate the two, we extend and split the refcount

bits in two parts. One is used to count normal raw_ptr, and the other is used to

count the raw_ptr allowed to dangle.

When an allocation is freed, we verify the first refcount reached zero,

otherwise we detected an unexpected dangling pointer.

To help developers we report two stacktrace:

- One indicates the location where the memory was deleted.

- The second indicate the location where the dangling raw_ptr was released.

With both stacktrace, it is very easy to understand what happened, and identify

the pointer.

30 of 35

Example

30

- const raw_ptr<ServiceWorkerContainerHost> container_host_;

+ const raw_ptr<ServiceWorkerContainerHost, DanglingUntriaged> container_host_;

Invalid assumption!

The last few months. We annotated almost every pre-existing dangling pointers in

Chrome. I wanted to show a typical illustration:

Here, we can see the author claimed the pointer was not dangling, because it is

referring the owner of this instance. So its lifetime must logically be greater.

Right.

Against all odds, the dangling pointer detector found it was an incorrect

assertion. There are dozen of examples like this in Chrome. There are many

potential bugs waiting to happen.

The dangling pointer detector provides this information, and this is something

that would have been hard for a developer to discover by themselves.

There are many reasons:

- First, it is very difficult. At the scale of Chrome, C++ object lifetime are

sometimes too complicated for a human brain to reason about.

- Secondly, code is evolving. This assertion might have been true, when it was

added, but overtime, code evolved, and a change broke this assumption.

If the dangling pointer detector was added on the CQ, we could have detected the

regression immediately when it was introduced.

31 of 35

31

Remove pointer (24%)

14.6% use unique_ptr
3.13% use weak_ptr
Etc: RenderFrameHost ID, scoped_refptr, etc..

Fix destruction order (25%)

go/dangling-ptr-retrospective

Reset pointer (39%)

Other (10%)

So far, we haven't only identified every pre-existing dangling pointer, but the

team worked fixing some of them. We fixed 170 so far.

Here is an overview of what it means broadly to fix dangling pointers.

One quarter of them was about getting rid of the pointer. A large chunk was

about using unique_ptr instead of managing memory manually using new & delete.

That's 15% of the patches. The other one was more diverse depending on the

component. For instance, using WeakPtr, ScopedRefPtr or some IDs, like

RenderFrameHost ID.

The second quarter of the patches was about fix the destruction order of

classes. When one classes depends on another one. It must be destroyed first,

because otherwise, it might use a dangling pointer referring the deleted object.

Finally, the third category was about clearing the pointer, when the memory is

about to be deleted. For instance, Chrome the observer pattern heavily, and

there are many classes that are still referring the observed class after they

received the event it is going to destroy itself.

32 of 35

Roadmap update

✅ PartitionAlloc support

✅ Report useful debugging info: 2 stacktraces: free() and ptr release + stacktrace.

🔁 Annotate pre-existing dangling pointer (Linux ✅, others 🔁)

🔁 Enforce on the commit queue

🔁 Evaluate overhead that can't be tested via field trials (binary A/B experiment)

❌ Experiment against real users and fuzzers

32

✅ done

🔁 in progress

❌ not started (but planned)

Finally, let me share with you our roadmap:

1. We have implemented Dangling Pointer Detector using PartitionAlloc.

2. When a pointer becomes danglings, we reports useful informations to the

developer: two stacktraces. The first stacktrace indicates where the memory was

freed. The second stacktrace where is released the dangling raw_ptr.

3. Currently we are working on annotating in Chrome every pre-existing dangling

pointers. This is mostly done. At least on Linux, and in progress on the

other OSes.

4. Very soon, we would like to start enforcing it on the CQ so that developers

can't silently introduce new dangling pointers anymore.

5. We are about to evaluate the performance impact of the overhead of

maintaining the two refcount. This is compile flag, so this part can't be

tested via Finch.

6. Finally, the last item is about using it against fuzzers and real users. So

that we not only know about dangling pointers discoverable against our own

tests, but also about the ones we miss tests for.

33 of 35

Thank you!

33

34 of 35

Thank you to everyone on the team!

MiraclePtr implementation & testing: keishi@, bartekn@, glazunov@, tasak@, lukasza@, arthursonzogni@, ahijazi@, paulsemel@, pmeuleman@, kdlee@, danakj@, lizeb@

Security advisors: glazunov@, markbrand@, adetaylor@, lukasza@, danakj@, tsepez@

Release: sebmarchand@, srinivassista@, govind@, benmason@, pbommana@

Data analysis advisor: mpearson@

PM: dharani@

Shepherding the project: haraken@

34

35 of 35

Questions?

35