1472990 - AddressSanitizer: heap-use-after-free [@ ~PluginScriptableObjectParent] with READ of size 8

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Christian Holler (:decoder)]

The attached crash information was submitted via the ASan Nightly Reporter on mozilla-central-asan-nightly revision 63.0a1-20180703100028-https://hg.mozilla.org/mozilla-central/rev/a0e47ebc4c06e652b919dabee711fdbd6bfd31b5 (originally reported by unknown).

For detailed crash information, see attachment.


I've hit this reproducibly when trying to start the flash plugin through click-to-play. Since there is a channel error on the stack, this could well be a problem of the plugin-container not starting up properly. I will try to reproduce on a regular ASan build as well. Marking s-s due to use-after-free.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Christian Holler (:decoder)]

I confirmed that this reproduces also in the regular ASan builds and it is due to the fact that the plugin-container does not start up properly. I saw this trace from the plugin container (which might well be due to a broken setup here on my side):

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (<unknown module>) 
Thread T2 created by T0 here:
    #0 0x4aa6ed in pthread_create /builds/worker/workspace/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:204:3
    #1 0x7f07064a2a9b in NP_Initialize (/usr/lib/browser-plugin-freshplayer-pepperflash/libfreshwrapper-flashplayer.so+0x20a9b)


However, we should still fix the use-after-free, no matter how the plugin-container behaves.

Comment 3

[Daniel Veditz [:dveditz]]

calling this sec-moderate rather than sec-high because it appears to require the plugin process being broken in a way a remote hacker couldn't control. (Also requires the user to click, but we can assume they will for compelling content.)

Comment 4

[Pascal Chevrel:pascalc]

Is it reproducible in 60/61/62?

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for a fix in 63. We could still take a patch in 65 nightly.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Does this still happen?

Comment 7

[Christian Holler (:decoder)]

I just retested this on 66 and it seems to be gone, Flash is working in ASan Nightly.

The reports indicate that 64 was still affected, but not a single report on 65+. Assuming this was fixed, even though I don't know for sure how. Did we do any refactorings in that area recently?

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Any thoughts, David?

Comment 9

[David Parks [:handyman]]

Cuando hay llueve...

I'm just about certain that this is a dupe of a different sec bug found by fuzzing -- bug 1449736.  I got pinged on that a couple of weeks ago and this matches the behavior in faulty.txt in that bug.  I've got a good bead on the cause and the fix, also mentioned in that bug.

Not sure what the common cause for this is but it happens whenever Flash fails to initialize while holding some pre-created NPObject, which in turn causes us to tear it down halfway through our init, which hits this bug.  Specifically, it gets here [1], which is because Flash's NPP_New function returned an error.  A nefarious faux-"Flash" install could potentially use this crash to attack the content process.  

I see about 30 of these crashes in the last week in crash-stats [2].

I (still) intend to fix this crash in the other bug.

---

[1] https://hg.mozilla.org/mozilla-central/annotate/33346f699996/dom/plugins/base/nsNPAPIPluginInstance.cpp#l327 
[2] https://crash-stats.mozilla.com/signature/?signature=mozilla%3A%3Aplugins%3A%3APluginScriptableObjectParent%3A%3A~PluginScriptableObjectParent&date=%3E%3D2018-12-05T05%3A19%3A29.000Z&date=%3C2018-12-12T05%3A19%3A29.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-date&page=1#summary