Hacker News new | past | comments | ask | show | jobs | submit login

Hilariously, this bug seems to also crash the Mac error reporter, maybe because it has the evil string in it. I did manage to copy and paste a crash dump before the crash reporter crashed: http://pastebin.com/UkhERvaA

The underlying reported error is * Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'condition "wrong extraction: File:///"'

Interesting that it's an asynchronous crash. What part of MacOS is paying such close attention to typed URLs?

From the openradar bug, it is obvious that the bug is inside the "Data Detectors" thing. Looks like it triggers on anything starting with file:// (+/) case-insensitive, but then something later in the data extraction makes the incorrect assumption that the string should start with file:// (+/) lowercase, and throws an assert.

It's really quite bad that a bug inside the data detectors can bring down a whole app.

Edit: some interesting links:

http://support.apple.com/kb/PH4519 ("This feature is called “data detectors.”")


checkDataDetectors will extract 'File://a/' - or any other 'complete' file URL - which at a minimum is a schema (file://) and a path '/' - as a valid data URL and then pass it to DDResultCopyExtractURL, which does some additional sanity checking.

There it validates it by asserting that the URL begins with 'file://', which it doesn't. It then converts to an NSInternalInconsistencyException which is what crashes the application, since it isn't caught.

The timing differences that people are seeing is because the NSSpellCheckerCheckString process checks the spelling only after your key entry has been idle for a short period.

checkDataDetectors will also run if you simply open a file or application with this text inside it in a text control. When declaring your text control class you can disable the automated spell checking and data extraction (which will run even if you have spell checking disabled).

There really is no need for this thread to be filling up with 'it works on x, doesn't work on y', since we know what causes this (any NSTextField on Mountain Lion).

If you want to have a look at it and can't read the crash report, attach to TextEdit with gdb

    $ gdb /Applications/TextEdit.app/Contents/MacOS/TextEdit
    (gdb) r
    <switch to textmate and type 'file://a/aaaaa' into a new doc'>
    (gdb) <crash report>
    (gdb) disass DDResultCopyExtractedURL
    <dump of function>
Also, this means the bug can't be exploited

What do you mean "exploited"? It certainly can be exploited to cause a denial of service (like the one at this page: http://gironda.org/this_will_crash_safari.html).

'exploit' is the term for getting a bug to run your own shellcode

Can you clarify what about that output shows that the crash cannot be exploited? Not doubting, just curious.

Unhandled exceptions can't be exploited in general, because they safely unwind the stack and terminate the application. This crash is just an unhandled exception. By contrast, a segfault (at an address other than NULL) would be more interesting from a security perspective.

thank you sir!

The data detectors, at least in my TextEdit were turned off (never touched it before) so typing the aforementioned string doesn't cause any issues.

However in my stupidity of attempting to tell you guys that I could type the aforementioned string, I caused Safari to hang. No crash, but it was complete and utterly useless.

Nevermind ... re-ran TextEdit and tried again, immediately crashes. data detectors are still turned off.

Perhaps that preference only suppresses the display, but the data detectors still run.

Another link, with disassembly and a patch: https://twitter.com/landonfuller/status/297592929923502080

If you're stuck because you typed this and now your app is automatically crashing itself all the time, go to System Preferences, under Language & Text, Text, uncheck "Correct spelling automatically" _and_ "Use symbol and text substitution". Both need to be unchecked.

You can use TextExpander to work around it temporarily. Just map {The bad string that starts with 'F' that I cannot type here} to file:/// and it seems to add some protection.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact