Microsoft is the company that set the precedent that browsers should treat some files as safe because they're certain kinds/in safe zones/signed/whatever. Apple is being quite a bit less trusting when they follow this daft precendent, but would they have been encouraged to implement "Open Safe Files" if Microsoft hadn't blazed the trail?
If you use multimedia (broadband) sites a lot, you don't want a "warning" when you click a realmedia,windowsmedia,quicktime link.
But these files are not opened in a helper app, they're opened in a plugin. Plugins are intended to be used with untrusted apps and thus don't need to be treated as potential exploits the way applications launched through LaunchServices must (but aren't).
Safari goes a step further: it removes the archive, leaving only the contents, and then (this is the key point), if the archive contained only one file and the file is deemed "safe," Safari will open that file.
Is Safari doing that or is BOMArchiver doing that?
If it's Safari, then what does it do for an Internet-enabled Disk Image containing a single safe file?
If it does the same thing, then it may be possible to embed the same exploit in an Internet-enabled Disk Image that unpacks itself to a single file (as, for example, the Unsanity disk images do).
Most people never run anything that uses the terminal, and these are the people who do need the safety net.
Most people do not intentionally run anything that uses the terminal.
That doesn't mean that applications they use don't use the terminal.
This isn't a "safety net". This is a childproof cap that granny has to ask her 7 year old granddaughter to open for her.
Installing Stuffit Expander so that BOMArchiver isn't used to open ZIP files and thus can not be tricked into using Terminal is a "safety net". Turning off "Open Safe Files In Safari" is an even better safety net. Do both, for a big win that does not break anything.
It probably kills the "Open Terminal Here" Applescript in Finder.
It certainly will disable at least a couple of open source apps that I've run into that open a Terminal.app window to run a command line install dialog from their installer, because they're ports of apps that have interactive install dialogs on UNIX.
There's at least a couple of programs that use Terminal.app to run scripts to edit system configuration text files. One of them was the one I used to enable Quartz Extreme on my PCI Radeon.
You may never use any of these programs. If you do, they'll fail and you won't know why. And since it doesn't actually solve the underlying problem... why bother?
This is a new instance on an old and well known security hole in the way Apple uses LaunchServices for untrusted content that I have been talking about for years. The underlying flaw (the idea that "files" rather than the applications that open them need to be "safe") has been exploited before, and will be exploited again if Apple merely fixes this particular instance.
Microsoft has been in denial about their own (and much nastier and harder to fix without breaking existing code) problem in their browser for almost 10 years now, I hope Apple is smarter.
This will disable any applications that use Terminal.app to run shell scripts (which includes some installers, and a number of utility programs and menu extras), and will not prevent the attack. Terminal.app is not the only application that can be used to launch an unrestricted script.
The two things you should do are:
1. Use Stuffit expander or some other application that doesn't support the __MACOSX hack as your handler for ZIP files, instead of BOMArchiver. This will prevent this attack in any application (including Mail.app and Finder).
2. Disable "Open Safe Files After Downloading" in Safari.
3. Don't open attachments in Mail.app, save them to disk and examine them. Also, don't follow links directly from Mail.app, copy them somewhere first to make sure you're not being phished. Mail.app's handling of untrusted content is pretty skanky in general.
4. Contact Apple and ask them to provide a "Safe Applications" equivalent of LaunchServices that programs like Safari, Firefox, and other programs that have reason to pass untrusted documents to sandboxed applications can use. I have been calling for this for at least a year and a half, every time "Open Safe Files" and other interfaces that use LaunchServices for untrusted documents leads to a security hole, and every time Apple has simply applied another patch that handles one possible attack.
That's what Microsoft has been doing for *their* horrendous security holes in the HTML control since 1997, and they STILL haven't gotten it to work.
It's not possible to find and track all the new holes (this one was opened up by switching from Stuffit Expander to BOMArchiver for zip files, for example), and patching the holes by finding the 'last responsible application' and restricting that only makes the system less reliable and convenient to use... and leaves the fundamental security hole unplugged.
I just ran across an application that tries to solve the problem in the wrong place, by restricting Terminal.app.
1. Applications use Terminal.app in normal use... for example, some installers use it to run installation scripts.
2. Terminal.app is not the only possible application that can be used for this kind of attack, and others would cause even more disruption if you blocked them.
The problem is NOT that terminal is unsafe. Your system is full of unsafe apps, that's normal, most apps are never intended to be used on utrusted content.
The problem is...
1. Safari considers untrusted content safe because it's _normally_ run in safe apps, but doesn't ensure that it's really doing it. BOMArchiver is not a "safe app", and doesn't try to be. The previous unzipper was trying to be safe, but it didn't really do a good job.
2. Safari considers containers safe if it can't see any unsafe content inside the container. That's the wrong choice for a security system, it should assume containers contain unsafe content, and NEVER automatically open them... AND, again, it should take responsibility for making sure that a "safe application" is really used for opening unsafe files after downloading them... or not open them at all.
My letter to the author of "Safe Terminal":
The security problem is not in _Terminal_, it is in _Safari_ and _BOMArchiver_.
Preventing terminal from executing files will break installers and other application sthat use Terminal this way _legitimately_, and will not prevent people from using _BOMArchiver_ into tricking LaunchServices into running scripts under other applications that _correctly_ and _legitimately_ accept commands.
It is _not_ safe to use "Open Safe Files AFter Download".
It has _never_ been safe to do this.
PLEASE withdraw this application, or at least remove the claim that it makes "Open Safe Files" safe. It isn't. It will never be. There are no "safe" files, there are only "safe" applications, and LaunchServices is not (and can not be) limited to running only "safe" applications.
Known Issues
This application breaks all Installers that use Terminal.
This application breaks "Open Terminal Here" and other Applescripts for Finder that use Terminal.
This application breaks many utility programs that launch applications in Terminal.
This application breaks Terminal shortcuts.
This application does not actually solve the security problem in Safari and BOMArchiver.
Files are not "trustworthy" or "not trustworthy". Applications are "safe" or "not safe", and attempting to make applications like Terminal that _have to be able to do dangerous things_ "safe" will just make normal use of teh system much more inconvenient (as it has on Windows, where COM (via ActiveX) is the commonly abused interface) without solving the problem (which signed content HAS NOT done on Windows).
Applications are safe, or not safe. Safe applications assume that ALL documents are untrusted, and only pass documents to other safe applications (for example, as plugins). Only the user, by requesting an unsafe application (like Finder) open a document, can make the decision as to whether to trust a file or not.
Mixing up trusted and untrusted documents in the same interface is doomed to failure. Even if the code is perfect, it makes social engineering so much easier it's trivial (as it has on Windows).
+ This study doesn't count the servers I have running Gentoo/Debian/etc -- Most of the revenue reported is actually hardware, so yes it does
You need more servers to provide the same services using Windows. We replaced a tool that was running as one of a dozen applications on a modest sized UNIX box with a Windows version... it was supposed to save manpower and money because we could use a cheap PC instead of 1/12th of an Alphaserver.
We ended up with 2 high end multiprocessor boxes that each cost more than the amortized value of the Alphaserver (which is still running the other 11 apps), an extra employee to support it, plus additional network hardware to isolate the Windows boxes (which was a good thing when Code Red went through). Oh, and a couple more PCs to support the box.
That counted as 5 copies of Windows replacing 0 (1/12 rounded to the nearest unit) copies of UNIX.
+ My *nix servers have 234 CPUs and run more applications than my Windows servers -- Because the survey counts $$$ and not CPU or box counts, this sorta works itself out, but I guess this is valid.
My *nix servers are typically on slower hardware than the Windows servers. Older hardware, hardware that stays in service longer. We spent more money on Windows, but got less value for it.
+ We put Linux on our i486-33 Servers -- Who cares? IDC doesn't, they're counting new server revenue.
I care, because my job is providing services, not buying hardware.
In UNIX, well-written applications that are dealing with unsafe content do not call "system()" to open files. They call the responsible application directly, using "fork()" and "exec()", or they pass the input to the application through another mechanism than the command line.
LaunchServices has the ability to launch any application in the system. No well-written application should use LaunchServices and let it decide how to open a file. They MUST open the file directly, using their own table or using a utility similar to LaunchServices that only contains safe applications. AND they MUST NOT include in their table any application that does not enforce the same restrictions: BOMArchiver, for example, is right out.
That would have been no problem at all if the Finder had agreed
LaunchServices, not Finder.
Safari should not be using general application LaunchServices to open unsafe files. Safari should be using its own list of applications, or using a service like LaunchServices that only contains applications that are intended for using with unsafe files.
Do you mean to say that HTML, CSS, JavaScript, JPEG, GIF, PNG, Flash, and PDF aren't safe?
Yep. None of them are "safe files".
They're files that are typically displayed by "safe applications". Files that claim (to Safari) to be safe types but aren't... well, that's exactly the problem we have now.
It's OK for browsers to open (directly or through a "safe applications" API like internet plugins, not through LaunchServices) handlers that claim to safely handle certain file types. It's NOT OK for browsers to treat some file types as "safe files" and hand them off to an unsuspecting desktop shell.
I didn't say all control panel applets used ActiveX, I said that control panel applets that do (for example: Add/Remove programs) would not work if you disabled ActiveX.
Windows Explorer uses ActiveX for sidebars.
There's ActiveX all over Windows. Anything that uses the HTML control for rendering structured text with active components is using ActiveX (technically, I guess, anything that uses the HTML control at all is using ActiveX).
How do you run control panel applets and other components that depend on ActiveX?
Like I said, a Locked Down enviroment. I was not claiming a standard install of XP was as secure as OSX.
I'm pretty damn paranoid, and willing to put up with a lot of inconvenience, but... damn, why are you bothering to use Windows at all? That sounds like a singularly unpleasant Windows environment, and all the apps you listed are available for a variety of operating systems... many of which require a less rigorous regimen!
Not as long as you use any application that invokes the HTML control on untrusted content, such as IE, Outlook, Media Player, or third party apps like Lotus Notes or Realplayer.
Because, unlike Mac OS X, you can not turn off the Windows equivalent of "Open Safe Files After Downloading".
First, that was a different exploit and attack than this one.
So far almost 1/2 our Macs on campus got infected (while the campus was closed, no one was even using the Macs as they were locked up)
How did someone run the infected app while the Macs were locked up?
I suspect that the Macs were *attacked*, but the worm didn't get a chance to run... it was sitting there waiting for someone to step into the booby trap when the AV software detected it.
Is there a danger in having Acrobat (reader) automatically open a PDF?
No.
There is a danger in having Safari trust LaunchServices to open a PDF, assuming that LaunchServices will make the same decision as to the type of the file that Safari did. So, for example, if someone could create a PDF that would appear as a file used by a different and unsafe application to LaunchServices, there would be a danger there. Note that this attack would probably work with a PDF-that's-really-a-script embedded in a zip file as well as a Movie-that's-really-a-script.
Safari (or some component that Safari uses) should have its own database of applications that are trusted to handle files, and a way to handle them that doesn't involve calling LaunchServices.
"RCDefaultApp" [...] Is that what you mean?
No. That's a tool to let you change the configuration of LaunchServices, it won't help if someone manages to trick or override LaunchServices choice (as happened here)... I'm talking about a completely parallel mechanism that doesn't involve LaunchServices at all. This could be implemented as a separate "WebServices" API, or a flag passed to LaunchServices that would tell it to use the "Safe Handlers" database.
Presumably RCDefaultApp or some similar tool would let you edit and modify THAT list of files as well.
Then you have a nonstandard configuration (have you installed a different unzipper or otherwise changed the handling of zip files?), or you didn't actually have "Open Safe Files" turned on.
There is no totally safe software, but there are practices that are inherently safe, and practices that are inherently unsafe.
Passing an unsafe file (ALL files recieved from an unsafe source are unsafe) to an API designed to allow dangerous things (LaunchServices is how many applications run their own components, it has to be able to do dangerous things) is an inherently unsafe practice. It should never be followed.
Maintaining a separate registry of applications that are designed to accept unsafe files (safe applications) and using that for unsafe files is an inherently safe practice.
This was the norm for all applications that dealt with untrusted data. The rare case where it wasn't (the Internet Worm, the WANK virus,...) were treated as bugs, and the unsafe practice was stopped. Until Microsoft integrated IE's HTML control with Windows Explorer (under the name Active Desktop) in 1997, and refused (even, ironically, under threat of being forcibly split up for unrelated reasons) to abandon the practice of using a common mechanism for handling local and internet content.
Now, what Apple's done (and continues to do) is a smaller exposure than Windows's habit of waving its technicolor bum at virus writers, but it's still inherently unsafe and they need to turn around and fix it right.
Of all the times for Apple to follow Microsoft's lead, why did they have to pick this one? Dear God, if you exist, please explain this...
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".
But... LaunchServices doesn't have any way to tell if an app is "safe" or "unsafe", so it's possible for an unsafe PDF viewer to override Preview.
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. Preview could be registered there, along with other applications that are designed to deal with potentially untrusted content.
Slashdot Mirror
Microsoft is the company that set the precedent that browsers should treat some files as safe because they're certain kinds/in safe zones/signed/whatever. Apple is being quite a bit less trusting when they follow this daft precendent, but would they have been encouraged to implement "Open Safe Files" if Microsoft hadn't blazed the trail?
If you use multimedia (broadband) sites a lot, you don't want a "warning" when you click a realmedia,windowsmedia,quicktime link.
But these files are not opened in a helper app, they're opened in a plugin. Plugins are intended to be used with untrusted apps and thus don't need to be treated as potential exploits the way applications launched through LaunchServices must (but aren't).
The Unsanity disk images don't unpack to a single file, but the way I wrote it can be read as implying they do. Apologies. Bad editing.
Safari goes a step further: it removes the archive, leaving only the contents, and then (this is the key point), if the archive contained only one file and the file is deemed "safe," Safari will open that file.
Is Safari doing that or is BOMArchiver doing that?
If it's Safari, then what does it do for an Internet-enabled Disk Image containing a single safe file?
If it does the same thing, then it may be possible to embed the same exploit in an Internet-enabled Disk Image that unpacks itself to a single file (as, for example, the Unsanity disk images do).
Most people never run anything that uses the terminal, and these are the people who do need the safety net.
Most people do not intentionally run anything that uses the terminal.
That doesn't mean that applications they use don't use the terminal.
This isn't a "safety net". This is a childproof cap that granny has to ask her 7 year old granddaughter to open for her.
Installing Stuffit Expander so that BOMArchiver isn't used to open ZIP files and thus can not be tricked into using Terminal is a "safety net". Turning off "Open Safe Files In Safari" is an even better safety net. Do both, for a big win that does not break anything.
It probably kills the "Open Terminal Here" Applescript in Finder.
It certainly will disable at least a couple of open source apps that I've run into that open a Terminal.app window to run a command line install dialog from their installer, because they're ports of apps that have interactive install dialogs on UNIX.
There's at least a couple of programs that use Terminal.app to run scripts to edit system configuration text files. One of them was the one I used to enable Quartz Extreme on my PCI Radeon.
You may never use any of these programs. If you do, they'll fail and you won't know why. And since it doesn't actually solve the underlying problem... why bother?
This is a new instance on an old and well known security hole in the way Apple uses LaunchServices for untrusted content that I have been talking about for years. The underlying flaw (the idea that "files" rather than the applications that open them need to be "safe") has been exploited before, and will be exploited again if Apple merely fixes this particular instance.
My comment on this from May 2004, getting on for two years ago now.
Microsoft has been in denial about their own (and much nastier and harder to fix without breaking existing code) problem in their browser for almost 10 years now, I hope Apple is smarter.
This will disable any applications that use Terminal.app to run shell scripts (which includes some installers, and a number of utility programs and menu extras), and will not prevent the attack. Terminal.app is not the only application that can be used to launch an unrestricted script.
The two things you should do are:
1. Use Stuffit expander or some other application that doesn't support the __MACOSX hack as your handler for ZIP files, instead of BOMArchiver. This will prevent this attack in any application (including Mail.app and Finder).
2. Disable "Open Safe Files After Downloading" in Safari.
3. Don't open attachments in Mail.app, save them to disk and examine them. Also, don't follow links directly from Mail.app, copy them somewhere first to make sure you're not being phished. Mail.app's handling of untrusted content is pretty skanky in general.
4. Contact Apple and ask them to provide a "Safe Applications" equivalent of LaunchServices that programs like Safari, Firefox, and other programs that have reason to pass untrusted documents to sandboxed applications can use. I have been calling for this for at least a year and a half, every time "Open Safe Files" and other interfaces that use LaunchServices for untrusted documents leads to a security hole, and every time Apple has simply applied another patch that handles one possible attack.
That's what Microsoft has been doing for *their* horrendous security holes in the HTML control since 1997, and they STILL haven't gotten it to work.
It's not possible to find and track all the new holes (this one was opened up by switching from Stuffit Expander to BOMArchiver for zip files, for example), and patching the holes by finding the 'last responsible application' and restricting that only makes the system less reliable and convenient to use... and leaves the fundamental security hole unplugged.
An older post on the same topic.
1. Applications use Terminal.app in normal use... for example, some installers use it to run installation scripts.
2. Terminal.app is not the only possible application that can be used for this kind of attack, and others would cause even more disruption if you blocked them.
The problem is NOT that terminal is unsafe. Your system is full of unsafe apps, that's normal, most apps are never intended to be used on utrusted content.
The problem is...
1. Safari considers untrusted content safe because it's _normally_ run in safe apps, but doesn't ensure that it's really doing it. BOMArchiver is not a "safe app", and doesn't try to be. The previous unzipper was trying to be safe, but it didn't really do a good job.
2. Safari considers containers safe if it can't see any unsafe content inside the container. That's the wrong choice for a security system, it should assume containers contain unsafe content, and NEVER automatically open them... AND, again, it should take responsibility for making sure that a "safe application" is really used for opening unsafe files after downloading them... or not open them at all.
My letter to the author of "Safe Terminal":
Files are not "trustworthy" or "not trustworthy". Applications are "safe" or "not safe", and attempting to make applications like Terminal that _have to be able to do dangerous things_ "safe" will just make normal use of teh system much more inconvenient (as it has on Windows, where COM (via ActiveX) is the commonly abused interface) without solving the problem (which signed content HAS NOT done on Windows).
Applications are safe, or not safe. Safe applications assume that ALL documents are untrusted, and only pass documents to other safe applications (for example, as plugins). Only the user, by requesting an unsafe application (like Finder) open a document, can make the decision as to whether to trust a file or not.
Mixing up trusted and untrusted documents in the same interface is doomed to failure. Even if the code is perfect, it makes social engineering so much easier it's trivial (as it has on Windows).
+ This study doesn't count the servers I have running Gentoo/Debian/etc
-- Most of the revenue reported is actually hardware, so yes it does
You need more servers to provide the same services using Windows. We replaced a tool that was running as one of a dozen applications on a modest sized UNIX box with a Windows version... it was supposed to save manpower and money because we could use a cheap PC instead of 1/12th of an Alphaserver.
We ended up with 2 high end multiprocessor boxes that each cost more than the amortized value of the Alphaserver (which is still running the other 11 apps), an extra employee to support it, plus additional network hardware to isolate the Windows boxes (which was a good thing when Code Red went through). Oh, and a couple more PCs to support the box.
That counted as 5 copies of Windows replacing 0 (1/12 rounded to the nearest unit) copies of UNIX.
+ My *nix servers have 234 CPUs and run more applications than my Windows servers
-- Because the survey counts $$$ and not CPU or box counts, this sorta works itself out, but I guess this is valid.
My *nix servers are typically on slower hardware than the Windows servers. Older hardware, hardware that stays in service longer. We spent more money on Windows, but got less value for it.
+ We put Linux on our i486-33 Servers
-- Who cares? IDC doesn't, they're counting new server revenue.
I care, because my job is providing services, not buying hardware.
In UNIX, well-written applications that are dealing with unsafe content do not call "system()" to open files. They call the responsible application directly, using "fork()" and "exec()", or they pass the input to the application through another mechanism than the command line.
LaunchServices has the ability to launch any application in the system. No well-written application should use LaunchServices and let it decide how to open a file. They MUST open the file directly, using their own table or using a utility similar to LaunchServices that only contains safe applications. AND they MUST NOT include in their table any application that does not enforce the same restrictions: BOMArchiver, for example, is right out.
Safari thought it was a JPEG file.
Safari thought it was a Video.
That would have been no problem at all if the Finder had agreed
LaunchServices, not Finder.
Safari should not be using general application LaunchServices to open unsafe files. Safari should be using its own list of applications, or using a service like LaunchServices that only contains applications that are intended for using with unsafe files.
My system handles .zip with Stuffit Expander.
:)
Which is not standard for Tiger.
Do you mean to say that HTML, CSS, JavaScript, JPEG, GIF, PNG, Flash, and PDF aren't safe?
Yep. None of them are "safe files".
They're files that are typically displayed by "safe applications". Files that claim (to Safari) to be safe types but aren't... well, that's exactly the problem we have now.
It's OK for browsers to open (directly or through a "safe applications" API like internet plugins, not through LaunchServices) handlers that claim to safely handle certain file types. It's NOT OK for browsers to treat some file types as "safe files" and hand them off to an unsuspecting desktop shell.
There are other components that would do just as well and are harder to get away with moving.
I didn't say all control panel applets used ActiveX, I said that control panel applets that do (for example: Add/Remove programs) would not work if you disabled ActiveX.
Windows Explorer uses ActiveX for sidebars.
There's ActiveX all over Windows. Anything that uses the HTML control for rendering structured text with active components is using ActiveX (technically, I guess, anything that uses the HTML control at all is using ActiveX).
Myself, ActiveX is totally disabled
How do you run control panel applets and other components that depend on ActiveX?
Like I said, a Locked Down enviroment. I was not claiming a standard install of XP was as secure as OSX.
I'm pretty damn paranoid, and willing to put up with a lot of inconvenience, but... damn, why are you bothering to use Windows at all? That sounds like a singularly unpleasant Windows environment, and all the apps you listed are available for a variety of operating systems... many of which require a less rigorous regimen!
A locked down XP system, is as secure as MacOSX
Not as long as you use any application that invokes the HTML control on untrusted content, such as IE, Outlook, Media Player, or third party apps like Lotus Notes or Realplayer.
Because, unlike Mac OS X, you can not turn off the Windows equivalent of "Open Safe Files After Downloading".
if people are able to get control of your machine they can turn it into a spambot, a DOS machine or other such device without your knowledge.
But they don't need root to get control of your machine and turn it into a spambot...
All they need is a place to hide an executable that you'll run every time you log in.
Like, oh, dozens of places beneath ~/Library/
First, that was a different exploit and attack than this one.
So far almost 1/2 our Macs on campus got infected (while the campus was closed, no one was even using the Macs as they were locked up)
How did someone run the infected app while the Macs were locked up?
I suspect that the Macs were *attacked*, but the worm didn't get a chance to run... it was sitting there waiting for someone to step into the booby trap when the AV software detected it.
Is there a danger in having Acrobat (reader) automatically open a PDF?
No.
There is a danger in having Safari trust LaunchServices to open a PDF, assuming that LaunchServices will make the same decision as to the type of the file that Safari did. So, for example, if someone could create a PDF that would appear as a file used by a different and unsafe application to LaunchServices, there would be a danger there. Note that this attack would probably work with a PDF-that's-really-a-script embedded in a zip file as well as a Movie-that's-really-a-script.
Safari (or some component that Safari uses) should have its own database of applications that are trusted to handle files, and a way to handle them that doesn't involve calling LaunchServices.
"RCDefaultApp" [...] Is that what you mean?
No. That's a tool to let you change the configuration of LaunchServices, it won't help if someone manages to trick or override LaunchServices choice (as happened here)... I'm talking about a completely parallel mechanism that doesn't involve LaunchServices at all. This could be implemented as a separate "WebServices" API, or a flag passed to LaunchServices that would tell it to use the "Safe Handlers" database.
Presumably RCDefaultApp or some similar tool would let you edit and modify THAT list of files as well.
To get it to unzip I had to double-click on it.
Then you have a nonstandard configuration (have you installed a different unzipper or otherwise changed the handling of zip files?), or you didn't actually have "Open Safe Files" turned on.
There is no totally safe software, but there are practices that are inherently safe, and practices that are inherently unsafe.
...) were treated as bugs, and the unsafe practice was stopped. Until Microsoft integrated IE's HTML control with Windows Explorer (under the name Active Desktop) in 1997, and refused (even, ironically, under threat of being forcibly split up for unrelated reasons) to abandon the practice of using a common mechanism for handling local and internet content.
Passing an unsafe file (ALL files recieved from an unsafe source are unsafe) to an API designed to allow dangerous things (LaunchServices is how many applications run their own components, it has to be able to do dangerous things) is an inherently unsafe practice. It should never be followed.
Maintaining a separate registry of applications that are designed to accept unsafe files (safe applications) and using that for unsafe files is an inherently safe practice.
This was the norm for all applications that dealt with untrusted data. The rare case where it wasn't (the Internet Worm, the WANK virus,
Now, what Apple's done (and continues to do) is a smaller exposure than Windows's habit of waving its technicolor bum at virus writers, but it's still inherently unsafe and they need to turn around and fix it right.
Of all the times for Apple to follow Microsoft's lead, why did they have to pick this one? Dear God, if you exist, please explain this...
It's not the FILE that's safe or unsafe, it's the application that opens the file.
... 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.
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".
But... LaunchServices doesn't have any way to tell if an app is "safe" or "unsafe", so it's possible for an unsafe PDF viewer to override Preview.
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. Preview could be registered there, along with other applications that are designed to deal with potentially untrusted content.