Installer priviliges

If any script runs as sudo - it gets logged to /private/var/log/system.log

If any process (including the installer) uses the Apple provided security framework that calls the keychain or the box we are familiar with - it gets logged to /private/var/log/secure.log

wow - you're definately on the right trail. I don't know much about the installer and the promotion message - but it sure has me wondering too...

I do think the installer is smart enough to tell if it will execute any script (and hopefully looks for sticky bits on the installed pieces) but it's one chink in the armor if an un-authorized package can deploy items that later are more trusted than they should be.

Have you gotten pacifist from the web and opened the package to look around and see what it really installs (and which permissions/scripts might be in the bundle?)

No, I haven't, I haven't heared of pacifist before.

Pacifist can show you quite a bit. I took a quick look at the installer both using Pacifist and looking at a sampling of the various packages Info.plists. To me it looks like the maker of the packages missed on the ownership of the files. From what I saw, all the files to be installed carried ownership of admin:wheel. For the admin owner the UID 501 is being used. This is the first account created when you install Mac OS X. The default installation is to take place at /usr/local/php5/.

When I examined some of the Info.plists, they showed that "admin" authorization was required for installation. As the account you were using when installed was an administrator account, you implicitly gave your permission. It would not have asked you for a password.

Example from an Info.plist showing the level of authentication needed and default install location --

<key>IFPkgFlagAuthorizationAction</key>
<string>AdminAuthorization</string>
<key>IFPkgFlagDefaultLocation</key>
<string>/usr/local/php5</string>

But the package seems to be a simple directory, at
least I can cd into it in the shell. It contains a
directory called "Contents", which itself contains
Info.plist (a file)
Packages (a directory that seems to contain the
actual content that is installed)
PkgInfo (a (small) file)
Resources (a directory containing some additional
stuff)

You might want to take a look at the anatomy of a metapackage in the developer section.

I think the package itself can be trusted, as it was
linked from the official PHP homepage.

While the package comes from a reliable source and its contents can be presumed to be safe and the software will run as expected, that does not mean that the installer can't have mistakes such as file ownership errors.

However, I
don't see a way how OS X could find out that this
package is trusted and that the installer can be
granted root privileges - except perhaps by checking
all the things the package wants to to and granting
the installation only if this does not affect other
parts of the system. But I think such a check would
be difficult to implement and error-prone.

The installer was not granted root privileges. It was only granted administrator privileges as you cited --
Jul 26 20:29:39 hostname : Package Authoring Warning: entropy-php.mpkg authorization level is NoAuthorization but was promoted to AdminAuthorization for compatibility, ensure authorization level is sufficient to install. . . .
Jul 26 20:30:18 hostname : admin auth received to install

If root privileges were granted, this line would look something like this exerpt from my computer logs--
Jul 25 18:09:32 mini : Package Authoring Warning: Install xxxxx.mpkg authorization level is NoAuthorization but was promoted to RootAuthorization for compatibility, ensure authorization level is sufficient to install. . . .
Jul 25 18:09:54 mini : admin auth received to install

The other option is that the installer asked my
password when I installed the package for the first
time (unfortunately, I don't remember) and OS X now
"knows" that this installation is "authorized".

It doesn't work that way. If username and password are required for a higher level of authority, you will always be asked for it.

You might want to review what is in your /var/log/install.log for varying examples. This log contains everything that is in the log file you can view when running the installer.

What I did not see (too many packages to rifle scrutinize) is how the installer was able to make a directory in /usr/local without root authorization. I think this might be possible if one of the enclosed packages was set to overwrite permissions. In any event you will probably want to do a recursive chown to set the /usr/local/php5/ directory and its contents to root:wheel. You will probably also want to check for any other directories that were created or where files were installed to see if additional permissions need changing.

Hope this helps somewhat. I am certainly no expert, but I am somewhat familiar with making packages.

Matt

Mac Mini G4; B&W G3/300

As a follow up to my previous post. I did spend some time this morning looking more closely at the PHP metapackage and playing around with the developer tools PackageMaker.

The upshot is that you can make a package that will make a directory "php5" with ownership root:wheel in /usr/local and install files to that directory with ownership "username:wheel" with only giving the Installer.app adminstrator authorization. If you are installing from an adminstrator's account, this means that you will not be prompted for username and password. Administrative authority is implicit by your operating in an administrator's account. Only when Root Authorization is require will you be prompted for username and password to run the installer as "sudo", "su", or in effect "root". This does not seem right to me and is almost certainly the part that was leading to confusion.

Matt

Mac Mini G4; B&W G3/300

This is interesting, thanks for your investigations.
And indeed, it is very strange, as the /usr/local
directory is writeable only for root. Thus, even if
the installer would simply ado[p]t the access rights
specified in the package, it should not be allowed to
create a directory inside /usr/local, I think - even
if running with admin privileges.

I would agree. Certainly every time I have compiled something by hand, I had to do a "sudo make install" in the Terminal to install into /usr/local.

It would be interesting if one can make the installer
create arbitrary directories or even overwrite
existing ones.

I don't believe that you can overwrite a directory. Whenever I make a package, I always show a default path of "/" . For installation of the PHP files, you would see the path /usr/local/php5 whether you looked at it in Pacifist or did a(n) "lsbom" on the Arichive.bom. That way you know exactly what is going on. I believe you can, however, overwrite files of the same name. There is some version checking. I'm not sure if that applies to files or just previously installed packager versions.

This, I think, would be definitely a
security issue. Perhaps Apple should be informed as I
think it's possible that this is not the demanded
behaviour.

My hope is that Apple is aware of any such security bugs. I don't feel that I am knowledgeable enough to fully understand whether or not there is a real problem here. I do know that I have had some flakiness with PackageMaker. Many times I will have specified Root Authorization in PackageMaker and found that when the package gets built, it will show Admin Authorization. I have to go back in and edit the Info.plist by hand.

Regardless of whether the action we are witnessing is a security threat, it wouldn't take much effort to cause real havoc even if it called for Root Authorization. A preflight or postflight script could contain something like "rm -f -R /Applicatins" (there is a deliberate typo there). It again boils down to trusted sources and trust in the developer/packager.

Matt

Mac Mini G4; B&W G3/300

Yikes!

This is terrible, at least another reason not to use an "admin" account for day to day use. Spurred on by this thread, I just did some tinkering of my own, and wow - you're both absolutely correct. In terms of susceptibility to malware, we're still in the same state as back in the "Panther" days where "admin" = "root" due to vulnerabilities exposed by "iOpener". In fact, this is worse. A lot worse.

Excellent job gentlemen.

Boo Apple. Boooo.

Now imagine the package would specify a path that is already existing and perhaps important to the system. You could pack exactly the same files into that package like the ones that are already installed, but with different content. If that would work, you could overwrite important code or data.

I think that might be possible, I haven't tried it. I do know that there are some versioning checks in place. For example, you install "Tiger Serial Print.pkg" version 1.2.2 from my website. If you then try to install an earlier version such as version 1.1, it won't allow it. I specified that you could not revert to an earlier version. That being said, I do recall that there was an Apple updater (can't remember if it was in Jaguar or Panther) where Apple accidently left the file /usr/libexec/cups/backend/serial in the installer and it did overwrite the same file that the software from my site installed. (Apple doesn't support serial printing and has purposely left out the serial backend. It does get built at compile time, however, and Apple forgot to remove it when they updated some CUPS components.)

Of course, you would have to manually execute the installer, and if the malware is hidden in a package you trust, it doesn't matter whether you have to enter your password or not. But the assumption that as long you don't enter your password, your system cannot be compromised, would turn false.

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.

Matt

Mac Mini G4; B&W G3/300

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 any trojan app - not just an obvious installer, can potentially ' curl' the package and install it in the background if run in an "admin" account.