Slashdot Mirror
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."
You're doing it wrong.
no big deal.
Steve
BRB, heading down to the Apple Store...
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Not likely. It crashes due to an assertion failure and subsequent exception being thrown.
Here speaketh the Apple fan. No matter what... it's a good thing.
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.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
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.
> 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.)
Cut that out, or I will ship you to Norilsk in a box.
Landon Fuller has posted a gist on GitHub with an explanation of the bug and a binary patch to the affected library.
This sig is umop apisdn.
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!
"Education is not the filling of a pail, but the lighting of a fire." -- William Butler Yeats
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.
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.
Only to idiots, are orders laws.
-- Henning von Tresckow
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.
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.
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.
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.
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.
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.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;