Or you could uncheck Open "safe" files after downloading in Safari. Seems easier to me. As far as I can tell Mail.app always puts up a ok/cancel dialog so it isn't needed there. Can you elaborate on what other applications might be vulnerable? I can't think of anything.

Seems Mail has the same problem:

http://www.heise.de/english/newsticker/news/69919

Sorry, APE framework and malicious modules inject code in running applications and violate the boundries of protected memory.

The problem with Mail is so minor that it isn't worth worrying about. If you click on attachments in unsolicited email you are asking for trouble.

The problem with Safari is that the download can happen with no user interaction which makes it very dangerous. But since it is easily disabled by unchecking a single preference, I don't see the need for a Haxie to fix the problem.

I'm not sure if you guys read the article or not or even have an idea of what the root problem is...but judging by some of the comments I'd assume not.

This issue of deceptive icons is at the OS level (LaunchServices) as stated above. As it stands there is no way to guarantee an innocent looking .jpg file is not in fact a malicious shell script in disguise at a glance.

Simply turning off the "open safe downloads" option in safari merely delays the problem. You're probably going to assume the jpg you just saved is safe and open it soon enough anyway.

Definitely hope somebody that has any say in this matter looks at this and does the right thing. I really wouldn't want to see this devolve into a train of dialog windows I'll end up blindly clicking through to get something done.

The fix needs to be elegant and effective..and soon wouldn't hurt either :-)

Thanks Rosyna for that great breakdown of the problem. The issue is that the user must be able to trust the way the Finder displays a file, in order to predict how it'll be handled.

One problem remains: the custom (deceptive) icon pasted over the default icon.

Why doesn't Apple put a special "badge" over the icon of any executable file, just like it is done for aliases ?

Wouldn't that solve the problem ?

Ned, actually the problem with this "exploit" is there is no custom icon.

When I try the "happy fun completely benign version of the exploit", Preview pops up and grees me with the message:

"Couldn’t open the file. It may be corrupt or a file format that Preview doesn’t recognize."

Sounds like something is broken.

Great article, by the way.

Almost two years ago we had another problem with LaunchServices. Paranoid Android was a temporary fix, to be used until Apple fixed the REAL problem... which was that LaunchServices is not and should not be treated as a safe way to open untrusted files. LaunchServices can open any application, and doesn't provide any real information to the application it's opening as to whether it should trust the document it's opening.

Unfortunately, Apple hasn't fixed the real problem.

Instead, they implemented an only slightly less aggressive version of the Paranoid Android temporary fix. A version that wouldn't have helped with the original attack, but seemed to have convinced people (including the good folks here at Unsanity) that the problem was over.

It's not.

And unless Apple fixes the real hole... the use of LaunchServices for running untrusted content... yet more quote-unquote holes in applications will be discovered.

LaunchServices is a "shell" interface, like system(), and should be avoided by secure software for the same reason. Using this same interface for local applications and user requested commands (which must be allowed to do unsafe things) and requests from untrusted sources (which must not) is like using "system()" to pass a user's login name from a CGI variable to a mailer. How many exploits can you trace back to *that* mistake?

Uhm, huh? All application and document launches go through LaunchServices. You cannot avoid it. Even the command line "open" utility goes through LS.

It's a core part of OS X. Fixing a problem in LS will fix it in ALL aspects of OS X. It's a very good thing that all of these opening actions go through LS.

And the second point...

"Simply turning off the "open safe downloads" option in safari merely delays the problem. You're probably going to assume the jpg you just saved is safe and open it soon enough anyway."

I have been maintaining our workplace here almost virus-free for 15 years now, and one of the ways I've managed to do that is by banning the use of any application that uses the Windows HTML control.

Hold on, I'll show you why that's relevant in a second.

One of the things about apps that use the HTML control is that they allow remote sites to request that software be opened on the local user's computer. The user sees a dialog box that pretty much screams to me "something's wrong", but I've had users come to me multiple times because they'd been using IE (against policy, but I could only 'ban' it so far) or Outlook (ditto) and clicked on the "INFECT ME" button in this big glaring "SHOULD I DO SOMETHING STUPID" box, because they get so many dialogs they reflexively look for and click on whatever the "go ahead" option is.

I have yet to have someone come to me more than once and say they'd been infected because they'd downloaded a file and opened it from the desktop or a download manager. because that's a deliberate act, it takes time, you have time to think about it. You don't have a dialog box you HAVE to respond to now...

So...

Automatically executing worms, on a badness scale of 1-10... at least 11.

Worms that execute after a dialog box, maybe a 7 or 8.

Worms that you have to download and open manually, even from a download manager which is just about as convenient as auto-opening? 1 or 2 at the most.

I think that what Peter is saying is that using LaunchServices to open both trusted and untrusted content is problematic. And I agree.

I don't advocate creating a whole new API to deal with untrusted content, LaunchServices is fine. But there needs to be some way of telling it, "I as a developer want to open this file, but it's fresh off the internets, treat it as dangerous!". Right now, there isn't.

All application and document launches go through LaunchServices. You cannot avoid it. Even the command line "open" utility goes through LS.

There's nothing magical about LaunchServices. All it does is run Whatever.app/Macos/Whatever and passes it parameters. I've run stuff that way, directly, and it works fine.

And I'm not saying that Apple should abandon a central document-application binding. I'm saying that they should provide two (or provide an option to LaunchServices), one for normal application and user requests, and one for documents that come from an untrustable source... like a document viewed in a web browser, an email attachment, and so on...

Jason: that's exactly it. Whether it's called "LaunchServices with the UNSAFE option" or "WebServices", it doesn't matter.

Making it a separate registry, or having separate columns for each option, would be useful. It would even make things MORE convenient for the user. For example, you could have a full macro-enabled Microsoft Word for word documents opened from Finder, or a limited and restricted one that doesn't even implement macros for documents opened from Safari.

Trusted/Untrusted has nothing to do with this vulnerability. This one is caused by metadata being attached to the document instead of in the LS database. If it was moved to the LS database, this one would be fixed.

And apple added "trusted/untrusted" concepts to LS to fix the previous LS vulnerability that PA was designed to fix. They just need to use it more and expand on it.

Rosyna, if all LS api's took a "trusted" parameter, the metadata would be ignored and this vulnerability wouldn't exist.

Of course, what I'm suggesting isn't particularly feasible - you can't go change a bunch of APIs that already exist and are already in use. But it would have been a good plan six years ago.

Not feasible at all, AFAICT. As soon as the users start complaining, the developers would stop passing that flag (or start, whichever one causes it to be "trusted" and stops the dialogs). The Keychain does something similar via trusted/untrusted whenever an application gets updated.

The "correct" answer is far better, but it requires an entirely separate blog post.

On the subject of the custom icon flag: it could simply be overloaded for the ‘usro’ resource. If no ‘icns’ or icon family is found, use icons from the app specified by ‘usro’ instead of the default or weak binding.

I didn't follow all that.

You seemed to say that there are three places where the system can look for who can open a file. If they are not consistent the system should aggressively complain.

If the system displays a file as .jpg in the Finder and then passes that file to Terminal.app to be opened and executed, the system is sick and the bug needs to be reported and fixed.

The problem isn't that there are three methods, the problem is the system respects the first two and handles risk assessment and other issues with the first two methods, but completely ignores all that for the last (strong binding) method.

It's what is broken. And this bug has probably been filed 50 times already since the exploit was made public.

from my post on Mac OS X Talk...

you've mixed together several different vulnerability issues here

you've pointed out an issue with what icon is provided when the icon resource is deleted for custom binding ("strong' binding, as you call it); that issue is worth exploring, but it doesn't matter to the Safari download exploit because the victim never sees the icon (besides which i see the wrong icon _without_ deleting the resource)

you've also questioned whether custom binding should should travel with a file; i doubt it's used much, but it seems to be part of the devil's bargain Apple made in conflating file type and app binding info, and it's plausibly useful within workgroups; in any case it also takes much more explicit action to work this into a vulnerability if the user must manually open the file

the real issue in question is that Safari deems certain files "safe" for opening and in this case opening a the document actually runs a script, which is outside the purported definition of safe; Safari makes a contract with the user right in Preferences as to what is safe; as far as possible, Safari should uphold this contract, though wiser souls will turn the feature off

it seems from your article that Safari is relying on LaunchServices for an OS-level "risk assessment"; offhand, i couldn't find this in the LaunchServices API, and your article is fairly vague, so some detail on the mechanism would be helpful; what is the name of the call?

if this is as you describe, then the risk assesment is indeed flawed -- it seems it can recognize a shebang in a text file, but it fails to recognize that a file is custom-bound to Terminal; if so, i agree LaunchServices is the root cause of the vulnerability

Very confusing thread of posts for us non-geek regular folk.

garbanzito, the call is explicitly mentioned in the post. It is not documented.

Once again, this has nothing to do with Safari at all. Just because it may be the most common vector used for "infection", it is not related to Safari at all as Mail.app is subject to the same problem, but it does no risk assessment.

These terms such as "Strong Binding" are not my own, but what apple uses to refer to them.

And no, strong binding was not the "devil's bargain". Weak Binding would be that bargain, but weak binding works just fine.

Rosyna, you said that "the problem is the system respects the first two and handles risk assessment and other issues with the first two methods, but completely ignores all that for the last (strong binding) method".

I wouldn't say that risk assessment is ignored for the strong biding method. It is done the same way as for the two other methods, and here the file is identified as a JPEG, which is supposed to be safe. After all, the fact that because of strong binding the JPEG file is going to be opened by such or such application instead of the default application is not supposed to represent a particular risk, and can be useful in some situations, so I don't think detecting a strong binding should change the result of the risk assessment algorithm.

In this particular case, I see two problems.

First, a problem with LS: the risk assessment algorithm is flawed. Not because of anything related to strong binding, but because it doesn't seem to take into account the (unix) executable flag of a file. Here, if the fake JPEG file didn't have it's executable flag set, opening it would launch Terminal but not do anything else. So, what makes the file dangerous is its executable flag. Normally, seeing any JPEG file with its executable flag set should be considered as an abnormal situation and LS should categorize the file as *very* unsafe (because of the *very* abnormal situation). Of course, this should be the case for any file type normally considered as safe.

Second, a problem with the Terminal: why does Terminal open and execute a file, whatever its type, just based on the fact that this file has its executable flag set? I don't think this is particularly useful to anybody, and as we can see here it is potentially dangerous. Terminal should check the type of the files it is told (by LS) to open. If it's one of its own declared file types (term and command), or a script file (with a known extension, like .sh or .csh), or just a text file with executable flag set, or a file of unknown type (no HFS type, no extension or unknown extension) with executable flag set (which probably means a unix binary executable file), then it can open it and execute it. But if the file is of any other type, even if it has its executable flag set, it shouldn't be executed.
An application as potentially dangerous as Terminal should make the (little) effort to check what kind of file it is asked to open and execute.

I think Apple should correct these two problems first, as it is easy to do and fixes this vulnerability without sacrificing features like strong biding, or adding even more dialogs that users won't read.

Of course, later, they should rewrite the strong biding process to make it cleaner:
- solve the icon problem by really getting, in real time, the icon from the application the document is bound to;
- make the strong binding process user- and machine-specific by relying on the user's UUID (which is supposed to be globally unique);
- make it more mac-like by using the application bundle identifier (or creator code) instead of a path.
But all that can be done later and is not absolutely required in order to fix this vulnerability.

Technically (the best kind of -cally) a weak binding can completely change the risk assessment of a file. A recent, real world example appeared on a developer's mailing list recently. Disk Image claims the .img extension as a disk image. This would be marked as "safe". However, if a user used weak bindings to assign the .img file to an Atari GEM image (http://www.leadtools.com/SDK/RASTER/FORMATS/Raster-Format-GEM.htm) opening program that did not have an image UTI type to go with it because the .img is a GEM image, and not a disk image, then LS would mark it as unsafe when doing risk assessment. So it was safe with default bindings then unsafe with weak bindings.

Assume this same img file has a strong binding that opened it in the Terminal. Then LS would see the default binding, mark it as safe, then open it in the terminal, where it becomes unsafe.

Yes, this is a very bad bug in the terminal for handling the opening of files. We aren't talking manual execution like ./ya_rly.jpg but opening the file via a double click. But fixing the bug in the Terminal won't fix the core vulnerability. A malicious person would just have to find another application with the same execution problem (I can think of a few that are theoretically exploitable this way). You just need any old file that has an application that will execute executable code inside the file. Heck, if there was a bug in the format of the file, you could exploit that by using this LS exploit as a "launch pad".

Extensions do not exist in the unix world. They're an MS-DOS/Windows creation that spilled over into OS X and other OS's. Metadata that is easily changeable (like the file name) should never, ever dictate the format of a file. But because this problem is not isolated to the terminal, it's a moot point. I think everyone's agreed that the way the terminal (and NOT the shell) interpret opened files needs to be fixed. But I'd be really, really disappointed if Apple fixed the buggy terminal.app and declared this problem fixed. Because it wouldn't be. Someone (anyone) would just have to find another vector for exploiting this that doesn't require the terminal.

I agree with all the points about making strong binding better, except the GUID suggestion. If the data is stored in the file (as it is now) then strong bindings are still per document and one user can overwrite the strong bindings of another, causing the default bindings to be used. This can cause massive problems with shared files on network drives (like common media files such as porn and medical images).

"But fixing the bug in the Terminal won't fix the core vulnerability. A malicious person would just have to find another application with the same execution problem"

Of course, but I think that's another problem: Apple can't work around the vulnerabilities of all third-party applications. Their job is to make sure that the applications they supply behave correctly. Plus, it's much more interesting for a malicious person to exploit a vulnerability in a system-provided application such as Terminal, which is guaranted to be found on every Mac, than to rely on the same kind of vulnerability in a third-party app which might be present only on small percentage of Macs (hence, the risk of having somebody exploit the vulnerability is not the same). In the first case, it can be seen as a vulnerability of the system, while in the second case it's the fault of the app developer; should we lose functionality at the system level just because some third party apps might be buggy?
When I was talking about how Terminal should check the declared type of files it opens before executing them, I actually meant that any application of this kind (ie, which executes code from documents) should behave this way. Unfortunately, I know I'm just dreaming here. :)
But again, I find it much more dangerous in apps that are part of MacOS X than in third party apps.

Btw, I hope the "few apps you can think of that are theorically exploitable this way" are not other Apple apps installed as part of MacOS X (else, they would indeed be as dangerous as Terminal).

"Metadata that is easily changeable (like the file name) should never, ever dictate the format of a file."

I completely agree.
Unfortunately, I think a lot of users (mostly ex-Windows users, I guess) are happy with the adoption of extensions by Apple in MacOS X, so I'm afraid it's here to stay. :(

"But I'd be really, really disappointed if Apple fixed the buggy terminal.app and declared this problem fixed. Because it wouldn't be. Someone (anyone) would just have to find another vector for exploiting this that doesn't require the terminal."

I see your point. Indeed, it wouldn't be completely fixed... in theory. But as I said above, finding another vector as widely available (and easily exploitable) as Terminal seems difficult to me.
And in the meantime, Apple could apply the other changes we talked about to make strong binding... stronger! :)
The use of user, machine-specific binding, in particular, would do a lot to fix this vulnerability for good.

As for my suggestion of using GUID: indeed, as you said, in this case one user could intentionally overwrite the bindings of another user for a particular document (it would have to be intentional, since the system would separate settings for each user, unlike now). However, I feel this is just part of the numerous problems posed by shared files with write permissions for everyone (which pose security risks anyway).

But you're right, it would be much safer to store strong bindings in a separate, per-user database (which would also allow to set strong bindings for read-only files). It's just that I feel a bit weird about keeping per-file settings in a separate database, with the risk of loss of synchronization between the database and the files on disk (particularly on external disks) and the risk of ending with a database full of bindings for files that were opened only once from a CD-ROM (why would a user set a binding for such files? I don't know, but the user might do it anyway).

Question: would it be possible, with HFS+, to have access permissions to some extended attributes? Then, it would allow for a nice implementation of per-user strong bindings, stored with the file but safe from other users. Unfortunately, I'm afraid it's not possible. But you probably know more about it than I do.

okay, the mention of LSCopyDownloadAssessmentDictionary was sort of vague -- you mention patching it, but not explicitly that Safari calls it

as for "devil's bargain", i meant that when adding binding by file "type" (in its various forms), and making it common for files to lack creator codes, Apple seems to have realized this might be too rigid, and added "strong binding" as a way to win back some of the benefits of creator codes; it's a devil's bargain because introducing compatibility with a degenerate standard led to attempts to get back some of what was lost, which in turn introduced more problems ...

nonetheless, i think strong binding's benefits should extend to workgroups, and should be archivable; otherwise the productivity gain in working with large filesets would be moot; so storing such binding separately from the file is about the same as just removing the option completely

as for whether it has to do with Safari, i agreed with you that LS should do better risk assessment, but while Safari (reasonably, i guess) relies on LS for this assessment, it increases the severity of this vector because in this case downloading executes code without the user even seeing the icon or the "kind"; this sets it apart from the various masquerades in which the user is more complicit

Unix has a program _file_ that determines the type of a file.

If I run this on one of the sample exploit files:
> file Heise.jpg
Heise.jpg: ASCII text

It quickly determines that this file is NOT a jpg, but a text file.

The problem is that Launch Services relies upon easily spoofed meta data (file name and/or file type in the resource fork) to determine what the file is. It should do a better job.

"trusted" files are no help here -- how do I determine that a zip file was downloaded from the internet two weeks ago? Or that a file was originally in a zip file that was downloaded from the internet, and now is not? Or that the zip file I just copied from a file server was from the internet, instead of one of my other machines?

At the very least launch services should be wary of any file whose type differs by ANY of the methods. That is, if file with the '.jpg' extension is set to open by Terminal (an app that can't open jpgs) it should throw a flag.

If the 'files' unix command shows that the file is not the same as the resource type, the extension type, or is not among the types used by the app it's strongly bound (or weakly bound) to it should throw a flag.

It should do this ALL the time, because with a modern computer these checks would not take but a fraction of a second.

The result is that the computer spends a bit of a time trying to make sure that the file I'm clicking on is roughly what it says it is, and what I think it is, rather than blindly trusting third party information.

the unix files command is not foolproof -- but it's far better than what is going on right now.

And, since Apple has concentrated all opening into the same API -- it should be easier for them to implement the first line of defense by making LaunchServices even more resistant to being spoofed.

And this is a GOOD thing. It's bad when there is a security bug, as it means the hole exists EVERYWHERE (even if Safari doesn't uncompress the zip file, the problem is still there). But, it also means that instead of plugging holes all over, apple can plug the hole ONCE and it's plugged.

And, of course Apple should take the time to make Terminal a bit more discriminating as well. But if Launch Services was doing it's job and telling me that this executable ASCII text file with a JPEG extension (a non executable file type) was being opened by Terminal (an app that can't open jpgs) -- then this wouldn't be a problem.

Now -- writing that dialog box so that it was clear -- that would be a nice trick, and is much harder than writing the code!

And, in some extreme cases (like this one), It should just refuse to open the file until something is fixed.

That is, unless someone can explain why I'd WANT to open an executable jpg file -- no matter what the strongly bound application was?

Well this is enough, Apple used to have a wonderful record and made a solid operating system.

There were a few exploits over the entire life of "Classic" Mac OS.

But Mac OS X has been nothing but a botched job with a history of exploits mounting up just like Microsoft has.

I'm ashamed of Apple, I'm ashamed of myself for believing in them and the cult like behavior of it's users and myself is a total embarassment. I'm ashamed I got "stealth marketed" over a product that only is superior in looks.

When Apple announced the Intel switch, I knew EFI and Trusted Computing were coming along for the ride, no longer will us users have control over our hardware. EFI will take the OS calls to hardware, make internet connections/download drivers even before a OS loads.

I just want a machine that works, and Apple used to be a company that I could trust to do that. But it doesn't seem to be the case anymore.

First it was the URL handler exploits, then others and now this.

I used to rememebr saying Windows was insecure because it had a egg shell security, seems Mac OS X is not any better.

These obvious blunders in coding Mac OS X is designed to do one thing, get us to accept the more stringent Trusted Computing inititives.

Apple has even started allowing developers to install their programs requiring root access, and they have been going crazy with it.

Almost everything is requiring a root install, this is total BS, I want to decide who I trust messing with my operating system and knowing all my sensitive information. Apple is encouraging this behavior!!

I'm done with Apple, they are just too naive. Let the EFI and trojan hackers commence.

http://www.lafkon.net/tc/

Here's a explaination what's happening with the MacTels

http://www.againsttcpa.com/what-is-tcpa.html

Apple sold us out.

Hi everyone,

Paranoid Android keeps asking if I want Safari to open:

"/System/Library/PrivateFrameworks/Syndication.framework/Resources/SyndicationAgent.app/."

I realize this has something to do with Safari's RSS reader, but is there a way to set PA to always allow and never ask about this?

Thanks,
Jon
(Tiger 10.4.5 Safari 2.0.3)

Nevermind, just figured out that adding the path

"/System/Library/PrivateFrameworks/Syndication.framework/Resources/SyndicationAgent.app/"

to the allowed URL schemes list fixed it.

Jon

oops . . . I spoke too soon.

I had quit Safari and logged out, relaunched and didn't get the message so I *assumed* it was fixed, but while browsing Slashdot a moment ago, that same message popped up . . .

Jon

Read the comments on the paranoid android post.

I would like to ask one thing: you can ask AppleScript to do shell scripts and could'nt that be used to do the same damage?

"strong bindings should not transfer between computers"

Of course they should be transferred. Do you think I'd want to open the html files I marked to open in SubEthaEdit instead of Safari to open in Safari just because I moved them to a different computer?

It appears the exploit has been patched with Security Update 2006-001. Can anyone comment on changes made with regards to this exploit? The about file ( http://docs.info.apple.com/article.html?artnum=303382 ) states that additional validation occurs with Mail.app and Safari, but in my limited testing, I couldn't get it to trigger so I'm wondering how foolproof this validation is.

MacFixit reports that script can still be triggered by double-clicking the file. Therefore the underlying vulnerability in LaunchServices is still there - only the additional problem in Safari has been "fixed". In some ways that is worse than no fix at all, in that it breeds complacency.

I'm on a 10.3.9 machine (with the security update installed) and although the file does not automatically open, the ya_rly.jpg example shows up in the Safari Downloads window and in the Finder with a TextEdit icon and opens in Terminal when double-clicked. Scary.

A little bit less strict than completely stripping that stuf from the resource fork: I wonder if Apple could simply check the file's extension and then check to see if the App in question is registered with LS to open files of that type. For example, it knows from the resource fork that this file should open in Terminal. So it could ask LS if Terminal wants to open jpg files. LS would say, no, it can't and then it would strip the resource.

This would get around ssp's problem because SubEthaEdit would be registered to open HTML files and the binding would remain.

I just installed Apples new security update Security Update 2006-00. It has no effect on the exploit vector demonstrated here. The second link coninues to execute without warning of any kind. I'm not sure what apple tried to do but the exploit is still there.

Ok. The fix is working now something going on on my machine.

Ok. Apple's Security Update 2006-001 requires that you dump /Library/Caches and reboot before it will work properly. This allows the system to reset the luanch service cache. Once active it prevents the defualt app for being changed for a file marked by safari as safe for auto open. PA will still warn that a non defualt app is being used but the document will open in the defualt application if you click continue. Further more the document remains assioated with the default app until set locally to open with another. Apple also seems to have to changed how the icon is set in this case if the document's defualt app is changed locally. Only the second demonstration is affected. Firefox 1.5 is immune to both exploits as it seems to strip 'usro' resources from downloaded files. Why doesn't Apple just do this and save themselves a headache?

I just installed Apple's Security Update 2006-002 for 10.4.5 and 10.3.9. This update seals the security hole demonstrated above.

Safari should not be using LaunchServices or Finder for *anything* to do with displaying, downloading, or opening documents linked from, attached to, or otherwise associated with any web page.

Apple *has to* either provide an API for a "WebServices" database that ONLY contains applications intended to handle unsafe files, or have Safari maintain its own database of helper applications.

The longer they try and make LaunchServices "safe", the harder it will be to fix it when they finally give up.