Closed Bug 328751 Opened 19 years ago Closed 19 years ago

Trunk crash [@ SinkContext::~SinkContext]

Categories

(Core :: DOM: HTML Parser, defect, P1)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha1

People

(Reporter: tommy, Assigned: mrbkap)

References

Details

(Keywords: crash, testcase, Whiteboard: [sg:critical?][patch] post 1.8-branch)

Crash Data

Attachments

(1 file, 1 obsolete file)

crash testcase
(deleted), text/html
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060221 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060221 Firefox/1.6a1 A heap overflow vulnerability exists within Firefox and Deer Park Alpha 2, which allows for an attacker to cause the browser to crash, and or execute arbitrary code on a targeted host. The vulnerability is caused due to a boundary error within the “SinkContext::~SinkContext ()” function when processing an applet. Below is output from gdb on OS X 10.4.5 PPC with Deerpark2 (build 2006022104): Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x7c7f1b78 0x0054bdec in SinkContext::~SinkContext () (gdb) bt #0 0x0054bdec in SinkContext::~SinkContext () #1 0x0054dbe4 in HTMLContentSink::~HTMLContentSink () #2 0x0059bf4c in nsContentSink::Release () #3 0x00307f84 in nsParser::~nsParser () #4 0x00308028 in nsParser::Release () #5 0x003479ac in nsDocumentOpenInfo::OnStopRequest () #6 0x000abbd8 in nsBaseChannel::OnStopRequest () #7 0x000cb788 in nsInputStreamPump::OnStateStop () #8 0x000cb32c in nsInputStreamPump::OnInputStreamReady () #9 0x10083238 in nsAStreamCopier::PostContinuationEvent_Locked () #10 0x10044aa4 in PL_HandleEvent () #11 0x100449c8 in PL_ProcessPendingEvents () #12 0x9075ea68 in __CFRunLoopDoSources0 () #13 0x9075df98 in __CFRunLoopRun () #14 0x9075da18 in CFRunLoopRunSpecific () #15 0x9317d1e0 in RunCurrentEventLoopInMode () #16 0x93261f20 in GetNextEventMatchingMask () #17 0x93261df0 in WNEInternal () #18 0x93261d50 in WaitNextEvent () #19 0x006d9700 in nsMacMessagePump::GetEvent () #20 0x006d965c in nsMacMessagePump::DoMessagePump () #21 0x00369238 in nsAppShell::Run () #22 0x00405b80 in nsAppStartup::Run () #23 0x00014514 in XRE_main () #24 0x0000f698 in start () #25 0x0000f518 in start () (gdb) quit Versions Affected: Deer Park Alpha 2 build: 2006022104 on OS X 10.4.5 Camino 1.0 seems to just lock up, and not crash. Talkback Incident #: TB15697882X Please let me know if you need any other information. Thanks, -- Tom Ferris Researcher www.security-protocols.com Key fingerprint = 0DFA 6275 BA05 0380 DD91 34AD C909 A338 D1AF 5D78 Reproducible: Always Steps to Reproduce:
Attached file crash testcase (deleted) —
please note, this does not seem to affect Firefox 1.5.0.1. thanks.
This smells like a parser bug.
Assignee: nobody → mrbkap
Status: UNCONFIRMED → NEW
Component: General → HTML: Parser
Ever confirmed: true
OS: MacOS X → All
Priority: -- → P1
Product: Firefox → Core
QA Contact: general → parser
Hardware: Macintosh → All
Target Milestone: --- → mozilla1.9alpha
Version: unspecified → Trunk
Keywords: crash, testcase
Summary: Deer Park Alpha 2 "SinkContext::~SinkContext ()" DoS → Trunk crash [@ SinkContext::~SinkContext]
Whiteboard: Comment 0 claims this crash is exploitable
Status: NEW → ASSIGNED
Whiteboard: Comment 0 claims this crash is exploitable → [patch] Comment 0 claims this crash is exploitable
Attached patch Fix the crash (obsolete) (deleted) — — Splinter Review
The problem here is that we end up with a context stack that looks something like: <HTML><HEAD><OBJECT><APPLET><BODY><ISINDEX><TABLE><TBODY>. This leaves the HTML content sink in an inconsistent state, with the head context pushed onto its stack twice, which causes pain and unhappiness when we try to delete it.
Attachment #213392 - Flags: superreview?(jst)
Attachment #213392 - Flags: review?(bugmail)
Comment on attachment 213392 [details] [diff] [review] Fix the crash sr=jst
Attachment #213392 - Flags: superreview?(jst) → superreview+
So Firefox 1.5 and 1.5.0.1 don't crash... how did they get fixed without the trunk getting fixed too? Or, what happened on trunk that would cause this to reemerge?
This isn't a regression (so this emerged, not re-emerged). This is fallout from bug 272702, which didn't land on branch.
Blocks: 272702
When I crash in a debugger it's operating on deleted objects.
No longer blocks: 272702
Whiteboard: [patch] Comment 0 claims this crash is exploitable → [sg:critical?][patch]
Blocks: 272702
> This isn't a regression Ah, fooled by comment 0's claims about "Deer Park Alpha 2". That's just what the current confusing trunk start page says, not that Tom was actually using a DPa2 build.
No longer blocks: 272702
Does anyone know which fields persist despite the warning and which don't? I'm quite confused. Sorry for zapping the dependency bugs
Blocks: 272702
Comment on attachment 213392 [details] [diff] [review] Fix the crash This patch is subsumed by the patch in bug 329007, which also fixes a variant not caught by this one.
Attachment #213392 - Attachment is obsolete: true
Attachment #213392 - Flags: review?(bugmail)
So that makes this bug depend on bug 329007, right?
Depends on: 329007
Depends on: 329399
This ended up being fixed by bug 329309.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
That would be bug 329399.
Group: security
Flags: wanted1.8.1.x-
Whiteboard: [sg:critical?][patch] → [sg:critical?][patch] post 1.8-branch
Crash Signature: [@ SinkContext::~SinkContext]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: