Typing These 8 Characters Will Crash Almost Any App On Your Mountain Lion Mac

An anonymous reader writes "All software has bugs, but this one is a particularly odd one. If you type "File:///" (no quotes) into almost any app on your Mac, it will crash. The discovery was made recently and a bug report was posted to Open Radar. First off, it’s worth noting that the bug only appears to be present in OS X Mountain Lion and is not reproducible in Lion or Snow Leopard. That’s not exactly good news given that this is the latest release of Apple’s operating system, which an increasing number of Mac users are switching to. ... A closer look shows the bug is inside Data Detectors, a feature that lets apps recognize dates, locations, and contact data, making it easy for you to save this information in your address book and calendar."

Comments

printf

[Sigvatr]

C-strings strike again.

Re:printf

[Anonymous Coward]

Not likely. It crashes due to an assertion failure and subsequent exception being thrown.

Re:printf

[Anonymous Coward]

Here speaketh the Apple fan. No matter what... it's a good thing.

Re:printf

[Anonymous Coward]

Why do you assume it's a C-string issue? An exception was thrown, indicating no real corruption just an unhandled exception.

Re:printf

[Anonymous Coward]

as a programmer myself, when coding something and a harmless and not completely unexpected input occurs, your program shouldn't crash, due to any reason, asserts included. Such a failure is sign of nothing but lazy programming and even lazier unit testing.

Re:printf

[Anonymous Coward]

When you detect that your program is in an inconsistent state, is it better to continue executing, possibly corrupting data and granting an attacker access to your system, rather than aborting the program and providing a stack trace to help diagnose why things went wrong?

Re:printf

[peragrin]

What is funnier that file:/// doesn't work.

The Captil F is required. at least in my limited testing.

Re:printf

[jones_supa]

Good point.

Re:printf

[TheRealMindChild]

Exceptions should be exceptional. A bad string isn't exceptional

Re:printf

[Dahamma]

No, it's better to return an error or thrown an exception rather than assert when the input to a function is perfectly reasonable but not what you expect.

And, in the end, who knows. Maybe it was the caller aborting by not handling the error/exception. In which case it's STILL bad coding by someone, as this is not an exceptional case...

Re:printf

[Anonymous Coward]

Hey its just a GUI event indicating that the user entered something in a text bar.

When that event gets processed and an exception occurs while the user input is parsed no actual state modifying operation occured yet. Atleast in my happy world where we don't modify state until we're done figuring out what the user wanted.
If it wasnt even able to figure out what the user wanted and concluded that the input is unparseable, reset the input field, forget about that event and its still a consistent state.

Re:printf

[EvanED]

Yes, input validation is usually a good thing and no amount of you hating Apple Inc is going to change that.

That's true. But a crash is not the way to handle invalid input.

Re:printf

[Savage-Rabbit]

I have also had the impression that assert() is a hack that shouldn't be used much (?).

$ man assert

NAME
          assert -- expression verification macro

SYNOPSIS
          #include

          assert(expression);

DESCRIPTION
          The assert() macro tests the given expression and if it is false, the
          calling process is terminated. A diagnostic message is written to stderr
          and the abort(3) function is called, effectively terminating the program.

          If expression is true, the assert() macro does nothing.

          The assert() macro may be removed at compile time with the cc(1) option
          -DNDEBUG.

Somebody forgot to remove some debugging code, embarrassing but hardly something that hasn't happened before and definitely not the end of the world as we know it.

Re:printf

[Savage-Rabbit]

What is funnier that file:/// doesn't work.

The Captil F is required. at least in my limited testing.

Typing 'file:///' opened Finder.app from Safari's address bar just fine on my machine.

Re:printf

[black3d]

That's what he said.. you need a capital F

Re:printf

[fyngyrz]

C-strings strike again.

Nope. Lousy programmers strike again. There's nothing at all wrong with c-strings. There is, however, a sufficiency of lousy programmers who lack the skill to handle perfectly simple data structures. Seriously, if you can't handle a zero terminated string or keep from overrunning an array, it's not the string format that's the problem. It's you.

Assuming the problem here is a string problem may be jumping the gun, too. Could just as easily be something else.

Re:printf

[Anonymous Coward]

I agree with you, you couldn't abort on bad input.

However, based on my interpetation of what is happening, this isn't what is happening. My expecation is as follows:

The user types something in an address bar.

That string is passed to hypothetical function 'process_uri'.

'process_uri' sees that it is a file uri, and passes it to the hypothetical function 'process_file_uri'.

'process_file_url' sees that it wasn't given a file uri, and aborts.

The problem ISN'T that the use gave bad input. If process_uri was given a URI it didn't recognize, it would have generated a proper error and not called anything. If process_file_url was given a path to a file that didn't exist, it too would have generated a proper error. The problem IS that process_uri and process_file_uri have different expectations on what constitutes a proper file uri.

Re:printf

[Anonymous Coward]

Not likely. It crashes due to an assertion failure and subsequent exception being thrown.

Yeah. Data Detectors on Macs is just like Semantic Desktop on KDE. When I make a fresh install of the OS, disabling these pesky little "features" is one of the first things I do. I'm glad somebody somewhere out there finds them useful but I definitely don't.

Re:printf

[Anonymous Coward]

as a programmer myself, when coding something and a harmless and not completely unexpected input occurs, your program shouldn't crash, due to any reason, asserts included. Such a failure is sign of nothing but lazy programming and even lazier unit testing.

Sorry, but you are wrong.

By the time you fail an assertion, you better crash because you're not supposed to be there. The code in FRONT of the assertion is supposed to prevent that.

Assertions go between the input checking front, and the sane input needing rear. Their only purpose in life is to prevent an unknown state in the rear guts, not to do what should have been done up front.

Re:printf

[matunos]

And yet, unchecked input is the root of almost all software vulnerabilities

Re:printf

[AuMatar]

Totally and completely fucking wrong. A well written program should not crash for any reason. It should alert the user and allow new input or fail gracefully, not suddenly crash. Asserts should always be compiled out in release code, and cause premature return from the function with an error code or reasonable default, it should NEVER crash on release.

Re:printf

[Jorl17]

This is not input checking. Input checking is checking the input for validity and acting accordingly. This is an assert, which is usually used as a way for programmers to make sure they didn't fuck up. If it is triggered, then the programmer fucked up. That's how it's supposed to be used.

Hence, the programmer fucked up, and this isn't input checking. It is nevertheless, IMO; a good practice to assert things (in debug code), but it also isn't checking for valid inputs, it's checking for programmer stupidity.

Re:printf

[Obfuscant]

A bad string isn't exceptional

Especially when the interpretation of that "bad string" is supposed to be CASE INSENSITIVE and the "exception" occurs because one character is upper case.

URI are defined here, and the part that deals with the "file:" or "http:" part (called the "scheme") says this:

3.1. Scheme ...

Scheme names consist of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-"). Although schemes are case- insensitive, the canonical form is lowercase and documents that specify schemes must do so with lowercase letters. An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" as well as "http") for the sake of robustness but should only produce lowercase scheme names for consistency.

Emphasis mine.

This is a case of a programmer implementing a feature defined in a standard and ignoring the standard when doing so. Not lazy, just ignorant and stupid. Just like the ignorant stupid programmers who write javascript email address verifiers that refuse to accept valid email addresses because they contain characters like '+'. Those programmers should be shot.

Re:printf

[AuMatar]

The user never types in a null terminated string. They type in a sequence of bytes and the program turns it into a null terminated string. Strings with separate lengths work the same way- would you trust a length field coming straight from a user?

Re:printf

[Anonymous Coward]

Based on what you said, the summary title is incorrect. The programs aren't crashing, but rather are ending normally, just not when the user thinks they're telling it to.

Re:printf

[Darinbob]

Check the input, then deal with the error. Crashing is not dealing with the error. Assert should be used for "should never happen" cases, like pre/post-conditions.

Re:printf

[Darinbob]

To the user, there is no difference between crashing due to an assert or crashing due to following some strange pointer. Now the assert may give the developer more information to work with to fix the bug, but it should always be considered a major failing if a user ever sees it.

Re:printf

[matunos]

assert should be compiled away in production code. :-)

Re:printf

[Anonymous Coward]

Somebody forgot to remove some debugging code

As far as I'm concerned, leaving assertions turned on in production code is a good thing (as long as they're just doing simple sanity checks that won't hurt performance). Actually _triggering_ one of them in production code is bad, but not as bad as letting the program continue into undefined behavior with data it never expected to see.

Re:printf

[Darinbob]

Well, yes, but the last three jobs we've had to leave them in...

Re:printf

[TheRealMindChild]

The point of assert is to set a breakpoint to go to during unit testing

Re:printf

[shutdown -p now]

assert() isn't really "debugging code". It's more of a sanity check - as the name implies, it's a macro that checks that expression is indeed true, where the standing assumption on this particular code path is that it must be true. If it's not true, then there's a logic bug somewhere in the program, and that may lead to data corruption or worse. So liberally sprinkling asserts around and leaving them in release builds actually helps - it's far better to fast-fail than to continue running the process in a potentially corrupted state, from security perspective.

Of course, the assert shouldn't be triggered in the first place - the fact that they somehow got into this state is itself a bug, which they should fix. Still, kudos to Apple folk for handling this one in a manner that makes it useless for an exploit.

Re:printf

[shutdown -p now]

A perfect program should not crash for any reason - but very few programs of any considerable size are perfect. And even well-written software has bugs.

Asserts are meant to indicate that the condition should always be true on this particular code path - that's why it's called an "assert". It's not a tool to check for exceptional conditions and gracefully handle them - you have conditional statements (and exception handling, if the language supports that) for those purposes. You use assert after you have used a conditional to fork off onto a code path to assert that all the implied conditions are, indeed, true. If the conditions are not true, it indicates a bug in the logic of the program - the assumption was not correct. There is no way to gracefully handle that, because you don't know where exactly the problem is, and therefore you can no longer rely on the state of your process being correct. If you hit an assert, it means that some objects you thought to be alive are now dead, and you might have dangling pointers around. Or maybe some variables that you think have correct values in them have something outdated and completely irrelevant. Either way, if you keep running, you risk integer and buffer overflows - and from there, execution of arbitrary injected code. From security perspective, this is the worst scenario you can end up with, especially for an application facing the network or processing external inputs from the network. Fast-fail (i.e. consistently crashing right away) is much preferable to that, even if it inconveniences the user.

Re:printf

[shutdown -p now]

Asserts should not be hit. If they are hit, the program is in a bad, unexpected state. If your program is in a bad, unexpected state, you want to kill it ASAP, production code or no.

The only reason why asserts are usually compiled out in non-debug builds is because those extra checks are not free, and because the assumption often is that in production code, you have no bugs - and therefore the asserts will never fail anyway, so why bother? But if you're not entirely sure, and if you're willing to sacrifice a little performance, it is not unreasonable to leave them there.

Re:printf

[shutdown -p now]

Programmer stupidity (or rather inattentiveness) is not limited to debug code, so why limit asserts to it? Unless you really need that 1% of performance you gain by disabling them...

Re:printf

[shutdown -p now]

Asserts are there to ensure that you do indeed handle all inputs and "process a sane default or abort the function returning an error". If the latter is done, then the assert never gets hit (and there's no need to remove it). But if it's not done, by mistake - i.e. due to a bug - then the assert will ensure that your process dies right there and then, before it can be exploited. It's the last line of defense. Its purpose is not to be user friendly - by the time you get to it, all the code that deals with "user friendly" part of things has already done its job (and failed - which is a bug, but...). Its purpose is to prevent a buffer overflow or a similar exploit vector in buggy code.

Re:printf

[Jorl17]

You're right, the performance difference is negligible. I guess it's just a habit I've developed, though when I come to think of it, it really makes some sense to leave that in release code. OTOH, it might reveal what you expect a function to do more easily, thus facilitating reverse-engineering if one is afraid of that.

Re:printf

[gargleblast]

as a programmer myself, when coding something and a harmless and not completely unexpected input occurs, your program shouldn't crash, due to any reason, asserts included. Such a failure is sign of nothing but lazy programming and even lazier unit testing.

Whoa there!

1. Don't worry about the harmless. WORRY about the HARMFUL
2. Don't worry about the "not completely unexpected". That is, of course, the expected. WORRY about the UNEXPECTED
3. "your program shouldn't crash" ... thank you Capt'n Obvious. Now quick: think of three things a program can do that are worse than crashing.

Bzzzt. Time's up. Did you get: (1) Have exploitable security flaws; (2) Corrupt or delete data; (3) Hang or livelock. There are others.

Cheers.

Re:printf

[shutdown -p now]

I think I'd worry about security (think dangling pointers and integer/buffer overflows in case your data isn't in a state you expect it to be) before worrying about ease of reverse engineering in pretty much every scenario I can think of. In the end, if someone really cares that much about my code, they will reverse engineer it one way or another - by tracing all the way through the assembly, if necessary. Weaker security, on the other hand, means potential problems for users of my code - i.e. my employer's customers. When you have a lot of customers, that can add up to a major snafu real quick - not to mention the moral responsibility.

Re:printf

[Bomazi]

You don't understand what assert() is for.

It doesn't cause a crash. Quite the opposite. It is a way of deliberately causing program termination upon encountering an internal inconsistency; precisely so as to avoid a crash, a silent failure or some other undesirable behavior.

Obviously, in a bug-free program, assert() would never trigger and is therefore unnecessary. In the real world it is a useful safety net.

Note that assert() is sometimes used to catch runtime errors. That is indeed inappropriate. But you shouldn't condemn the tool because it is sometimes used incorrectly.

Re:printf

[Anonymous Coward]

Totally and completely fucking wrong. A well written program should not crash for any reason. It should alert the user and allow new input or fail gracefully, not suddenly crash. Asserts should always be compiled out in release code, and cause premature return from the function with an error code or reasonable default, it should NEVER crash on release.

Maybe you want to correct the wikipedia article on assertions then, because you are so horribly wrong and sure of yourself, and upmoded that I'm really losing faith in /.

http://en.wikipedia.org/wiki/Assertion_(computing)

It is worth distinguishing assertions from routine error-handling. Assertions should be used to document logically impossible situations and discover programming errors — if the impossible occurs, then something fundamental is clearly wrong. This is distinct from error handling: most error conditions are possible, although some may be extremely unlikely to occur in practice. Using assertions as a general-purpose error handling mechanism is unwise: assertions do not allow for recovery from errors; an assertion failure will normally halt the program's execution abruptly. Assertions also do not display a user-friendly error message.

How many brain cells does it take to reason that if an assertion modified the logic of your program, that means removing them changes the logic of your program, which means having them in the first place would have been pointless. The only reason to ever take them out is for performance, because they should NOT EVER change the behavior of a program. That is WHY you CAN disable them. They should exit with debugging information for the DEVELOPER, not the user. Input validation code deals with the user.

This assertion detected a bug in the code in front of it, that's WHAT ITS JOB IS, PERIOD.
The code behind an assertion WILL NOT handle that state.

Re:printf

[Provocateur]

Ladies and gentlemen, I have the dubious honor of introducing the original "Bobby" Tables.

Re:printf

[AuMatar]

Then instead of an assert you should have a return error (or throw exception) statement. You should NEVER have an assert that doesn't also cause an error return. That's fucking programming 101- because the asserts WILL be compiled out in release builds, and because crashing could leave the system in an unrecoverable state- you ALWAYS kick the error up to a level that can deal with it.

Re:printf

[AuMatar]

You can remove asserts because your program is NEVER supposed to rely on them. The following code:

assert(foo!=null); //do something

is WRONG. Because it depends on the assert. The correct way to code it is

if(foo == null){
        assert(false);
        return some_error_value;
} //do something

Crashing is NEVER acceptable. And you cannot assume its ever an option in a production system- when you crash cleanup code is not necessarily run, and you can leave the system in an unrecoverable state. Fucking amateur.

Re:printf

[Omestes]

...it has to do with good programming practices.

If good practices involves planned crashes for innocuous user behavior, I'd hate to see what bad ones are.

Re:printf

[Macman408]

I used to think the same way about kernel panics in an operating system - I thought there was no reason why the system should ever halt. And then I had an OS class, where it was pointed out that halting is a quite valid choice when encountering an error condition that indicates that something has gone fundamentally wrong. For example, if you have an allocation bitmap that tells you what parts of your disk is in use, and what parts are free, it has a checksum, and the checksum is incorrect. It may very well be that the safest thing to do in this case is halt, rather than risk a write making it to the disk and overwriting a block that is in use. The user can reboot, and that will probably be the best way to recover from the error. It might be possible to display an error message, however since the code to display such a message is not often used, it's likely still on the disk (it was either never loaded, or was loaded and then swapped out of RAM). So you might think it's safe to try to read the disk still - but you have to set some state somewhere saying that under no circumstances should you write anything while you try to load this code. But what's to say that whatever state you set is working? Obviously something is broken, your checksum was wrong! And for that matter, if you need to swap something else out to load this new code in, you can't, because you've decided that writes are now unsafe. For that matter, maybe the disk is acting up - maybe it'll interpret a read command as a write, or take some other completely bogus action. Or maybe what you think is your memory-mapped disk is now really the network card, because some CPU configuration registers picked up a bad value. Bottom line; there are definitely good reasons to just stop a program, OS, or whatever when you detect an error that should never happen.

That said, this case is not one of those good reasons.

Re:printf

[I kan Spl]

File:/// in the "open location" command in Finder does crash on my Mac 10.8.2

The same also causes a crash in Safari, but only if you type (paste) it fast enough so that autocorrect does not suggest something before you are done typing.

Re:printf

[Too Much Noise]

Programmer stupidity (or rather inattentiveness) is not limited to debug code, so why limit asserts to it?

Because on failure assert() calls abort(), which is a good behavior if you're debugging code but is unacceptable for code shipped out to customers.[*] And the reason is, if you know you might have unexpected input there are other tools to approach it in release mode: if, switch, exceptions, your own custom macros and so on. Assert is for code that has to evaluate to true, otherwise it's a programming error (for a beginner example, bounds checking for array access). If you're using it for release code it's a programmer error, and if it triggers in release code it means you have an inattentive programmer, a testing problem and a design error. And if it happens in a system library that's used by most programs in your OS ...

[*] Image for a moment that you had patched up apache to assert() whether an URL/URI is valid or not, same as here but web-facing Your webserver's uptime would be measured in seconds.

Re:printf

[BasilBrush]

The user never types in a null terminated string.

Bad assumption. You might not intend for the user to type in a null terminated string. But that doesn't mean he can't or won't - depending on the platform. Either because the platform doesn't filter out the ctrl-shift-2 combination, because it's being pasted in, or because it's being piped in.

Classic.

Re:printf

[BasilBrush]

Being a programmer is no great claim here. It's almost expected.

And no, it's certainly not a sign of lazy programming. It's the sign of a bug. Everyone creates bugs, not just lazy programmers. And unit testing doesn't approach covering every eventuality. At best it covers easily predicted bugs and regressions.

Re:printf

[BasilBrush]

I have also had the impression that assert() is a hack that shouldn't be used much (?).

It should be used rather a lot. Every time you believe you know something will always be true, but might break if it wasn't, you should put an assert there.

There's no point putting an IF there, because you can't forsee the case where it will be taken. Likewise an exception - exceptions are for foreseen error states. And ignoring it will result in a harder to find bug if that belief is ever wrong.

It's pretty rare when the bug exists in the assert, rather than the main code. Rarer still when it's an assert that is active in release builds. This is one of those cases. But it doesn't mean that asserts are a bad thing.

Re:printf

[rve]

I have also had the impression that assert() is a hack that shouldn't be used much (?).

It's a hack that should be used extensively - in development code. In the production build, you generally turn on a compiler flag that prevents asserts from being compiled. This is why it's absolutely criminal to put code in an assert that has any side effects whatsoever.

Re:printf

[BasilBrush]

Totally and completely fucking wrong. A well written program should not crash for any reason.

All reasonable length programs have bugs. It's a fact of life.

It should alert the user and allow new input or fail gracefully, not suddenly crash. Asserts should always be compiled out in release code, and cause premature return from the function with an error code or reasonable default, it should NEVER crash on release.

There is no absolute rule on this. It depends on your local coding standards and it depends on the language and platform you're using. There's lots of well written software with release build asserts in it.

Crashing on an assert isn't the worst thing a program can do. Crashing on something that's not an assert is worse, because you don't get the helpful log error that pinpoints the cause. And causing data corruption is far worse still.

Re:printf

[BasilBrush]

That's only one of it's purposes.

It's general purpose is to give physical form to assumptions in the program itself. It both assures that the assumption *is* always correct past that point, and it documents it.

A novice programmer might say, don't make assumptions. But real programmers make reasonable assumptions all the time. For example if you've just written code to calculate an count, and that calculation can't make a number that's zero or less, then that's a valid assert.

Re:printf

[BasilBrush]

Then instead of an assert you should have a return error (or throw exception) statement.

No. Those can only ever be for foreseen error states. If they are not foreseen, then they are no documentable, and therefore the calling code can take no sensible action to react to the error or exception.

An assert is a documentation of something that's always true and will never fail. If it fails, that's a bug, and there's no graceful handling of bugs - if you could foresee them, you would have already fixed them.

The question is whether to only have them in debug builds or whether to have them in release builds too. Contrary to your ASSERTION, asserts aren't necessarily compiled out of release builds. The answer is they go in release builds too if the worst case scenario is data corruption from continuing in an unpredictable state.

None of this is in Programming 101. This is stuff you learn when you've been programming a long time.

Re:printf

[BasilBrush]

Not if the worst case scenario of the assertion not being true is data corruption.

Re:printf

[BasilBrush]

Because on failure assert() calls abort(), which is a good behavior if you're debugging code but is unacceptable for code shipped out to customers.[*]

There are several categories in which it's not only acceptable, it's the best thing you can do. e.g. High security issues, data corruption, or other user harm. Look it up in Code Complete for example.

there are other tools to approach it in release mode: if, switch, exceptions

No. Those can only deal with foreseen errors. They can't deal with unforeseen errors.

[*] Image for a moment that you had patched up apache to assert() whether an URL/URI is valid or not, same as here but web-facing Your webserver's uptime would be measured in seconds.

Checking for a valid URL is a foreseen error, and so shouldn't be an assert. It can be handled reasonably because we've predicted it. That doesn't mean that valid uses for asserts in release code don't exist.

Re:printf

[BasilBrush]

Have you heard of Code Complete? If you're a programmer, you probably should have read it. You should probably have a copy in your bookcase. Go read what it has to say in it's section on Assertions before you post any more ill-informed comments on this thread.

Re:printf

[smash]

If it it an assert thats the entire point. You can't trust the data in ram, you can't trust any file handles you have open, you can't trust anything. So no you should NOT be writing to disk in that situation. The only safe thing to do is terminate.

Re:printf

[smash]

Your apache example is bogus. This is terminating because the program hit a state where data is invalid in a way that the code does not know how to handle. Apache could just throw an error. Yes this is a bug and the code SHOULD handle it. But it doesn't. So the only safe thing to do is terminate because "something is wrong" - we don't know what, and it could be catastrophic for all we know. Continuing to run is dangerous from this point...

Re: printf

[Too Much Noise]

Sure Sparky, you can certainly have unforseen errors. You send a rover to Mars, and the whole computing system is bombarded with high energy radiation in much larger doses than here. Chances of having a bit flipped in a constant go up a bit (depending on your hardware mitigation measures). The problem is, when does it happen? Was your assert too late and damage is already done? Does it happen immediately after your assert? Heck you're only testing one place in a cached hierarchy, what if it's already inconsistent in other places?

There are ways to mitigate depending on how important your whole setup is. Of course aborting is an acceptable way, but only when things are so bad that context no longer matters. There are severity levels on errors and the vast majority should not abort. This case is especially egregious as it is a shared library doing input validation and asserting on unexpected input (ignoring for a moment that the input is valid per standard). This is the last thing you want to do in this case - scratch that, it's not even the last thing. The apache example I gave above, doing THE SAME MISTAKE but web facing, is a DOS waiting to happen. If you think that is fine, please let me know where you have worked in the last 10 years so I can blacklist those vendors.

Re:printf

[smash]

Of course it is better more return an error - if the programmer has put logic in to handle the situation. However this logic is mixing or broken and the only safe thing to do for the program at is point in the absence of such logic is to terminate. This is a bug, yes. However terminating at this point rather than continuing to attempt to process data that is an unexpected state it extremely dangerous as far as security goes. This is actually good programming practice. Bug happen. Terminating like this prevents them from being exploitable.

Re:printf

[smash]

Gah. Autocorrect. Typing on a tablet with 3G because power is out :-/

Re:printf

[smash]

Crashing/teminating before you are exploited is acceptable, nay - preferable. Fucking amateur.

Re:printf

[chrismcb]

It may not be "debugging code" but it should only be run in your debug build.
In your release build, it should either do something else (like say, phone home), or do nothing at all.

Re:printf

[smash]

Should yes. But if your input validation code has an error (as this does), the safest thing you can do is terminate. The input validation failed. Yes, it should have caught this. No it didn't and rather than continue on, the only safe thing the app can do is terminate.

Re:printf

[ebcdic]

However, in this case the only bug is in the assert() call itself. It didn't catch a mistake, it was one.

Re:printf

[aled]

it is, if the alternative is irrecuperable data corruption.

Re:printf

[edxwelch]

I don't know anything about Mac development build, but on Windows assert() is automatically removed in the release build (that's how assert is ment to work). So, looks more like a broken release build setup, than some one forgetting something.

Re:printf

[ebcdic]

A program can't necessarily fail gracefully. An assertion failing means that something has already gone wrong; perhaps data structures are corrupted and continuing might result in worse damage: writing wrong data, deleting the wrong file. Returning to the caller is not necessarily safer than exiting.

Re:printf

[Bomazi]

assert() doesn't work at compile time anyway.

By runtime error I mean something like an input validation error, an out of memory error, a disk full situation, etc... Basically something that might or might not happen, depending of what happens outside the program during execution.

This is in contrast with a programming error, which could be said to exist before the program starts, and which always happens (when the relevant code runs).

For example, malloc() returning null is a runtime error. Passing a null pointer to a function that doesn't expect it because you forgot to set it, is not. assert() would be an appropriate way to catch the second error, not the first.

Re:printf

[Bomazi]

assert() causes a *deliberate* termination, in the sense that the programmer explicitly intends the program to terminate at that point if the assertion fails.

This contrast with an unintended termination, as caused by something like a SIGSEGV.

assert() doesn't *gracefully* terminate, as exit() would, but that is a separate issue. And it is done that way because the state of the program can no longer be trusted at that point. Of course you might want to have more granularity than just assert() and exit(), but you need something that can do an "emergency stop" in some cases.

Re:printf

[shutdown -p now]

You don't have to define NDEBUG in release builds, and many people don't.

Also, assert in the C standard library is not the only way to do an assert. You can have your own macro that does things differently. The only thing that all asserts have in common is that they are designed to assert that a certain expression is always true on this particular code path, and indicate a design flaw in the code if they ever fail.

Re:printf

[Hal_Porter]

I like C, but the problem is that most programmers cause chaos when they write it. C was always meant as a language that people who like assembler will like and use and be more productive. It was not meant as a language that today's script monkeys should use.

Also Objective C was designed according to the prinicples of Objectivism - i.e. the code of the looters and moochers would crash and burn and bankrupt their companies whereas the code of Great Men would navigate the formidable obstacles of pointers and demonstrate their status as Nietzschean Ubermenschen and be rewarded with tonnes of cash and Patricia Neal, so this is not really surprising.

Re:printf

[nitehawk214]

What is funnier that file:/// doesn't work.

The Captil F is required. at least in my limited testing.

Typing 'file:///' opened Finder.app from Safari's address bar just fine on my machine.

In this case when GP says "doesn't work" he really means "does work", or rather, "doesn't crash".

Re:printf

[shutdown -p now]

This is terminated because the program did not expect to see an URI with such capitalization, and (presumably) doesn't have code to handle it correctly - leading to an unexpected state where you can no longer be certain of the data. It indicates a bug (they forgot to handle different capitalization correctly, and they forgot to do proper user input validation), yes. But the way it handles that program bug, until such time as it's fixed, is absolutely correct.

Re:printf

[shutdown -p now]

In your release build, it should never be hit. But unless you can absolutely guarantee it, leave it there. You will make mistakes, and it's better to handle them in a safer manner.

If it's hit, your program is in a state that you have not foreseen when writing it. If you're using assert for its intended purpose, then you're claiming: "I expect this condition to always be true here; the following code is written with this assumption in mind". If the condition is somehow not true, then the following code is a bug/exploit farm, and should not be allowed to run. You might also want to phone home, yes (though e.g. on Windows, WER will do it for you if you register for it). You definitely don't want to do nothing.

Re:printf

[AuMatar]

Then his string terminates sooner than the data stream he types. Which won't break anything. The key is you don't rely on the user to enter the terminating null, just like you don't rely on them to enter a length field.

Re:printf

[Jappus]

Based on what you said, the summary title is incorrect. The programs aren't crashing, but rather are ending normally, just not when the user thinks they're telling it to.

It is easy to argue that while this is technically a "normal" shutdown given the code of the program; it is certainly not a normal shutdown given the task and role of the program.

You know: Letter of the law versus spirit of the law.

Your program can only execute the letter of the law (its code), but its true purpose should always be the spirit (its intended role). Otherwise, any bug inside the program would need to be considered as a "normal program exit", as the bug is an inevitable result of its code. Since that is obviously not the case:

This assert being thrown IS a bug, and the subsequent application exit not a normal shutdown. There is nothing to defend here as being "good".

Re:printf

[SanitaryFather]

Cool! Great way to restart apps, no more clicking those pesky little x's.

Re:printf

[macsoft]

Here speaketh the Apple hater. Its bad because you can crash it if you type something you would never type anyway? "type" Ctrl+Alt+Del on your Windows machine, it will "crash" much worst.

Re:printf

[ScriptedReplay]

That doesn't mean that valid uses for asserts in release code don't exist.

There are no valid cases for assert() in release code. It's about as uninformative as it gets for that. If you really need thosue checks done, put an actual check in place - you know, something that will log/tell you useful information like what invalid value was encountered versus what was expected, a stack trace, and so on. Not just printing out __FILE__ and __LINE__ and expect what, that the customer will have a debugger already attached to the process to pick up the rest of the info a developer would need?

assert() is a debug macro. If you need to test release code then use/write something appropriate for release. Especially something that does not abort() when returning an error code would be sufficient.

Re:printf

[Fulkkari]

Just adding my 2 cents. I agree with you that crashing is never acceptable (as in you have something broken), but a forced exit out of the program through an assertion is the most sane thing to do when the error handling has failed and you have an inconsistent state. The best choice of bad ones so to speak. You should not continue hoping things will turn out good (imagine you were talking about a life critical system), but just exit and avoid further damage and restart the program. You might of course be able to write code to take you out of the situation and fix itself, but that is not assertions then, it is error handling.

Re:printf

[GoogleShill]

You should know that the 'return' statement is exactly what jumps to the shellcode in a stack-based buffer overflow exploit. Asserting and crashing is far more secure than calling 'return' from a potentially corrupted stack.

Re:printf

[niftymitch]

I assert() your assert is bogus. Bogus asserts are brutal and all too common.

Still I also assert() asserts are under used.

Re:printf

[viperidaenz]

When an input does not conform to your method/function/class/procedure's contract, your throw an exception or some other specified error condition in said contract.

You don't blindly swallow it and assume you know the intention of the callers.

Doing anything undocumented will result in subtle errors that manifest themselves in other parts of the system because you're not doing what you said you were going to do.

Re:printf

[viperidaenz]

You don't remove your debugging code. You do what the man page you pasted says - you disable assertions as a compile option. Otherwise next time you do a change, those assertions your removed won't be raised during testing and bugs will slip through.

The only reason to remove assertions in the first place though, is for performance.
The first rule of performance tuning is if a benchmark doesn't show an improvement, don't do it. Easier to read, test and maintain code is more important then a zero gain in performance.

Re:printf

[normangray]

That example is a WRONG use of assert -- you're using assert() as a poor-man's exception.

The right way to code that is

if (foo == null) { // bad state
    return some_error_value;
}
assert(foo != null); // do something which presumes that foo is not null...

Writing an assert in your code is the statement that you have examined your code and believe you have proved that it is _impossible_ under any circumstances, for the assertion to be false -- not bad user input, not a bad call from client code, there are no possible bad conditions you haven't already handled, nothing.

Thus if an assertion evaluates to false, the impossible has just happened. Black is white, gravity points upwards, your computer is an iguana. Your program has (in effect) already crashed, but the world hasn't noticed yet.

So, what do _you_ want to do at this exciting point, in production code? Just carry on with your fingers crossed and see what happens next?

Re:printf

[Hognoxious]

Not when all you're doing is highlighting things that look vaguely like phone numbers or URLs or names of Roman emperors or whatever so some hipster can do something pretentious and useless with one click.

You fucking silently ignore it.

Re:printf

[frisket]

Exactly. And what kind of dickhead types File:/// with a capital F?

I would have been more impressed if the error had been for the right reason: the file:/// URI is essentially a request for an ls -l / which is something the end user probably shouldn't get without authenticating.

Re:printf

[mug funky]

i hope i never need to use a program you've worked on.

Re: printf

[BasilBrush]

The problem is, when does it happen? Was your assert too late and damage is already done? Does it happen immediately after your assert? Heck you're only testing one place in a cached hierarchy, what if it's already inconsistent in other places?

You want a system to localise the error? Look up design by contract, and pre and post conditions. It's all there.

Of course aborting is an acceptable way, but only when things are so bad that context no longer matters. There are severity levels on errors and the vast majority should not abort.

Correct. Lots of reasons for aborting in debug builds, a few reasons for aborting in release builds.

This case is especially egregious as it is a shared library doing input validation and asserting on unexpected input (ignoring for a moment that the input is valid per standard). This is the last thing you want to do in this case - scratch that, it's not even the last thing. The apache example I gave above, doing THE SAME MISTAKE but web facing, is a DOS waiting to happen.

Also correct. No one is trying to defend the assert involved in this particular defect, not asserts in general to validate user input. Real my posts, you'll not see any such thing. At this stage the discussion is about whether there is any place for asserts in release builds. You said there wasn't in your previous post. You have now seen the light and accepted that there is.

Sure Sparky... If you think that is fine, please let me know where you have worked in the last 10 years so I can blacklist those vendors.

You're trying and failing to patronise. I've not been programming for just 10 years, I've been programming since 1979. I do know what I'm talking about. I made a point about asserts having a place in release builds. You tried arguing something else that I didn't say, and in the process you actually accepted my point.

Re:printf

[exomondo]

All reasonable length programs have bugs. It's a fact of life.

But /. always brings out these god-like programmers, they write perfect, bugfree, secure, invulnerable code...of course they never say what this code is or who they are, but they're anonymous people on the internet, why wouldn't you take their word for it?

Re:printf

[BasilBrush]

Then his string terminates sooner than the data stream he types. Which won't break anything.

Another bad assumption. Tricks like these are often used in exploits.

Re: printf

[Too Much Noise]

You want a system to localise the error? Look up design by contract, and pre and post conditions. It's all there.

And you bring this up to justify assert()ing ... fun stuff. Aside from the fact that it's completely irrelevant to the example i gave - which was intentionally far-corner case in that it had a high enough probability of hardware errors, where neither asserts nor design by contract solve anything (the correct answer would have been fault-tolerant computing at hardware level). I'll concede that mine was a poor example, but it did have the redeeming quality of generating an amusing reply.

I made a point about asserts having a place in release builds. You tried arguing something else that I didn't say, and in the process you actually accepted my point.

Sorry, no. Go back and re-read. I said aborting has places in release builds. Using assert for that is just a lazy man's solution. You're just doing if(...) then abort(), with some extra printout of where it aborted with no useful context as to why and how it got there. That's not going to help a developer understand what happened, especially since it's likely a context that occurred in production but not in testing. Ignoring the fact that one release manager later the compile flags might have an extra -DNDEBUG and your 'checks' vanished. Feel free to stick to it, but it still makes for bad programming practice. I would advise writing a different piece of checking code that provides more information and has more flexibility in dealing with the error than shutting everything up.

I've not been programming for just 10 years, I've been programming since 1979.

Good for you. I however only want to avoid installing software that i would need now and was produced following dubious coding standards, so that means reasonably recent and 10 years should cover it. Sadly, it's an impossible task in absolute terms, but every little bit helps.

Re:printf

[RaceProUK]

Did you write the code in question? No? Then you have no idea what the internal state is.

Re:printf

[RaceProUK]

I've read a number of posts here confirming that this caused various browsers to crash, but I still see several people here insisting that the entire premise is false and that there it hasn't caused any crashes. Are these Crash Truthers just playing a game of picky wording, or are the programs in question actually working properly?

Most of the argument is about crash vs immediate termination. An assert failure generally triggers the latter. From a user POV though, they're identical.

Re:printf

[YodasEvilTwin]

If it wasn't foreseen there wouldn't be an assert. If asserts were placed everywhere something unforeseen could happen then they would be, well, everywhere.

Re:printf

[BasilBrush]

If it wasn't foreseen there wouldn't be an assert.

That's not true at all. In fact it's the opposite of the truth. Asserts go wherever there is an assumption of an invariant. They don't go where you can foresee that something might not be invariant.

If asserts were placed everywhere something unforeseen could happen then they would be, well, everywhere.

They can indeed be very frequent. It depends. If you want a methodology for it, look at programming by contract. That would limit you to putting asserts on pre-conditions and post-conditions of routines.

Apple's response

[Anonymous Coward]

You're doing it wrong.

no big deal.

Steve

Re:Apple's response

[radiumsoup]

damnit, I just ran out of mod points, too... +infinity for you.

Re:Apple's response

[girlintraining]

Steve is in the iCloud now. Someone tried turning him off and then back on again. In an appeal to hipsters, he's gone underground to sell more macs. He is permanently 404. There is no way he could have had anything to say about this. There is no app for that. Get it? :P

Re:Apple's response

[dugancent]

My response:

Steve is dead and has been for over a year. Time for some new jokes.

Re:Apple's response

[Drgnkght]

The humour is just pining for the fjords.

Re:Apple's response

[node 3]

Maybe they'd be less hostile if you stopped calling them "fanbois"?

Re:Apple's response

[jrumney]

Indeed, they already released a fix for it. It's called iCloud. Keeping things in the privacy of your own disk is now officially a bug (soon to be reclassified as user error).

BRB

[AmiMoJo]

BRB, heading down to the Apple Store...

Re:BRB

[drcagn]

Typing the string has the same effect on the app as quitting the app. So.... have fun going to the apple store and quitting the apps.

Re: BRB

[rsmith84]

Not without a Genius Bar appointment you're not!

Re:BRB

[Anonymous Coward]

I wish I knew how to quit you.

Re:BRB

[drcagn]

I know, I can be dangerously addictive sometimes.

Re:BRB

[Tablizer]

heading down to the Apple Store...

Reminds me when I was teen at the mall before the PC era, I'd see a computer on display in the store and type in:

10 PRINT "RUN, COMPUTER WILL EXPLODE!"
20 GOTO 10
RUN

Re:BRB

[YttriumOxide]

Typing the string has the same effect on the app as quitting the app. So.... have fun going to the apple store and quitting the apps.

Exact behaviour seems to depend on the app. Just tried it here and:

TextEdit: Prints the final /, hangs for a long time, then shows "quit unexpectedly" dialog
Safari (text box on webpage): Does not print the final /, hangs the tab indefinitely, tries to allow continued usage of Safari (in other tabs), but data won't load, and already open tabs when scrolled contain large "grey" spaces instead of further content.
Safari (address bar): Prints the final /, hangs for a short time, then shows "quit unexpectedly".
Notes (content of note): Prints the final /, hangs for a long time, then shows "quit unexpectedly" dialog
Notes (name of new note): Prints the final /, hangs for a very short time, then shows "quit unexpectedly" dialog
Preview (search field): Prints the final /, hangs for a very short time, then shows "quit unexpectedly" dialog

I assume the "Prints the final /, hangs for a very short time, then shows "quit unexpectedly" dialog" behaviour is the "immediate quit" of the assertion failure, however things like Safari's behaviour are clearly a process within the app terminating without the app itself being terminated.

Re:BRB

[AmiMoJo]

It produces a nice exception error message. Perfect for making Apple fanbois who claim that Macs never crash look like twats.

Re:BRB

[AmiMoJo]

Back at school when I was about 10 we argued for weeks over the meaning of an "illegal operation" error message, and if the poor child who was using the computer at the time was going to jail.

Re:BRB

[caseih]

No it doesn't. Applications crash all the time in OS X, Windows, and Linux. No fanboi will claim otherwise unless he's really stupid. And that has nothing to do with Macs never crashing or Linux never crashing. In fact a system crash in MaOS *is* very rare. Certainly much rarer than it was in Windows XP, which was the dominant OS when MacOS came to be and the Mac fanbois got all excited over it. Now I think even the most diehard fanbois have to admit now that Windows is pretty darn stable.

Android, now that's another story, though in Android's case it's not the OS crashing either, it's the Android environment triggering a reboot when it freezes, which irritates me to no end. Why can't Android just restart the environment? Why does it have to reboot Linux kernel?

Re:BRB

[ahabswhale]

It's the app that crashes, not the OS but lets not let facts get in the way...

Powerpoint summary of TFS

[TapeCutter]

- An obscure library bug triggered by a magic string.

- In the latest version.

Re:Powerpoint summary of TFS

[jonadab]

> An obscure library bug triggered by a magic string.

The thing is, the magic string in question is not particularly obscure. Any app that normally handles URLs is fairly likely to get that typed into it at some point. Okay, granted, protocols are usually not capitalized, and File:/// is no more common than Http:// or Mailto:, but nonetheless, this is something people are definitely going to run into occasionally.

(Yes, file protocol terminates the protocol with just two slashes; but, importantly, the next segment of the URL is an absolute path. So while the third slash would be a typo on a multi-rooted system like Windows or VMS, it's pretty much mandatory on a single-rooted system that uses slash as a directory separator -- like, say, anything with Unix underpinnings.)

Re:Powerpoint summary of TFS

[oakgrove]

Just a thought, using something like vnc from a mobile device would make it more likely to happen since keyboards on most smartphones/tablets capitalize the first letter in anything it thinks is a sentence.

Re:Powerpoint summary of TFS

[BasilBrush]

but nonetheless, this is something people are definitely going to run into occasionally.

Looks like a very embarrassing bug to me. But it's taken 6 months for anyone to spot it. So, surprising though it may seem, the chances of any one individual ever getting it accidentally are slim.

(Intriguingly the third slash it not necessary. Typing random letters after 2 slashes also tends to crash it. It just takes a few more. It'll be interesting to get the diagnosis of exactly what's going on here.)

Re:Powerpoint summary of TFS

[DarwinSurvivor]

I'm actually curious if clicking a link to File:/// will crash one. Any mac users want to try it and (after possibly restarting their browser) report the results? Note: slashdot changes File to file, so you might have to try a local html file.

Re:Powerpoint summary of TFS

[adolf]

Actually, the third slash means "this computer" and is required on Windows too. You have to write "file:///C:/..." on Windows to get anywhere. So no, it isn't a typo.

[citation needed]

On my computer (Windows 7), in Windows Explorer, these all work the same:

file://C:/
file:///C:/
file:////////////////C:/

These also work the same:

file://
file:///
file:////////////////

Re:Powerpoint summary of TFS

[marcansoft]

Clicking a link to a page containing a textbox containing File:/// will. So this is also a remote DoS for Safari.

Re:Powerpoint summary of TFS

[jonadab]

> Actually, the third slash means "this computer"
> and is required on Windows too.

If the third slash meant "this computer", single-rooted systems would require a fourth one to indicate the filesystem root. Such is not the case.

Little light on specifics....

[Kenja]

Tried this in every app I could think of and have had no issues (TextEdit, Komodo, iCal, Eclipse, Libra Office, Chrome, FireFox). Not calling shenanigans, but a specific example would be nice.

Re:Little light on specifics....

[Anonymous Coward]

Are you sure? "file:///" works fine, but "File:///" does not.

It's case-sensitive.

Re:Little light on specifics....

[Kenja]

Ah, did manage to replicate it. Despite what the long article says, it does seem to be case sensitive. Very odd bug. The truly worrisome thing is that this would seem to indicate that even the most basic of text editors is capable of running scripts from plain text (as opposed to apple script). Not sure what the ramifications of that are, but it seems like a potential vector for malware.

Re:Little light on specifics....

[Anonymous Coward]

Case seems to matter. I was able to crash Text Edit, and then the Crash Reporter too.

Re:Little light on specifics....

[Assmasher]

I just crashed it in 10.8.2 by simply typing it (exactly as specified) into the document area in TextEdit.

Re:Little light on specifics....

[93 Escort Wagon]

Interesting - it's fairly reproducible in programs that take a URL, but, unlike what some of you are claiming, it's not crashing anything for me when I type it somewhere else (e.g. In an open document window in BBedit, in the Google search box in Firefox). When I tried it in TextEdit's search box, it (sorta) crashed It... Actually, while it killed the active window, it left the program itself running.

Re:Little light on specifics....

[cheesybagel]

Let me guess. The Google search box in Firefox was not implemented using Apple's Cocoa widget Framework.

Re:Little light on specifics....

[Assmasher]

I was surprised, maybe it's a spellchecker or something - I never use TextEdit but just opened it up, typed in the File:/// and after about 1/4 of a second the window disappeared and I got "TextEdit quit unexpectedly." with the standard Ignore|Report...|Reopen buttons...

Just double checked - same result.

Strange.

Re:Little light on specifics....

[93 Escort Wagon]

Let me guess. The Google search box in Firefox was not implemented using Apple's Cocoa widget Framework.

Yes, of course - but the claim was that simply typing this magic string could crash just about any program in Mountain Lion.

Re:Little light on specifics....

[SilverJets]

Tried this in every app I could think of and have had no issues (TextEdit, Komodo, iCal, Eclipse, Libra Office, Chrome, FireFox). Not calling shenanigans, but a specific example would be nice.

Try typing it into the URL field in Safari.

Re:Little light on specifics....

[Twinbee]

Wouldn't that slow programs down anyway - constantly checking the input like that? How ugly and inefficient.

Re:Little light on specifics....

[Twinbee]

How about if you try pasting it in?

Re:Little light on specifics....

[Alioth]

The set of "just about any program" is smaller than the set of "all programs". So the claim is entirely true. Yes, just about any program will crash if you type the magic string and just because Firefox is outside of the set of "just about any program" doesn't make it any less true. Firefox is somewhat of an oddity by being a Mac app that doesn't use the Apple framework. Most do.

Re:Little light on specifics....

[scarlac]

The bug requires Text Replacements to be enabled. It is enabled by default (but I disabled it because it's annoying). When enabled, I was able to reproduce the bug in iCal and Chrome but not TextEdit (where my default mode is plain text).

Re:Little light on specifics....

[petervandervos]

Tried this in every app I could think of and have had no issues (TextEdit, Komodo, iCal, Eclipse, Libra Office, Chrome, FireFox). Not calling shenanigans, but a specific example would be nice.

Try typing it into the URL field in Safari.

Not only the URL, but also a search field of any (sorry, a lot) of programs will crash the program. Clearly whenever the OS evaluates a string it will crash so URL's, search strings and even when the spellchecker kicks in. I even can not type the string in this Comment field (spellchecker). Also noted that it is not File etc, but any permutation of file with a capital letter in it so File, filE, fILe etc.

You're doing it wrong

[greggman]

No one should ever need to type file:///

There are no bugs. You're doing it wrong

Re:You're doing it wrong

[Anonymous Coward]

The lowercase version doesn't cause a crash, so your claim is irrelevant.

Re:You're doing it wrong

[Vreejack]

That was sarcasm, right?
Anyway, I have twelve examples of file:/// in my browser history, all of them automatically generated by scripts. If I ever meet a script that capitalizes "File" then we may be in trouble.

Re:You're doing it wrong

[sjames]

Maybe he's using a Mac. The first two times he tried that message, Safari crashed.

Re:You're doing it wrong

[Sigg3.net]

Yeah. Two // 's should be enough for anyone.

Sure enough

[DaMattster]

I tried it for myself with Google Chrome and Firefox and File:/// does crash the software. Very interesting!

Re:Sure enough

[BasilBrush]

Even more interesting is that fact it didn't prevent you from making that post.

Re:Sure enough

[SilverJets]

No crash in Firefox for me but it took down Safari.

Re:Sure enough

[StripedCow]

Does it also crash your browser if you click this link?

click here please

Re:Sure enough

[Mex]

Firefox didn't crash for me, for what it's worth. I did type it with a capital F.

I managed to crash a couple other apps I wasn't using, including the Finder, so it's an interesting bug, although kind of silly how the summary blows it up.

Security hole?

[Billly Gates]

THe only difference between a crash and an exploit is one has control when the app leaves the bounds of its ram addresses. Since MacOSX apps have access to file:/// in strings that can leave the control of the app then logic would dictate someone could do a file://sh grep -i .../etc/host cp malware.BAD .../etc/host or something stupid.

I do not own a mac so I do not know. Maybe another slashdoter who owns one who is more intuned with where critical files and services are can try to do execute something with it?

Either way this is not good at all and poor exception handling of some of the string apis.

Re:Security hole?

[pushing-robot]

It's not a buffer overflow or anything like that. Some address-reading library happens to have a sanity test that makes a naive assumption; when it catches a file URL, it tests the prefix against the string 'file://'. When the strings don't match (because of a simple case difference) the sanity test fails and the program is shut down. Oops.

It *is* a dumb bug (aren't they all?), but I doubt it could anyone could make a remote code exploit out of that.

Re:Security hole?

[John Hasler]

> I doubt it could anyone could make a remote code exploit
> out of that.

Perhaps not that precisely but what else is that library call (or whatever it is) doing that might be exploitable?

Re:Security hole?

[Your.Master]

Possibly anything, but I don't think this assert is indicative of it doing anything else that might be exploitable. If anything, the overactive assert makes it less exploitable.

The one thing I can think of, is if this assert was in a function that shouldn't have been called at all, so this tips off black-hats into seeing that an exploitable codepath is being taken in a situation where it shouldn't have been taken in the first place.

But I'm guessing it's not doing anything with this string, just doing some kind of type-detection and then exploding, so there wouldn't be any indication of anything exploitable.

Re:Security hole?

[Billly Gates]

What type detection would accept a file:/// for the argument?

It makes me wonder what other arguments are there and the most important question, why can you even do this?!

If I had a Mac I would do some dictionary terms in a script to see what happens. It probes my curiosity.

Re:Security hole?

[Megane]

What type detection would accept a file:/// for the argument?

The type that says "Ooh this looks like a URL, let me change it into a pretty underlined blue for you!"

It Works

[presspass]

I've tested it in several native apps, (Reminders, Textedit, Preview) and in Adobe Acrobat Pro 9.

Find a text input field, even in preferences and it crashes. Bizarre!

OSX 10.8.2
Build 12C3103

Re:It Works

[Anonymous Psychopath]

Spotlight, too.

So?

[Bogtha]

First off, itâ(TM)s worth noting that the bug only appears to be present in OS X Mountain Lion and is not reproducible in Lion or Snow Leopard. Thatâ(TM)s not exactly good news given that this is the latest release of Appleâ(TM)s operating system, which an increasing number of Mac users are switching to.

Talk about over-egging the pudding. You're talking as if it's a fundamental flaw that ruins the whole operating system. It's a bug. Of course it's not good news, but it's not certain doom for Mountain Lion either.

Re:So?

[93 Escort Wagon]

Speak for yourself - I just rolled back to Tiger!

Re:So?

[VortexCortex]

First off, itâ(TM)s worth noting that the bug only appears to be present in OS X Mountain Lion and is not reproducible in Lion or Snow Leopard. Thatâ(TM)s not exactly good news given that this is the latest release of Appleâ(TM)s operating system, which an increasing number of Mac users are switching to.

Talk about over-egging the pudding. You're talking as if it's a fundamental flaw that ruins the whole operating system. It's a bug. Of course it's not good news, but it's not certain doom for Mountain Lion either.

Oh yeah? Well, this link says otherwise.

it would if slashdot wasn't lowercasing the protocol, but you get the point.

Now, to use some JavaScript or HTTP Redirects to auto-load that URL, and have some REAL fun.

The cause, and a fix

[rsteele19]

Landon Fuller has posted a gist on GitHub with an explanation of the bug and a binary patch to the affected library.

Re:The cause, and a fix

[93 Escort Wagon]

Landon Fuller has posted a gist on GitHub with an explanation of the bug and a binary patch to the affected library.

Yeah, THERE'S a good idea - apply a binary patch from some random post on Slashdot!

Re:The cause, and a fix

[EmperorArthur]

Thanks for the advice, too bad I'm going to ignore it.

I'm going to go out and buy a mac, and then I'm going to find the software with this bug, then I'm going to follow the directions that straight up say not to do so.

On a more serious note, It's always nice to see someone find the problem, and offer a workaround.

I've never heard of data detectors before. It's an interesting idea but also scary. I'm a big fan of sandboxing, so I seriously hope that this is just some function in a library and the OS isn't pawing over every text box.

Re:The cause, and a fix

[Tablizer]

Whaddya mean? It fixed my Goatse screensaver just dandy.

Re:The cause, and a fix

[phantomfive]

You can read the patch first, like the rest of us, right?

Re:The cause, and a fix

[toddestan]

What are you talking about? It's for Macs, and Macs don't get viruses!

Re:The cause, and a fix

[aquabat]

Landon Fuller has posted a gist on GitHub with an explanation of the bug and a binary patch to the affected library.

^this. The bug is in the assert() statement itself, not in the program logic. Assuming that input validation code exists and was already run before this point, the purpose of this assert() seems to be to make sure the validator is actually doing its job properly. However, the test in the assert() itself is incorrect, since it disallows mixed case file URLs, which are valid, according to spec. Of course, if this assert() statement is his validator, then he's doing it wrong. Big time.

Re:Running Mountain Lion....

[Raistlin77]

It kills Chrome if typed into the address bar and it kills Finder and iTunes if typed into the search. It is case sensitive - File:///

Not happening for me

[shatfield]

Running OS X 10.8.2 here, and I tried it in TextEdit, Mail, and Safari.. no crash.

Re:Not happening for me

[Assmasher]

Running 10.8.2 here also and it crashes in TextEdit when simply typing the text into the document - LOL!

Re:Not happening for me

[shatfield]

Just to be sure, I type file:/// into TextEdit or a new Mail message or whatever and it's supposed to crash?

Re:Not happening for me

[tepples]

It is if any of the four letters is capitalized.

Re:Not happening for me

[shatfield]

Ah yes, caps is da bomb ;-)

Ok, now I feel like I'm part of the in crowd again LOL

Re:Not happening for me

[Assmasher]

Not file:/// you must type File:/// and it vanishes with a crash dialog for me.

I literally just run TextEdit and type File:/// and 1/4 second later it vanishes and I get the "quit unexpectedly" dialog ;).

Must be a spell check/URL converter (like Word/Outlook does.)

BTW, crashes Notes when you put it in the search box, but not in the note text area.

Re:Not happening for me

[blackraven14250]

No. It needs to be File:/// or fILe:/// or any other weird capitalization.

Re:How often does a Mac user type this?

[jonadab]

> rarely would a Mac user have to type File:///

I admit, it is a bit odd to see it capitalized like that.

> (wait, I typed File:/// and it did not crash Firefox).

It probably has to be at the very beginning of a text-entry field.

(I'm just guessing, based on what "file:///" means. I can't test this one myself, as I don't have a Mac here, and the Mac I have access to at work is running Snow Leopard.)

Gödel Lives!

[Sam Williams]

http://kleinschmidt.wordpress.com/2006/07/03/i-cannot-be-played-on-record-player-x/

Re:No, It Doesn't

[H0p313ss]

Crashes textedit

Similar feature in Windows

[clickety6]

We have some text files from a Unix system named aux.something Trying to copy them or open them in Windows causes the whole system to grind to a halt.

Re:Similar feature in Windows

[tragedy]

This is probably because of windows problems with old DOS devices: AUX, CON, PRN, COM1, LPT1 Using them in file names can cause all kinds of weird Windows issues even now. There used to be a spectacular Windows issue that affected just about any program that could interpret a URL. URLs containing a combination of the above device names separated by backslashes (or slashes) could cause a windows machine to crash or hang if the machine tried to parse a URL. Naturally, people would send other people links in e-mail and instant messaging programs with such URLs which would, depending on the program, cause a freeze or bluescreen on clicking, or even just on receipt. Sigh. Good times. Good times. I think there are still a few instant messaging programs that will mysteriously edit out anything you try to send with any of those combinations of letters in combination with a slash, even if it's not a combination that would cause a crash. DragonCon/NASFiC, for example, might do it.

It works

[spire3661]

Confirmed personally. OSX 10.8.2, 2011 mac mini. Entered the text into the search box in finder, crashed. It recovered fully in about 30 seconds though.

Re:No, It Doesn't

[Anonymous Coward]

The bug is case sensitive; as the bug report says "The capital 'F' is important."

Please do not bother posting something so quickly, without looking into it.

Let's look at the stack trace

[MrEricSir]

This is the stack trace mentioned in the article:
http://pastebin.com/UkhERvaA

Doesn't look like a c-string or printf issue to me at all.

Re:Let's look at the stack trace

[Hal_Porter]

They should comment out the call to DDCrash. As its name suggests that often causes problems

X-Sarcasm : This post is sarcasm.

Doesn't crash Terminal

[PDG]

Tried it, capitals and all, no crash

Re:Doesn't crash Terminal

[Anonymous Coward]

No spell check in terminal, which is a part of this bug.

Re:No, It Doesn't

[HJED]

It's case sensitive.

Re:No, It Doesn't

[scream at the sky]

correct, It crashed Chrome, Safari, itunes and text edit on my MBP w/ ML, but the F does have to be capitalized.

Even crashes the crash reporter!

[Wormholio]

I tried this in Safari on Lion. Capital F required, but indeed just "File:/// " crashes it.
Then you get a pop-up asking if you want to report the problem to Apple? Sure.
But then that crashes with a pop-up reporting that crash reporter has crashed. Bonus!

Re:Even crashes the crash reporter!

[EmperorArthur]

Nice, it's an error large enough to prevent it from being auto reported, yet went quite a while before people noticed it.

Re:Even crashes the crash reporter!

[fnj]

Funnier than hell. In fact it's positively precious. I wonder where that shared library is actually trying to branch to when it happens.

Re:Even crashes the crash reporter!

[whoop]

To Apple's credit, they have received 0 reports from users of this crash. So, it can't be that important, right?

It's the old Windows 98 bug all over again.

[Dwedit]

You used to be able to BSOD a Windows 95 or 98 machine by trying to read C:\con\con, and this included any web pages that requested file://C:/con/con.

So, how can I type it for them?

[rduke15]

No one should ever need to type file:///
There are no bugs. You're doing it wrong

Yes, they are doing it wrong, by typing file:/// in lowercase, or not typing it at all. So the obvious question is: "how can I type it right for them?" If I include "File:///" in an email I send to a Mountain Lion user, will it crash his Mail.app? Or if someone quotes it in a reply here?

That could become a cool little meme.

Re:So, how can I type it for them?

[retchdog]

it's triggered by the spellchecker (roughly speaking, actually a bit more detailed), so it has to be in a text input field, and further the cursor has to be in the string (or something similar).

even replying to an email with quoting won't trigger the bug unless you edit the "File:///" string. a string which i just entered with chrome on an affected mac to no ill effect, btw.

it's an embarrassing bug, but not easily exploitable (though i'm sure someone will find some corner case).

Re:So, how can I type it for them?

[cheesybagel]

"not easily exploitable"? How about inserting it in a text input form and opening it in Safari?

Re:So, how can I type it for them?

[cheesybagel]

File:/// Or whatever.

Re:So, how can I type it for them?

[retchdog]

okay, fine. it won't do anything unless the victim clicks on the entry field. if they do, you've ... crashed their web browser. not the hack of the century, and the victim won't do it again.

sorry, i just don't see how this would be a problem. most websites don't want to crash their visitors' web browsers. i guess you can use it in a shock site, but hell, last measure (link mostly safe) was more annoying than this could be, and that didn't even exploit a bug.

Re:So, how can I type it for them?

[SuperKendall]

That gets you closer but the user still has to enter the textarea.

Re:So, how can I type it for them?

[tbird81]

When you crash, you're often inserting data to where it shouldn't be - sometimes this can trick the computer into running code.

Every time there is a crash, there's potential for an exploit.

Re:So, how can I type it for them?

[krinderlin]

Allegedly, it's even more complicated than that. It's in the Data Detector, which several apps will use on inactive text fields and other strings. You can actually send an iMessage from an iOS device to someone and it will crash the Messages app on OS X. Furthermore, you will be unable to re-open messages until you eliminate the message from your history database at the command line. (It's a sqlite database...I think.) Next, I managed to open a crash report from Mail in Console.app and said string crashed Console and then crashed the crash reporter. It was pretty wicked.

Re:So, how can I type it for them?

[retchdog]

yeah, except this is "crashing" due to a malcoded assert, as has been brought up many times on this forum.

that's basically the safest crash that's possible. i won't say it's unexploitable, but it's about as close as can be. you'd be better off looking for uncaught exceptions.

I actually typed it, and nothing happened

[mmarlett]

I searched in the Finder (iMac running 10.8.2) and got nothing strange. I tried Chrome, Firefox, Safari, Mail, a few text editors ... nothing. Sorry.

Re:I actually typed it, and nothing happened

[mmarlett]

Oh, wait, capitol F. That does cause a crash. Since when has a Mac been case sensitive? I guess that's what they get for listening to all those hackers complain about case insensitivity. ;)

Re:I actually typed it, and nothing happened

[EvanED]

From a comment above, the problem is that it's not case sensitive, except for an internal sanity check which is.

E.g. the dispatching code said "the user typed File:/// and I have a handler for file:///, so I'll call it", but then the handler had what was basically an case-insensitive comparison assert(url.startswith("file:///")).

So the problem isn't case sensitivity or insensitivity -- it's that it was being inconsistent about it.

Re:I actually typed it, and nothing happened

[putaro]

Not true! HFS+ (the standard Mac file system) is case-preserving but case-insensitive (usually). Causes some real fun with SVN sometimes when people change capitalization on file names.

didn't some thing like @sony crash mac os 6?

[Joe_Dragon]

didn't some thing like @sony crash mac os 6?

Why is Apple shipping non-optimized code?

[Branka96]

If this is an assert as it appears to be, my question is, why is it in shipping code. Normally asserts are controlled by the NDEBUG symbol (or equivalent) which is undefined in optimized builds. In my opinion asserts should not be in shipping code. You should have something more solid in place.

Re:Why is Apple shipping non-optimized code?

[Jeremi]

If this is an assert as it appears to be, my question is, why is it in shipping code. Normally asserts are controlled by the NDEBUG symbol (or equivalent) which is undefined in optimized builds. In my opinion asserts should not be in shipping code. You should have something more solid in place.

There is a school of thought that says that asserts should be left enabled in the shipping code, since otherwise the software you ship is going to be different than the software you tested against, with possible unfortunate results.

The original reason for disabling asserts for the release build was to maximize runtime performance, but that reason is less important for many programs these days, as there are more CPU cycles to spare.

Re:Why is Apple shipping non-optimized code?

[fnj]

And that, people, is why operating systems have become so grotesquely bloated and gigantic. An endless accumulation of "oh it's only a few more bytes".

Re:Why is Apple shipping non-optimized code?

[shutdown -p now]

asserts are there to catch bugs. Not invalid user input or other conditions that you can predict and gracefully handle, but actual programmer bugs - mistakes in the logic of the program.

If you ship your code with asserts disabled, you are, effectively, asserting that your code is bug-free. If you don't feel confident enough to make such a claim, then leaving them in there is a good idea - you lose a wee bit of perf, yes, but if things do go wrong, the user (and therefore you, when the user files a bug report with a crash dump) will find out much faster, and you will be able to pinpoint the problem more precisely. Furthermore, it prevents the program from running in a bad state and potentially opening up vectors for exploits.

Re:Why is Apple shipping non-optimized code?

[arth1]

If you ship your code with asserts disabled, you are, effectively, asserting that your code is bug-free. If you don't feel confident enough to make such a claim, then leaving them in there is a good idea - you lose a wee bit of perf, yes, but if things do go wrong, the user (and therefore you, when the user files a bug report with a crash dump) will find out much faster, and you will be able to pinpoint the problem more precisely. Furthermore, it prevents the program from running in a bad state and potentially opening up vectors for exploits.

It depends on the program. Sometimes you might want to let the program continue despite known errors, and leaving an assert would be a design error. Think car and airplane computers, data collection units, space probes, medical equipment...

Many of these would have redundant processes if not entire systems, so you could restart one while another was running, but more often than not, a failed assert in one of them would be a failed assert in all of them.

I'd think that the correct approach for an app that has a bona fide user feeding it input would be to give the user a choice - abort, or continue with a big red marker stating that the program is in an unstable state and that risk of crashes, corrupted data or security breaches will be high until the program is closed or restarted.
Perhaps the user really wants to at least try to save the pages he had typed in and not saved yet, or bookmark the web pages, submit a form, or otherwise save data or work.

Re:Why is Apple shipping non-optimized code?

[BasilBrush]

The balance between functionality and cost of space changed. If anyone is not using asserts for the reason of saving bytes, on anything other than a tiny embedded device, they are severely misguided.

Re:No, It Doesn't

[H0p313ss]

Crashes Safari (address bar)

Re:No, It Doesn't

[pushing-robot]

Technically, any capitalization other than 'file:///' will do it. File, fILE, or FILE all have the same effect. The problem is the code compares the string to 'file://' without converting to lower case first...oops.

Progress

[GrahamCox]

It's encouraging that such a minor obscure bug makes a supposedly newsworthy article. That's progress. Back in the day almost anything could crash a Mac (or any other PC), including just leaving it on for a sufficiently long period, so the fact that a crash of this type makes news today shows how much progress we've made.

Re:No, It Doesn't

[gnasher719]

Technically, any capitalization other than 'file:///' will do it. File, fILE, or FILE all have the same effect. The problem is the code compares the string to 'file://' without converting to lower case first...oops.

Some code has figured out that the user entered a file url. A sanity check (badly programmed) figures out (wrongly) that it is _not_ a file URL. That wouldn't be a problem; I would have coded it so that something that looks like a file url but doesn't pass sanity checks is just not a file url. The problem is that this code throws an exception that isn't caught.

A note to C++ programmers: Convention in Objective-C is that exceptions are thrown to indicate programming errors. Exceptions are not handled by catching them, but by fixing the code that causes the exception to be thrown. So this sanity check shouldn't have thrown an exception.

Re:How often does a Mac user type this?

[gnasher719]

> rarely would a Mac user have to type File:///

More people probably did this within the last hour than in the total history of MacOS X before :-)

Not really joking. If many people had done this, then the problem would have been found a lot earlier.

WTF

[Anonymous Coward]

Ok, I didn't believe this, I thought it might be a hoax so I wanted to try this and typed it into a file in the TextEdit.app, and it crashed the TextEdit.app completely!!!!! I had a 10 page paper that I was writing in there opened and it hadn't failed yet. The paper is due tomorrow!! is there a way to sue apple for damages over this?!!?!!!!??

Re:WTF

[BasilBrush]

I realise this is a troll, but for anyone thinking it might be real:

He's just need to restart Textedit, and all the documents he had open will still be there, still opened, in exactly the state they were in seconds before the crash. Snow Leopard documents don't need saving, they are constantly persisted whilst editing. Even if you have't yet given them a filename.

Re:WTF

[squiggleslash]

I realise this is a troll

It was pretty obviously a joke, not a troll. You're not a Slashdot moderator are you? In my experience, they can't tell the difference either.

Nope

[SuperKendall]

Just does nothing at all when clicked on, but that's not really a surprise since data detectors are not involved at that point. It's just rendering HTML so there's nothing to detect, the spec already says what it is and what it does.

Office handles this string perfectly

[raque]

Well, so much for the quality of Apple software compared to Microsoft. MSOffice 2011 handles this string perfectly. Every piece of Apple software goes down in flames. Word makes it into a link, Excel and Power Point treat it as text, I didn't pay for Outlook so I don't know about it handles this string.

Re:Office handles this string perfectly

[TheoCryst]

Try typing it into the search box in the toolbar in Word/Excel/PowerPoint. The document fields of the Office apps aren't "standard" OS controls (whereas the document body of TextEdit is), so they're not susceptible to the bug. But the search field, which appears to be a standard system search field, is.

Re:Running Mountain Lion....

[Nerdfest]

Giving money to Apple.

It also crashes the error reporting function.

[raque]

If you're like me and send feedback to Apple when things go sideways, you can't on this. The Crash brings down the error reporting function "Problem Reporter". As soon as you click into the text field to describe the error it crashes too. Please note from my log:

2/2/13 8:43:18.001 PM Problem Reporter[517]: assertion on /SourceCache/DataDetectorsCore/DataDetectorsCore-269.1/Sources/PushDown/DDResultExtraction.c:1576 "CFStringHasPrefix(urlVal, CFSTR("file://"))" failed :wrong extraction: File:///
2/2/13 8:43:18.001 PM Problem Reporter[517]: wrong extraction: File:///
2/2/13 8:43:18.001 PM Problem Reporter[517]: An uncaught exception was raised
2/2/13 8:43:18.002 PM Problem Reporter[517]: condition "wrong extraction: File:///"
2/2/13 8:43:18.003 PM Problem Reporter[517]: (

I love the last line, is that open parenthesis supposed to be there all alone like that? This is a horrendous bug.

I noted that MSOffice seems to be immune. MS still uses Carbon instead of Coca as their framework. Is this a case of the old ways are still the best ways? Or is this an other case of Apple needs to improve their Quality Assurance.

Adam Engst of Tidbits has an article up on the Tidbits site on a Pages 4.3 bug that nearly prevented him from publishing his Take Control ebook on iTunes 11.

Re:Running Mountain Lion....

[flimflammer]

You were typing file:/// instead of File:///

Version names vs numbers

[DulcetTone]

Why can't Apple stop using these hokey names for their software versions after release? There is no means of knowing what version it is, and it requires out-of-band knowledge of the most useless type. "About this Mac" quotes the grown-up version number. The names are 100% pure loss

A new feature!

[pjabardo]

This is apple we are talking about. Somehow this is a feature...

Snow Leopard FTW

[russotto]

Since I haven't upgraded thanks to Apple's removal of scroll arrows, I can still type "File:///" on my Mac all I want. However, I can't imagine why I would want to.

It would be funnier if merely RENDERING "File:///" would crash the Mac.

It is case sensitive

[PhunkySchtuff]

After trying this in every app I could think of, and failing to crash them, it turns out that this is case sensitive.

Some dude has done a more detailed analysis over on github but the long and short of it is that there is a specific check in the code for 'file://' and any other case will cause it to crash. All caps - crash. Capital F and the rest in lower-case - crash. All lower-case and a capital L - crash.

Aquamacs

[smittyoneeach]

Aquamacs does not seem to understand what the slave process know as "OSX" is on about in this case.
Probably not important.

Re:Aquamacs

[EdgePenguin]

Aquamacs is more than capable of crashing itself without any dodgy library code.

Re:Running Mountain Lion....

[Frankie70]

You are holding it right. The others aren't.

Automatic Hyperlinking

[ModernGeek]

It appears that this has something to do with URL validation for automatic hyperlinking in text fields. I am assuming that it does some sort of procedure that causes File:///[no carrier]

Re:Automatic Hyperlinking

[Gallomimia]

Agreed. I think that in the process of highlighting the hyperlink and finding the file it should be linking to, the background service eventually comes to a file descriptor that references no file and tries to dereference it. Some smart programmer is expecting the File:/// link to be completed all at once rather than typed in slowly. I would ask testers to try pasting in a full string that actually references an existing file and see if that causes the same results. Also a link that has a complete path for a file which does not exist.

Is this for real?

[the_B0fh]

Every single application I have open didn't crash.

Excel
Pages
Chrome
FireFox
Safari
Terminal
iTunes
Omnigraffle Pro
Activity Monitor
Keychain
Preview

Re:Is this for real?

[raque]

Did you capitalize the F in file? Are you running a version of Mountain Lion? The bug seems to be that the routine is not handling the capitalization properly.

Re:Is this for real?

[__aaltlg1547]

I disagree. I think the problem is trying to "handle" user input that isn't intended to be executed at all.

Re:Is this for real?

[raque]

The MacOS checks each string as you type it, that's how it spell checks and things like that. If you look at the language and Text panel in the System Preferences you will see check boxes for spell checking and replacing text with certain symbols: like a copy write symbol if you type (c). This is how if you get a date in your email the OS can offer to make an appointment in iCal for you, passing info between applications is an OS function. That process has a flaw which causes a crash when it encounters that particular string. There are some more detailed explanations above.

Re:Is this for real?

[the_B0fh]

Yes and yes.

Re:Is this for real?

[__aaltlg1547]

The MacOS checks each string as you type it, that's how it spell checks and things like that. If you look at the language and Text panel in the System Preferences you will see check boxes for spell checking and replacing text with certain symbols: like a copy write symbol if you type (c). This is how if you get a date in your email the OS can offer to make an appointment in iCal for you, passing info between applications is an OS function. That process has a flaw which causes a crash when it encounters that particular string. There are some more detailed explanations above.

Yes, I understand what the feature does and what people use it for. But understanding what it is for does not result in my thinking that it is a good thing to have a subsystem searching user input and other data sources for anything that looks like a file reference.

Maybe you wonder why that's an issue. It's because referencing a file is a half step from opening it. Opening it is tantamount to editing it or executing it if it's executable. By attempting to generate a shortcut to open the file, the system is exposing the user and every program to potentially opening, editing and executing files accidentally when it would not otherwise be the case, and counter to prevailing expectations of what user inputs are supposed to do in the program the user is using.

Re:Is this for real?

[petervandervos]

Are you sure? I tried Pages, Chrome, Safari, Preview and iTunes and they ALL crashed. Try opening a search box or load a file. Type the string on the Comment: page of slashdot => crash. If the spellchecker kicks in, it crashes the program.

Re:Is this for real?

[raque]

In that case we are in complete agreement. Just because you can do something doesn't mean you should.

I get why people get so enamored of what computers can be made to do. As someone with writing based learning disabilities Mac and spell check changed my world. I went from not being able to finish High School to Honors in College. WriteNow and MacWrite Pro with that little 9 inch black and white screen were magic in the most pure Harry Potter way. I took my minor in computer science so I could understand this tool that freed me.

I'm amazed by what people don't care about and don't want to know. Just make twitter work .. Wow I'm the mayor of something on Foursquare ... What are people saying on Facebook? Send me your contact info and we'll set up a date. It goes on and on. Just because the first one was a good idea doesn't make the second, or third, or fourth one a good idea too. Matt Hanan found out that Apple's Opaque nature makes them difficult to trust. I've spoken to friends about how all of this interconnected, I'll do it for you-ness may not be a good idea. That cloud services have to be monitored and secured. What I get back is a suspicious look and being asked why I want to take their twitter from them. How can they live without it, it's magic. If you point out that magic has side effects and things you don't see I get more suspicious looks. It's rather bizarre.

       

it's an old joke

[PopeRatzo]

"Doctor, it hurts when I do this... Can you help me?"

"Sure, don't to that."

I'm going to give some free advice to users of Apple's OSX Mountain Lion: Don't do that.

Re:Redirection

[the_B0fh]

Do you live in the real world or in some made up fantasy world?

Lets assume that their stock price does magically fall to $50. They have $150 billion in the bank. How many fucking buildings do you think US$150 billion can build?

Re:No, It Doesn't

[Volguus Zildrohar]

I had the same problem, but apparently it relies on spell check being enabled (and case sensitivity, as so many keep pointing out). Turn off the spellchecker and there's no problem.

Also, learn to spell, in case it's not fixed quickly :)

you obviously didn't read it

[Chirs]

It's a commented assembly listing with a proposed hacky fix in assembly.

Re:donotwant

[node 3]

It's kind of fantastic, actually. Someone sends you an email saying, "let's meet for lunch tomorrow", or "my new phone number is ...", etc., and these become clickable to enter a calendar appointment, or address book entry, etc.

These trace back to the Newton, and were a huge part of that device's "magic". And when you get an email with a UPS tracking number as plain text (instead of a hyperlink), and it becomes clickable and asks if you want to track your shipment, you get one of those, "oh, now that's cool!" moments.

Google does something similar in search results. If you put in a UPS tracking number, the top result is for you to track the shipment, etc.

Hater Fail

[SuperKendall]

You did realize that a link does NOTHING because it's a bug in auto-detect code, right? I mean a link you post doesn't need to be detected, because it's a link... so clicking on your link on a Mac does NOTHING WHATSOEVER.

What a doofus.

Now, to use some JavaScript or HTTP Redirects to auto-load that URL, and have some REAL fun.

Which would have the same effect... I'm not sure why you get your jollies out of posting links that are inoperable, you may as well be posting text marked-up to have underlines.

My Fix

[SuperKendall]

My fix is much simpler, to never type in a string I have never typed before for any reason anyway.

I mean, honestly - who capitalizes a URL scheme anyway? A C# developer? Madness.

oh ya.

[AndyKron]

It just works...

I've been closing my apps that way for years.

[joelville]

I thought everyone knew File:/// is the new Command-Q

Auto-quoting?

[Misagon]

I wonder if automatic quoting of a message on an online message board could cause a crash of the web browser ...
Many message boards, although not Slashdot, has quoting of the previous message enabled by default when you click the [Reply] button. That would copy the previous post into a text field, which would trigger the bug, apparently.

Then all a MacOS/Mountain Lion user would have to do to crash his web browser on those message boards would be to hit the Reply button to the wrong post.

I expect File:/// trolling to explode on message boards in the next few days ...

It's worse than that

[ebcdic]

It turns out that some programs (e.g. Unison, a usenet reader) will crash if they try to display a document containing the string. Quite possibly more will turn up - they'll be programs that try to recognise URLs and display them as a link.

This is appalling

[richardcavell]

Everyone's making fun of this, but this really is appalling. Apple has had nothing but trouble since Steve Jobs died. Just as people predicted. It shows that modern OS's are so bloated that it is impossible to remove all bugs. OS X and Windows 8 probably contain other similar bugs, but we just haven't found them. I would like to believe that bug-free code is possible. Perhaps Apple need to change their programming paradigms. If you want true security you need to greatly minimize your operating system and compartmentalise its tasks, so that it can be exhaustively bug-checked. Adding "features" to an operating system simply creates new security holes. We laugh at the Space Shuttle for running on 386's, and there's a bank here that still runs its terminals on OS/2, but there are applications for which code reliability is absolutely paramount. Think of space probes, nuclear weapons, pacemakers... Richard

How many people does this really effect?

[gravis777]

It's an odd bug, but how many people are really going to be using this command on a Mac? Let's rephrase that: how many people actually know of this command, Windows or Mac users? I have probably used this command maybe a half dozen times in probably 10 years, and that is because Explorer or something has hard locked on me, and killing and restarting the process doesn't work, and I need to save or copy or move something before I reboot.

Now I will grant that I know many more geeks and nerds on Macs now than even 5 years ago, so I am not going to make the joke that "no Mac user would use this". I am just wondering how many people this really effects, and even those users who know about the command, how many would know that it was broken if not for this article.

No crash on my system

[geo3rge]

I tested this on my Mac running Mountain Lion. I tested with Safari, BBEdit, and Mathematica. NO CRASH. something else is going on here.

Re:No crash on my system

[konohitowa]

1. Make sure it's not all lowercase in 'file'.
2. In Safari, type a space after the 3rd slash to activate the checking.

Autocorrect

[Kenshin]

Apparently this is a fault with autocorrect, which is enabled-system wide. If you disable it the bug doesn't work anymore.

Cool!

[desertfool]

It not only crashed Safari, but also crashed the bug report when I typed what I did to cause the crash!

This is fun!

Yes it does... :-(

[Douglas Goodall]

I find it hard to believe such an error exists, but I tested it on my MacBook Pro by typing it into Safari "File->OpenLocation" and sure enough it a bended Safari just like that. I said, "Dad, it hurts when I do this...", he said, "Don't do that". Given that this is now a known and discussed , it is very surprising that it has not been fixed right away by a software update. It does not take admin privileges to try to open a file by that name. Now all it seems to do is crash a single App, like Safari, but what if this was fed to a system process such that it cripples the OS if it crashes?

Doctor, doctor..

[Ginger Unicorn]

Doctor, it hurts when I go like this.

Don't go like that then.