Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Hack Mac OS X With Installer Packages 194

Posted by kdawson
from the why-not-to-run-as-admin dept.
nezmar writes, "MacGeekery has a short but insightful piece with examples on how to use a malformed Installer package (.pkg) on Mac OS X to 'insert user accounts with administrator rights and change root-owned system configuration or binary files without prompting the vast majority of Mac OS X users for a password of any kind.'" The article notes that this issue was brought up on the Apple Discussion Boards 6 weeks back and that it was noted there as a duplicate / known issue. It also gives as an example the installation of Parallels, the popular virtualization software, which uses the described technique, but not for nefarious purposes.
This discussion has been archived. No new comments can be posted.

Hack Mac OS X With Installer Packages

Comments Filter:
  • Ouch (Score:5, Informative)

    by bnenning (58349) on Saturday September 16, 2006 @01:44PM (#16121051)
    I knew it was weird when I installed Parallels a few months ago and it added several kernel extensions without a password prompt. This is a serious design flaw, and yet another reason for developers and users to avoid installer packages unless absolutely necessary.
  • by 93 Escort Wagon (326346) on Saturday September 16, 2006 @02:03PM (#16121120)
    It is hard to get most Mac users to not use an admin account, because if you're the only user it will be admin by default.

    I've tried to explain to other Mac users that running as an admin by default is bad, and they always come back with "but you always get a pop-up asking for your username and password anyway, so you always know something is up". Unix-heads know this is wrong, but Mac users as a whole are as uninformed as your average Windows user.

    The silly thing is OS X makes it absurdly easy to run as a non-admin. Just create a second account, make it an administrator, and then remove that privilege from your own account! If some task needs admin privileges, OS X will automatically prompt you for an admin account login - you don't even need to think about it beforehand (unlike XP's less-than-perfect "Run as..." solution). If an application tries to do something admin-y without asking you to authenticate as an admin, it will fail.

    The only time this is ever a hassle is if you're installing one of a handful of software packages that doesn't use the OS X security framework. Adobe is the most egregious offender in this regard - they even require that the first time you launch a number of their programs (right after install in other words), it has to be done as an administrator. There's no good reason for them to do this, but it's part of their "We can't stop the pirates, but we can darn well make it a pain for law-abiding customers" initiative.
  • Not a real concern (Score:3, Informative)

    by John Nowak (872479) on Saturday September 16, 2006 @02:25PM (#16121215)
    On almost any system today, including Linux, OpenBSD, OS X, etc, software has far too much power. Even if I'm not logged in as an admin user, I could download an application, run it, have it trash my user folder, add some things to my .profile, etc. The truth is that the current 'security' on just about every system out there is a joke if you consider intentionally running a (secretly) malicious application a security problem. I absolutely do, but in the grand scheme of things, if Installer asks for a password or not on OS X to do things as root is not much of a concern compared to the gaping holes already there. Should it be fixed? Yes. Is it a major problem? No.
  • by GeffDE (712146) on Saturday September 16, 2006 @02:29PM (#16121229)
    I believe you misunderstand. sudo is a command that takes a user listed in the sudoers file and gives them root priviledges. In a default OS X install, only admins are in the sudoers file. There are three levels of access in OS X: unpriviledged user, admin and root. Only admins may be promoted to root through sudo. If your password works for the installer, you are an admin.
  • by 93 Escort Wagon (326346) on Saturday September 16, 2006 @02:35PM (#16121256)
    tell application "Terminal"
        do script "exec bash -c \"touch /Applications/Gotcha\""
    end tell
    If you are in the admin group, you can write into any number of important directories without additional authentication. "Applications" is not the most important one; I used it here because it's visible and obvious. However it's the less-than-obvious ones you need to be concerned about.
  • by CaymanIslandCarpedie (868408) on Saturday September 16, 2006 @02:48PM (#16121315) Journal
    I do not know any Mac users, so I really don't know whether they are as dumb as Windows users.

    Oh, sure! I'm certain you were expecting a bunch of well thought out replys discussing if Mac users and/or Windows users are stupid and really get to the bottom of this deep question. Its a textbook flame, deal with it. You were just tossing out insults in some sad attempt to make yourself feel superior.

    Here's the thing, many of us /.ers still come here to see the latest tech news and participate in or see in-depth discussion of these issues to enrich ourselves and others. The problem is there are too many smug people like yourself here not acutally lending anything to the actual discussions but instead just toss pointless insults around and generally trying spread to show how smug you are. It kind of lends itself to a Beavis and Butthead mentality where the lowest common denominator (you) end up distracting people from the actual discussion taking place. Now do I think this is a real issue? Not really and certainly not specifically for Apple (see my other post) but it is worth an educated discussion about the pros and cons and look at the options. Posts like yours just distract from the issues at hand I guess in some hope to get some cheap karma points by pointlessly slamming people when its completely irrelevant to the discussion while actually adding nothing.
  • by Anonymous Coward on Saturday September 16, 2006 @03:13PM (#16121390)
    I don't even think we're making a different point. My definition of admin is just more confusing I guess. You're indeed right that the default user is a user from the admin group, but my point is that even though the user might be an admin, he doesn't have root priviledges without giving a password first.

    The problem is with the package management. What the article is saying is that package creator is allowed to set authorization for installation. They can choose either to authorize with Root privilege or with Admin priviledge. Installations that require Root privilege will prompt for password from a user even if the user is logged on as an Administrator. Admin privileged installation doesn't require a password if the user is Administrator. The danger is that some installations which should require Root priviledge (ones that deeply modify the OS) can be carried out with a passwordless Admin priviledge, so the Admin doesn't realize just how much modification is being made to the system.

    A scenario would work like this:

    Admin thinks he just installing a regular editor application. Package author specifies installation with Admin priviledge no authorization. Admin proceeds to install package but is unaware that package install program is silently adding system kernel extensions. Normally, this would require Root priviledges for system modifications, but doesn't because of this weakness in the installation api.
  • by SilverAlicorn (986453) on Saturday September 16, 2006 @03:30PM (#16121442)
    Uhh... have you even used Mac OS X? The vast majority of applications are distributed as "bundles," which are basically special directories that contain everything the program needs to run. You can put the bundle whereever you like, and execute it from there, though the OS provides an "Applications" folder to keep everything neat.

    Frameworks, like Quicktime or SDL, work in a similar way, though they get dropped in the "Library/Frameworks" folder.

    The only things that use the Installer are things that need to make fundamental changes to the system, such as kernel extensions, or programs that have to noodle with the main directory structure, like Fink. They usually provide an uninstall script as well. Granted, Apple's first party apps use the Installer, but they're more complex and integrated. The only program I've ever used that wasn't supplied as a bundle was Fink (basically a port of Debian's APT to make installing Unix applications easier).
  • Here is the FIX (Score:4, Informative)

    by goombah99 (560566) on Saturday September 16, 2006 @03:36PM (#16121467)
    I've known about this hole for about a year (yes I reported it to apple). The solution, which I use myself, is very simple. Do not run as sudo. I have two accouint. my everyday account and my sudo-user account. If you always run the installer as normal users then it will be forced to ask for a sudo-account name and password any time it needs to escalate privledges. There that's the fix.

    If you always run as a sudo user then you are exposed to this hole. It's not techincally a hole, but most people would consider it an unexpected behaviour. Most people figure that if they don't give the installer their password then it can't be installing anything priveldged. Wrong, it is possible. But you were installing so....you sort of got what you asked for, but obviously it's ripe for a trojan.

    The fix I give above simply forces the expected behaviour. If something wants to modify privledged files then it has to ask.

    Now here's the nice thing. Unlike linux and windows, it is a perfectly pleasant experience for a poweruser to run as anormal user on a mac. I'd die if I had to have this dual account system on linux, since not having super user privs is a pain. KDE and GNOME try to help you with some operation, but it's so inconsisten you cant make it work well.

    But on mac's it's nearly seemless. Anytime you need to authorize it pops up a window asking for a sudo account name. It's ubiquitous and there's virtually no time you need to be logged in as sudo-user. For extensive scrirpted or CLI coperations the terminal suffices to su to the sudo user. Now about once or twice a year, I find some situation where it is simpler to be in a GUI desktop as the sudo user. (one of those is fink-commander) For that there's fast user switching which lets me flip over to a logged in sudo GUI account instantly.

    It's painless.

  • by goombah99 (560566) on Saturday September 16, 2006 @04:13PM (#16121583)
    I'm going to reply to my own post because reading other comments I see that people don't grasp why this is an unexpected behaviour on a mac. It's a fairly normal behaviour on linux and Windows.

    On a mac, it's normally possible to install an application without requiring any super user privledges. On linux and Windows it's frequently impossible or at least quite hard (on linux you often have to fiddle with the make configuration, and it results normally in a crippled application.

    Here's one example. On a windows computer when you install something it has to have some way to get it's hooks into the OS. This might be as simple as notifying the OS of what extension/suffixes it can open or what services or filters it provides to other applications. This is done through the registry. And you need to be root to modify the registry. So you can't really install anything properly without giving your application the ability to write to the registry.

    And since there's no selective privledges that would say "well I trust you to only modify this part of the registry and no where else nor any other file, you basically pull your pants down around your ankles, close your eyes and pray there is no unsolicited finger up the butt every time you install. Linux is simmilar, since it propably wants to shove stuff in /bin and maybe overwrite somethings in /lib.

    On a mac, applications don't do that. Normally an entire application lives in a single folder with no stuff placed anywhere else. SO how does the application provide services? Well what happens is that the operating system will interorogate the Application when it is installed or when you boot or launch it the first time. Inside the application is a standard XML file info.plist that declares all sorts of things the OS might want to know about the application. And then the OS relays this to the other applications as serices that are available. This is how for example, the OS knows what applications can open what kind of documents.

    As a result, there is no need to unbuckle your jeans and grab your ankles when you do an install in most cases. And it's also easy to undo an application since the number of places it touches (usually just the application's folder and the library/preferences)

    Now I just said in most cases. Some applications do need privledges since they are going to make strong modifications. THis might be installing a start-up item, for example, or things that make intimate hardare interface modifications And for those when you run the installer script you naturally expect it to ask you for your password so it can escalate it's privs.

    And there is the problem. It turns out that the installer application on a mac, is a an application that can retain root privs after the first time you grant them (like says SETUID). To me this would seem unneccessary, but it does. And it turns out that if you are a sudo users, and if you have ever granted the installer elevated privs, then when it goes to install an application the requires elevated priv, it does not have to ask you for them! Now it also turns out that in most cases the applicaitons that are being installed can't know if a sudo user or a normal user is installing them so they automatically ask for the password. But they don't have to if you are sudo.

    So the fix is not to install as a sudo user. Then the installer can't get the elevated privs be default. And so the application is forced to ask for them if it needs them.

    Thus when your "make-a-smiley" application you got from gatorware asks for root during the install you have a chance to rethink if this might be a trojan.

    Thus the behaviour of the installer that blows past the authentication check is bothersome to mac users even though they are doing an install. On linux and windows doing an install normally is always done at root privs so the peril is always there.
  • by Foolhardy (664051) <csmith32@gmail.HORSEcom minus herbivore> on Saturday September 16, 2006 @04:16PM (#16121588)
    Actually, a better solution for authentication from the OS is a secure attention sequence (SAS), e.g. CTRL+ALT+DELETE on Windows NT or CTRL+ALT+PAUSE on Linux. The OS supersedes any application's attempt to trap this key sequence and puts the display into a mode that only shows OS sanctioned secure dialog boxes. On Windows (and XP with the welcome screen off) this is the "Windows Security" screen. This way, if you always enter the SAS before entering your password, you know that only the OS is receiving it. It helps to build the habit when the OS always asks you for the SAS before entering passwords.

    The new authorization dialog boxes in Vista are like this; this is the reason they take over the desktop. IIRC, you can hit CTRL+ALT+DELETE while one of these is up and you'll know its authentic because it'll stay there (if it weren't you'd switch to the "Windows Security" screen instead.)

    Of course, these are useless if the OS is already compromised, but the whole idea is to keep it from getting that far.
  • by 93 Escort Wagon (326346) on Saturday September 16, 2006 @05:12PM (#16121823)
    The main issue will be the occasional app that doesn't use the security model. I've run into just a few:

    - Google Earth (mentioned by someone else) will run fine, but you'll have to install it using the admin account.

    - App Zapper requires an admin account to even use the app. I wrote to them about it, and got back a somewhat generic "yeah we've thought about it, but you should be deleting from an admin account" reply. I'm guessing this is an old-school Mac developer that has a bit to learn about Unix.

    - Most Adobe applications need to be installed as an admin, and run for the first time as an admin (because of their activation crap). After that they'll work fine run under your normal non-admin user account.

    - Fink (shame on them) will not install correctly unless you run the installer from an admin account.

    If you find an app that won't install, email the developer! Chances are they just haven't thought about it. There have been a few I've written to that, once they were aware of the problem, fixed it pretty quickly. But in the meantime you'll probably have to log in under the admin account a few times to install some apps.

    Since we like to pick on Microsoft here, I'm going to mention that Office will install just fine under a non-admin account - they've used Apple's security framework. Say what you will about the company as a whole; their Mac Business Unit seems to be on the ball.

  • by goombah99 (560566) on Saturday September 16, 2006 @06:12PM (#16122048)
    On macs you would not generally install into /usr/lib. Sometimes you would sure. But not normally. Even for pure CLI apps, in most cases you would have gotten those from a package manager like fink. And fink follows, partly, the apple style of being self contained. So it goes into /sw/bin. So what's the difference? well this means your bin's form other package managers and the system don't get stirred together. To delete just remove /sw. it's gone. You can also grant the permissions to change these more selectively using ACLs for the separate bin directories. Not that people do very often since macs don't need that kind of paranoia. But it's built into the security model so if you need it you can do it.

  • by drsmithy (35869) <drsmithy&gmail,com> on Saturday September 16, 2006 @07:23PM (#16122277)
    I'm going to reply to my own post because reading other comments I see that people don't grasp why this is an unexpected behaviour on a mac. It's a fairly normal behaviour on linux and Windows.

    According to the Apple documentation linked from TFA, if this behaviour is actually happening, then it is neither expected, nr proper, and is definitely a bug. How the article writer managed to arrive at the conclusion that Apple's documentation say it is correct and expected, I don't know.

    On a mac, it's normally possible to install an application without requiring any super user privledges. On linux and Windows it's frequently impossible or at least quite hard (on linux you often have to fiddle with the make configuration, and it results normally in a crippled application.

    On Windows this is an issue completely up to the application developer, who decides a) whether their installation procedures requires access to system areas, and/or b) whether they allow the user to specify where to install the applications (and/or c) if they bother to check the privilege level that the user has).

    On Linux, if you're compiling from source, it's a matter of passing --prefix=/some/path to 'configure'. WIth packages, it's a function of the package manager and subject to the same restrictions regarding whether or not the developer has done the right thing.

    OS X is *exactly* the same.

    Here's one example. On a windows computer when you install something it has to have some way to get it's hooks into the OS.

    No, it doesn't.

    This might be as simple as notifying the OS of what extension/suffixes it can open or what services or filters it provides to other applications. This is done through the registry. And you need to be root to modify the registry. So you can't really install anything properly without giving your application the ability to write to the registry.

    This is wrong.

    Firstly, you don't need to be "root" to write to the Registry (Windows has no "root" equivalent and access to the Registry is governed by the same types of ACLs that restrict filesystem access, applied on a per-Registry-key basis).

    Secondly, file associations and similar config data are stored in the per-user Registry hives which, of course, users are (typically) able to modify. The equivalents in OS X are all those XML config files hiding in your home directory (which, of course, you have permissions to modify - although access is not restricted at the same fine-grained level as it is to the Registry).

    And since there's no selective privledges that would say "well I trust you to only modify this part of the registry and no where else nor any other file, you basically pull your pants down around your ankles, close your eyes and pray there is no unsolicited finger up the butt every time you install. Linux is simmilar, since it propably wants to shove stuff in /bin and maybe overwrite somethings in /lib.

    There most certainly *is* the capability for such "selective pivileges" when accessing the Registry, and it is enforced. Linux (and unix in general - including OS X), however, lacks both the centralised repository to lock down access to such a degree and the fine-grained permissions system to actually do so, and is somewhat hampered by the fact "root" has no restrictions whatsoever (at least in typical configurations).

    As a result, there is no need to unbuckle your jeans and grab your ankles when you do an install in most cases. And it's also easy to undo an application since the number of places it touches (usually just the application's folder and the library/preferences)

    From a technical perspective, the situation in Windows (and Linux, to a less degree) is no different.

    And there is the problem. It turns out that the installer application on a mac, is a an application that can retain root privs after the first time you grant them (like says SETUID). To me this would seem unneccess

  • Re:Ouch (Score:3, Informative)

    by drsmithy (35869) <drsmithy&gmail,com> on Saturday September 16, 2006 @07:36PM (#16122314)
    I knew it was weird when I installed Parallels a few months ago and it added several kernel extensions without a password prompt. This is a serious design flaw, and yet another reason for developers and users to avoid installer packages unless absolutely necessary.

    According to the documentation linked from TFA, this behaviour is neither "proper", nor expected. Assuming the documentation is correct, it's not a design flaw, it's just a bug.

  • by goombah99 (560566) on Monday September 18, 2006 @12:03AM (#16128012)
    I'm going to reply to my own post because reading other comments I see that people don't grasp why this is an unexpected behaviour on a mac. It's a fairly normal behaviour on linux and Windows.

    According to the Apple documentation linked from TFA, if this behaviour is actually happening, then it is neither expected, nr proper, and is definitely a bug. How the article writer managed to arrive at the conclusion that Apple's documentation say it is correct and expected, I don't know.

    **perhaps if you are not informed on this, it's because I and probably that author reported this behaviour to apple and got the response, Whereas you did not.

    On a mac, it's normally possible to install an application without requiring any super user privledges. On linux and Windows it's frequently impossible or at least quite hard (on linux you often have to fiddle with the make configuration, and it results normally in a crippled application.

    On Windows this is an issue completely up to the application developer, who decides a) whether their installation procedures requires access to system areas, and/or b) whether they allow the user to specify where to install the applications (and/or c) if they bother to check the privilege level that the user has).

    **Reality intrudes here: on Linux and Windows ubiquitously the applications need root, or whatever you want to call it, so often that everyone does run and install as root level user. Your reply is really pretty strange and weasly lawyer speak

    On Linux, if you're compiling from source, it's a matter of passing --prefix=/some/path to 'configure'. WIth packages, it's a function of the package manager and subject to the same restrictions regarding whether or not the developer has done the right thing.

    **Oh come on...this is stupid. Have you ever tried to do large numbers of package installs this way and not basically break the usability of installed libraries for other users, or maintain any consistency between package mangers or had to hand edit other make files unaware of your non-standard installs??? This is completely disingenuous or you are not considering multi-user systems

    OS X is *exactly* the same.

    **errr no it's not. That's the WHOLE point.

    Here's one example. On a windows computer when you install something it has to have some way to get it's hooks into the OS.

    No, it doesn't.

    **Yes it does, he retorted tersely.

    This might be as simple as notifying the OS of what extension/suffixes it can open or what services or filters it provides to other applications. This is done through the registry. And you need to be root to modify the registry. So you can't really install anything properly without giving your application the ability to write to the registry.

    This is wrong. Firstly, you don't need to be "root" to write to the Registry (Windows has no "root" equivalent and access to the Registry is governed by the same types of ACLs that restrict filesystem access, applied on a per-Registry-key basis).

    **Oh were back to semantics about "no root" on windows. Whatever.

    Secondly, file associations and similar config data are stored in the per-user Registry hives which, of course, users are (typically) able to modify. The equivalents in OS X are all those XML config files hiding in your home directory (which, of course, you have permissions to modify - although access is not restricted at the same fine-grained level as it is to the Registry).

    **There are no application XML config files hiding in the your home directory on a mac. That's the point: APP information is in the APP itself. The only thing that ends up in the user prefs folder is the persistent user customization data. But that's not the same thing as what goes in the windows registry.

    And since there's no selective privledges that would say "well I trust you to only modify this part

Long computations which yield zero are probably all for naught.

Working...