5 ms·

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 befor

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 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?

0x0 14y ago
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 http://support.apple.com/kb/PH4519 ("This feature is called “data detectors.”") https://developer.apple.com/library/mac/#documentation/Foundation/Reference/NSDataDetector_Class/Reference/Reference.html https://developer.apple.com/library/mac/#documentation/Found...
- X-Istence 14y ago
  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.
  - X-Istence 14y ago
    Nevermind ... re-ran TextEdit and tried again, immediately crashes. data detectors are still turned off.
    - MBCook 14y ago
      Perhaps that preference only suppresses the display, but the data detectors still run.
- pifflesnort 14y ago
  Another link, with disassembly and a patch: https://twitter.com/landonfuller/status/297592929923502080 https://twitter.com/landonfuller/status/297592929923502080
- nikcub 14y ago
  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
  - codeka 14y ago
    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 http://gironda.org/this_will_crash_safari.html).
    - nikcub 14y ago
      'exploit' is the term for getting a bug to run your own shellcode
      - deleted 14y ago
        [deleted]
      - deleted 14y ago
        [deleted]
shess 14y ago
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.
eludwig 14y ago
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.

0x0 14y ago

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 http://support.apple.com/kb/PH4519 ("This feature is called “data detectors.”") https://developer.apple.com/library/mac/#documentation/Foundation/Reference/NSDataDetector_Class/Reference/Reference.html https://developer.apple.com/library/mac/#documentation/Found...

X-Istence 14y ago
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.
- X-Istence 14y ago
  Nevermind ... re-ran TextEdit and tried again, immediately crashes. data detectors are still turned off.
  - MBCook 14y ago
    Perhaps that preference only suppresses the display, but the data detectors still run.
pifflesnort 14y ago
Another link, with disassembly and a patch: https://twitter.com/landonfuller/status/297592929923502080 https://twitter.com/landonfuller/status/297592929923502080
nikcub 14y ago
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
- codeka 14y ago
  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 http://gironda.org/this_will_crash_safari.html).
  - nikcub 14y ago
    'exploit' is the term for getting a bug to run your own shellcode
    - deleted 14y ago
      [deleted]
    - deleted 14y ago
      [deleted]

shess 14y ago

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.

eludwig 14y ago

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.