Safari gets the zip file, and sees it contains a JPG, which is "safe" because JPGs can't spread a virus.
See, that's the problem.
It's not the FILE that's safe or unsafe, it's the application that opens the file.
If the file is a JPG, Safari opens it with... Safari, which doesn't trust the contents of files, and is therefore safe.
If the file is a zipfile, Safari opens it with... LaunchServices, which doesn't know anything about "safe" or "unsafe". Safari *believes* that LaunchServices is going to open the zipfile in something that's safe, but it doesn't *know* that. As it turns out, on Tiger, it's not. It was closer to safe on Panther (but there were still problematic issues in Stuffit), but it's not safe on Tiger.
If the file is a PDF, Safari opens it with LaunchServices, which opens it with Preview. Preview doesn't trust PDFs, so it's safe. BUT not because the file is a "Safe File", but because preview is a "Safe Application". And LaunchServices doesn't have any real reason to care if an app is "safe" or "unsafe".
Apple needs to create a registry like LaunchServices for "Safe Applications" to open files with, and let users explicitly disable applications they don't want to trust.
What could be done - I don't know what, frankly - to prevent then propagation of trojans (with or without user assistance) between sandbox levels?
Well, not running as root removes a lot of ways for malware to hide and propogate later.
It makes it harder. Not impossible, but harder. It's good security, but it's not a magic bullet. really, there are no magic bullets, you have to remember to lock your front door *and* your car door *and* your back door *and* your trunk.:)
Shouldn't content that requires the metadata to be intact be transferred in a disk image?
The good news is "Yes".
The bad news is that you don't want Safari or anything Safari calls automatically mounting disk images either, because the metadata in disk images has also been involved in attacks.
PDF viewers do not trust that PDFs are "safe". opening a PDF in a PDF viewer isn't opening a "Safe File", it's opening an "Unsafe File" in a safe application.
Safe applications could be registered EXPLICITLY as handlers for "Unsaf Files".
The solution would be a "WebServices" counterpart to "LaunchServices", for handlers of "Unsafe Files", and Safari could remove the "Open Safe Files" option completely.
Safari's fault for attempting to execute an unsafe file
Yes, it's Safari's fault for attempting to execute an unsafe file.
Safari should treat all files as unsafe files.
Files should only be opened by the web browser itself, or by plugins and applications that are EXPLICITLY registered for use BY A WEB BROWSER and are thus declaring they do not treat any files as "safe".
OS X's fault for executing files themselves instead of opening them in the appropriate application.
Two steps missing here.
1. The unzipper's fault for accepting metadata that specifies the location of the handler for a file.
2. The unzipper's fault for opening the contents of the zipfile automatically.
After it had done that, OS X was doing the right thing. LaunchServices was told to run Terminal.app and pass it the name of a command. Terminal.app opened bash (as it should) and passed it the command. Bash executed the command passed to it.
There are all kinds of other scenarios I can see for getting to the same place, once the three conditions specified above (open safe files, poorly defined metadata, automatic execution) are satisfied. Once the OS (LaunchServices) got involved, the exploit was already over.
The problem happens when you choose to download a file from a web site.
1. Following any link will "choose to download a file". 2. There are a number of ways websites can "force you to choose" to download a file.
There is a problem in Safari. There is a problem in the fact that Safari uses LaunchServices. There is a problem in the fact that Apple's unzipper can override LaunchServices. There is a problem in the fact that Apple's unzipper automatically executes code.
EVERY ONE OF THESE PROBLEMS must be fixed, separately.
I do not keep my apps all unsorted in/Applications/, I have them organized in subfolders such as/Applications/General
The exploit isn't in Calculator, it's in Terminal, but even moving Terminal won't help. Looking around the system I can see quite a few potential candidates that aren't as simply avoided.
The lesson to be learned is that Apple needs to be hit with a clue bat. Their system is not as inherently unsafe as Microsoft's (the problem is in the safari shell application, not the Webkit itself), but they're not continuing to apply the same good security practices that the operating system they inherited had been using.
The solution, I suspect, is to simply not auto-open *anything* that isn't handled by the downloading app itself.
Or by a plugin designed to work with the downloading app, that is intended to implement the same security guarantees.
It would actually be reasonable to call external applications for *some* files, but only if they were able to register as applications that are intended to handle untrusted content.
Unfortunately, Apple's LaunchServices doesn't qualify as such a registry.
(not to mention that having ZIP files automatically unpacked is something I personally find EXTREMELY inconvenient and unpleasant, and if they implemented such a registry and if the unzipper WAS 100% secure I would still want to be able to remove it from the list of "safe" applications)
1. Open Safe Files. 2. Letting metadata in ZIP files explicitly specify handlers rather than file types. 3. Automatically using a handler specified by metadata in zip files.
All three are problems, all three must separately be fixed.
So the guys in apple who had the __MACOSX part to zip files didn't communicate that to the Safari folks.
Unzipper: "Hey, Safari, we're doing something really stupid that could cause problems if you're doing something really stupid. You guys OK with that?" Safari: "Oh, yeh, we're doing something really stupid as well."
Both the Safari team and the unzipper team are seperately fully culpable.
They rely on users choosing to open files that they download.
Not this time. If you have "Open safe files after downloading" enabled (which is on by default in Safari) and are using Apple's unzipper (which is default in Tiger) you just have to hit a web page and you're owned.
ALSO, even if the "that's an executable" check caught it, "granting permission for an operation requested by a remote site" is not "choosing to open".
"Open Safe Files" is a handgrenade without a pin. It just went off.
The suggestion in the original announcement of simply moving Terminal.app will probably NOT be enough to keep you safe. I won't go into details, but it should be obvious why.
Internet-enabled DMGs in zip files opened by Stuffit Expander are another potential problem... I don't know of an explout, but stuffit shouldn't be automatically mounting disk images, ever.
Nothing should ever be passed off to any component that's not known to implement as strong a sandbox as the original program, and that includes using metadata embedded in the potential exploit to tell how it should be opened.
Just ban Internet Explorer, Outlook, Windows Media Player, Realplayer, Lotus Notes, and any other applications that use the HTML control on untrusted content.
It appears that on the Mac, you have to ban Safari. Luckily it's Safari and not Webkit that's screwed up, so you can build a safe shell around Webkit and you don't have to ban everything that uses Webkit.
None of the steps involved in causing this attack to happen should have been implemented in the first place. They're all well-known to be risky, and have all been used in exploits in the past.
"Open Safe Files After Downloading" is inherently risky. No files should be considered safe. The user should always make an explicit request to open any file not handled by the browser itself. Approving an action requested by a potential attacker is not making an explicit request: even if Safari detected the executable and popped up a dialog it would still not be good enough to prevent many people from reflexively approving it.
In addition, automatic execution or interpretation by a general purpose scripting language of any files in an archive, removable media, disk image, or any other potentially untrusted container is inherently risky. Executing code, using applications found in the volume as handlers, or otherwise using them, should be deferred until the user has explicitly requested the code be run, installed, or used.
This should be such a fundamental principle of secure software design that it shouldn't have even occurred to Apple not to follow it.
Just being less insecure than Microsoft is not enough. One might as well laud smallpox as being less deadly than Ebola.
A UNIX shell script is an executable. That's how the execute bit in UNIX works. That's how the shell (not Terminal.app) knows to execute a file.
(don't teach your grandfather to suck eggs - I've been writing software for UNIX since 1979, and I was a developer for what became Mac OS X before it was FreeBSD)
Slashdot Mirror
Safari gets the zip file, and sees it contains a JPG, which is "safe" because JPGs can't spread a virus.
... Safari, which doesn't trust the contents of files, and is therefore safe.
... LaunchServices, which doesn't know anything about "safe" or "unsafe". Safari *believes* that LaunchServices is going to open the zipfile in something that's safe, but it doesn't *know* that. As it turns out, on Tiger, it's not. It was closer to safe on Panther (but there were still problematic issues in Stuffit), but it's not safe on Tiger.
See, that's the problem.
It's not the FILE that's safe or unsafe, it's the application that opens the file.
If the file is a JPG, Safari opens it with
If the file is a zipfile, Safari opens it with
If the file is a PDF, Safari opens it with LaunchServices, which opens it with Preview. Preview doesn't trust PDFs, so it's safe. BUT not because the file is a "Safe File", but because preview is a "Safe Application". And LaunchServices doesn't have any real reason to care if an app is "safe" or "unsafe".
Apple needs to create a registry like LaunchServices for "Safe Applications" to open files with, and let users explicitly disable applications they don't want to trust.
What could be done - I don't know what, frankly - to prevent then propagation of trojans (with or without user assistance) between sandbox levels?
:)
Well, not running as root removes a lot of ways for malware to hide and propogate later.
It makes it harder. Not impossible, but harder. It's good security, but it's not a magic bullet. really, there are no magic bullets, you have to remember to lock your front door *and* your car door *and* your back door *and* your trunk.
Shouldn't content that requires the metadata to be intact be transferred in a disk image?
The good news is "Yes".
The bad news is that you don't want Safari or anything Safari calls automatically mounting disk images either, because the metadata in disk images has also been involved in attacks.
The point for me is PDF.
PDF viewers do not trust that PDFs are "safe". opening a PDF in a PDF viewer isn't opening a "Safe File", it's opening an "Unsafe File" in a safe application.
Safe applications could be registered EXPLICITLY as handlers for "Unsaf Files".
For now, Schubert|it's PDF Browser plugin seems to be the best workaround.
The solution would be a "WebServices" counterpart to "LaunchServices", for handlers of "Unsafe Files", and Safari could remove the "Open Safe Files" option completely.
Can someone remind me what is the point of a browser allowing "driveby downloads" and automatically launching the content of the download?
"Microsoft does it"?
(nice phrase, by the way)
Is it too much to ask for normal users to double click on a file to launch it?
I don't know, but somehow just suggesting to some computer users that they make ONE EXTRA CLICK is enough to get you flamed for being a security nazi.
Safari's fault for attempting to execute an unsafe file
Yes, it's Safari's fault for attempting to execute an unsafe file.
Safari should treat all files as unsafe files.
Files should only be opened by the web browser itself, or by plugins and applications that are EXPLICITLY registered for use BY A WEB BROWSER and are thus declaring they do not treat any files as "safe".
OS X's fault for executing files themselves instead of opening them in the appropriate application.
Two steps missing here.
1. The unzipper's fault for accepting metadata that specifies the location of the handler for a file.
2. The unzipper's fault for opening the contents of the zipfile automatically.
After it had done that, OS X was doing the right thing. LaunchServices was told to run Terminal.app and pass it the name of a command. Terminal.app opened bash (as it should) and passed it the command. Bash executed the command passed to it.
There are all kinds of other scenarios I can see for getting to the same place, once the three conditions specified above (open safe files, poorly defined metadata, automatic execution) are satisfied. Once the OS (LaunchServices) got involved, the exploit was already over.
I think you mean 1997. That's when Active Desktop showed up.
I would expect something more elegant as a long term solution.
Like, removing "Open Safe Files After Downloading", removing the way the unzipper handles metadata, and removing automatic opening of files.
The problem happens when you choose to download a file from a web site.
1. Following any link will "choose to download a file".
2. There are a number of ways websites can "force you to choose" to download a file.
There is a problem in Safari. There is a problem in the fact that Safari uses LaunchServices. There is a problem in the fact that Apple's unzipper can override LaunchServices. There is a problem in the fact that Apple's unzipper automatically executes code.
EVERY ONE OF THESE PROBLEMS must be fixed, separately.
I do not keep my apps all unsorted in /Applications/, I have them organized in subfolders such as /Applications/General
The exploit isn't in Calculator, it's in Terminal, but even moving Terminal won't help. Looking around the system I can see quite a few potential candidates that aren't as simply avoided.
The lesson to be learned is that Apple needs to be hit with a clue bat. Their system is not as inherently unsafe as Microsoft's (the problem is in the safari shell application, not the Webkit itself), but they're not continuing to apply the same good security practices that the operating system they inherited had been using.
The solution, I suspect, is to simply not auto-open *anything* that isn't handled by the downloading app itself.
Or by a plugin designed to work with the downloading app, that is intended to implement the same security guarantees.
It would actually be reasonable to call external applications for *some* files, but only if they were able to register as applications that are intended to handle untrusted content.
Unfortunately, Apple's LaunchServices doesn't qualify as such a registry.
(not to mention that having ZIP files automatically unpacked is something I personally find EXTREMELY inconvenient and unpleasant, and if they implemented such a registry and if the unzipper WAS 100% secure I would still want to be able to remove it from the list of "safe" applications)
There's three separate issues.
1. Open Safe Files.
2. Letting metadata in ZIP files explicitly specify handlers rather than file types.
3. Automatically using a handler specified by metadata in zip files.
All three are problems, all three must separately be fixed.
So the guys in apple who had the __MACOSX part to zip files didn't communicate that to the Safari folks.
Unzipper: "Hey, Safari, we're doing something really stupid that could cause problems if you're doing something really stupid. You guys OK with that?"
Safari: "Oh, yeh, we're doing something really stupid as well."
Both the Safari team and the unzipper team are seperately fully culpable.
They rely on users choosing to open files that they download.
Not this time. If you have "Open safe files after downloading" enabled (which is on by default in Safari) and are using Apple's unzipper (which is default in Tiger) you just have to hit a web page and you're owned.
ALSO, even if the "that's an executable" check caught it, "granting permission for an operation requested by a remote site" is not "choosing to open".
"Open Safe Files" is a handgrenade without a pin. It just went off.
If a worm or other nastiness hid itself as ~/Library/Internet Plugins/Adfilter.plugin how many people would notice?
Also...
The suggestion in the original announcement of simply moving Terminal.app will probably NOT be enough to keep you safe. I won't go into details, but it should be obvious why.
Internet-enabled DMGs in zip files opened by Stuffit Expander are another potential problem... I don't know of an explout, but stuffit shouldn't be automatically mounting disk images, ever.
Nothing should ever be passed off to any component that's not known to implement as strong a sandbox as the original program, and that includes using metadata embedded in the potential exploit to tell how it should be opened.
It's easy to make Windows reasonably secure.
Just ban Internet Explorer, Outlook, Windows Media Player, Realplayer, Lotus Notes, and any other applications that use the HTML control on untrusted content.
It appears that on the Mac, you have to ban Safari. Luckily it's Safari and not Webkit that's screwed up, so you can build a safe shell around Webkit and you don't have to ban everything that uses Webkit.
'nuff said. Someone else let the cat out. Secunia just reported it.
That one only set up a boobytrap.
This one pulls the pin on the grenade and releases the handle.
What's more upsetting is that Apple hasn't made the unchecked state of that box the default...
Not to mention:
1. Stuffit still automatically mounts disk images by default, including "internet enabled" disk images.
2. Apple still uses the same set of bindings for LaunchServices for opening files from Finder and Safari.
3. Now Apple's unzipper makes the LaunchServices problem almost moot, by letting the zipfile specify the helper application by path!
Apple needs to hire a competant security geek and give him authority to issue smackdowns on bad design.
/.'s comments that you can activate this problem by simply visiting a web site is absolute bunk
It's possible for a website to initiate a download.
and have the automatic "safe file open" option turned on
Which is on by default, therefore it can be used to propogate worms.
Files that don't match their extension should be handled.
WRONG! There's three things that MUST be fixed.
Open safe files after downloading SHOULD NOT BE ON BY DEFAULT EVEN IF IT IS AN OPTION.
Zip files and other containers SHOULD NOT BE TREATED AS SAFE FILES EVEN IF IT IS ON.
Unpackers MUST NOT AUTOMATICALLY OPEN ANY FILES IN THE CONTENTS OF A PACKAGE.
Both Apple's unzipper (attacked in this case) and stuffit expander violate this last in different ways.
The worm was a tgz file that propogated over instant messaging.
This one is a zip file and opens the calculator to demonstrate an exploit.
None of the steps involved in causing this attack to happen should have been implemented in the first place. They're all well-known to be risky, and have all been used in exploits in the past.
"Open Safe Files After Downloading" is inherently risky. No files should be considered safe. The user should always make an explicit request to open any file not handled by the browser itself. Approving an action requested by a potential attacker is not making an explicit request: even if Safari detected the executable and popped up a dialog it would still not be good enough to prevent many people from reflexively approving it.
In addition, automatic execution or interpretation by a general purpose scripting language of any files in an archive, removable media, disk image, or any other potentially untrusted container is inherently risky. Executing code, using applications found in the volume as handlers, or otherwise using them, should be deferred until the user has explicitly requested the code be run, installed, or used.
This should be such a fundamental principle of secure software design that it shouldn't have even occurred to Apple not to follow it.
Just being less insecure than Microsoft is not enough. One might as well laud smallpox as being less deadly than Ebola.
(and... I told you so)
Well, I can appreciate it, but Zelda is a technology demonstrator for Nintendo as well as a game and I can't see them going back to 2d.
A UNIX shell script is an executable. That's how the execute bit in UNIX works. That's how the shell (not Terminal.app) knows to execute a file.
(don't teach your grandfather to suck eggs - I've been writing software for UNIX since 1979, and I was a developer for what became Mac OS X before it was FreeBSD)
Any way, in this particular case auto-running content is not exploited anyway.
But it is in this one.
Wow, it took a whole four days before the next "Open safe files" exploit.
HELLO, APPLE, CAN YOU GET THE HINT THIS TIME?