542064 - Flash crash involving security dialogs

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Brandon Sterne (:bsterne)]

Attachment: proof of concept

Attila Suszter reported the following to security@m.o.  Apologies for the poor summary.  The attached testcase crashes deep in libflashplayer, and they're even crashing my Flash decompiler, so I'm not even really sure what the SWF files are trying to do.  The output I did get is fairly nonsensical.  I can attach it if it's helpful.

-------

Hi,



Firefox 3.6 with Adobe Flash 10.0.42.34 crashes on the attached PoC.



Crash reproducation: open 1.html in Firefox and wait for the 3.html to be loaded. Once Adobe Flash Player Security dialog will be popped up click to the OK button to get the browser crashed.



It's possible to decrement the DWORD by 1 at any 32-bit address. Hence this vulnerbaility is likely exploitable for code execution by changing the code to force the program into another vulnerable code path.



NOTE: The attached PoC fills the deleted object with the contents of 3.swf. 41414141 value will be read from the file (3.swf @738). The DWORD at 41414141+608 will be decremented by 1. The PoC may be unreliable in some cases. The PoC tested on WinXP system.



You can find the windbg log of A/V below.



Any question let me know.



Regards,



Attila



(4c4.430): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=00000001 ebx=00000000 ecx=41414141 edx=00150608 esi=04427734 edi=00000001

eip=03f5b200 esp=0012eb70 ebp=0012eba4 iopl=0         nv up ei pl nz ac po cy

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00250213

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\Macromed\Flash\NPSWF32.dll - 

CNPSWF32+0xdb200:

03f5b200 838108060000ff  add     dword ptr <Unloaded_Ed20.dll>+0x607 (00000608)[ecx],0FFFFFFFFh ds:0023:41414749=????????





EXCEPTION ANALYSIS

==================



FAULTING_IP: 

NPSWF32+db200

03f5b200 838108060000ff  add     dword ptr <Unloaded_Ed20.dll>+0x607 (00000608)[ecx],0FFFFFFFFh



EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)

ExceptionAddress: 03f5b200 (NPSWF32+0x000db200)

   ExceptionCode: c0000005 (Access violation)

  ExceptionFlags: 00000000

NumberParameters: 2

   Parameter[0]: 00000001

   Parameter[1]: 41414749

Attempt to write to address 41414749



FAULTING_THREAD:  00000430



PROCESS_NAME:  firefox.exe



ADDITIONAL_DEBUG_TEXT:  

Use '!findthebuild' command to search for the target build information.

If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.



MODULE_NAME: NPSWF32



FAULTING_MODULE: 7c900000 ntdll



DEBUG_FLR_IMAGE_TIMESTAMP:  4ae7bd0e



ERROR_CODE: (NTSTATUS) 0xc0000005 - A "0x%08lx" c men tal lhat  utas t s a "0x%08lx" mem riac mre hivatkozott. A mem rater leten nem v gezeht



EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - A "0x%08lx" c men tal lhat  utas t s a "0x%08lx" mem riac mre hivatkozott. A mem rater leten nem v gezeht



EXCEPTION_PARAMETER1:  00000001



EXCEPTION_PARAMETER2:  41414749



WRITE_ADDRESS:  41414749 



FOLLOWUP_IP: 

NPSWF32+db200

03f5b200 838108060000ff  add     dword ptr <Unloaded_Ed20.dll>+0x607 (00000608)[ecx],0FFFFFFFFh



BUGCHECK_STR:  APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINTER_WRITE_WRONG_SYMBOLS_FILL_PATTERN_41414141



PRIMARY_PROBLEM_CLASS:  STRING_DEREFERENCE_FILL_PATTERN_41414141



DEFAULT_BUCKET_ID:  STRING_DEREFERENCE_FILL_PATTERN_41414141



LAST_CONTROL_TRANSFER:  from 03f5dbfa to 03f5b200



STACK_TEXT:  

WARNING: Stack unwind information not available. Following frames may be wrong.

0012eba4 03f5dbfa 043357a0 04320ab8 00000000 NPSWF32+0xdb200

0012ec10 03f706ad 04332b10 044412b8 04427000 NPSWF32+0xddbfa

0012ec48 03f4e2ac 044b6180 044330c0 04332950 NPSWF32+0xf06ad

0012ec9c 03f21d02 04441060 043333e0 00000000 NPSWF32+0xce2ac

0012ecbc 03f210ea 00000000 043a2278 043333e0 NPSWF32+0xa1d02

0012eccc 03f2b703 00000000 04427000 00000000 NPSWF32+0xa10ea

0012ecf4 03f732c3 03f732cb 00000000 00000001 NPSWF32+0xab703

00000000 00000000 00000000 00000000 00000000 NPSWF32+0xf32c3





SYMBOL_STACK_INDEX:  0



SYMBOL_NAME:  NPSWF32+db200



FOLLOWUP_NAME:  MachineOwner



STACK_COMMAND:  ~0s ; kb



BUCKET_ID:  WRONG_SYMBOLS



IMAGE_NAME:  C:\WINDOWS\system32\Macromed\Flash\NPSWF32.dll



FAILURE_BUCKET_ID:  STRING_DEREFERENCE_FILL_PATTERN_41414141_c0000005_C:_WINDOWS_system32_Macromed_Flash_NPSWF32.dll!Unknown



WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/firefox_exe/1_9_2_3667/4b5102f0/NPSWF32_dll/10_0_42_34/4ae7bd0e/c0000005/000db200.htm?Retriage=1



Followup: MachineOwner

Comment 1

[Brandon Sterne (:bsterne)]

Attachment: backtrace

Crashes deep in libflashplayer.

Comment 2

[Attila Suszter]

(In reply to comment #0)
> summary.  The attached testcase crashes deep in libflashplayer, and they're
> even crashing my Flash decompiler, so I'm not even really sure what the SWF
> files are trying to do.  The output I did get is fairly nonsensical.  I can

The crash should be reproducable with non-altered SWF files which contain
security dialog (sorry - I altered the files to spot the likelihood of
exploitability). Thus the crash of Flash decompiler is coincidence.

This is not a file format vulnerability in Firefox, it looks like some
connection problem when the page is navigated and the security dialog is still
visible. This case may be similar to the Bug 493601.

Comment 3

[Josh Aas]

I can reproduce with Firefox 9 on Windows 7 with the latest Flash plugin. I can't reproduce with a Firefox nightly build.

Sal - can someone at Adobe help here? This seems like an issue on the Flash side.

Comment 4

[Josh Aas]

Jim - can you think of any fix that would help a Nightly build avoid this issue? Looking for an explanation of why I can't reproduce with a nightly.

Comment 5

[smadayag]

i'll ask jeromie to assign someone...

Comment 6

[Jeromie Clark]

Thanks.  We're tracking this as bug 3098919, and will triage ASAP.

Comment 7

[Josh Aas]

Any update here?

Comment 8

[Jeromie Clark]

Thanks for the ping, I apologize for not following up.

We're unable to reproduce this on our side.  If there's any additional information you can provide that would help us reproduce it, I'd be happy to have someone take another look.

Here are the results from the engineer that worked on it:

I tested with the following configs but was unable to repro the crash:

* Using Firefox 3.6.26 with reported Marlin release 10.0.42.34 (as reported by the Mozilla user here) and 10.3.183.11 (last supported release for FF 3.6.26) on Win7 x86.

* Using Firefox 9.0.1/ 10.0 with Marlin release 10.0.42.34 (as reported) and 10.3.183.11 (last supported release for FF 3.6.26), the current public Anza release 11.1.102.55, the latest Brannan build 11.2.202.206 and the latest Cyril build 11.3.300.106 (with both sandboxing on/off) on Win7 x86.

Comment 9

[Josh Aas]

I tried to reproduce again just now. I was using 64-bit Windows 7 in a VMWare Fusion VM with Firefox 10.0.1 and Flash 11.1r102.

I downloaded the PoC zip file here and unzipped it. I loaded 1.html and soon after loading it I get an unsafe operation prompt. I was able to get the plugin to crash by experimenting with waiting times before clicking "OK" on the prompt (let the prompt be for anywhere from 1-15 seconds before trying to click OK). I was able to get the plugin to crash and I was able to get the whole browser to hang up for tens of seconds, even when there was no crash.

I was not able to get the browser parent process to crash.

Jeromie - can someone try again with the exact steps I outlined above? Perhaps a test setup closer to mine?

By the time we're likely to resolve this we won't be supporting Firefox 3.6 any more. We should focus on a Firefox 10+ first.

Comment 10

[Attila Suszter]

As far as I remember the time I reported this there was no default on plugin-container so would it make sense to disable it and see what happens?

Comment 11

[Jeromie Clark]

Sure, I'd be happy to take another look.  We have our hands full at the moment, so it will be Friday/Monday before we can do a comprehensive job at re-testing this.

If it's all right with you, I'd like to narrow the scope down to things that make the most sense to fix, and focus testing on the current shipping version of Flash Player, plus our current engineering builds, with Firefox 10.0.1 and 11.0.

Comment 12

[Josh Aas]

(In reply to Jeromie Clark from comment #11)

> If it's all right with you, I'd like to narrow the scope down to things that
> make the most sense to fix, and focus testing on the current shipping
> version of Flash Player, plus our current engineering builds, with Firefox
> 10.0.1 and 11.0.

Sounds good.

Comment 13

[Attila Suszter]

> I've tested Bug 542064 with Firefox 11 and it's still consistently
> crashing with plugin container disabled. Also I was able to crash
> it with plugin container enabled albeit not consistently but got
> the same crash state.

The following is done by plugin container disabled.

When OK button is clicked on the security dialog 5dfc6435 is executed.

5dfc642f ff90b4000000    call    dword ptr [eax+0B4h]
5dfc6435 8b4e04          mov     ecx,dword ptr [esi+4] ds:002b:111e03a0=5e557184
5dfc6438 8bf8            mov     edi,eax
5dfc643a e871d70400      call    NPSWF32+0x123bb0 (5e013bb0)
5dfc643f ff7518          push    dword ptr [ebp+18h]

It seems ESI points to a valid heap region but the heap can be arranged to contain user controlled data, this might be achieved via heap spray, but sometimes the SWF file (3.swf) is loaded in that region that can be filled with user data.

We can control ECX.

We setep into the call that looks like below.

5e013bb0 56              push    esi
5e013bb1 8bf1            mov     esi,ecx
5e013bb3 8386b8010000ff  add     dword ptr [esi+1B8h],0FFFFFFFFh

At 5e013bb3 we can write the memory at arbitrary address.

I can confirm the above crash on Windows7 with Flash 11.1.102.63.

Comment 14

[Al Billings [:abillings - ex-MoCo]]

(In reply to Attila Suszter from comment #13)

> The following is done by plugin container disabled.

What if the plugin container is not disabled? This is on by default and has been for quite some time. Does the crash only happen if out of process plugins is turned off as a feature?

Comment 15

[Attila Suszter]

At the time of the bug report there was no plugin container used in the stable product and it reliably crashed with default settings.

Firefox 11 with turned-off plugin container crashes reliably.

Firefox 11 with default settings crashes randomly. I could crash the plugin container process by clicking fast on the flash object just before the dialog box comes up.

Comment 16

[Al Billings [:abillings - ex-MoCo]]

I understand that when you logged the bug, plugin container didn't exist but that means we've effectively mitigated this issue with out of process plugins, which is on by default for flash.

Do you have a testcase that reliably crashes firefox in an exploitable manner?

Comment 17

[Attila Suszter]

The existing testcase crashes Firefox in 1/10 ratio for me. When it crashes I get the same crash state to the one in #Comment 13. It might be exploitable because I can write the memory at arbitrary address in the plugin-container process.

(When plugin container is disabled, Firefox crashes in 10/10 ratio for me, and I get the same crash state to the one in #Comment 13.)

Comment 18

[Jeromie Clark]

Thanks for your persistence on this issue.  We're unable to reproduce the issue on our end using Firefox 11 and current Flash Player builds with plugin-container enabled.  

I've assigned it to another engineer to look into, and I provided Al's contact information in case they need to follow up.

Comment 19

[Attila Suszter]

Any chance to know when do you plan to release a patch?

Comment 20

[Al Billings [:abillings - ex-MoCo]]

If we can't reproduce the issue, it is unlikely anyone is going to be able to create a patch for it.

Comment 21

[Attila Suszter]

I understand you cannot reproduce the issue with plugin-container enabled. Could you try it with plugin-container disabled? I think plugin-container mitigates the testcase because of some implicit dependence and not on purpose. It was not designed to prevent security issues.

Also, I think the plugin-container as a mitigation can be bypassed, and the crash on the testcase could become reliable. The plugin-container doesn't resolve the underlying bug.

Again, I was able to reproduce crash with plugin-container enabled, however as I said, I couldn't reproduce it at any time; I was experiementing with clicking on the flash object before the dialogbox pops up.

Comment 22

[:Gavin Sharp [email: [e-mail]]]

(In reply to Attila Suszter from comment #21)
> Also, I think the plugin-container as a mitigation can be bypassed

How? As far as I know there is no way for a given plugin instance to prevent itself from being loaded in the plugin container - it would kind of defeat the point.

Comment 23

[Attila Suszter]

I've had a look at OOPPluginsEnabled() and it seems if the MOZ_DISABLE_OOP_PLUGINS environment variable is set we prevent loading the plugin-container. It also says that plugin-container is "Always disabled on 2K or less. (bug 536303)". I'm not sure about different architectures e.g. Mac?

There are other decisions in the above function that could be an attack surface to prevent loading plugin-container but I didn't investigate them because I think this is out of the scope of this bug even though we linked them.

However, I don't think the attacker needs to bypass the plugin container. It was just an example it could be done that way, but the bug could be triggered in the plugin-container process, too.

Comment 24

[Jeromie Clark]

We have a good set of reproducible test cases for this issue now, thanks for all of the input.  We've locked down our current release, but the fix should be in the following release.

Comment 25

[Jeromie Clark]

Just FYI, this bug is fixed as of Flash Player 11.4.400.128.

Comment 26

[Attila Suszter]

Thanks.

Comment 27

[Attila Suszter]

(In reply to Jeromie Clark from comment #6)
> Thanks.  We're tracking this as bug 3098919, and will triage ASAP.

I just had a look at this on https://bugbase.adobe.com but once the bug id is given it says "The information requested is not found".

Comment 28

[smadayag]

the bug number is an internal reference.  the actual resolved internal bug is #3167051...

Comment 29

[smadayag]

Dolores 11.4.402.265 was released 8/21.  closing.

Comment 30

[Attila Suszter]

(In reply to smadayag from comment #29)
> Dolores 11.4.402.265 was released 8/21.  closing.

Good news :) I'm the reporter of this bug and think I missed the communication happened at Adobe's site because was unable to access the internal bug reference. Have you assigned a CVE for this, could you provide me with the number please?

Comment 31

[Al Billings [:abillings - ex-MoCo]]

No CVE was assigned by Mozilla because we did not fix this in Firefox or any of our code. If Adobe assigned a CVE, it isn't known to us.

Comment 32

[smadayag]

there was no cve mentioned in our internal bug.  i have forwarded the comment/question to rajesh, our security dev manager...