Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Microsoft

Huge security hole in Internet Explorer for MacOS 606

Posted by CmdrTaco from the now-thats-really-funny dept.
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!".
This discussion has been archived. No new comments can be posted.

Huge security hole in Internet Explorer for MacOS More

Huge security hole in Internet Explorer for MacOS

Comments Filter:

  • Intrinsic Security in OS X (Score:4, Insightful)

    by Buran ( 150348 ) on Tuesday October 02, 2001 @06:34PM (#2380685)
    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.)
    • 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.
      • 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.

    • Near-Useless Security (Score:4, Troll)

      by Giant Hairy Spider ( 467310 ) on Tuesday October 02, 2001 @06:42PM (#2380740)
      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 (Score:4, Insightful)

        by manly ( 69244 ) on Tuesday October 02, 2001 @07:21PM (#2381004)
        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 (Score:5, Insightful)

          by Giant Hairy Spider ( 467310 ) on Tuesday October 02, 2001 @08:13PM (#2381224)
          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 (Score:4, Insightful)

            by ToLu the Happy Furby ( 63586 ) on Wednesday October 03, 2001 @12:05AM (#2381849)
            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 (Score:3, Insightful)

            by weave ( 48069 )
            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...

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

    • Re:Intrinsic Security in OS X (Score:5, Insightful)

      by mr3038 ( 121693 ) on Tuesday October 02, 2001 @06:43PM (#2380748)
      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 (Score:2, Interesting)

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

    • User level is DANGEROUS for malicious code! (Score:4, Insightful)

      by infractor ( 152926 ) on Tuesday October 02, 2001 @06:49PM (#2380799)
      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...
      • 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.
    • 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
      • ...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.
        • 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

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

    • Not true (Score:5, Insightful)

      by Auckerman ( 223266 ) on Tuesday October 02, 2001 @07:08PM (#2380934)
      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 (Score:4, Informative)

        by sugarbomb ( 22289 ) on Tuesday October 02, 2001 @08:38PM (#2381303)
        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 (Score:3, Informative)

          by Auckerman ( 223266 )
          "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.

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

  • Sigh. (Score:3, Funny)

    by DarkZero ( 516460 ) on Tuesday October 02, 2001 @06:35PM (#2380695)
    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. (Score:2, Funny)

      by !recycle ( 467325 )
      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!"

  • Preferences (Score:4, Informative)

    by Anonymous Coward on Tuesday October 02, 2001 @06:37PM (#2380701)
    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 (Score:3, Informative)

      by Master Bait ( 115103 )
      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.

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

  • Well, yeah..... (Score:4, Insightful)

    by kerincosford ( 228730 ) <kerin@@@pullhere...co...uk> on Tuesday October 02, 2001 @06:37PM (#2380702)
    ...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.

    • Users are dumb (Score:5, Insightful)

      by nvainio ( 135908 ) on Tuesday October 02, 2001 @07:01PM (#2380899) Homepage
      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: Well, yeah... (Score:2, Interesting)

      by gwyrdd benyw ( 233417 )
      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...)

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

    • Not Stuffit's Fault (Score:5, Informative)

      by Brownian Motion ( 463959 ) on Tuesday October 02, 2001 @08:07PM (#2381197)

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

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

  • somewhat unfair to gloat (Score:3, Insightful)

    by shibut ( 208631 ) on Tuesday October 02, 2001 @06:40PM (#2380721)
    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...

  • Original posting (Score:3, Informative)

    by tbmaddux ( 145207 ) on Tuesday October 02, 2001 @06:43PM (#2380751) Homepage Journal
    Here's the original posting [macintouch.com] 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)"

  • 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 (Score:5, Informative)

    by ehintz ( 10572 ) on Tuesday October 02, 2001 @06:44PM (#2380760) Homepage
    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.

    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.

  • Workaround? (Score:2, Insightful)

    by maniac11 ( 88495 )
    Setting StuffIt Expander [alladinsys.com] to be the helper app for .sit, .bin. and .hqx file types should circumvent this problem, right?
  • I can't think of a better case for Mozilla or OmniWeb [omnigroup.com] (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 [microsoft.com] looks kinda neat. I just hope Corel hurrys up and makes a "Corel Office Suite X".

  • i didn't even think it was a bug (Score:4, Interesting)

    by SirSlud ( 67381 ) on Tuesday October 02, 2001 @06:51PM (#2380823) Homepage
    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.)

  • Knowing Microsoft... (Score:3, Funny)

    by neema ( 170845 ) on Tuesday October 02, 2001 @06:52PM (#2380827) Homepage
    "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 (Score:3, Interesting)

    by coyote-san ( 38515 ) on Tuesday October 02, 2001 @06:52PM (#2380832)
    This sounds a lot like the recently discovered slrn bug (see Bugtraq, LWN, Debian [debian.org]) 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.
  • 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.
  • 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.
  • IE Exploits:

    q279328 [microsoft.com] - allows execution of code through print templates or web forms

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

    q286043 [microsoft.com] - 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 [microsoft.com] - 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.

  • Here's the fix (no sarcastic anti-MS comment here) (Score:5, Informative)

    by Anonymous Coward on Tuesday October 02, 2001 @07:02PM (#2380902)
    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.

  • Why is it there? (Score:4, Insightful)

    by Phrogz ( 43803 ) <!@phrogz.net> on Tuesday October 02, 2001 @07:07PM (#2380929) Homepage
    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.
    • 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.
      • 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? (Score:4, Informative)

      by hearingaid ( 216439 ) <redvision@geocities.com> on Tuesday October 02, 2001 @07:45PM (#2381124) Homepage

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

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

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

  • Solution (Score:5, Funny)

    by KFury ( 19522 ) on Tuesday October 02, 2001 @07:58PM (#2381168) Homepage
    1. Create script to toggle 'autoexec .hqx downloads' to FALSE
    2. Insert the file into the X-10 popup banner
    Problem solved.

  • New slogan (Score:2, Funny)

    by Lumpy ( 12016 )
    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 (Score:3, Offtopic)

    by fjordboy ( 169716 ) on Tuesday October 02, 2001 @08:33PM (#2381290) Homepage
    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!)

  • Execution (Score:2, Funny)

    by garoush ( 111257 )
    "...it automatically executes them."

    Now if an "executed" program is STILL a security risk -- I don't know how we can ever be secure.
  • 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

  • Step back and smell the irony (Score:3, Funny)

    by 1stmammaltowearpants ( 514509 ) on Tuesday October 02, 2001 @09:07PM (#2381395)
    We're talking about a Microsoft product running in Unix that came pre-installed with the Mac OS.

    These are strange times, my friends.
  • 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.

  • That's not the security hole... (Score:4, Insightful)

    by jmegq ( 33169 ) on Wednesday October 03, 2001 @01:21AM (#2381996) Homepage
    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.

  • Shades of MSN 1.0 (Score:3, Informative)

    by hatless ( 8275 ) on Wednesday October 03, 2001 @11:25AM (#2383488)
    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.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close