Closed Bug 529165 Opened 15 years ago Closed 9 years ago

Crash [@ layout_flush_block] (in Apple's PDFKit ?)

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: MatsPalmgren_bugz, Unassigned)

References

Details

(Keywords: crash, platform-parity, sec-vector, Whiteboard: [sg:vector-critical (Apple) if we had steps to reproduce] rdar://7678506)

Crash Data

It's ranked #225 in the 3.5.5 (past 7 days) top crash list:
http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.5.5/7
with 472 crashes, all on MacOSX 10.6.x
(NOTE: no crash reports on 10.5.x or earlier).

Crashes in layout_flush_block on all branches (past week):
http://crash-stats.mozilla.com/report/list?platform=mac&query_search=signature&query_type=exact&query=layout_flush_block&date=&range_value=1&range_unit=weeks&do_query=1&signature=layout_flush_block

stack:
libPDFRIP.A.dylib	layout_flush_block
libPDFRIP.A.dylib	PDFTextLayoutFlush
libPDFRIP.A.dylib	PDFContentStreamDrawGlyphs
libPDFRIP.A.dylib	pdf_DrawGlyphs
libRIP.A.dylib	rips_DrawGlyphs
CoreGraphics	draw_glyphs
CoreGraphics	CGContextShowGlyphsWithAdvances
XUL	_cairo_quartz_surface_show_glyphs
XUL	_cairo_surface_show_text_glyphs
XUL	_cairo_gstate_show_text_glyphs
XUL	_moz_cairo_show_glyphs
XUL	gfxFont::Draw
XUL	gfxTextRun::DrawGlyphs
XUL	gfxTextRun::Draw
XUL	nsTextFrame::DrawText
XUL	nsTextFrame::PaintText
XUL	nsDisplayText::Paint
XUL	nsDisplayList::Paint const
XUL	nsLayoutUtils::PaintFrame
XUL	nsPageFrame::PaintPageContent
XUL	PaintPageContent
XUL	nsDisplayGeneric::Paint
XUL	nsDisplayList::Paint const
XUL	nsLayoutUtils::PaintFrame
XUL	nsSimplePageSequenceFrame::PrintNextPage
XUL	nsPrintEngine::PrintPage
XUL	nsPagePrintTimer::Notify
XUL	nsTimerImpl::Fire
XUL	nsTimerEvent::Run
XUL	nsThread::ProcessNextEvent
XUL	NS_ProcessPendingEvents_P
XUL	nsBaseAppShell::NativeEventCallback
XUL	nsAppShell::ProcessGeckoEvents
...


I'm filing this bug to Graphics because that's the closest thing on
the stack that is ours, but I suspect the bug is in Apple's PDFKit
which is why I marked it Security-Sensitive -- I don't want to 
zero-day them since PDFKit is likely used in other apps too.
Do you have a contact within Apple we could forward this issue to?
(I tried to report the bug at https://bugreport.apple.com/ but that's
not open to the general public apparently.)
jesse has sent them stuff in the past.  he might have a contact.
Try http://www.apple.com/support/security/.  Ping me again if that doesn't work.
I have sent an email to product-security@apple.com, will update when I get
a response.
Response from Apple <product-security@apple.com> follows:

Please include the line below in follow-up emails for this request.

Follow-up:  88521474

Hello Mats,

Without a reproducible test case, there's nothing we can do.  The comments in the crash reports page 
http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=layout_flush_block&version=Firefox%3A3.5.5
indicates that the issue is related to printing.  I tried printing a few pages from Firefox, including ones mentioned in the comments, and could not reproduce a crash.

We don't have any reports of crashes in layout_flush_block in other applications, so perhaps the crash is a result of memory corruption elsewhere in the code, or incorrect use of the CoreGraphics APIs.
Best regards,

Cedric
Apple Product Security team
http://www.apple.com/support/security/
PGP Key ID: 0x8A648901
Fingerprint: 39EC C76A 3D62 7062 C321  10B2 7928 75E8 8A64 8901
My reply to them on the message above follows:

Follow-up:  88521474

Thanks for your quick investigation and response.

I think it's odd that we don't see any crash reports from 10.5
users though and that's the reason why I suspect an internal PDFKit
bug. As far as I know, we distribute the same Firefox for both 10.5
and 10.6 systems (built on 10.5) and there are few, if any, runtime
differences between 10.5/10.6 in the Mozilla and Cairo code involved.
I'm not an expert on this part of the code though, so I will CC
Vladimir Vukicevic <vladimir@pobox.com> on the bug.

Kind regards,
Mats
Summary: Crash [@ layout_flush_block] (in Apple's PDFKit ?) → Crash [ @ layout_flush_block] (in Apple's PDFKit ?)
Summary: Crash [ @ layout_flush_block] (in Apple's PDFKit ?) → Crash [@ layout_flush_block] (in Apple's PDFKit ?)
Bug 534672 has testcase and steps.  I emailed Apple about it, using the follow-up number above.
Depends on: 534672
Whiteboard: [sg:vector-critical (Apple) if we had steps to reproduce]
For posterity (this appears to be Apple's response to Jesse's mail):

Please include the line below in follow-up emails for this request.

Follow-up:  88521474

Hi,

The crash appears to be reading a null pointer, and thus probably not exploitable.  
In the absence of other evidence about its potential exploitability, we would prefer to treat it as a non-security issue and the best way to address it would be to file a radar on http://bugreport.apple.com.

Best regards,

Cedric
Apple Product Security team
http://www.apple.com/support/security/
PGP Key ID: 0x8A648901
Fingerprint: 39EC C76A 3D62 7062 C321  10B2 7928 75E8 8A64 8901

Follow-up:  88521474

In December, the Firefox team approached Apple about scary-looking
crashes in libPDFRIP.A.dylib function layout_flush_block.  At the
time, we did not have steps to reproduce, and Apple couldn't figure it
out based only on the stack trace.

http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=layout_flush_block&version=Firefox%3A3.5.7

We now have a testcase and steps to reproduce for at least some of
these crashes.

https://bugzilla.mozilla.org/show_bug.cgi?id=534672

This bug report is public.  Let me know if you're really scared and
want me to restrict the bug report to only Mozilla security group
members and chosen Apple employees.
Maybe the Steps to reproduce in bug 534672 always crashes with
null-pointer access, but I'm skeptical that's ALWAYS the case.
If you look at the Address column, many are indeed "near zero"
but there's a significant amount that is not.
http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=layout_flush_block
(For the record, I sent comment 9 as a reply to Apple's mail in comment 8.)
I've filed a bug report to Apple with Problem id: 7678506.
(referring to the public bug 534672)
Whiteboard: [sg:vector-critical (Apple) if we had steps to reproduce] → [sg:vector-critical (Apple) if we had steps to reproduce] rdar://7678506
Apple says of rdar://7678506

"This appears to be a non-exploitable null dereference.  It is fixed on Mac OS X 10.7."

Maybe whatever is causing non-null crashes in this function is a different bug.
You get a very curious result if you sort layout_flush_block crashes by Firefox version: the address is 0x4 for 3.5.8 and later but always a scarier random address in versions 3.5.2 through 3.5.7 (NEVER near-null). I'm not seeing this crash at all in 3.5.1 or lower

Thunderbird version 3.0.1 shows the random address, 3.0.2 and later crash at 0x4.

Looks like we exposed this crash in 1.9.1.2 and then somehow made it safer in 1.9.1.8. Should we use bug 534672 to cover the 0x4 crash, let this one represent the older scarier one, but then close it WFM? I don't see anything all that relevant-looking in the fixed-in-1.9.1.8 bugs. Maybe bug 528493 or bug 528134 related to using dead nsRuleNodes? (grasping at straws...)

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20status1.9.1%3A.8-fixed
Keywords: testcase-wanted
Crash Signature: [@ layout_flush_block]
Keywords: sec-vector
Keywords: sec-other
Group: core-security → gfx-core-security
All recent reports are from Fx/TB 3.x and nothing newer. Calling this WFM.
Status: NEW → RESOLVED
Closed: 9 years ago
Keywords: testcase-wanted
Resolution: --- → WORKSFORME
Group: gfx-core-security
You need to log in before you can comment on or make changes to this bug.