Slashdot Mirror
Mac OS X Struck By Severe Security Hole
An anonymous reader writes "Macworld is reporting about a new security hole in Mac OS X that can be exploited to compromise a system if the user simply visits a web site with Safari. Currently, no vendor patch is available. Secunia has a demonstration of the vulnerability and suggestions for temporary workarounds."
.. finally learned how to "Think Different".
You can test this by downloading this harmless exmaple:
http://www.heise.de/security/dienste/browsercheck
...and sending the resulting JPG to yourself in Mail.app.
This is rooted in something that has been true about Mac OS in general for over 22 years, which is that any file or document - including executables - can have any icon. Other elements of the OS (such as the Get Info window) properly identify it as a Terminal document (shell script), and show that it is opened with Terminal, but most users won't see or understand this.
I'd expect a security update that addresses this *very* soon. This is a bad one.
Glad I have that option turned off!
It's inevitable though that there will be a major OSX infection, so it's time for Mac users to get more conscious of this stuff.
Oh, and more $$$ for the anti-virus guys I guess.
The revolution will NOT be televised.
..... www.internetexplorer.com
I don't use Safari because it doesn't render pages as well as a mozilla based browser, and now I have a reason to gloat :)
Get Camino here. Camino is an OS X native browser using the gecko rendering engine. Looks better than Safari, is faster than Safari, and apparently is more secure than Safari. Plus the security is more easily tunable.
Most Mac users have heard of it by now, but I'm just giving them another plug because it kicks ass.
the last thing that came up about this icon-tricking required an administrative password, does this one?
-- lol pwned
*RING*
Jobs: Hello?
Gates: BWAHAHAHAHA! PWNED!!!!
Jobs: Goddamnit, Bill, I told you to stop calling!
____
~ |rip/\/\aster /\/\onkey
The 'workaround' is to just disable auto-opening 'safe' files. I've done this on every Mac I've used, since I started using them, as I always saw it as a potential security risk (and a potential annoyance - I don't want my files opened immediatly sometimes). In my mind, automatically doing almost anything like opening downloaded files without asking is bad.
So just live without automatic file opening for the time being, and you're safe.
"Your effort to remain what you are is what limits you."
Mac OS X users can protect themselves simply by removing the check mark from the "Open safe files after downloading" option in Safari's preferences under the General tab. I have tested this and it works. This is quite a nasty little exploit so I suggest making the change ASAP.
Strange women lying in ponds distributing swords is no basis for a system of government.
The only difference is that the default behavior in Safari is to automatically open downloaded files of certain trusted types.
Who wouldn't try clicking on a movie icon? I would think that most people would.
Putting moderation advice in your
On 3-way iChat: Ballmer: Screw you both! I'm goint to F*ing kill Google!
Correct me if I'm wrong, but doesn't this only affect the system at the user level? Unless the person is browsing the web as root.... I'm sure some clever person could do some damage with this exploit but to affect the system as a whole, you would still get a dialog box to make system changes.
From TFA:
Users can mitigate the threat by disabling the "Open safe files after downloading" option in Safari.
If I'm not mistaken, this option is already turned off by default in Safari, so this exploit would only affect those users who have deliberately turned it on. It still sucks, but at least the number of affected users is somewhat small.
Went to the proof of concept, followed directions and it did not execute.
I'm running 10.4.5 with Safari 2.0.3. Looks like not everyone is vulnerable.
I remember when this came out for IE - you could have a link in a webpage that would launch Notepad or open the systems cdrom drive. As IE is with Windows, it sounds like Safari is to OS X; too close to the OS. Of course what can a cmd like this do to someone w/o admin access? We'll see, but the focus should be on *why* this happened in OS X? What was the idea to have Safari be able to run apps?
We shouldn't be surprised at things like this popping up, OS X is getting more popular/press, so they've become the bigger target we knew they would once they went the MacTel route. Popularity has it's quirks ya know.
fak3r.com
How the heck do people figure this stuff out!! Man, if they'd devote this kind of effort to creating legitimate software, imagine the possiblities! The best programmers in the world in my opinion are code crackers... If I had their talent I'd be loaded!!! lol...
Auf Wiedersehen!
...what a stupid idea.
:sigh:
I honestly think that Jobs really bought into his own RDF with this one.
You can't tell me that after Win98 & IE4 + 8 years... anyone still believes that bypassing security for "features" is a good idea on as hostile a network as the internet.
Esp. with someone with as seemingly high a clue-factor as Jobs...
I just turned off the feature on my Safari, and sent an email to my wife to do the same on her powerbook.
Make sure everyone's vote counts: Verified Voting
I never saw the point of the option in the first place, regardless security issues. If I tell Safari to download a file, that's what i want -- download it. I never said what I want to do with it next, so why would i want to open it? Yes in most cases when i download an archive, I'm going to unstuff it soon after. But I might just as well want to burn it to a disc or do whatever else with it, and that's what i want to choose myself. That's why i never enabled that stupid, exploit-ridden option anyways.
MS Windows users have had this for 5 years. Congrats to Apple for finally catching up to us.
Very inneresting. I downloaded the Secunia.mov.zip file on my XP machine at work. Looking at the unzipped files in a text editor, you get the Secunia.mov file which contains "/Applications/Calculator.app/Contents/MacOS/Calcu lator; exit". In the __MACOSX folder (resource data), there is a ._Secunia.mov, which contains binary data and the string "/Applications/Utilities/Terminal.app". Basically, it's a shell script that fires up calculator and exits.
As others have said, it's a result of the split off of the resource metadata in OS X. As mentioned, disabling the 'open safe files after download' option in Safari will fix it, too. Or just use Camino. That coupled with the CamiTools plugin seems to do just about everything I need.
This guy's the limit!
It's true that you don't have to worry about this if you switch off the "Open safe files" option, but I've always thought the option was a bad idea, especially when left on by default. It was a vuln waiting to happen because as soon as you figure out how to trick Safari into seeing a malicious file as "safe", you can own a large portion of Mac users.
So the guys in apple who had the __MACOSX part to zip files didn't communicate that to the Safari folks. Communication gaps happen, but this is gross oversight in a company which claims to sell their software for a premium because it is cool (and well-tested UNIX background).
Shell vulnerabilities seem to be the entry point usually, seeing the firefox shell:// that was recently discovered... Integration comes with its own sweet price.
Quidquid latine dictum sit, altum videtur
Better integration with the keychain and mail, as well as a native appearance. Me, I use Firefox.
There's also Camino if you want something that looks native. It's gecko based, but doesn't have the extendibility.
I don't want to start a flaimbait. However here it is: There is no safe software. OSX is inherently safer than windows, but it's not 100% safe, by default (no software is). This is to say that I hope many mac user will finally get conscious about this: Mac OSX is not de facto immune by any exploit, flaw or whatever. Not because you are using OSX you should not be careful, and use the proper software.
1. User must download link
2. Safari must allow expanding of zip file
3. Zip app must allow executing of unzipped file (this is not normal)
4. Normally, the file will appear on the desktop, without being executed. It does have a movie icon, but for those of us who always pre-watch movies and what have you in a Finder column window, this doesn't really present a problem; it says Terminal Document below the movie icon (and no one in their right mind would zip a movie anyway, it's a bit like those pornmovie.exe you find sometimes).
As the bible says.
He who humbles themselves shall be exhulted he who exhults them selves shal be humbled.
This is true in tech as well.
If you feel that your computer is involnerable to hacks you will get hack eventually. This is true for Linux, Solaris, even OpenBSD users. The more secure you say it is the more people will want to find a way to break in. This is espectially true for OS X users because they like to glote on how secure their OS is. But there are a lot of people still feel bitter with the IBM vs. Apple wares (even though the PC won a while ago) and still hate apple with a pation so they will find ways to break in. Never gloat on how secure your system is because it will only end in tears.
But if you figure your system isn't truely safe and take steps to keep it as safe as possible and not make a big toute of how safe it is, then you may have a chanse of keeping it safe.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Those bastards at Microsoft! When are they going to learn not to release code that's... What? It's not Microsoft? That doesn't even make sense! I thought Apple was immune from any security vulnerabilities, because they were error-proof.
Seriously, I'm not a Microsoft fanboy. As the admin for small Microsoft network, I spend hours a day cursing them. However, I'm glad that it's finally been shown that ALL OSes have problems. Windows is definitely a victim of it's own success, because there aren't a whole lot of people out there that want to spend hours and hours discovering a way to compromise BeOS and OS/2. I think Apple has done a superb job in the last year or two really setting themselves up for a major comeback, and kudos to them. My next PC will probably be an Apple.
The dark side, however, is that we're going to see more and more exploits/holes/worms for the Apple OS in the future as they gain market share. The scariest part is that there's probably more low hanging fruit in the way of exploits. Love it or hate it, Windows is pretty battle-hardened at this point.
-Arthur
Cave ne ante ullas catapultas ambules
Someone correct me if I'm wrong, but this exploit can only affect items that the user has rights to. If a script were written to make changes to the system, OSX should prompt you for your password, right?
Kiteboarding Gear Mention slashdot and get 10% off!
I hope the KDE guys take a gander at this one too, just to be safe.
But I missed the part in the article where this can all be blamed on Microsoft, can someone please help me out?
...it wants it's exploit back.
fak3r.com
I'd expect a security update that addresses this *very* soon. This is a bad one.
Security fix has been out for some time.
Available here
My pics.
I am envious, the exploit doesn't work on my windows box. If I try to run the proof of concept file, it says it's not a movie file. Damn it!
I know it's an ancient version, but I just tried it under VMWare in Safari 2.0 (412) and it only launches Quicktime. Well I guess that's bad enough.
... would be using Firefox for OS X?
The CB App. What's your 20?
Comment removed based on user account deletion
Is the end of the world near? Will dogs and cats start living together? Google do evil and MS be good?
Quick point of order: the bug doesn't execute automatically if you turned off the "Open Safe Downloads" preference. However, it's still really Really REALLY bad.
Explanation: Apple recognizes a particular folder within a zip archive as resource forks. This way you can correctly upload/download old-style apps and/or OSX metadata. The latter feature is where the problem occurs.
If you take a shell script, rename it to a "safe" file extension (such as mov, jpg, etc), then change its metadata (aka the "Open With..." setting) to Terminal.app instead of the expected default application, you now have a shell script that looks like an ordinary media file.
If you then use OSX built-in BOMarchive command, you have a zipped shell script that looks like a "safe" download.
End result: arbitrary shell script execution (under OSX default settings) upon visiting a malicious URL.
Conclusion: remote metadata should not be trusted. This bug would not occur if downloaded files could only belong to their default app.
Are we so used to MS bundling the browser with the OS that we can't think that they're different things? Granted, Safari does come with OSX, but thats not the point - its the wording of the headline thats trollish.
I want to delete my account but Slashdot doesn't allow it.
http://aspell.sourceforge.net/
Why isn't Secunia being flamed here for releasing details of an exploit before Apple has had a chance to patch it? Are there not enough details for someone to create their own version? I may be wrong, but I did not notice one mention of any fact that indicates that Apple was notified of the problem and/or given an opportunity to fix the problem. I am used to seeing such information releases eing labeled as "irresponsible" but I have not seen any discussion of this aspect of the story yet.
Laws affecting technology will always be bad until enough techies become lawyers.
The most value I get out of Camino is for browsing some heavy AJAX sites that have not been tested with Safari. A few more iterations might make it better.
use firefox instead
I make these: http://beatseqr.com
It's just another choice you're free to make. I like Safari a lot more than Firefox, because it works the way you would expect a Mac app to work. I haven't tried Camino yet, though.
I use 10.3.last revision.
Nothing happened and even when I clicked on the file.
I'm a big retard who forgot to log out of Slashdot on Mike's computer! LOOK AT ME.
I like how this was modded flamebait when it's so obviously trolling :) ...I was thinking the same thing, though. After months of reading about how great and secure Apple is here on /. I expected at least a bit more apologetics from the zealots.
I use .Mac to synch Keychains and Bookmarks between the three machines I use regularly. Safari is easier to do that with. Plus it's got native appearance.
ian
For everybody else who says "thank heavens I use Firefox" in these threads, please read parent post. This is a problem held over from when OS used metadata/extensions to figure out what to do with a file, automatically, before we had to worry about the bad guys trying to manipulate this data. These techniques date back to single-user systems, and they are vulnerable.
(Usual disclaimer: I use a unix>windows mix at work, mac at home, and use primarily firefox on all three).
People need to learn techniques to lock down their boxes - different OS are not all equally vulnerable, but are all vulnerable.
Using plain ol' text since 1968
Since IE is no longer supported or being developed on OSX, Safari will have to try harder in creating more backdoors on a monthly basis. They have a long way to go to catch up with IE.
Comment removed based on user account deletion
Perhaps this was after their honeymoon period in another dimension..
I just tried the following:
Safari + open safe downloads ON - Terminal and Calculator opened automatically
Safari + open safe downloads OFF - file downloads, opening it from the Downloads window does nothing
OS X 10.4.5, Safari 2.0.3, everything up to date from Software Update.
This is a nasty one, but turning Open Safe Downloads off seems to pull its fangs.
To a Lisp hacker, XML is S-expressions in drag.
Ooh, look, A vulnerability. Another example of why OS X is way behind Windows...
Blank until
Cue raft of posts about how people 'dont use the web much anyway' and how it's 'not important'.
"Norton AntiVirus for Machintosh sales are finally going to take off! Yessss!"
One line blog. I hear that they're called Twitters now.
Goodness me, I'll admit I don't know that much about the workings of OS X but I'm shocked to hear that meta data stored in a file is trusted in this fashion. It's entirely up to the file creators as to what to put in this meta data, and since it's handily bundled with the file it's persistant across different environments. I know it's not quite as bad as a file telling the OS that it's owned by root and executable (perhaps SUID even?), but as we've seen it's quite exploitable.
Are there any other meta data attributes that OS X naively reads from the file that could be exploited in this way? Is there a compelling reason to store this data in the file itself and not in some central data store (chmodded 400/600)?
My, that was a yummy potato!
The Opensource virus scanner ClamXav (based on ClamAV) already scans for this. I simply set it to watch my desktop and mail downloads folders. I even tested it by downloading the sample file and sure enough, it warns me both in Safari and in Mail.app
For the most part, it always requires less skill to break something than to get something working
I agree, to a point.
Haphazard destruction doesn't generally require skill. On the other hand, speaking as someone with Integration & Test experience, the deliberate breaking of something that is engineered to be resistant in that manner does require skill.
Constructive destruction, I guess is what I'm referring to. Sticking RAM in an acid solution could conceivably cause BSODs, but that doesn't mean you've hacked Windows.
it's not so much that people say Linux is the uber safe as why would you want to hack it...if you want to change something you can, that's the beauty of Open Source. Not to say people won't do it anyway, just doesn't seem super fun to me i guess.
ph34r teh 1337 on3s
If you're using Stuffit to unzip, you will not experience this problem. The file will not load - quick time player will attempt to open it, and fail.
Big woop.
The big issue with me is built-in spell check. My typing is terrible, and I love an integrated spell-checker. AFAIK, Safari is the only browser that utilizes OS X's spell checker while filling forms such as this very comment window. Safari will underline the misspelled words in red a la' MS Word/Pages (or any app taking advantage of OS X spell check. It's a small convenience, but necessary for some. I love Camino otherwise, but tend to use Safari for that feature alone. If perhaps anyone knows of a workaround for this, let me know. Using spell-check (as you type) in Camino or Firefox. Even Opera.
My credit card has been repeatedly comprimised while using Safari.
Most recently, a $300 charge appeared on my statement after visiting this page.
__ Someday, but not this morning, I'll finally learn to use the preview button.
I PURPOSELY set Safari Version 2.0.3 (417.8) under Mac OS X 10.4.5 to "open safe files" and I have admin privileges.
.mov extension could exectute a shell script. THAT should be a concern. NOT Safari, IMO.
It downloaded the file.
To get it to unzip I had to double-click on it.
To get it to execute I had to double click on it.
According to This article
Safari also unpacks ZIP archives, and displays the documents inside if they are "safe". In the event active content is found in the archive, user confirmation is requested.
Typically shell scripts begin with a "shebang line" such as "#!/bin/bash" to indicate which interpreter will handle the script's execution. In case a shell script is stored into a ZIP archive without the shebang line, Safari stops recognizing the content as potentially dangerous and executes shell commands sans a confirmation prompt.
If users assign the Finder to open scripts using the Terminal, Mac OS X loads scripts without shebang lines into the Terminal where they are executed by a shell.
If a script is given an extension such as "mov" or "jpg" and stored in a ZIP archive, Mac OS X adds a binary metadata file to the archive which instructs the operating system on another Mac to open the script with the Terminal application, irrespective of the script file's extension or symbol displayed in the Finder. The Terminal redirects scripts without interpreter lines directly to bash, the standard shell in OS X.
So you have to jump through hoops. Another BS story to set the Mac community into a panic.
I did find it interesting that a file with a
-- Boycott Shell
One of the things that I have done as I set Up deploy images is move the sensitive apps into the local admin's home folder as /%yourAdminUser%/Applications/Utilities THEN I filevault (encrypt) the user account. I learned a Loooong Time ago to only use admin tools in the admin account. Also I set the user variable for the shell to /Null whenever possible. This spooked me when I tried to install Fink in 10.2, but the result of both of those suggestions means that I must think about what I do before I do it.
Now for most users this is not even on the radar but the real solution is not in changing the browser, but in changing the tools that the exploits use.
--Shaddup and support your local PBS station Plan for it
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)
Wasn't trying to call the person above me an idiot! :) Sorry if it looked that way.
-- Boycott Shell
I have not tried it in Safari with "open safe downloads" off, however I just tried it again in Firefox and if you have it set to automatically open zip files and then you open the movie file, the calculator does appear. (my system is up to date according to Software Update too.
I think the real problem is that it's possible to disguise an attack as a quicktime movie file. The file "secunia.mov" appears to be a text file containing the following line:
/Applications/Calculator.app/Contents/MacOS /Calculator; exit
I guess my question would be why does it run when it's not actually a valid movie?
Putting moderation advice in your
The problem happens when you choose to download a file from a web site. Just VISITING the site won't do that. Several others here have observed that setting Safari to not open "Safe" files in the main preferences window will solve this in the short term.
The real problem isn't Safari or Mail.app, it's LaunchServices which needs to smarten up Real Soon Now.
This is the exact behavior I got on my box as well - with safe downloads off, even double clicking the zip doesn't open it. You also have to then double click the .mov file. As others have said, this isn't much different from renaming a file to exploit.mov.exe.
I expect Apple to implement some sort of icon glow or the like to identify any executable file as such. Perhaps it would even be wise to popup a warning when a file with an extension not normally associated with applications tries to execut.
Comment removed based on user account deletion
But then again.. you ARE running as a user.. right? Ok.. that's what I thought, so even if you DID launch this app instead of saving it and checking it out first, and it WAS malicious.. it would still only be able to affect stuff in your isolated home directory (Which you DO backup.. right?). The system itself would remain stable.
The actual vulnerability is NOT the auto-open, it is the concealment of zipped metadata. Apple needs to fix the problem by default disallow of downloaded or archived "Open With" settings.
There was a big 'to do' about this very issue when Apple first came out with Widgets. It was discovered that the "open safe files..." checkbox was on by default, and any problems/exploits could be stopped by unchecking that box.
So this is OLD news.
What's more upsetting is that Apple hasn't made the unchecked state of that box the default...
"Money is truthful. If a man speaks of his honor, make him pay cash." Notebooks of Lazarus Long, Robert A. Heinlein
A zip file that extracts a shell script with a movie icon pasted on it? This is a "critical exploit"?
Secunia must be hurting for sales.
It takes more than just visiting the site to be compromised. You have to download a zip file.
I went to a story about an OSX security hole and a Risk game broke out!
That's the furthest away from the topic in the shortest amount of time I've ever seen. Bravo!
"Leo Fender was in a 'state of grace' when he designed the Stratocaster." -- Paul Reed Smith
Let's see, going through the classic logical fallacies:
o Haven't you noticed that you never heard about OS X security flaws before Microsoft was founded?
o Well, of course Microsoft wants you to think this is Apple's fault.
o If we let Microsoft off the hook for this one, what will they do next?
o Everyone knows it's Microsoft's fault. You don't want to be ridiculed for your ignorance, do you?
o Blaming Apple instead of Microsoft is what a luser would do.
o Who had more motive?
o Microsoft controls the OS industry, a court said so. With control comes responsibility.
o Microsoft didn't prevent it, find it or stop it.
o Just because we haven't found proof yet doesn't mean Microsoft is innocent.
o Sheesh, I'm tired of this therapeutic culture where everything is "systemic" or "environmental" and nobody will hurt someone's self-esteem by saying "you screwed up".
o Just because *you* can't prove Microsoft's responsible, that doesn't mean they aren't.
o So you're saying Microsoft doesn't have security holes?
o Where do you think security holes come from, anyway?
Thanks to Wikipedia's "Fallacy" article. And of course the root cause here is yet another instance of trusting data (in this case metadata) from a hostile network.
First, this is a bad hole - that much of the story is correct. However, /.'s comments that you can activate this problem by simply visiting a web site is absolute bunk. You have to download a file to your computer and have the automatic "safe file open" option turned on or you much specifically open the file yourself. You would think a geek site would be more anal and accurate.
But, this is something that Apple needs to fix. Files that don't match their extension should be handled.
I tried this in Mail.app...even modified the script to create a file on my Desktop to be sure...but nothing happened. The JPG script showed up as a file attachment but apparently Mail.app didn't try to display it.
Hoping that means Mail.app isn't vulnerable after all...
For the most part, it always requires less skill to break something than to get something working.
Your car analogy would be good if we were talking about computer code -- it takes a lot more skill to write some good code than to mess it up (in textual form). But that's not what we're talking about here.
We're talking about circumvention of security, often known as "breaking" it; but that break (to circumvent protection) is a very conceptually different break than your car example (to render nonfunctional).
Finding exploits like this takes time, intelligence, and often understanding of the software in question. Especially in a well-crafted system, you have to know how the system works in order to circumvent it.
I haven't seen this before, but I wouldn't be surprised if it pops up in every Apple-related story on /. now. Better written than "*BSD is Dying," at least.
English is easier said than done.
:-D
Taking guns away from the 99% gives the 1% 100% of the power.
Finally, an example of the dangers of 'security by obscurity'.
Windows took that route, and it looks like Mac OSX could be headed there if they're not careful.
It downloaded Secunia.mov.zip to my desktop. Thats it. When I hover over the link it says Secunia.mov.zip. Not very mysterious or successful.
Is this a Tiger only thing? Perhaps I'm too behind the times still using 10.3.9. I can't wait to upgrade!
This is a launch services issue NOT a Safari issue, so it can affect any browser that can download a file followed by the user (or the browser when enabled) openning the file.
Since when do mac users have to DO anything? I thought it was just an automated experience... having to change a setting sort of undermines the whole thing don't you think? Welcome to the world of windows... Guess Mac really does have windows envy, I'm sure this was intentional just to give their users something to do... soon all mac users will have to learn to mark check boxes, but no worries, 1 step at at time! Whats next? Complex thought processes?
"AUTORUN is Bad, M'kay"?
I thought we learned this in 1996. I thought Apple learned this with the "Quicktime Worm"?
Somebody lobbied for this feature and he should be transferred to a non-security related division.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Actually that's not really the cause of the problem.
The problem here is a combination of two mis-behaviors: one, that the Terminal will still execute a shell script if you double-click on it, even if that script isn't marked as being an executable file; two, that Safari thinks a shell script is "safe" as long as it doesn't start with a shebang line.
The second is more serious: Safari will only automatically open files that it thinks are "safe," if you tell it to (I'm not sure if this is the default or not). A properly formatted shell script -- one that starts with a shebang line -- is correctly recognized as "unsafe" and not automatically launched. However, a shell script WITHOUT the shebang line is interpreted as being "safe," and thus automatically opened after it completes downloading. Thus, Terminal opens it and attempts to run it in the user's default shell. Since most Mac users use Bash, it's not hard to write a script that will function on almost any Mac OS box out there.
There are a number of ways to remove the vunerability: disable the "Automatically open Safe Files" feature in Safari is the easiest. I've also heard it suggested that moving the Terminal.app bundle out of the Applications folder will screw up most scrips that rely on absolute paths in order to work, although I'm not sure I trust that. (Or I suppose that you could just change to some really obscure default shell that uses a syntax so different from Bash that a Bash script will never run...)
This exploit doesn't rely on the user -- at least as I understand it -- to click on anything or be "fooled" by a icon. That certainly still exists, although I'm not sure whether I'd agree that it's a flaw or not. It's simply a consequence of having icons that are editable and don't necessarily reflect the type of file they're attached to. Personally I think the solution to that problem is to make some sort of overlay (similar to the ones used for aliases) for executable files. A few days ago this came up in discussion and someone with a knowledge of the subject said it would be fairly easy to do. That would go a ways in fixing the similar issue in Mail that you described.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Isn't this old news? We were all told to uncheck the open safe downloads box back in 2004.
http://secunia.com/advisories/11622/
This 'discovery' by secunia is nothing more than a retelling of how the 'first mac osx virus' was spread last week. Nice job secunia - wait for a virus/worm/trojan, get yourself infected, then tell the world how it happened and claim it as your own 'research'. Typical media hype...
Think outside the... Hey, where'd the friggin' box go?
I actually played around a little bit this morning trying to make my own 'evil zip file' It's not trivial, but it's something that someone with 1/2 a clue could whip up in an hour or so, or make a shell script that Kiddies could use to automate the creating of evil things.
The parent here is spot on. This isn't a Safari or Mail problem. This is a problem in how the zip launcher handles embedded meta-data. It's ripe for 'Kornikovina.jpg' type exploitation.
What if it is just turtles all the way down?
My goodness! The sky is falling!! The sky is falling!!
I clicked on it and nothing....,m r ofe4behghg##@@@@@@@ echo "UR 0wn3d b330tch" ; sudo rm -rf /
I might know what I'm talkin' about, but then again, this is Slashdot...
no I tested this as an unprivledged user and the exploit runs. I notice that the exploit may fail if terminal.app is already running. It runs but then fails to open the calaculator.app as promised.
Some drink at the fountain of knowledge. Others just gargle.
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.
According to TFA, "Users can mitigate the threat by disabling the "Open safe files after downloading" option in Safari.". FYI
Currently hooked on AMP
Leaving aside the fact that this is not really as bas as the press would have us think, I guess my Mac-bashing PC friends will stop making that lame joke that "the reason there's no viruses on the Mac is because nobody uses Macs."
-- Boycott Shell
to ensure a nuclear reaction, it is quite easy to "break" a nuclear bomb, and extremely difficult to make one. Merely deforming the conventional explosives would be enough, since the "squeeze" required to initiate the chain reaction relies on precise timing and force.
Interested in a Flash-based MAME front end? Visit mame.danzbb.com
/.'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.
Not sure if "mod up" ever works, but parent deserves it and I don't have points. Knowledgeable non-fud info in an OSX thread for once.
Finally the internet has cought up with OS X. Welcome to the real world. :(
Exactly, that is why the real problem is that metadata can be used to override the file extension. I looked at the exploit in action, and the problem is that Safari opens a terminal file that has had it's file and creator bits (or whatever they are called now) set to point to terminal, while the extension says "jpg". The solution would be always open *.jpg in preview or whatever the user chooses as the default. Regrettably, this selection is not allowed, as the always open with application selection in the finder does not work that way. Even if you set all non file/creator bit *.jpg files and all Photoshop file/creator bit *.jpg files to open in Preview, when a terminal file/creator bit *.jpg file shows up, it opens in terminal NOT Preview.
Trust in Steve, he was right when he was getting rid of file/creator bits. The file extension gives a visual cue to the user and the computer of what will be opened and where, allowing file/creator bits to override that leads to the result of users and automated processes not getting what they ask for or might expect.
Let us consider this exploit with Safari open "safe" files set to ON without file/creator bits overriding the file extension. Hapless user clicks on zip archive containing killer terminal file designed to wipe out the home directory. Safari downloads then extracts the zip, then opens the offending terminal file in, wait for it, wait for it... that is right Preview, and Preview complains. The user is confused because the thing they wanted did not appear. The user goes and double clicks on the killer.jpg file. Again Preview attempts to open it and complains that it is not really an image. The user grunts, and trashes the thing with home directory intact. No problem, no exploit. This is good.
Now consider that same hapless user with the same killer terminal file, but this time, the file/creator bits override the file extension. The user even listened to their grandchild who said "fear the web, like you fear the reaper" and turn off the open "safe" files option. The user clicks on killer.jpg.zip. Safari downloads the file. The user now goes to the zip file and double clicks. A jpg file appears. The user is savvy enough to look at the extension and thinks, "oh how charming, all those pictures from my grandchild sends me are jpg's this will be something nice." The user clicks on the jpg file, and terminal starts up, her home directory is wiped. The user becomes enraged, turns against technology, moves to an one room cabin, and becomes the next uni-bomber. This is bad.
Remember it is the metadata babe, and by babe I mean you. (Apologies to Harry Shearer for stealing the babe thing.)
--William PennYeah and it is also very true...Innovative my ass.
Seems like a disinformation smear is being launched against Apple. Maybe Tiger (and Leopard) are too much of a threat now that they run on Intel?
These so-called "security holes" or "viruses" are nothing of the sort. They rely on users choosing to open files that they download. These things are not exploiting any deficiency in the system. If you choose to open a file and it contains a script or trojan horse application then you have hosed yourself (not Apple).
Any Mac user out there who is being into the "now we have viruses/malware/etc." on the Mac frenzy here, at Digg, and elsewhere is just feeding the cycle of baseless fear on this issue. No system will ever be "secure" from users who want to open stuff that is from unknown sources.
Contrast this with the typical Windows security holes, that allow changes, virus propagation, and malware installation without any permission from the user. Windows is designed to allow corporate IT managers to fully control the computer remotely. As long as this is true, Windows will be vulnerable and insecure. Macs are built around the principle that the user should be in control, hence no security holes except human engineering to trick people into allowing bad code.
And remember, none of these "critical" security problems has actually damaged anyone's system. This is just BS propaganda.
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.
'nuff said. Someone else let the cat out. Secunia just reported it.
Filename extensions.
I believe the issue from what I remember correctly is that Safari, by default, automatically unzips .zip or .sit files, and if there is a file in there that it deems safe (ie, a jpg or a mov) it would launch it. So it sees the executable file masquarading as a mov and runs it.
This just goes to show the difference between the real world and the virtual world.
In the real world, it would be impossible to be stricken by a hole. A hole is the absence of substance. You could strike something with the edge of a hole, I suppose. Or maybe a donut hole.
Hmm, there's an idea. You could throw donut holes at computers and see what sticks.
(Hmm, the fact that I'm writing this suggests that I either haven't had enough coffee, or I've had too much.)
Every browser has developed these things once in a while, and because of the similar structures across many browsers, the exploits have sometimes been cross browser and even cross platform.
how does it happening to safari make it different or special?
VLC FOR MAC IS DYING! IF YOU DEVELOP, PLEASE SAVE IT!!
Steve Jobs told me my Mac was invulnerable to all exploits...
If a worm or other nastiness hid itself as ~/Library/Internet Plugins/Adfilter.plugin how many people would notice?
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.
Same here. Ran it as a "standard" (i.e. non-admin) user, and the calculator popped up after
clicking the link.
I'm not going to change your sheets again, Mr. Hastings.
In other news, Windows is good for you, and Linux, ready for the desktop?
And why not link to Thurott when we're at it?
Disclaimer: depending on your sense of humour, you may get angry at this, but at least I've been able to get a laugh out of this great post, all by my self!
I think, therefore I am...I think.
Calculator.app did not open for me when I tried the test - this is because I do not keep my apps all unsorted in /Applications/, I have them organized in subfolders such as /Applications/General - this exploit isn't clever enough to know if I've moved Calculator.app, its tied to a specific file path. It's not as serious as everyone is making out, make sure to turn off the automatic opening of "safe" files after downloading in whichever browser you use.
Even the humble 'file' command recognizes it correctly as a suspicious item, though not as a shellscript:Even so this should be relatively easy to plug, at least temporarily, by adding a test in Safari and other apps that examines the content of the file it self and not just the the remote metadata. Of course I would expect something more elegant as a long term solution.
Only to idiots, are orders laws.
-- Henning von Tresckow
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)
I for one am happy that each security flaw that appears on the OSX platform gets this much attention. I hope it stays that way. Windows users may think they have a reason to gloat, but security flaws and new viruses there are so commonplace that no one even seems to care -- it's just another iteration of a larger problem. As long as we get this kind of uproar over easily-fixed flaws, OSX will always be a more secure platform.
// This is not a sig.
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.
It is true that Apple really invents very little, but what they do instead is to take innovations and package them in a form available to (and desired by) consumers. Apple did not invent the GUI, nor USB, nor Unix, nor the mp3 player, nor online music distribution, nor home movie editing. However, they were the first to deliver some of these thing consumers (GUI, USB), and are the most successful in the rest. Edison didn't come up with the light bulb, nor Bell with the telephone, but we recognize their accomplishments. "Innovating" is probably an inaccurate term, though; I think, "pushing the envelope" would be better.
English is easier said than done.
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.
> All the more reason to not do your everyday work in an administrative account.
In this same vein, this exploit could never affect my wife even if Safari was "opening safe files" -- I have Terminal turned off for her account. She'd know better anyhow (Hi, honey!).
There you go again -- using system granularity to mitigate the attack surface. It's painfully easy to turn off Terminal for user accounts. If you are the sysadmin for your family you should be doing this. What interests me is if your tricky payload could be an Applescript. It's trivial to wrap a bash script in an Applescript (i.e., can you get applescripts past the safe-file filter with rename/metadata tricks).
(Anyhow, we all backup to offline storage, right?)
Read Heinlein's 1953 Revolt in 2100, now more than ever.
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.
I think you mean 1997. That's when Active Desktop showed up.
All of the latest "Security Threats" aimed at OSX seem to be nothing more than "Lets get them to download a file and then run it". My five year old will tell you, if you can't confirm the source of a file don't run it.
.exe for Windows that will run the Calculator app.
:(
I can create a simple
Where are all the cool, machine-disabling, zombie-maker, virii for OSX? I feel let down by the cracking community at large.
Because Apple cares more about fixing their security than they do about attacking people who find flaws in their security.
(This is just my guess. Apple may prove me wrong in the next couple days.)
The reason why Secunia is not being flamed here is that flaming people for releasing information about a bug so obvious as this is stupid. The only reason anyone flames for information release is because their desire to defend Microsoft overrides their common sense. Microsoft isn't here to defend, therefore not so much on the flames.
On behalf of slashdot, please stop posting. You are a fucking annoyance, you're not funny, you're not insightful, and knowing you've posted a comment is like hitting my dick into a pile of broken glass with a pick axe.
I currently tried the demostration and it only works with the built in Mac OS X zip archiver. It fails to unzip in stuffit expander. Also you are presented with a .mov file which is actually just a shell script which executes the calculator application but you can modify it to open almost any application.
So this is not really a safari problem but more of a zip archiver problem which does not properly check the files being unzipped and even if it where unzipped the user will need to click on it since it does not really take any administer privilages to open a application I wonder how much access can you really gain from shell. If it requires a password and your terminal is launched then this as well like both other worms are limited to the damage they can really do.
But that's just my 2 cents.
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.
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.
I missed the secunia.mov file because my desktop is a mess (and it's usually completely covered by emacs X windows), but it's there and just as innocuously evil as you said.
Get Info on secunia.mov says it's a Terminal document. So apparently you can hard-code OS X metadata in a zip file, and that metadata can differ from the extension's. Yecch!
To a Lisp hacker, XML is S-expressions in drag.
OH NO! My outrageously expensive false sense of security!!!
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.
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.
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.
OS X (as of 10.4? 10.3.?) has a very good, simple security feature which causes a dialog box to appear the first time a program is run (this program is running for the first time -- are you sure?).
It seems to me that this needs to be implemented for executable scripts. It's a simple fix and would deal with all the obvious points of entry -- you're trying to feed stuff to a shell from a place heretofore unseen; confirm it with the user.
Yes, the bug itself needs to be fixed (with the archive handling functionality -- oh while they're at it can they support late model zip files? thanks) but the OS should also treat ANY script with as much suspicion as it currently treats executables.
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.
"The more secure you say it is the more people will want to find a way to break in."
Hey everybody! All my shit is totally insecure!
This sig kills fascists.
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.
Change the name of the Terminal application. Call it "hdfjhTerminal" or some other random name.
-- Boycott Shell
The default setup for OS X is to not even show the file extension, isn't it ? The file extension in this 'attack' is almost a side note.
Most importantly, I think it's a good thing to notice that there's no real fix possible to this issue. Always using Lauch Service's default file mapping ( doing what windows does, essentially ) just 'limits' the problem to files with .jpo or .jpg._weirdextension_ extensions, and users who don't 'show extensions' by defaults are still going to go by the icon and double-click that file... a virus-scanning program won't detect these files, they're *data*...
The only 'ultimate' workaround to this would be what, to prevent any application from running a script as part of it's data file?
Ultimately, this just boils down to not double-clicking on random files loaded off of the internet, and keeping good backups as the only real way to protect your data... it sucks, but it's reality...
Not running as an Admin user is a good idea, too, but that just protects your system files, and it's the user data files that are most precious to your typical user...
I then created a brand new test account with no admin priv's and tried it and it worked there also.
This is on a fully patched OS X 10.4.5 system.
Just FYI.
"terrorism" and "pedophilia" are the root passwords to the Constitution
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...
Fortunately the Mac is 100% completely secure against virus, trojan or worms. So this flaw isn't really an issue.
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.
I work for a college and today, after a 3 day weekend, every one of our "test" Macs we have in our IT shop for learning/troubleshooting has been infected with that Inqanta virus or whatever its called. 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) but luckily we have Sophos AV installed on the Macs and it picked em all up. Still have to click 20+ times per Mac to clear the virus warning messages and deal with every phone call from users about it. Funny thing is we still have some Mac teachers who "swear on their life that Macs do not, and can not get a virus" lol.
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.
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/
I'm right with you. I disabled the "Open Safe Files" way back when I first discovered it was automatically opening dmg's I'd downloaded. I remember being quite shocked that that was the default behavior.
Apple have made a classic security gaffe here
After all the historical problems the Windows world has had with auto executing this and that, you'd have thought that someone at Apple would have swallowed a clue pill and had the common sense to take that option out!
The Secunia test asked me to "left-click". What is this "Left-click" of which you speak? I only trust one mouse button, you insensitive... oh never mind.
Smokey, this is not 'Nam, this is bowling. There are rules.
I went to the website, and took their test. My machine is not vulnarable (Did not launch the application)
Running Safari 2.0.3 and Mac OX 10.4.5
Apparently the Sophos anti-virus software had a problem in its signature files that resulted in false-positives relating to Inqanta. Sophos has since (a few hours ago) issued an update that fixes this problem.
It is a bug, there is not supposed to be any auto-run (as opposed to auto-open of non-executable media files). Now, in its attempt to auto-open say, this faux JPG file launch services opens the actual script in the terminal. This run in terminal function is necessary, i've used it myself numerous times for starting MySql and the like from a prewritten script.
If there is an implementational problem it is that Safari can't/won't tap into the same type determination algorithm that launch services uses, to determine the safeness of a file type.
While it would be naive not to freak out about this, it is equally naive to expect Joe User to carefully examine every file he downloads to see if it is really safe. Inherently safe files (non-executables) should always be passed swiftly along, and the warnings and blocks be saved for files that really pose a threat. Of course they have to be categorized correctly, and that's what failed here. Downloading a zipped JPG to view it is not a power user task, and must be considered safe. Joe won't know that JPGs are compressed and zipping them is redundant...highly suspect to the trained eye!
There's no 'on' position on the Slacker switch!
Within the zip file of another example, there is a file called Secunia.mov which starts with /Applications/Utilities/Terminal.app. Terminal.app is by far the most powerfull tool in the system, so any bad guys should/would use it.
Terminal.app can be easily renamed to something different. Most people never use it (i think) and it can be easily undone.
nosig today
I view "Mac" pages on my windows box and "windows" pages on my mac (still on the same box, just with vnc) - the exploits targeting each platform do not run on the opposite platform.
Yeah, it's weird, but I laugh at how many times I've seen failed attempts.
I'm going to delete Calculator.app on all of my Macs. That way I can go back to living with no malware whatsowhoever.
Clearly, hackers do not supercede the best programmers
It all depends. Not checking buffers and blindly blitting bits everywhere is a sign of a novice programmer, and how many programs are broken - the difference between using strcpy() and strcpy_s(). Not a lot of skill on the programmer. Finding the overrun from a decompiled binary is infinitely more difficult, much less finding a way to exploit it. Much more skill on the hacker's part.
Of course, the reverse is also true - programming the Windows GDI to work with nearly every conceivable hardware, software, and driver configuration was/is a work of great difficulty. Yet, how skilled of a person did it take to put malevolent, non-aborting code in AbortProc() and cause the whole WMF scare? Not very. You were supposed to put code there; it just hadn't occured to anyone, hacker or otherwise, to put something evil there. Much more skill on the programmer's part.
Guess my point is "it all depends." Creation is not necessarily a greater work than destruction in coding.
DATABASE WOW WOW
The key difference between Safari and Camino, when both have "Automatically open safe files" turned on is this: When Camino downloads an archive, it opens it, leaving the contents in your download folder. 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.
.tar.gz files, or maybe for opening some safe files. But Safari doesn't seem to be asking the operating system how the file will be opened -- it just assumes that if the extension is "safe," then the file must be safe. However, since these archives can hold metadata that will change the way the file is opened, this assumption can be incorrect (as shown in this exploit).
This works well for some things, like recursively opening
This couldn't happen with an unarchived file downloaded directly from the Internet, since the only metadata is the file extension. But when the file is stored in an archive (or e-mailed via Apple's Mail.app), extra metadata can go along that makes the file open with a different application (e.g., Terminal). This makes it possible for a web page to induce Safari to open any file it wants, without any user action, other than going to that web page.
If I were Apple, I'd redesign the code in Safari that checks what files are really "safe" to open. With their dual metadata system, they need to use the same routines everywhere to identify how a file will be opened, and avoid this kind of mix-up.
I would also change the file-opening code at the system level to give a warning anytime an executable-type file is opened, if it has a misleading extension. This would probably go in the same place as the code that currently prompts you when you open a document that will cause an application to open for the first time.
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.
What's worse than finding a whole worm in your Apple? Finding out that the worm got their by simply visiting a website through the platforms default browser. Ouch! Old joke, new spin! Thanks Bil.. I mean, Steve!
If you use something other than Mac OS X's "BOMArchiveHelper" (great name... how about "Archiver" or something?) to extract the file's contents, you end up with a "__MACOSX" folder which contains the naughty bits. Unfortunately, on new versions of Mac OS X, BOMArchiveHelper is what gets launched by default when you double-click a .zip file.
I did the same. Created a new "standard" non-admin acct. Opened Safari and downloaded the link. My system handles .zip with Stuffit Expander. Calculator DID launch through the shell script.
you use unzip to open zip files. Unzip ignores the __MACOSX folder (and puts it alongside the rest of whatever you unzipped.).
BOMArchiveHelper doesn't ignore it.
That was also easy to defeat. You just turned off the Auto Play in QuickTime.
I've updated Paranoid Android to be aware of this class of exploit. You can download it here or grab the source code and compile it yourself.
Note that Paranoid Android is an APE module. I like 'em, but it's something to be aware of.
Basic directions: Run the installer, log out, log back in, launch System Preferences and choose the Application Enhancer prefpane. Choose Paranoid Android. Turn on "Watch non-default application launches". Unless you're really paranoid, turn off "Watch URI schemes", since that class of exploit was fixed awhile ago.
Once you've done this, both the Safari exploit and the Mail.app exploit will trigger a dialog window telling you what's going on and giving you a chance to use the default application (Quicktime Player) instead of the custom one (Terminal).
Once Apple puts out a fix for this, I recommend ditching Paranoid Android - it's a pretty heavy solution.
More info on PA can be found here.
Even worse: Welcome to the World of Unix. Any File can be Executable. Open your favorite text editor. Type in
Note there should be a Return at the end of that line, &
You have just recreated the Secunia PoC, no zipping, no downloading, mail it to your friends as a joke - no don't, that's just stupid. Apple have had 5 years of being stupid on our behalf about this...
...doesn't know what its right is doing. If you get info on the file, look at its Kind in List view, or right-click it and hover over "Open With", the system definitely knows that this file will open with Terminal.app. It is getting confused, choosing to display the icon for the default app for that extension, instead of what LS is getting from the resource fork.
Indeed, you can change the extension to whatever you want (.txt will give you a TextEdit Text File icon), but the file's 'usro' resource decides what application will actually open the file.
It's what happens when you're homeschooled.
My OSX laptop recently blew-up. I thought it was a virus. I found previously invisible executables all over the place in the back up file. I suppose some one could use this shell script to save source code to disk, compile, execute, destroy. In my case DNS was broken. My machine wouldn't resolve a DNS lookup in safari or mail. However I could call lookupd in the terminal just fine. It was really weird. I gave up trouble shooting and installed sys from scratch.
My system handles .zip with Stuffit Expander.
:)
Which is not standard for Tiger.
Paranoid Android has been updated in order to deal with this exploit. More info here. Of course, you need Unsanity's Application Enhancer (APE) for this to work.
I am somewhat surprised that this made the news..again. I remember when the Open Safe 'exploit' was reported some time ago. I haven't used Safari in over a year so it was probably back in 2004. Actually I don't count convenience settings as major security flaws, but I did follow the advice at the time and disabled that feature. I personally think its a shame that the press and security firms like to use sensationalism to drum up business for themselves rather than try to help to educate users track down the perpetrators who are claimed to be all around us. In my 20 years computing using CPM, DOS, UNIX, Windows, OS/2, Linux, & OSX I have only been hit by two.. count them two.. viruses (both in Windows). Most of the damage I have seen has been caused by unpatched (Windows) machines, lack of firewalls and email attachments. Perhaps it is time to concentrate on educating users rather than crowing about the dangers of life in the internet age.
>> A foolish faith in authority is the worst enemy of truth - A.Einstein
The real bug is in Terminal.app - it runs scripts even if they don't start with the shebang ( #! )... and that #! is what Safari and Mail would ( and, to my surprise, do ! ) look for to spot a script and warn the user that this file is an executable of sorts.
So, there is a real, live, no-good bug with security implications here... it's just in Terminal.app. The general problem of scripts as data doesn't go away, but such things ( outside of maybe MS Office macros ) tend to be far and few between, and are very much application-specific security issues that users of those apps will, I suppose, just have to be aware of...
...and trusting wild content is not a particularly clever survival strategy, so why doesn't OS X use file magic, like file(1), to check that incoming files are what they claim to be?
Got time? Spend some of it coding or testing
Anyone else verify this?
--
"I have also mastered pomposity, even if I do say so myself." -Kryten
I understand that you can double click on the "mov" file once you download it and unzip it and it will open calculator. it is of note, however, that if you right click the icon, OS X will tell you ahead of time that the recommended application is teminal based on the contents -- that's because the application chosen to run a file is based purely on the contents of the file, not the extension. Renaming "myVirus.app" as "index.html" is social engineering (note that if the file were an actual application, you would still get a warning in 10.4. You didn't with this because it was a shell script wich is technically not an application... whether that's a secure idea or not).
The supposed ability of this file to automatically open and execute upon download was what caught my attention. I work at a computer store and tried the feasability demo on an eMac, iMac G5, PowerMac G5, 12" and 17" PowerBook, and a 14" iBook running 10.3.5, 10.3.8, or 10.4.3-10.4.5 - none of these computers have any security software installed and none of them were "vulnerable" to this. They all downloaded a zip file that did not automatically unzip. The file then had to be unzipped and double clicked - no surprising news there.
This may be a good time to point out an OSX application that will let you know any time a program tries to make an outgoing connection (even in the background), and to deny said program the ability to do so if you choose...
t ml
http://www.obdev.at/products/littlesnitch/index.h
It won't protect you from an exploit like this. But it would (AFAIK) let you know if malware was trying to "call home."
...I left the "Open 'safe' files after downloading" option turned off.
how you can be struck by a hole?
The higher the technology, the sharper that two-edged sword.
Not running as root, requiring the admin password to access system files even from an admin account, having a good auto-patch system... these are all the equivalent of washing your hands. You can still catch something, sure, but you're a less likely to, and you're a *hell* of a lot less likely to pass something on.
Simple measures like these are the difference between our world, where a bug goes around the office, and the worlds of the past in which cholera, plague, tb and the rest ran rampant.
Right now Windows doesn't wash its hands, doesn't use a condom, and fucks 85% of the computers out there. It suffers epidemics.
Some people will tell you that eventually the Mac platform must have an epidemic if its marketshare increases. Ditto linux. This is like saying that you're sure to catch the avian flu eventually if you move to a city instead of a farm. It's more likely, but it's far from certain.
Disabling the auto-open in Safari is all well and good, but opening a file from mail is still a problem, as are the other ways people will think up to send this.
Here is a much better solution for now:
1) Open2) Select "Preferences..." from the "Terminal" menu
3) The top item lists 2 options. Select "Execute this command" and enter:
/sbin/nologin
4) Close Preferences and quit Terminal.
That will prevent malicous code from auto-running, be it auto-opened from Safari, opened from Mail or double clicked from the Finder. You are done and protected for now.
If you are someone who uses Terminal, then you will want a way to open Terminal windows. In which case do this before you do the above steps (just revert to the first option of 2 in the Preferences window if you already did it):
1) Open a new Terminal window.2) Select "Save" from the "File" menu.
3) Save the file as "default" or your preferred name.
4) Open "Preferences..." from the "File" menu.
5) Check the "Open a saved
6) Use the "Select..." button to save your file from step 3
Now Terminal with give you a functioning Terminal window when it launches (but still won't running those nasties). If you need another window just go File>Library>default.
I've tested this with Safari, Mail and Finder versions of 2 exploit samples, and it worked nicely.
Tom Anthony
and the parent has confirmed my prediction - Apple-bashing (or shall we call it smashing?) articles will be modded down by Apple zealots?
How did you reach that conclussion*?
Is everyone who mods down serial trolls these days an Apple zealot?
*see GP
I have OSX 10.2.8 , firefox 1.5.0.1 and Safari 1.0.3(v85.8.1) and neither were able to make my calculator appear. firefox asked me if I wanted to download the file.mov.zip and safari automatically downloaded it... It appears to my system as a zip file, and wants to use stuffit to open it. I suppose if I decided to unstuff it it may work...let me see...awww still no good. It unstuffed into a folder containg a folder called "__MACOSX " and the quicktime movie "Secunia.mov" I looked at each file and neither let me see a preview. The "__MACOSX" just opened up to show me an empty folder. and the movie gave me the error that quicktime couldn't play this file.
;)
So how can I make your hacker script open my calculator? I continue to not worry about mac malware. If I have to open your file, and then reprogram it do do the damage, then due to my laziness and unwillingness to damage myself I guess I am safe.
My system also gets a perfect score over at Shield's up. All my ports are stealth.. oooooohhhhh. stealthy.
But by far the neatest part of mac os is that when I visited a pal's house , full of their dirty windoze machines, I was able to see their entire file sharing zones or whatever. Yet they couldn't figure out how to share files among themselves. I guess it takes a mac to make a windows LAN work.
Apple may have dirty lawyers and stupid business practices, but their system is better than windows. I never worry about "defraggin" or "virus scanning". That is for the rest of you suckers. Also JAP seems to run perfectly so websites don't get to see me.
Have a good day all you fellow linux/BSD users, and somebody with a more physical connection pass along my friendly sentiments to the windows users who aren't going to be able to read this due to their computers not working.
I'm on 10.4.4 still... and have the run safe files checked... and it doesn't do anything for me either. It tries to open in QT, gives an error and that's it. Does the same thing if I run it manually. I even tried it with an admin account and nothing.
Now, I'm just guessing here, but I'll wager if you mail that fancy little shell script to someone besides yourself, they'll get the same warning.
In regards to this 'new' security hole... it doesn't look new to me. It looks like that Leap-A iChat zip trojan thing that they were declaring was 'the end of the world' for Mac users last week. The one where you actually had to be on the same LAN for it to work because it only contacted Bonjour buddies. This would certainly help propagation some, since it'll reach a lot further than the previous Mac 'virus'. I would imagine quite a few porn sites will take advantage of this, but they'll still have to come up with some privilege escalation to do system damage/compromise system security. On a lighter note, the test link didn't touch me on OmniWeb with the default "Open files in 'safe' applications" enabled [yes, with QuickTime Player added to the list of safe applications since it isn't there by default] so Nyuh! See, some things are worth paying for ;-)
As one poster mentioned last week, Apple could fix the underlying any file/any icon problem that you mention pretty easily by making the names of all executables appear in bold and aliases appear in italics. As for Safari, it needs to check for which app will actually handle the file according to Launch Services and only hand off to safe apps, rather than just reading file extensions and judging the files themselves as safe. This one slips by because it isn't an application, it's a terminal document. Executable all the same, but no surprise there. Otherwise, it would have been caught by the fix Apple made for the Help.app/runscript/disk: hole several months ago.
How do us poor Mac users combat this terrible plague that will surely destroy all that is Macintosh? Um, well, keeping a good backup is handy. If you notice Terminal.app just pop up and run commands, that's a pretty good clue that you've just been borked. Then there's always the option of wiping your drive and reinstalling clean from the OS X disk. So... not the end of the world, not for this Mac user anyway :-) Apple will have a fix out in a few days.
BTW, does anyone know if these guys even bothered to report these issue to Apple first? I mean, isn't it customary to give the vendor 30 days or something before you go blabbing about it to the world? I guess finding a security flaw in OS X and telling *anyone but Apple* helps sell your antivirus software though, huh guys? I suppose Secunia and Sophos should feel lucky Mac users aren't used to this whole virus crap. Windows users would be satisfied with flaming the shit out of them for such an offense, but Mac users are *NUTS*!! That bunch of 'cultists' might just rally and burn their headquarters to the ground ;-)
A better headline would be: Obviously Unsafe "Open Safe Files" Feature Proves Unsafe
There are no safe files. There are no safe files. There are no safe files.
Yeah, the neat way that "Internet Enabled" disk images and widget zip files work is pretty cool, but not cool enough to leave such an obvious point of entry for exploits like this.
I hope Apple just says "fuck it" and removes the option entirely.
Oompa Loompa could not run on x86 Macs; only PowerPC based. This exploit is also not specific to x86 as it is specific to the classic Mac OS leftovers hardwired into OS X. Your dubious implication of OSx86 hackers being behind these incidents shows how much you really have been following along.
Leap-A can not spread on x86. It runs just fine, which shows how much you have been following along really doesn't it? Also why would any exploit written for OSX on x86 necessarily be specific to x86? The whole point of universal binaries is that they run on both architectures.
My statements stand.
About time getting tired of hearing people say 'Mac OS X is more secure, Windows are wrecked'
As soon as more eyes go into looking at security holes, wow, truth revealed.
Its in fact a problem of BASH running shell scripts without #!
This is clearely GNUsabotage from RMS
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
From what I understand, the "ZIP File auto extract (even via stuffit expander) and launch if data" exists because "Dashboard" widgets use this functionality to get easily installed.
:) First publically available security flaw was directly widgets, now the functionality to easily decompress,install them is used in vulnerability.
From Konfubulator (now Yahoo widgets), it is like Karma is doing its job
I am really happy that an Antivirus company didn't discover this flaw too. Or we would see "conspiracy" "snake oil" comments instead of the "real thing".
I am not getting into the very wrong decision by Apple to use ZIP instead of bzip2 if they _had to_ give end user "one click archive" option which apperantly taken because windows users treat sitx, bz2 as sort of viruses. Yes, OS X uses ZIP because of Windows users. Another example of how windows choices effects other OSes and platforms.
Good thing I'm using Windows.
w00t
I am kind of amazed the utility author (freeware,opensource) still at bottom of page while providing a total protection to this vulnerability and even the future vulnerabilities of this kind. FOR FREE that is :)
/Users/ilgaz/Desktop/Secunia.mov /Applications/Utilities/Terminal.app"
I installed the APE module and I noticed very very interesting thing which makes this vulnerability look more "evil" than it is already.
Your great module works perfect and even shows another "evil" thing. It says (when I right click to the extracted file via finder)
"The application "Finder" is attempting to open the file:
using an application other than the default. The file will be opened using the application:
It is ONLY right click. I don't left click or double click.
Very interesting though my comment is trivial, hope you contacted Secunia about this and updated your version at versiontracker and macupdate, apple downloads.
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.
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.
The problem is dug very deep in Mac OS X: One does not know if one can trust a certain file or not. A patch for the current security hole is easy, but won't solve the real problem.
On Mac OS (9 and X) a file can have an arbitrary icon and type, independent from its name. Some systems use the filename to guess type and icon. On Mac OS this information is stored as separate data, in a so called ressource fork. So one could create a file "some_file.xls" that is a text-file and has the icon of photoshop. Or one could create a file "celebrity_naked.jpg" that is indeed a program and has the icon of the preview application --- or worse whose icon shows a naked person. Even when there is no security hole, the user might eventually try to open this file. With the current security hole this step can be skipped --- the browser will open it automatically.
Mac OS X needs a way to mark a file as trustworthy. When a file is not marked this way, several dangerous operation will be disabled and the file must be marked in a certain way in the file browser (Finder, open dialogue, etc.). I think the Finder should have an extra check box in the file info dialogue: "This file is trustworthy". Terminal, Help Viewer and other easily exploitable application should refuse to open a non-trustworthy file. And this files should be viewed with a big red explanation mark on their icon --- at least when they can be opened with a dangerous application. So the user can easily see, that these files are a potential threat. Of course, per default only the system files are marked trustworthy.
An easy way to implement such a "trustworthy" flag would be extended POSIX attributes. On Mac OS X 10.4 every file can have an arbitrary number of these attributes. I suggest the following scheme: A file is only trustworthy, when it has a certain attribute. The name of the attribute depends on the user, its value is a digital signature of the file; e.g. name="trustworthy:34833066-DC6A-459F-8462-7100E84A D100" value="Here comes the signature...". Additionally there are some virtual accounts for the machine and the administrator. When they trust the file, every user on the machine or the domain implicitly trust the file too. This scheme has several advantages:
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).
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":
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.
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.
True, but the command was just to load 'calculator.app', that doesn't require the current user to be on sudo list. So, how many potentially malicious commands can be executed on terminal without sudo privileges? (Please excuse my ignorance on this, I'm an OS X newbie.) Deletion of user documents maybe? (Script may not be aware of user name, but terminal loads inside the current user's directory)
I'm not trying to downplay the threat, I think Secunia were right to call it 'extremely critical', I'm just curious what, in worst case scenario, this thing could do to a standard user. Is there a way we can set up OS X so that certain commands (delete, for example) require a superuser?
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.
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).
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.
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?
[ecode]
Camino Preferences --> Downloads --> When Downloads Finish:
[] Open downloaded files.
Downloaded files can be passed off to other "helper" applications. While convenient, enabling this feature makes your computer vulnerable to damaging programs.
[/ecode]
1. Not enabled by default.
2. Tells you that enabling it is a stupid idea.
Cool, I don't know if that's Funny or a Troll !
It may be a BASH problem ( that would be news to me ). If BASH will run a script without #!, that is a dumb thing... there *should* be some sort of way to tell if a file is going to execute in some manner, or that in itself is a security problem. If Apple can't change BASH, perhaps they should prevent Terminal from executing scripts from files that don't end in .sh or something like that.
I'm afraid we won't see a fix for this for a while, as it might take some time to get people to agree what the problem/fix really is...
BASH aside, though, it's Terminal.app that gets the Open command and loads the file, so it *does* have a chance to check for #! before handing off the script. I mean, maybe what comes after #! isn't /bin/sh, anyway.
If you feel that your computer is involnerable to hacks you will get hack eventually.
Not necessarily. Marcus Ranum's Perfect Firewall is still 100% effective, as far as I know, and I can't imagine a network-based attack that could bypass it. But I doubt someone who can't spell "invulnerable" would know about it.
As soon as more eyes go into looking at security holes, wow, truth revealed.
Errrr... let's see.
OS X: all related automatic execution attacks are prevented by changing one setting in the default browser.
Windows: the only way to prevent comparable automatic execution attacks is to remove the browser, which disables software updates, many control panel applets and other essential system tools, and several unrelated applications.
I'm not sure I understand your point, can you elaborate?
The real bug is in Terminal.app - it runs scripts even if they don't start with the shebang
/bin/sh, which it's supposed to do.
/bin/sh either. The POSIX standard specifies that if the shell fails to execute the script using exec(), if the execute bit is set it should run it itself.
Terminal.app does no such thing. It simply passes on whatever you give it to
It's not a bug in
The "bug" is a pair of known design flaws in Safari that Apple should have fixed two years ago, along with a change in the unzipper that changed the behaviour Safari was mistakenly depending on.
there *should* be some sort of way to tell if a file is going to execute in some manner
There is. It's called "the execute bit". If the execute bit is set, then the file it's set on is executed. If it can't be executed by the kernel (based on the magic number on the first to bytes of the file), it's executed by the shell directly.
there's no real fix possible to this issue.
Abandon Finder and start over with the NeXTStep File Manager. Stop using metadata for icons and file handlers and keep all that info separately from the files. Abandon "Open Safe Files After Download" and replace it with a system like LaunchServices but restricted to applications that are intended to handle "unsafe" files.
The problem is that someone used the wrong definition of "safe file".
That's true.
There's no definition of "safe file" that can be stretched to include any file recieved from outside the local protection domain. All files recieved from outside the local protection domain (the local computer and any servers in the local protection boundary managed by someone trusted by the owner of the computer) are assumed unsafe, and must only be opened outside a sandboxed environment by request of a human.
The sandboxed environment in this case consists of the web browser, internet plug ins, and any applications explicitly defined as capable of safely handling untrusted/unsafe files. LaunchServices is not explicitly defined as capable of safely handling untrusted/unsafe files (that's why Safari limits 'open files after downloading' at all). Therefore, Safari should not be using LaunchServices to open files automatically... it should wait for a human to request the files be opened, or it should maintain its own database of safe applications *and* its own mechanism for opening files that doesn't involve the use of an unsafe interface, or it should use a system-maintained database of safe applications.
The rest of this message is a historical note, you can ignore it.
Safari used a different definition: Executable files, and files that contain a pattern that is typical, but not required, for script files.
Er, no. Safari used a different definition: Files beginning with a 'magic number'. The first two bytes of any executable file on UNIX determiine which loader the kernel will use to load the file. For example, on PDP-11 UNIX if the first two bytes were octal 04 and 07 the file was a normal a.out format executable. If they were 04 and 011 it was a split-instruction-and-data executable. If they were '#' and '!' the loader read the rest of the line to find the name of the program to execute the file.
The thing is, that on V6 unix and early V7, the #! magic number wasn't magic at all... but shell scripts still had to be executed. What happened then was that the shell would open and execute the file as a series of shell commands... for the early shells (V6 and earlier) it literally set standard input to the script and just continued running, if the file had the execute bit set.
And THAT is why the shell (/bin/bash) inside the Terminal ran the file as a script. Because it's retaining compatibility with the way the V6 shell _had_to_ work in 1976.
How the '#!' string came about, that'll be a story for another day.
As far as I can tell, the point of drive-by downloading is for things like Java Web Start. With this setting off, you cannot just click a JWS link and have it open. Instead, you have to manually navigate to the file and open it from the Finder.
Older browsers (eg. IE and anything that used "Internet Config") had a list of specific mime types/extensions that should be opened by apps rather than downloaded. Mozilla browsers have this too but it's not pre-populated so the default action is to ask if you want to open or save the file.
Personally, I prefer the old behaviour. The only annoyance was having to remove all the file types when you first setup your browser (there must have been about 50 entries for stuffit!).
I recommend preventing the whole class of exploits by turning off "Open Safe Files", installing Stuffit Expander (but turning off "Mount disk images" in there) and not worrying about "Watch non-default application launches".
But turning "Watch URI schemes" on is worth considering, because Apple's solution doesn't actually prevent the exploit that led to its creation.
a.) How much of a pain in the ass it is to install Open Office on a Mac
("wtf is X-11 and why should I care" is guaranteed to be enough to dissuade most potential users all by itself)
b.) How much RAM Open Office needs? I can run every app I need at once, including Photoshop, InDesign, QuarkXPress, Safari, Mail, BBEdit, and a half a dozen others but I do not have half a fucking gig of RAM and neither do a lot of Mac users. Don't need it. Won't pay for it.
c.) How many Mac users want to start over with another UI again.
Nice theory but you're reaching.
-the perfessor (Rustin)
Ass Master:
Why did you pretend to be someone else? That just goes to show how unbelievably lame you are. What really gives it away is your belief that there is only ONE AC who bashes you, when I know for a fact there are many. Don't be a douche and defend yourself while pretending to be someone else, knob gobbler.
Mac OS X's security is obviously terrible locally. http://rm-my-mac.widopenbsd.org/ A Mac with all the latest updates from Apple got owned in only a couple of hours. I think even a Windows computer would more secure than that.
There are privledge escalation threats you may not be aware of. If they can execute users code they can get root. If the user is an admin user it's even simpler to do.
I suppose the real fix (other than unchecking an option in prefs) is just simply to stop double-clicking files to open them. Personally I've always been of the drag n drop school of working. I wanna open a JPEG? I drag n drop onto the relevant app, because there's a real chance that I'll be wanting to open it into Photoshop rather than Preview... either that or right-click and 'Open with...'. If it aint a JPEG you'll find out soon enough - and relatively safely. Simple enough protection from socially engineered shell scripts for now.
stop double-clicking files to open them.
Yep, dragging them or selecting the app using "open with" is definitely recommended, particularly for files you just downloaded. Not just for security, but also to avoid annoyances.
One thing I've found is that a lot of files in disk images or stuffit archives (by the by, stuffit archives ALSO maintain the dangerous metadata) have the "wrong" default application anyway. I use Camino as my browser, for example, and for a long time I used the PDF plugin for PDFs so Camino was my PDF viewer as well. Typically, HTML help files and PDF docs would open in Safari (or, in some cases, Internet Explorer!) and Preview if I didn't override them.
First, the "." chaarcter in a UNIX file name doesn't separate the name from the extension. It's just another character. UNIX applications have traditionally used the first or last few characters of the name for a variety of reasons, but that's just a convention and you find things like "s.file" or "file,v" or "file~" or "._file", as well as applications using 'magic numbers' in the first few characters of the file... like "#!" or "%!PS" or ": ".
And the UNIX shell didn't use filename extensions to determine the application to run files. The UNIX shell uses a verb-noun syntax, not the object-action syntax of modern GUIs. The application was explicitly named in the first word of the command.
The extended UNIX 'ls' command from BSD, the one that established the convention of using "*", "/", "@", and so on at the end of file names to indicate the file's metatdata, payed no attention to the name itself to determine how to display a file.
Many individual GUI file managers on UNIX have, but the majority of GUI file managers on UNIX are copied from Windows, one way or another. The ones that are older typically made "deeper" decisions... I've had mail folders with no extensions at all show up as a little 'in tray', based on the contents of the file.
Windows file extensions are based on the DOS 1.x "8 character name plus 3 character type", which was based on the CP/M 6+3 filename, which was based on the ISIS 6+3 filename, which was based on DEC's RT- and RSX- operating systems that used 6+3 filenames.
They started out as a genuine file type, like the Mac creator and type Finder Info, which is why they are considered "strong" type information rather than "weak" type information. It's a pity that the OS X Finder didn't follow the early UNIX precedent of considering all 'creator/content' meta-information as "weak", and using the file itself as the primary source... the way the UNIX commands "ls" and "file" do.
Is there a way we can set up OS X so that certain commands (delete, for example) require a superuser? What you are asking for specifically would be impractical since you could not change any documetns. But look up access controll lists on tiger if you want to know about fine grained control of user priv.
Some drink at the fountain of knowledge. Others just gargle.
Ass Master:
Why did you address this to yourself?
Why did you pretend to be someone else?
What makes you think I'm T/\/\/\/\? I'm an AC, just like you are. You are just as likely to be the TripMaster as I am (you could also be CmdrTaco, but that's beside the point).
That just goes to show how unbelievably lame you are.
You are a hypocrite. Y'know that? You want to call me lame when you are the one spending your time stalking Monkey.
What really gives it away is your belief that there is only ONE AC who bashes you, when I know for a fact there are many.
You know for a fact, do you? Prove it. Give some usernames of people who stalk TMM (>900k blank UIDs don't count).
Don't be a douche and defend yourself while pretending to be someone else, knob gobbler.
You could uncheck that Post Anonymously box and reveal yourself, rather than pretending to be a legion of faceless AC trolls. I'll be waiting...
Safari is doing this (not BOMArchiver). And it does it for .dmg files too, so those could be exploited as easily as .zip or .sit.
.zip, .dmg, ...?). Then, it tries to make .sit or .zip files act like Internet-enabled DMG files -- it extracts the contents and deletes the original archive file. Alternatively, it will simply mount any regular, non-Internet-enabled .dmg file.
.zip or .dmg) contained only one file, and Safari deems that a "safe" file (subject to extension/creator spoofing) Safari will launch that file.
.dmg, or extract the contents of the .zip or .sit file. After that, it's up to you to find the enclosed file and open it.
This is unfortunately a rather Microsoft-like behavior -- building too much "intelligence" into the way the system handles an operation, rather than using a simpler, more transparent approach. Safari identifies archive files when you download them (.sit,
Finally, if the archive (.sit,
If you download any of these archive files in Camino, the behavior is different, and more like a regular social exploit (with file-type spoofing). The archive file will be dumped in your download folder. Then, if Camino is set to open "safe" files, or if you choose "open" in Camino's download window, or double-click on your download in the Finder, the archive will be handed off to the operating system. Then the operating system will treat it differently from Safari -- it will just mount the
I have learned this a while ago and I have not had problems by saving what I download to the disk or particular folder, then open it with a suitable application. Having an application automaticlly open what is downloaded increases the threat of a comprimised system.