Closed Bug 450508 Opened 16 years ago Closed 15 years ago

Crash [@ FillInMorphRunContextForRun] [@ OTL::GCommon::GetLookups] with astral character and other characters

Categories

(Core :: Graphics, defect, P2)

Product:
Core
Component:
Graphics
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jruderman, Assigned: jtd)

References

Details

(Keywords: crash, testcase, Whiteboard: [sg:vector-critical? (apple)] Apple bug)

Crash Data

Attachments

(2 files)

testcase
125 bytes, text/html
Details
standalone code that causes crash
3.66 KB, text/plain
Details
Attached file testcase — 
Loading the testcase in a trunk debug build of Firefox on Leopard usually triggers a crash.

The top of the stack is one of the following:
* FillInMorphRunContextForRun
* OTL::GCommon::GetLookups

This seems similar to bug 428633, which I can no longer reproduce.  That bug, in turn, is suspected of being a duplicate of bug 436663, which is supposedly fixed for Snow Leopard.

Before I reduced the testcase to its current form, I was getting crashes dereferencing 0x5555####, indicating that the crash might be exploitable.

Is this an Apple bug?  If so, do you guys know how to report it properly?
(In reply to comment #0)
> Is this an Apple bug?  If so, do you guys know how to report it properly?

No clue -- the bugs that I've reported using their bug report system at http://bugreport.apple.com/ have all been silently ignored, except for one bug which was silently fixed without my bug being closed.  So dunno.
I'm guessing this is the same bug as bug 436663.  I filed that one in the Apple bug reporter and pinged one of the Apple type developers directly.  Bugs for me sometimes get fixed, especially crashers, and I have gotten mails saying a bug was fixed in such-and-such a seed build.  I'm guessing that unless your Apple dev acct has special privs to receive a seed build you probably won't hear from them.
Whiteboard: [sg:critical?]
Flags: blocking1.9.1?
Whiteboard: [sg:critical?] → [sg:critical?] Apple bug?
I accidentally clicked on the testcase and didn't crash; that said, it wasn't a debug build.  Not sure what to do here, if the crash is inside ATSUI.  I wonder if CoreText might be less crashy?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P2
Still crashes for me (testing on my MBP, which I finally installed Leopard on).  Sometimes it crashes right away, sometimes it crashes later (e.g. a few seconds after the tab is closed).
Assignee: nobody → jdaggett
This is on our "Top Security Bugs" list and progress appears to have stalled.  Please treat this as a top priority, as we are making an effort to reduce our open security bug counts.
Unlike bug 436663, it's not clear to me that there's any workaround at our level, since all we're doing is passing the astral characters to OS text routines.  Unless it's thought wise to filter astral characters from known-buggy iterations of OSX (sub in U+FFFD, presumably) ...?
I'm going to work on this first thing Monday.  There isn't much we can do to work around this, the text sequence is fairly complicated and just altering the text sequence slightly avoids the problem.  So the first step is to raise a DTS issue with Apple and try and see if we can get any more insight into why this bug occurs, hopefully this will give us a clue as to how to work around the issue (breaking up text runs into when more than n fonts are involved?  or when specific scripts are involved?).

Might also be interesting to run with gmalloc enabled, possibly test with the new Mac OS X port of valgrind.
This is a standalone Carbon app that causes the same crash.  I extracted the text run string and set up the same font styles as in the crash situation.  The problem appears to be related to the Tibetan vowel symbol in the string, with a font like Kokonor or Kailasi (these shipped with 10.5).  With either of these set as the font for the vowel marker, a crash occurs.  With no font set, no crash occurs.

Steps:

1. Build the attached code in a Carbon app project
2. Run with libgmalloc enabled in the debugger

Result: crash due to EXC_BAD_ACCESS

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0xb14ec000
0xffff0e94 in __memcpy ()

Stack crawl:

#0  0xffff0e94 in __memcpy ()
#1  0x9102c159 in MoveGlyphs ()
#2  0x910770d5 in DoGlyphInsertion ()
#3  0x91030aaf in MorphTableDoInsertionSubtable ()
#4  0x9101d39c in ProcessSingleMorphRun ()
#5  0x9101be70 in ApplyMorphForRun ()
#6  0x9102818f in ApplyMorph ()
#7  0x9101b10f in _eLLCLayoutText ()
#8  0x9101afc3 in LLCLayoutText ()
#9  0x90f6b366 in ATSULayoutGlyphs ()
#10 0x90f6b252 in TTextLineLayout::LayoutGlyphVector ()
#11 0x90f7c3aa in TTextLineLayout::EnsureLayoutIsUpToDate ()
#12 0x90f86e99 in TTextLineLayout::GetGlyphBounds ()
#13 0x90f86dca in ATSUGetGlyphBounds ()
#14 0x000020c6 in main (argc=1, argv=0xbffff7c4) at /Users/jd/atsuiastral/main.cp:104
The next step is to report this to Apple.  There are several possibilities for ways to work around this: blacklist these fonts, blacklist Tibetan AAT fonts, blacklist Tibetan altogether, etc.  Nothing we'd really like to do but just several possible hacks to workaround until Apple fixes the problem, if they ever do.
Simon, I'm wondering if you think there might be a way of validating text runs that include some form of combining marks.  In this case, ATSUI is getting tripped up by a combining mark with no associated cluster base character (I'm probably screwing up the terms here).  Would it be possible to detect this situation efficiently and omit poorly formed clusters somehow?
If the crash only occurs when astral characters are present, I'm not sure that the combining characters are at the root of the problem. How is the testcase rendered if the astral character is omitted? For example, is an extra glyph added as a carrier for the orphan combining mark? What I suspect is that the astral character is causing one of the length arguments to be off by one and this is causing an overrun somewhere.
This is the text sequence that causes the problem:

0x202d, 0x0020, 0x005f, 0xdbe1, 0xdc04, 0x005f, 0x005f, 0x005f, 0x005f, 0x005f,
0x005f, 0x005f, 0x005f, 0x530d, 0x005f, 0x005f, 0x005f, 0x005f, 0x005f, 0x005f, 
0x530d, 0xc712, 0x005f, 0x005f, 0x005f, 0x005f, 0x005f, 0x005f, 0xc712, 0x530d, 
0x0f75, 0x1326, 0x0020, 0x002e, 0x202c

The crash is related to the Tibetan vowel U+0F75, if the Tibetan font Kokonor is used the crash occurs, if not it doesn't.  Given that MorphTableDoInsertionSubtable is part of the stack crawl I'm assuming this somehow relates to the 'morx' table data in Kokonor.  But U+0F75 is a combining mark next to a Chinese character, so I'm wondering if there's a canonical way of dealing with "invalid" sequences like this.

http://unicode.org/cldr/utility/character.jsp?a=0F75
Interestingly, if I replace U+0F75 in the test with its canonical decomposition <U+0F71, U+0F74>, then it no longer crashes. My guess (without actually disassembling the Kokonor 'morx' table) is that it uses an insertion action to split U+0F75 into its two components, to position them independently, and either the 'morx' subtable is broken or ATSUI's processing of it is buggy.

There isn't really any canonical way to deal with this; while placing a Tibetan vowel after a Chinese character may be unexpected, and unlikely to occur in "real life" text, there's nothing invalid about it from a Unicode encoding viewpoint.

A combining mark (or marks) that occurs without any preceding base constitutes a "defective" combining character sequence, and I suppose for practical purposes this could be considered to occur at the beginning of a font/style run, as well as at start of text or beginning of line, because of the difficulty of doing proper mark positioning across font changes. In that case, inserting U+25CC (dotted circle) as a base for the combining mark would be the most reasonable thing to do.
John, any idea of the status of this with Apple, as it looks like it's really their bug? I know some of the engineers involved and could try pinging them directly if you're not getting any info back from a Radar bug report (though it's still good to have that on file as well).
Technical support request logged with Apple DTS, awaiting a response.
(In reply to comment #14)
> John, any idea of the status of this with Apple, as it looks like it's really
> their bug? I know some of the engineers involved and could try pinging them
> directly if you're not getting any info back from a Radar bug report (though
> it's still good to have that on file as well).

Thanks, yeah I know some too but I think in this case it's better to go through Apple DTS at first since it's a security issue.  I've logged bugs and pinged developers in the past but I think these are treated internally as low priority because they (1) involve ATSUI and (2) seem to be edge cases and as such appear to be lower priority.

> Interestingly, if I replace U+0F75 in the test with its canonical 
> decomposition <U+0F71, U+0F74>, then it no longer crashes.

Yeah, I noticed that MorxTester does something similar, that's what made me wonder if there was some sort of normalization algorithm that would workaround the problem.
No response yet from Apple, should hear back within the next 48 hours.
Any response yet from Apple?  This bug is on our "Top Security Bugs" list and needs to be treated as a priority.
Brandon,

Since we raised a DTS incident with Apple several weeks ago [DTS followup 59175591] the only response I got was on 11/20:

> Hello,
> 
> I am looking into this with the ATSUI engineering team and I will get
> back to you when I have some more information.
> 
> Thanks, 
> J.R.

Still no response.  I've asked Josh to escalate this with our Apple rep, usually these cases are handled much more promptly.  I also mailed one of the ATSUI engineers directly but didn't hear back.  I suspect he's been away for the holidays and other folks don't know (want to know?) the ATSUI code, but that's pure speculation.

If you know anyone on the Apple security team, it might help to poke them also about this.
Combinations of Unicode characters can also crash Terminal.app, see the reduced testcase at:
https://bugzilla.mozilla.org/show_bug.cgi?id=465797#c10
Received Dec. 5 afternoon, California time, from Apple DTS:

Hello,

I have filed a bug report on your behalf and the ATSUI engineers are working on a fix for this bug.  You should receive an email in the next 2-3 business days with information on how to track the status of this bug.

Thanks,
J.R.
I have tried to reproduce this crash via CoreText, using the same character sequence and fonts, but it seems to run fine, generating the expected glyphs and not crashing. Therefore, it seems likely that the issue will be resolved when we adopt CoreText on OS X 10.5 (bug #389074). I hope to have this ready for review this week.

It would of course still be good to get the underlying ATSUI problem fixed.
I think once we know more about the underlying cause of this, we can make a better assessment of how to work around this.  Maybe just doing an itemize operation, breaking text runs into per-script chunks, would be enough to work around the problem?  

There seem to be a number of ways to tweak the testcase to avoid the problem, but we won't know whether we've just ducked a particular instance or really worked around the problem until we get more info from Apple.
Have we heard anything from Apple?  We have Mac valgrind available here too, copying sayrer for expertise in that area if people have questions.  (Does Safari crash on this?  Is that a dumb question, since they probably use CoreText?)
(In reply to comment #24)
> Have we heard anything from Apple?  We have Mac valgrind available here too,
> copying sayrer for expertise in that area if people have questions.  (Does
> Safari crash on this?  Is that a dumb question, since they probably use
> CoreText?)

We heard back in January, after that nothing:

From: "Apple Worldwide Developer Technical Support" <dts@apple.com>
To: jdaggett@mozilla.com
Sent: Tuesday, January 6, 2009 10:20:36 AM GMT +09:00 Japan
Subject: re: Crash in Mozilla with specific character seq [62058263]

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

Follow-up:  59175591

Hello,

I just heard back from our Text software engineering team and there is no work around other than using Core Text instead of ATSUI.

J.R.

---
J.R. Blackham
DTS Engineer
Worldwide Developer Relations
Apple

I'll test this again on the latest 10.6 seed build tomorrow.  If it's fixed there we can request that the fix get pushed back to 10.5, 10.4 doubtful.
John, I suppose 10.6 didn't fix this, huh?
Still happens using Firefox trunk on 10.5.  I should be able to test 10.6 soon.
Jesse, have you had a chance to test this on 10.6 yet?  I would test it if I had a copy, but I don't.
No, I don't have 10.6 yet.
Whiteboard: [sg:critical?] Apple bug? → [sg:vector-critical? (apple)] Apple bug
Does not crash on 10.6.2.
Also does not crash any more on 10.5.8!?

(I'm testing with the Firefox testcsae in comment 0, not the standalone testcase in comment 8.)
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ FillInMorphRunContextForRun] [@ OTL::GCommon::GetLookups]
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: