Previous 1 2 3 Next 41 Replies Latest reply: Nov 29, 2006 5:43 PM by Matt Broughton Go to original post
  • kullerhamPster Level 1 Level 1 (10 points)
    I think that might be possible, I haven't tried it.
    I do know that there are some versioning checks in
    place.


    Hm. If this would be possible, I would be really worried. As far as I can see, version checking isn't an appropriate way to avoid that files are overwritten. One could easily trick this by specifying a very high version number in the malicous package.

    Enter social engineering. Get you to trust the
    source or at least make you feel there will be no
    harm to "click here". I always verify the SHA1
    values even when I download from Apple. Not only
    does it ensure I got the legitimate file from the
    legitimate server, but it also verifies that the file
    has not been corrupted during download.


    Of course, social engineering can not be prevented by demanding your password or even checking hash values (what I rarely do).
    However, I think this is not an argument to ignore such (potential) security issues.
    Imagine, for example, one could hide the installer dialogue and simply execute it in the background. If root privileges were acquired correctly, a password would have to be entered, thus the background installation could not successfully complete without user interaction.
    But if there's no password dialogue, the installation could run completely in the background.

    As mentioned in my previous post, it is unclear or even unlikely that this would work (at least hiding the installer, even if overwriting files would be possible), but nevertheless I think this problem should be carefully investigated and patched, if necessary.
  • kullerhamPster Level 1 Level 1 (10 points)
    Actually, I just made packages to replace
    '/etc/sudoers', and install a "StartupItem",
    installed using '/usr/sbin/installer', and everything
    installed with correct permissions (ie. both tested,
    and fully functional).


    So the package you made installed without demanding your password and was able to overwrite /etc/sudoers? This is really bad, I think. Perhaps you could inform Apple on this, including the "malicious" package you crafted?
  • Michael Bradshaw Level 5 Level 5 (4,135 points)
    Matt,

    You've answered this here.

    admin users are root on OSX client. There isn't a root user unless you go to specific lengths to enable it. This seems to match the message that the installer automatically escalated the privelages.

    The only possible security ramification now would be if a non-admin user could change whatever list or property is used to sigify "admin" status.

    Also - it might need to be made known better that by being an admin - sometimes root things will happen without the password dialog. I for sure was under the impression that the system wouldn't do "root-like" things for me unless it asked for a password....
  • biovizier Level 5 Level 5 (7,925 points)
    ..." So the package you made installed without demanding your password and was able to overwrite /etc/sudoers?"...

    That is correct - working from an "admin" account (10.4.7), no authentication was requested at all, exactly as you described for the PHP5 package. I even did a 'sudo -k' and manually locked the lock in "System Preferences" just to make sure there weren't any elevated rights floating around for that account before running the installer.

    I would submit a bug report, except, I'm not sure where exactly the bug is. It may be scary in itself, but I had never used "PackageMaker.app" before today and was able to figure it out how to construct a potentially malicious package in about three minutes after reading Matt Broughton's description. The point is, I can say "hey look at this!" but I don't know the ins and outs of how the installer and the "authorization" framework should work to articulate the problem. I'll probably submit one anyway over the weekend (including the package is a good idea), but I think it would help if others did so as well.
  • kullerhamPster Level 1 Level 1 (10 points)
    admin users are root on OSX client. There isn't a
    root user unless you go to specific lengths to enable
    it. This seems to match the message that the
    installer automatically escalated the privelages.


    As far as I understood it, the default admin user is not the root user but can get root privileges by providing his password (and only by providing his password).
    For example, try to create a folder in /usr/local with "mkdir test" with your default admin user. It won't work as long as you don't use sudo (which asks for your password).

    The only possible security ramification now would be
    if a non-admin user could change whatever list or
    property is used to sigify "admin" status.


    I don't agree. Of course, an unprivileged user gaining admin- or root privileges would be worse. But an installer that is started from an admin (not root) account should not be able to do things that normally would require a password. And as mentioned above, normally you can't create a new folder in /usr/local, and you can't overwrite /etc/sudoers.

    Also - it might need to be made known better that by
    being an admin - sometimes root things will happen
    without the password dialog.


    I'm afraid I don't understand the part between the "-" of your sentence. Do you have an example for root things happening without asking for the password?

    I for sure was under the
    impression that the system wouldn't do "root-like"
    things for me unless it asked for a password....


    This is what I believed and what would be a "correct" behaviour, imo. Of course, there are system services running with higher privileges, perhaps the installer is one of them. But I think a user with only admin privileges should not be allowed to manipulate these services in a way like the one described here.

    And one more general aspect on this: I think Apple's intention using a sudoer instead of a root account and a default user was to let the "normal" user do his daily work with the default account created after the OS X installation. The sudoer concept is, on the one hand, a way to confine the risk of damage, while, on the other, it allows easy system administration without the overhead of an higher privileged account.
    This, of course, only works if the concept is implemented correctly and consistently. This is - in my opinion - not the case here.
  • kullerhamPster Level 1 Level 1 (10 points)
    I would submit a bug report, except, I'm not sure
    where exactly the bug is. It may be scary in itself,
    but I had never used "PackageMaker.app" before today
    and was able to figure it out how to construct a
    potentially malicious package in about three minutes
    after reading Matt Broughton's description. The point
    is, I can say "hey look at this!" but I don't know
    the ins and outs of how the installer and the
    "authorization" framework should work to articulate
    the problem. I'll probably submit one anyway over the
    weekend (including the package is a good idea), but I
    think it would help if others did so as well.


    I think submitting a bug report is a good idea in any case.
    Imo, the problem description can be simplified to the fact that files and folders only writeable for root can be (over)written by the default admin user without explicitly gaining root privileges. It's up to the guys at Apple to descide if this is a bug or if we see a problem that doesn't exist (although I don't believe this).
  • biovizier Level 5 Level 5 (7,925 points)
    Just to update, this afternoon I copied a package onto my flash drive, walked over to the local computer store, and with their permission, successfully tested it on one of their demo machines (logged in as an "admin"). Plug in the drive, double-click, prepare to sit back, but before your butt has a chance to hit the chair, it's done. A bug report has been submitted.

    Of course, nothing really changes - most people have been advising against routinely using an "admin" account anyway...
  • Matt Broughton Level 5 Level 5 (4,980 points)
    I also have an update of sorts. I got thinking about privileges in the Installer and what happens when. I put together three sample packages representing the three levels of authorization available when building a package -- NoAuthorization; AdminAuthorization; and RootAuthorization. I have posted the scripts for download. Give them a try if you want.


    The payload is quite simple. They each install a directory /usr/local/hello (root:wheel) with one file inside /usr/local/hello/world (userid502:wheel). I also included InstallationCheck, preflight, and postflight scripts. The main purpose of these scripts is to run the command 'whoami'. I had each script log the user they were running under to the install log. The InstallationCheck would not write to the log, so I included an AppleScript (osascript) display dialog for each of the script that also gives you the result of 'whoami'.

    The quick run down is that the NoAuthorizaion package worked as expected. The scripts were run as the current user and the payload would not install. The RootAuthorization package also behaved as expected with scripts running as root after proper authentication. The AdminAuthorization package ran the Installation check as the current user. The preflight and postflight scripts were run as root. Yikes! A package that has only AdminAuthorization will run scripts as root and install a payload in a directory where only root is supposed to have write privileges.

    Having discovered that, I raised the ante a bit and had the postflight script for the AdminAuthorization package change the ownership of the payload to roo:wheel for good measure.

    I found it quite interesting that when I went to build the packages, I had to supply user name and password as my administrator's account did not have sufficient privileges to archive the /usr and /usr/local folders. I had to authenticate to build the package, but an administrator doesn't have to authenticate to install the very same files. This does not seem right at all.

    Matt

    Mac Mini G4; B&W G3/300    
  • biovizier Level 5 Level 5 (7,925 points)
    I heard back from Apple, and the bug report has been marked a "duplicate". A note sent in parallel to product-security@apple.com received the response that the issue is "known" and is "being addressed".

    Good point about the script hazard - I accidentally discovered the same thing trying to do something else with the package. That really lowers the bar in terms of both what a user needs to know and what tools they need on hand to take advantage of the weakness...
  • Matt Broughton Level 5 Level 5 (4,980 points)
    Glad to hear that it had been previously reported and the Apple recognizes it as a problem.

    Matt
  • kullerhamPster Level 1 Level 1 (10 points)
    Of course, nothing really changes - most people have
    been advising against routinely using an "admin"
    account anyway...


    So it seems that I'm the only one here who uses the default (admin) account for daily work.
    I don't like the overhead of having another account. Ubuntu, for example, uses the same concept, the default account being a sudoer. This motivated me to do the same with OS X. I find this pretty nice for systems used by a single user only and I wish that Windows would do it the same way.
    I think that if the concept was properly implemented, working with a sudoer account is almost as secure as using a second, restricted account.

    We should not forget that we are talking about an error in the system. There were also errors in the past which could be used to gain root privileges from a restricted account. So there's always some risk left - the question is, how high the risk is.
  • Matt Broughton Level 5 Level 5 (4,980 points)
    So it seems that I'm the only one here who uses the
    default (admin) account for daily work.


    I still use an admin account for daily work. I just happen have my main account set up as user 502 rather than the default 501. This is mainly for my convenience. I provide support help for my sister's SOHO environment. For their computers, the first admin account set up the same on each computer. I use subsequent accounts the other stations. Nobody is running an administrator account in their setting. Partly for security reasons but also so they don't mess things up quite as easily even though they do have the admin password. So my using account 502 as my main account gives me more the look and feel of a multi-account setup.


    We should not forget that we are talking about an
    error in the system. There were also errors in the
    past which could be used to gain root privileges from
    a restricted account. So there's always some risk
    left - the question is, how high the risk is.


    In this case, I would prefer to say that there is a bug in the Installer program. I don't think it is a system wide fault. If you compile source code, you have to authenticate to install. If you want to make a directory in /usr, you have to authenticate. The PackageMaker used to create an installer requires the proper authentication to archive files for the package. Perhaps the PackageMaker application should be enhanced so that it takes into account the default location when it determines whether sudo authentication is needed to archive files when building a package. That might have brought the incorrect file ownership to the attention of the person making the PHP installer. It is only the Installer application that elevates the level of access improperly.

    There have been system wide holes such as the when it was possible to mount a remote disk without our knowledge or consent. I don't believe that the Installer situation is system wide.

    Matt


    Mac Mini G4; B&W G3/300    
  • kullerhamPster Level 1 Level 1 (10 points)
    I still use an admin account for daily work. I just
    happen have my main account set up as user 502 rather
    than the default 501. This is mainly for my
    convenience. I provide support help for my sister's
    SOHO environment. For their computers, the first
    admin account set up the same on each computer. I
    use subsequent accounts the other stations. Nobody
    is running an administrator account in their setting.
    Partly for security reasons but also so they don't
    mess things up quite as easily even though they do
    have the admin password. So my using account 502 as
    my main account gives me more the look and feel of a
    multi-account setup.


    I'm afraid I don't quite understand the advantage of setting the uid from 501 to 502 in your system configuration. So the 501 account also exists on each computer?

    In this case, I would prefer to say that there is a
    bug in the Installer program. I don't think it is a
    system wide fault. If you compile source code, you
    have to authenticate to install. If you want to make
    a directory in /usr, you have to authenticate. The
    PackageMaker used to create an installer requires the
    proper authentication to archive files for the
    package.


    Yes, I agree, it seems that the error is only in the installer, and thus not as dramatic as if it would be a system-wide problem. Nevertheless, the installer is part of the system, and this is a possibility to run a script with elevated privileges without authentification.
    As far as it seems up to now, the threat arising from this bug is not that big, as user interaction is required in any case.
    By the way: I wonder what happens when running the Installer from a restricted account. Do the pre- and postflight scripts run with higher privileges, too?

    There have been system wide holes such as the when it
    was possible to mount a remote disk without our
    knowledge or consent. I don't believe that the
    Installer situation is system wide.


    Yes. I remember an issue that was discussed about a year or so ago, where there was an error which allowed a local user to gain root privileges. Something like this is a lot worse.
  • Anthony Cunningham Level 3 Level 3 (625 points)
    Umm have any of you bothered to run this by Marc (ie the owner and devloper of entropy.ch)? He might give you some more info yuore missing. Hes quite responsive and open to inquiry...
  • Matt Broughton Level 5 Level 5 (4,980 points)
    I'm afraid I don't quite understand the advantage of
    setting the uid from 501 to 502 in your system
    configuration. So the 501 account also exists on each
    computer?


    I didn't change the uid at all. I still have the first account set up when you install the OS (uid 501). I have designated that account as the "master" admin account on all the computers for which I have control or provide support. Additional accounts are then created as needed with the appropriate privileges. I do not use the account with the uid of 501. The computers in the SOHO environment start their user accounts with 503 and are not admin accounts.

    One big advantage to me is that I can create a master image for distribution once they have acquired the proper number of licenses. This allows me to include some extras such as the w3c.org's 'checklink' program which they utilize by running an AppleScript. The 'checklink' program requires the build and installation of additional perl modules. It is far easier to provide it as a built in rather than lead them keystroke by keystroke (literally) through the process of building and installing programs.

    There are no real day to day operational advantages for the average single user machine in my account scheme.

    By the way: I wonder what happens when running the Installer
    from a restricted account. Do the pre- and postflight scripts
    run with higher privileges, too?


    The installer will ask for authentication where either admin or root authorization is required. Yes, after proper authentication, the scripts are run as root at the current time.

    Matt

    Mac Mini G4; B&W G3/300