×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted about a year ago | from the break-different dept.

Bug 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

425 comments

printf (2, Funny)

Sigvatr (1207234) | about a year ago | (#42773961)

C-strings strike again.

Re:printf (0)

Anonymous Coward | about a year ago | (#42773975)

I wonder if the bug will lead to possible RCE due to memory corruption.

Re:printf (5, Informative)

Anonymous Coward | about a year ago | (#42773995)

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

Re:printf (-1, Troll)

Anonymous Coward | about a year ago | (#42774033)

There is no memory corruption involved here, it's a failed assertion, namely that the string begins with 'File://' and the routine it was passed to expected the string to start with 'file://'.

The crash isn't because they were lazy, it's because they went out of their way to include checks for the data they were passing around and one of those checks found something unexpected, and aborted the program, by design. I'm pretty sure this is a good thing.

Re:printf (5, Funny)

Anonymous Coward | about a year ago | (#42774065)

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

Re:printf (0, Insightful)

Anonymous Coward | about a year ago | (#42774117)

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 (5, Insightful)

Anonymous Coward | about a year ago | (#42774133)

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 (0)

jones_supa (887896) | about a year ago | (#42774201)

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

Re:printf (5, Informative)

Savage-Rabbit (308260) | about a year ago | (#42774339)

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 (0)

Anonymous Coward | about a year ago | (#42774169)

If it caught the mistake it wouldn't crash. That's not error handling.

Re:printf (0)

Anonymous Coward | about a year ago | (#42774285)

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

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

Re:printf (5, Insightful)

EvanED (569694) | about a year ago | (#42774333)

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 (3, Informative)

Anonymous Coward | about a year ago | (#42774497)

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 (0)

Anonymous Coward | about a year ago | (#42774109)

On a file not found error, isn't it better to return "file not found" instead of "commit suicide" ?

Re:printf (3, Insightful)

Anonymous Coward | about a year ago | (#42774135)

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 (4, Insightful)

Dahamma (304068) | about a year ago | (#42774307)

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 (1)

Anonymous Coward | about a year ago | (#42774311)

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 (0)

Anonymous Coward | about a year ago | (#42774119)

Yes, crashing a computer over a trivial error is a good thing; kind of like how Google's networks goes down whenever someone tries to include an illegal character in an email address.

Re:printf (1)

peragrin (659227) | about a year ago | (#42774195)

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

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

Re:printf (1)

Savage-Rabbit (308260) | about a year ago | (#42774363)

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 (0)

Anonymous Coward | about a year ago | (#42774365)

case sensitive URL handlers is a good thing? that's straight crazy. assertions in library code are a good thing? hell no. you should exit gracefully doing nothing with an error code or an exception.

Re:printf (-1)

Anonymous Coward | about a year ago | (#42774401)

You're a fucking retard.

Re:printf (1)

Anonymous Coward | about a year ago | (#42774079)

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

Re:printf (4, Insightful)

fyngyrz (762201) | about a year ago | (#42774391)

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.

Apple's response (5, Funny)

Anonymous Coward | about a year ago | (#42773971)

You're doing it wrong.

no big deal.

Steve

Re:Apple's response (0)

Anonymous Coward | about a year ago | (#42774181)

You can't use your left-hand.

Re:Apple's response (4, Funny)

girlintraining (1395911) | about a year ago | (#42774203)

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 (0)

Anonymous Coward | about a year ago | (#42774419)

Like the Monty Python parrot sketch, except entirely devoid of humour.

Re:Apple's response (2)

dugancent (2616577) | about a year ago | (#42774265)

My response:

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

Re:Apple's response (-1, Troll)

mvdwege (243851) | about a year ago | (#42774379)

Since in that year the Apple fanbois haven't managed to grow a sense of iHumour yet, and they keep reacting hysterically to that old joke, why not keep it?

Re:Apple's response (0)

Anonymous Coward | about a year ago | (#42774469)

File:/// (typed into safari)

BRB (5, Funny)

AmiMoJo (196126) | about a year ago | (#42773973)

BRB, heading down to the Apple Store...

Re:BRB (3, Insightful)

drcagn (715012) | about a year ago | (#42774009)

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.

There are other strings of text (-1)

Anonymous Coward | about a year ago | (#42773991)

I typed "cock" in any mac app and it jizzes itself...

Powerpoint summary of TFS (4, Funny)

TapeCutter (624760) | about a year ago | (#42774019)

- An obscure library bug triggered by a magic string.

- In the latest version.

Re:Powerpoint summary of TFS (5, Insightful)

jonadab (583620) | about a year ago | (#42774145)

> 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 (2)

oakgrove (845019) | about a year ago | (#42774347)

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 (0)

Anonymous Coward | about a year ago | (#42774413)

(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.)

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.

Re:Powerpoint summary of TFS (0)

Anonymous Coward | about a year ago | (#42774309)

That's no PowerPoint. Where are the annoying sound effects or the flying text or the animations. Someone needs to go back to Using Office 101.

Little light on specifics.... (1)

Kenja (541830) | about a year ago | (#42774031)

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.... (1)

Anonymous Coward | about a year ago | (#42774063)

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

It's case-sensitive.

Re:Little light on specifics.... (5, Interesting)

Kenja (541830) | about a year ago | (#42774075)

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.... (0)

Anonymous Coward | about a year ago | (#42774329)

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.

Obviously someone left something open in a call to Data Detectors. Should be really easy to find and fix though. Most likely it causes some kind of buffer overload thus killing the requesting process which is the requesting application.

Because the coding for OS10 is a C variant, the call is case sensitive, same as all unix like systems. This is not something that is at all akin to an apple script.

This is not the same thing as crashing the shit out of Linux with a simple shell script fork bomb. But it does not surprise me that an overload can take place with a call to a function in Mac OS, I am sure it will be fixed and quickly. However, I doubt that it can be exploited in the same way some Microsoft software faults usually can.

Not that OS10 is that great, but at least there are reasonable safeguards at the user level against writing to /root from user level programs, and file overloads cause the OS by default to terminate applications instead of just hanging the system and leaving a buffer open! Which is the way some very sophisticated malware goes after similar Windows OS calls that can be hacked.

Re:Little light on specifics.... (0)

Anonymous Coward | about a year ago | (#42774415)

Yeah, sure, really worrisome, but not as much as your definition of code execution..l

Sir, i will have to ask you to step away from that keyboard slowly...

Re:Little light on specifics.... (1)

Anonymous Coward | about a year ago | (#42774103)

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

Re:Little light on specifics.... (1)

Assmasher (456699) | about a year ago | (#42774367)

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

You're doing it wrong (3, Funny)

greggman (102198) | about a year ago | (#42774047)

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

There are no bugs. You're doing it wrong

Re:You're doing it wrong (1)

Anonymous Coward | about a year ago | (#42774153)

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

Re:You're doing it wrong (1)

Vreejack (68778) | about a year ago | (#42774155)

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.

So, how can I type it for them? (1)

rduke15 (721841) | about a year ago | (#42774313)

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.

donotwant (0)

Anonymous Coward | about a year ago | (#42774051)

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."

Sounds like a disaster to me.

Sure enough (1, Informative)

DaMattster (977781) | about a year ago | (#42774055)

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

Re:Sure enough (0)

Anonymous Coward | about a year ago | (#42774385)

10.8.2 here, and file:/// did not crash Google Chrome but File:/// did crash it. Did not try any other app.

Security hole? (1)

Billly Gates (198444) | about a year ago | (#42774057)

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? (1)

pushing-robot (1037830) | about a year ago | (#42774283)

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? (1)

John Hasler (414242) | about a year ago | (#42774485)

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

Running Mountain Lion.... (0)

Anonymous Coward | about a year ago | (#42774071)

didn't kill chrome, didn't kill finder, didn't kill iTunes

What am I doing wrong?

Re:Running Mountain Lion.... (1)

Raistlin77 (754120) | about a year ago | (#42774167)

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:///

How often does a Mac user type this? (0)

Anonymous Coward | about a year ago | (#42774107)

It seems like a harmless bug, rarely would a Mac user have to type File:///

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

Re:How often does a Mac user type this? (1)

jonadab (583620) | about a year ago | (#42774197)

> 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.)

So? (4, Insightful)

Bogtha (906264) | about a year ago | (#42774149)

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.

No, It Doesn't (0)

reallocate (142797) | about a year ago | (#42774175)

Thoroughly current Mountain Lion on a Macbook Pro here. When I enter "file:///" into apps, I get directory listings, not crashes.

Re:No, It Doesn't (-1)

Anonymous Coward | about a year ago | (#42774231)

No crashes here either. Mountain Lion 10.8.2

Re:No, It Doesn't (3, Informative)

Anonymous Coward | about a year ago | (#42774251)

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.

Re:No, It Doesn't (1)

pushing-robot (1037830) | about a year ago | (#42774475)

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.

Re:No, It Doesn't (0)

Anonymous Coward | about a year ago | (#42774259)

It is case sensitive ... the f must be in caps.

Not happening for me (1)

shatfield (199969) | about a year ago | (#42774187)

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

Re:Not happening for me (1)

Assmasher (456699) | about a year ago | (#42774355)

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 (1)

shatfield (199969) | about a year ago | (#42774477)

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

Similar feature in Windows (1)

clickety6 (141178) | about a year ago | (#42774233)

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 (0)

Anonymous Coward | about a year ago | (#42774395)

What application and Windows version?

Abort, Retry, or Fail used to crash Mac TTS (0)

Anonymous Coward | about a year ago | (#42774239)

About 3 or 4 years ago it was possible to crash recipient's (iChat or radium, don't remember) IM app by sending Abort, Retry, or Fail? In an IM to someone that had text to speech enabled. Used to have fun with our manager. :)

It works (1)

spire3661 (1038968) | about a year ago | (#42774245)

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.

Even crashes the crash reporter! (5, Funny)

Wormholio (729552) | about a year ago | (#42774295)

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!

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

Dwedit (232252) | about a year ago | (#42774305)

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.

I actually typed it, and nothing happened (1)

mmarlett (520340) | about a year ago | (#42774361)

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 (2)

mmarlett (520340) | about a year ago | (#42774375)

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 (2)

EvanED (569694) | about a year ago | (#42774425)

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.

Freaking sh*t (0)

Anonymous Coward | about a year ago | (#42774433)

Just crashed my Safari - and now it won't reopen! It crashed my Internet! Help!!!

No crash on linux mint (0)

Anonymous Coward | about a year ago | (#42774439)

Cannot replicate in any app in linux.

Why is Apple shipping non-optimized code? (3, Insightful)

Branka96 (628759) | about a year ago | (#42774447)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...