1613879 - AddressSanitizer: heap-use-after-free [@ GetConsoleService] in fuzzer harness

Status: NEW

(Core :: Fuzzing, defect, P5)

Description

[Christian Holler (:decoder)]

Attachment: ipc-uaf-b0f071e99da0.txt

Running the ContentParentIPC target locally, I found out two things first

1. I had to fix some easy null checks that caused immediate crashes (note that this can cause some line numbers in the backtrace to be slightly off).

2. I had to limit the allocation size in the JS engine to a reasonable value, because the fuzzer was creating GB large TypedArrays through StructuredClone deserialization.

Once I did this, I hit the use-after-free attached, which seems to involve an OOM condition (caused by MOZ_FUZZ_LARGE_ALLOC_LIMIT in the fuzzing case).

This looks dangerous to me because a compromised child could easily provoke such an OOM by using really large TypedArrays, leading to a sandbox escape.

So far, I was not able to reproduce the issue reliably with a testcase, but I will continue to work on it and also try it without my fixes on Monday. In the meantime, maybe the uaf trace is already enough to confirm that this is a legit issue and to find the right fix.

Comment 1

[Nika Layzell [:nika] (ni? for response)]

I think this is being caused by the ContentParentIPC test runner, not by a bug in the protocol. The issue here appears to be that the ContentParent actor itself was freed by the cycle-collector. The code in https://searchfox.org/mozilla-central/rev/623de665034eee43a54ff02939b61385ffd5990d/dom/ipc/fuzztest/content_parent_ipc_libfuzz.cpp#19-30 allocates a ContentParent, and doesn't ever call AddRef on it.

I'm guessing that, because there are no non-cc-ed strong references, the cycle-collector (which is run due to the memory pressure warning) cleans up the dangling object, thus causing the apparent UAF.

You will want to make the references used in content_parent_ipc_libfuzz.cpp and ProtocolFuzzer.cpp hold a RefPtr to keep the actor alive while tests are running.

Comment 2

[Christian Holler (:decoder)]

(In reply to :Nika Layzell (ni? for response) from comment #1)

I think this is being caused by the ContentParentIPC test runner, not by a bug in the protocol. The issue here appears to be that the ContentParent actor itself was freed by the cycle-collector. The code in https://searchfox.org/mozilla-central/rev/623de665034eee43a54ff02939b61385ffd5990d/dom/ipc/fuzztest/content_parent_ipc_libfuzz.cpp#19-30 allocates a ContentParent, and doesn't ever call AddRef on it.

I'm guessing that, because there are no non-cc-ed strong references, the cycle-collector (which is run due to the memory pressure warning) cleans up the dangling object, thus causing the apparent UAF.

You will want to make the references used in content_parent_ipc_libfuzz.cpp and ProtocolFuzzer.cpp hold a RefPtr to keep the actor alive while tests are running.

Confirmed, holding a RefPtr fixes the problem for me. I'll post a patch soon. And we can unhide this bug.

Comment 3

[Chris Peterson [:cpeterson]]

(In reply to Christian Holler (:decoder) from comment #2)

Confirmed, holding a RefPtr fixes the problem for me. I'll post a patch soon. And we can unhide this bug.

Assigning to decoder. This is a bug in the fuzzer.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:Sylvestre, could you have a look please?

For more information, please visit auto_nag documentation.