The Crash from 'File:///' — More Broadly What Are These Keyboard Sniffer Hooks Doing in a System-wide OS X API?

2013-02-15 • SEND FEEDBACK |
Related: Apple, Apple macOS, security

Update March 14, 2013: this bug is apparently fixed in OS X 10.8.3.

See Apple Core Rot coverage.

This site is not the first to document the “File:///” bug in Apple OS X, but I have some different thoughts about it than might have been covered elsewhere.

The bug

Typing File:/// will crash many programs on OS X 10.8 (those that use the OS X NSText API).

Actually, simply pasting File:/// will crash (I just tried pasting the first few words of the above into TextEdit). Try it in Apple’s TextEdit and see for yourself.

On my system, when typing File:/// —

Crash / hang: Mail, Notes, TextEdit
Works OK: Pages , Keynote, Numbers

Typing File:/// will crash many OS X 10.8 programs

Matthew H writes:

I was messing around testing this File url bug you commented on, and was surprised to learn that just *viewing* a file with that url would cause a crash. After first crashing TextEdit following your blog post, I opened the Console log viewer, which then crashed when I clicked the TextEdit crash report.

Using the good old fashioned command line in Terminal, I confirmed the crash report also contained the file url string, making the Console app crash. In addition, the Problem Reporter.app, which is the process that sends crash reports to Apple if you so instruct after a crash, *also* crashed if I clicked for it to show the details of the crash report. Maybe Apple can't fix the bug because their computers crash whenever they open the crash report! Crazy! Thanks for reporting on it.

MPG: I wrote what follows nearly a week before this reader email. It seems particularly a propos to my “When the impact is potentially widespread...” assertion below. And it’s not just about stability— ill-considered global hooks into system code present potential global security breaches too; it’s poor engineering judgment, and this is a serious part what I call Apple Core Rot. And ironic in the context to all the Apple emphasis on sandboxing and similar “lockdown” features.

Security implications

A system-wide API doing unnecessary and unwanted “sniffing” on the things I type makes me nervous, being inherently inappropriate (that NSTextView also happens to have a severe performance hang with large blocks of text is another indictment, but an unrelated issue per se).

Code which doesn’t just process text as raw data, but that actively looks for certain patterns is by definition a keyboard sniffer, regardless of what its purposes or intent is. That is troubling in its own right for a system-wide API.

More important, code this sloppy does not give me confidence that handling of passwords and passphrases and other sensitive data is done in a way that avoids scattering copies of them around in memory (which also means to disk potentially, e.g., VM paging).

This File:/// thing is only one little crash bug (affecting dozens if not hundreds or thousands of programs using the NS* API). When the impact is potentially widespread, the expectations for quality necessarily rise commensurately in all respects and especially in the areas of stability, performance and security. This isn’t one bug in one program. Severe criticism is warranted in such cases, criticism along the lines of questioning competence of testing and quality control. Because the idea that this is the last and only bug is ludicrous.

Security is hard, very hard to do right. What security problems might lurk within the NSText APIs with regards to passwords and/or other sensitive data? When a programmer can’t get basic things right (and a huge world-class organization can’t test code properly), it does not breed confidence. Furthermore complexity breeds bugs of all kinds.

Whatever extra stuff this Apple keyboard sniffer code is doing ought to be deracinated and extirpated from the API. Heck, perhaps the sniffer code is even responsible for the multi-minute hangs when pasting large text blocks.