4 ms·

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

by 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]

by 0x0 14y ago

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]