If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.
Bug 898117 (harden-layers-ipc)

layers IPC infrastructure allows child to trigger parent-process UAF

RESOLVED FIXED in Firefox 30

Status

()

Core
Graphics: Layers
RESOLVED FIXED
4 years ago
5 months ago

People

(Reporter: jrmuizel, Assigned: bjacob)

Tracking

(Blocks: 1 bug, {csectype-uaf, sec-critical})

unspecified
mozilla30
All
Gonk (Firefox OS)
csectype-uaf, sec-critical
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox23 wontfix, firefox24 wontfix, firefox25 wontfix, firefox26 wontfix, firefox27 wontfix, firefox28 wontfix, firefox29 wontfix, firefox30 fixed, firefox-esr17 wontfix, firefox-esr24 wontfix, b2g18 wontfix, b2g-v1.1hd wontfix, b2g-v1.2 wontfix, b2g-v1.3 wontfix, seamonkey2.26 wontfix)

Details

(Whiteboard: [qa-][adv-main30-])

(Reporter)

Description

4 years ago
There's likely a bunch of work that needs to be done here. Currently the lifetimes of objects generally require co-operation for management. We should aim to fix this after bug 858914.

As a first step we should just focus on areas that could be actively exploited and not worry about resource exhaustion.
(Reporter)

Updated

4 years ago
Group: core-security
My understanding is that the main specific known problem is this: The parent maintains some tree of layers that it is going to compose together. It makes some assumptions about the lifetimes of the nodes in this tree (e.g. child nodes outlive their parent or some such). However, the child can send IPC messages to cause layers to get deleted. But, since they will still be in the layer tree, the compositor will still try to use them; that is a use-after-free.

My understanding that the more general problem is that "none" (to quote some graphics people) of the graphics IPC code has been designed to be a security boundary.

kang: Could you please share this with the other people in b2g land who should know about this? Also, could you please comment on the relative priority of this bug in terms of B2G system security? I imagine it must be at the top.
Blocks: 862082
From comment 1, it sounds like this could be a real problem as is, rather than purely a defense-in-depth desired thing.
Keywords: sec-critical
Who can we assign this to? Jeff?
We don't have the capacity on act on this right now, so we don't have anybody to assign it to.  Needs to be escalated.
Lucas do you know who could take this one?
Flags: needinfo?(ladamski)
Honestly I'm not familiar with this code.  Adding jlebar as he can probably point us in the right direction.
Flags: needinfo?(ladamski)
Flags: needinfo?(justin.lebar+bug)
I'm sorry to continue to kick the can, but I'm not at all familiar with this stuff, and I'm not sure who is, outside the gfx team.  Maybe dzbarsky.  :)
Flags: needinfo?(justin.lebar+bug)
blocking-b2g: --- → koi?
status-b2g18: --- → affected
status-firefox23: --- → wontfix
status-firefox24: --- → wontfix
status-firefox25: --- → wontfix
status-firefox26: --- → affected
status-firefox-esr17: --- → wontfix
Lucas, Justin is no longer here, and this bug needs to be owned by someone. Can you help?
Flags: needinfo?(ladamski)
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → All
Per Justin's comment though this requires GFX knowledge.  I suggest we pair up a GFX person with an IPC person to work through this.  Next week seems like a great opportunity to kickstart the discussion.  I nominate Gregor to lead (or better yet delegate) the IPC side.  Also cc'ing two engineers who are ramping up on IPC, Alexandre and Cervantes.
Flags: needinfo?(ladamski)
That's a good suggestion, but I still don't see gfx being available until B2G 26 issues get taken care of. I've explicitly added the dependency on the bug 858914 that fixes the object lifetimes.  That one is still in progress.
Depends on: 858914
Guillaume just a nudge to make sure you saw comment 1 (or in case it fell off the radar).
Flags: needinfo?(gdestuynder)
Blocks: 918680
it sounds like to me that while comment 0 is pretty generic, comment 1 is specifically about the graphics IPC
We're working on documenting the issue in general (for any API/use of IPC) at https://wiki.mozilla.org/Security/B2G/FirefoxOSCommsHardening

For the very issues mentioned in comment 1, we're trying to prioritize right now - but any such issue is going to relatively high priority to fix.
If there's a use after free which can be triggered through arbitrary IPC messages in the graphics code, this _is_ top priority to fix.
Flags: needinfo?(gdestuynder)
blocking-b2g: koi? → 1.3?
status-firefox26: affected → wontfix
status-firefox27: --- → affected
status-firefox-esr24: --- → wontfix
Alias: harden-layers-ipc
status-firefox28: --- → affected
Jeff, let's start talking about what would be involved with this in a bit more detail.
Flags: needinfo?(jmuizelaar)
(Reporter)

Comment 14

4 years ago
Do we have any fuzzing infrastructure for IPC?
Flags: needinfo?(jmuizelaar)
(Reporter)

Updated

4 years ago
Flags: needinfo?(jmuizelaar)
blocking-b2g: 1.3? → 1.4?
(In reply to Jeff Muizelaar [:jrmuizel] from comment #14)
> Do we have any fuzzing infrastructure for IPC?

Yes, see bug 777067 where Christoph is working on this.
status-b2g18: affected → wontfix
status-b2g-v1.1hd: --- → wontfix
status-b2g-v1.2: --- → wontfix
status-b2g-v1.3: --- → wontfix
status-firefox27: affected → wontfix
status-firefox28: affected → wontfix
status-firefox29: --- → affected
status-firefox29: affected → wontfix
Setting wontfix basically everywhere if this is targeted for B2G 1.4, which is based on Gecko 30.
Changing summary a bit to clarify why we think this bug is sec-critical (hackable) as opposed to sec-want (harden).

(In reply to Jeff Muizelaar [:jrmuizel] from comment #14)
> Do we have any fuzzing infrastructure for IPC?

Our current IPC fuzzing is at the pickle layer and may not work well for fuzzing object lifetimes.
Summary: Harden layers IPC infrastructure for security → layers IPC infrastructure allows child to trigger parent-process UAF
Assignee: nobody → bjacob
Flags: needinfo?(bjacob)
(Assignee)

Updated

4 years ago
Flags: needinfo?(bjacob)
(In reply to Daniel Veditz [:dveditz] from comment #17)
> Our current IPC fuzzing is at the pickle layer

I know that this must sound perfectly reasonable to the specialists, but taken out of context, "Our current IPC fuzzing is at the pickle layer" is an awesome thing to say.

"Les cornichons" by Nino Ferrer
https://www.youtube.com/watch?v=BOGuJRUsQls
(Assignee)

Updated

4 years ago
Depends on: 963790
status-firefox30: --- → affected
We should keep landing these if we have time, but it does not block 1.4
blocking-b2g: 1.4? → ---
With bug 963790 done, we have all gfx/layers IPC protocols at least sufficiently hardened for e10s desktop linux (with OpenGL layers) to successfully complete a reftest run without any crash or Address Sanitizer error.

So the only thing that remains to be done here is complete a reftest run on B2G. This is almost, but not quite the same: there are some Gfx IPC things that are specific to B2G, at least the PGrallocBuffer protocol.
(Assignee)

Updated

4 years ago
Flags: needinfo?(jmuizelaar)
After some successful manual testing on B2G, trying to run reftest with Faulty in GDB but failing because GDB+emulator is still a losing combination (tried both emulator and emulator-jb) and manually inspecting PGrallocBuffer implementation, I think we should close this bug here, i.e. bug 963790 was all what needed to be done here.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
status-firefox30: affected → fixed
Target Milestone: --- → mozilla30
Marking [qa-] for verification based on comments 20 and 21.
Whiteboard: [qa-]
Whiteboard: [qa-] → [qa-][adv-main30-]
driver for this was IPC in b2g [as I read c#20/21], wontfix for SeaMonkey 2.26.1 (Gecko 29-based)
status-seamonkey2.26: --- → wontfix
Group: core-security
Keywords: csectype-uaf
You need to log in before you can comment on or make changes to this bug.