969549 - Faulty: PCompositableTransaction reinterprets between layer types based on untrusted message params

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: Faulty session

Found by Christoph Diehl's "Faulty" fuzzer, see bug 777067

This is similar to bug 968833, but now for the PCompositableTransaction protocol.

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

Similar to bug 968833, I suggest sec-crit here. While the present faulty session gives a nice assert failure, that's because it was only calling a virtual method that turned out to be asserting on the current object type. Looking at CompositableTransactionParent.cpp there are places that static_cast between layer types based on untrusted inputs exactly like bug 968833.

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

To give just one example:

http://hg.mozilla.org/mozilla-central/file/a96affc08b1c/gfx/layers/ipc/CompositableTransactionParent.cpp#l158

    case CompositableOperation::TOpPaintTextureRegion: {
      MOZ_LAYERS_LOG(("[ParentSide] Paint ThebesLayer"));

      const OpPaintTextureRegion& op = aEdit.get_OpPaintTextureRegion();
      CompositableParent* compositableParent = static_cast<CompositableParent*>(op.compositableParent());
      CompositableHost* compositable =
        compositableParent->GetCompositableHost();
      ThebesLayerComposite* thebes =
        static_cast<ThebesLayerComposite*>(compositable->GetLayer());

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Interesting bit in this Faulty log:

[Faulty] pickle field {int} of value: 8 changed to: 7

In CompositableType enum, 8 is COMPOSITABLE_IMAGE, 7 is BUFFER_TILED.

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

hit an avatar of this in bug 971262.

Patch coming up.

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: fix-PCompositableTransaction-casts

Comment 6

[Andrew McCreight [:mccr8]]

Assigning to bjacob because he has a patch.

Comment 7

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 8374559 [details] [diff] [review]
fix-PCompositableTransaction-casts

[Security approval request comment]
How easily could an exploit be constructed based on the patch?

Not easily. To someone with good understanding of our codebase (please send your resumes) the patch gives away that passing forged messages to PCompositorTransaction can result in unsafe memory accesses. It remains to figure how exactly to forge such messages (not hard, since it was found by fuzzing generic pickles) and how to actually exploit that (harder).

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

No.

Which older supported branches are affected by this flaw?

All of them.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

No backport ready, but wouldn't be difficult.

How likely is this patch to cause regressions; how much testing does it need?

Not very risky, but not trivial.

Comment 8

[Daniel Veditz [:dveditz]]

Comment on attachment 8374559 [details] [diff] [review]
fix-PCompositableTransaction-casts

sec-approval=dveditz

Comment 9

[Benoit Jacob [:bjacob] (mostly away)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/3bfe9190b72d

Comment 10

[Carsten Book [:Tomcat]]

landed on central https://hg.mozilla.org/mozilla-central/rev/3bfe9190b72d

Comment 11

[Ryan VanderMeulen [:RyanVM]]

v1.1 will be EOL on Monday, so it seems highly unlikely that this is going to be uplifted there :)

Comment 12

[Ryan VanderMeulen [:RyanVM]]

If we were going to backport these to 1.2 and 1.3, that time was a long time ago.

Comment 13

[Matt Wobensmith [:mwobensmith][:matt:]]

Marking [qa-] for desktop QA verification. FxOS QA may choose to verify at a later date.

Comment 14

[Justin Wood (:Callek)]

Applied cleanly to SeaMonkey 2.26.1 (Gecko 29-based)

https://hg.mozilla.org/releases/mozilla-release/rev/304350ccb7ac