Hack Mac OS X With Installer Packages

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.

Comments

Well...

[Anonymous Coward]

At the very least, until this is fixed, this is yet another reminder not to install things without knowing what they are.

Ouch

[bnenning]

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.

Hacking OS X? Hardly

[morgan_greywolf]

You still have to install the package as an admin user. Lots of tools on Linux create admin user accounts without prompting for a password when run as root. The Debian Advanced Package Tool (APT), in fact, is one of them. It's perfectly possible to create a .deb package that sets up admin user accounts without prompting, as long as you are running as root. Does that mean you can hack Debian or Ubuntu with .deb packages?

Re:Hacking OS X? Hardly

[Wm_K]

I believe you misunderstand. sudo is a command that takes a user listed in the sudoers file and gives them root priviledges.

Exactly! But when do you get root priviledges? Only after you give your password to sudo (either on the cli or in the installer). Before that point you have as much privileges as a ordinary user.

The little thread started because cgenman said "OSX users run as admin by default" with which he seemed to imply that Mac OS X users run with root priviledges by default and therefor don't get prompted for a password. But this is not the case.

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.

Re:Hacking OS X? Hardly

[Anonymous Coward]

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.

So, in summation

[banky]

1. If you're sitting at the box, you might be able to 0wnz0r it. Same as for Linux, BSD, and Windows.
2. Regular folk should only install software from reasonably trusted sources.

I would assume that second point would be clear, given 10 years of watching Windows users open every last attachment that arrives in their inbox, while we sit at our Macs and laugh, but something tells me, probably not.

Not a "solution" per se, but

[93 Escort Wagon]

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.

"Installs" are bad

[Animats]

One of the great features of the original MacOS was that it didn't have "installation". You put an application somewhere, the Finder found it, and you could launch it. If you wanted to delete it, you deleted it, and it disappeared. Maybe once in a while you had to rebuild the desktop to update the derived info that made this work.

But now, Apple has "installation", where install programs put stuff all over the place, and maybe change the state of the system. Just like Windows. Big step backwards.

Three lines of AppleScript

[93 Escort Wagon]

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.

Re:it still asked me for a password

[Midnight Thunder]

This reminds of the suggestion that one security advisor provided. I think it was a story some time back here on slashdot.

Basically the guy suggested that the authentication dialog should have a user customisable image (you would customise in control panel). That way when the password entry dialog appears the person would know whether the password request dialog was being provieded by the system, or being faked. The idea is that the is little chance in the rogue program working out the image the user used to authenticate password dialogs.

It also makes us realise that validity of Microsoft providng the facility of signing packages. Although there are chances that you can have a faked certificate, this would help you limit yourself to a party with a valid certificate, if you so choose. The important point is that the certificate is used as an indication, not as a control mechanism.

The truth is though, if you have enough careless users installing random garbage you increase the chances of your system getting 0wned, no matter what the OS. It is the same principal as in the real world where even if you have the best security system, if you have people leaving doors open, covering detectors because they make life inconvenient they are truely worthless.

Seems nobody really got it.

[l0ne]

Admin user in OS X are regular users on the admin group. The default setup creates an admin user. Installer.app allows PKGs run by admin TO RUN AS ROOT AND WRITE ON ROOT:WHEEL OWNED FILES WITHOUT A PASSWORD PROMPT. It's more-or-less OK for admins to write to /Applications. It's not to change /etc/sudoers or similar nefarious things without a prompt.

WHY this is unexpected for macs

[goombah99]

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.

Re:WHY this is unexpected for macs

[drsmithy]

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

Whew!

[cciRRus]

Good thing I'm using Windows.