Typing These 8 Characters Will Crash Almost Any App On Your Mountain Lion Mac 425
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."
Re:BRB (Score:4, Insightful)
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:printf (Score:0, Insightful)
My comment had nothing to do with Apple, it has to do with good programming practices. Catching mistakes as soon as possible is a good thing, no matter who is writing the software. assert() is a programmers best friend, regardless of who he works for.
Re:printf (Score:5, Insightful)
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 (Score:3, Insightful)
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:Powerpoint summary of TFS (Score:5, Insightful)
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.)
So? (Score:5, Insightful)
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.
Gödel Lives! (Score:3, Insightful)
Re:printf (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Why is Apple shipping non-optimized code? (Score:4, Insightful)
Re:The cause, and a fix (Score:4, Insightful)
Landon Fuller has posted a gist on GitHub with an explanation of the bug and a binary patch to the affected library [github.com].
Yeah, THERE'S a good idea - apply a binary patch from some random post on Slashdot!
Re:Why is Apple shipping non-optimized code? (Score:2, Insightful)
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:printf (Score:2, Insightful)
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 (Score:5, Insightful)
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 (Score:1, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
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:Why is Apple shipping non-optimized code? (Score:4, Insightful)
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:printf (Score:4, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
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".