Slashdot Mirror
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.
At the very least, until this is fixed, this is yet another reminder not to install things without knowing what they are.
i run as a admin account and it still asks me to use my password to gain access even the program they listed it asked for my password to be entered to install. so it still is all good for me... i dont install things that i dont know what they are in the first place so those kiddies trying to hack on a mac will have problems downloading their haxzor programs cause it will crash their mac and allow some one to access it no big. just one less user in the world that cant learn how to get into ppls computers oh well
(yes i know i suck at spelling fell free to correct my grammar and/or spellin i dont care, im still not going to change
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.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
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?
My blog
So, when you're logged in as admin, and you install a package, that package can add whatever is in that package. Isn't that how it is supposed to work?
I'm not seeing the problem here. Am I missing something?
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.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
...you win the "First 'But, but Windows...' snark of the thread award".
:)
Enjoy wallowing in your smug sense of false security.
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.
#DeleteChrome
Is this true? Jeebus, this is as bad as Microsoft. I thought Apple was smarter than this.
from TFA:
Read my previous guide to securing Mac OS X and do not run as an admin user for daily activities.
Moreover, if you must run as the administrator, do not install packages from non-reputable sources without cracking open the package
Well, thank you, Captain Obvious!
well as I recall after using Macs for over 12 years now.. since OS X has come out you need to enter a password when installing software.. so given that, if you install software from an untrusted source it's just like downloading malware ridden software on a PC. But since I think most people think twice before doing that (MOST) then I don't think this is a problem.. considering that, that is how the install packages are supposed to work.. AFTER you put in your admin password.
Mac users just love being r00ted.
The solution is to make it so that nothing, not even kernel upgrades, can ripple out and effect things they shouldn't. The only way to reliably do that is to make them unable to see the things they shouldn't.
Please, for the good of Humanity, vote Obama.
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.
addictstrike@gmail.com
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.
At least OS X makes it extremely easy to install applications on a per user basis. When installing most applications on OS X, the user expects to drag the App to the appropriate "Applications" folder. If you don't have permission to write to that folder, then you can't install it. If the installer for the application needs more than that then I'm going to look hard at what that installer script does before I install it.
I don't see the "security" problem that TFA mentions as a real problem.
#DeleteChrome
Apple: Got Root?
Next scare: you can actually install stuff programs on Linux, Windows and AIX and those programs could do nasty things... euhm, yeah, that's why you don't just install everything.
Custom electronics and digital signage for your business: www.evcircuits.com
Installing software as an administrator can mess up your computer. Details at 11.
There's a great security T-shirt out there that carries the slogan "Once you're penetrated, you're ****ed" (except with the canonical 4LW instead of ****).
Once an attacker has gained the ability to run unrestricted code on your computer, they can cause you grief even if they have no ability to install applications, install kernel components, run as root or Administrator, or even access the network. Being able to prevent applications from gaining extra privileges is good, at least it makes the cleanup easier, and possibly limits exposure to one account (though anyone who had an account on a shared timesharing system in college knows that's not guaranteed). But for most people, that account has everything they care about on the computer anyway, so once they're penetrated they're ****ed.
Apple needs to make the following changes to reduce the probability of penetration here.
1. Don't treat files (like, say, installers) as "safe". Treat applications that operate on files as "safe" or "unsafe", with "safe" limited to applications that are designed to deal with untrusted files.
2. INSTALLERS AREN'T DESIGNED TO DEAL WITH UNTRUSTED FILES. Don't run an installer automatically.
3. The user is allowed to shoot himself in the foot, but he has to actually pick up the gun and aim it aware that it might go off. It doesn't go in the bathroom cabinet with the hair dryer.
Don't mix untrusted and trusted files by default... downloads go in a "Downloads" folder, not on the desktop. Don't automatically install downloaded files, let the user request that. Don't run helper applications that are selected for the Finder or Windows Explorer, keep a separate list of helpers for web browsers and mail software...
PS: Mozilla folks: the same issue applies to XPI. You've got a big red tag on XPI installer saying 'THIS IS A GUN', but you're still leaving it in the bathroom cabinet next to the hair dryer. Cut that out.
If you don't trust the provider of an installer, don't run it. And when it asks for your password, click cancel. Nothing to see here. Move along.
In a follow-up article, the author breaks the scoop about not leaving your password on a Post-It(TM) Note on your monitor...
It is pitch dark. You are likely to be eaten by a grue.
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.
Some drink at the fountain of knowledge. Others just gargle.
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.
One more reason why I hate installers of every kind.
/System: Just make that whole area read-only for all users, and give write-access only after 'sudo' or equivalent. (The same applies to more folders).
Luckily that most software for the mac comes as a dmg which you can mount, drag'n'drop inclosed app nearly anywhere, and that's it. Installers should be used ONLY when it's really needed and there is no other way to do it.
I do think that Apple should restrict write-access to anything in
Every developer should restrain him/herself from writing a kext (kernel extension). Really, unless you do something really unique and special, you do not need that much power. Leave the kernet alone. A kext is not a solution, its a new problem: A bad hack. Please prevent and eliminate these kind of problems.
What I cannot create, I do not understand
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.
/bin and maybe overwrite somethings in /lib.
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
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.
Some drink at the fountain of knowledge. Others just gargle.
I make websites and stuff. Buy one.
If you absolutely need to install from source*, here is a good way to do it:
./configure --prefix=$HOME/apps
.bashrc add:
/opt/[appname] and add the above things to /etc/bashrc. It works well.
make
make install
In
export PATH=$PATH:$HOME/apps
export CFLAGS="$CFLAGS -L$HOME/apps/lib -I$HOME/apps/include"
I haven't had that fail me. If you need to install something from source that needs to be accessible for other users, install it in
* Package repositories exist for a reason. Use them.
"It ain't a war against drugs.it's a war against personal freedom" --Bill Hicks
you prove the parent post's point about what a pain it is.
1) you have to use an application to uninstall the app.
2) and that only works when you used the same package manager to install it.
3) and you have to be root
4) and to instal it elsewhere you have to configure make
5) oh and don't forget the exports. hehe
6) oh and it doesn't work every time, since sometimes it needs to install fonts in a certain place despite the configure
jeeze
You can fucking say "fucked" on fucking Slashdot. Fuck.
"It ain't a war against drugs.it's a war against personal freedom" --Bill Hicks
check your user's group with netinfo.
If netinfo tells you your user is in group wheel (or was it admin) your user is an admin user.
I had thought Apple had repented of this and was prompting to make two default users now, one admin and one working, but I guess that was just wishful thinking.
But, really, until the OS allows one to surf the web with privileges reduced below even non-admin there will be paths open for stepped escalation.
Yet on the table here, linked to from TFA, the documentation quite clearly states that if a user is already an Administrator and the "Authorisation Access" specified is "Admin Authorisation", then the subsequent install will only run as the Administrator user. It also says that to get root privileges, "Root Authorisation" must be requested, which will prompt for appropriate user credentials.
So it would appear while TFA is correct in identifying the behaviour (if it actually happens) as a bug, it is *not* correct in stating this behaviour is "proper".
Unlike Windows where its not secure as you can intercept it.
Have a look at SysInternals - Ctrl2Cap utility for a working example.
You really think you know what you are talking about don't you? Must be nice, ozone man.
Good thing I'm using Windows.
w00t
Even though I imagine an RPM or DEB package could do the same thing, linux still has repositories. You can assume if it is in the origional repos it is safe.
The Gospel according to lolcat
unless things have changed linspire makes all users root unless otherwise told. yikes! watch out.
Before I saw the computers it was installed on, which I got one, I don't recall having heard of before. I got idea that it's by Lindows. What really got to me, and unfortunately many if not all computer manufacturers are now doing, it doesn't come with any printed manuals. And I like to RTFM. So I went to the Linspire website to print out what they have, and it didn't seem to me to be organized that well. I've printed out about 30 pages but both sides but I've barely touched all of the documents. I'll then put them in a binder. Also I agree the OS, not just Mac OS but all of them should have a wizard to setup different accounts.
Oops I hope this comes out right as I need to reboot the pc I'm using now, it's on it's last legs which is why I got Linspire.
FalconShould there be a Law?
Application with root access can do evil things. News at 11.
But yes, as someone else posted:: Windos-like installers are the problem. Most OSX software is still installed by dropping it into Programs and you're done, and I very much like it that way (among other things, it makes it trivial to uninstall software, which is often a nightmare on windos because a good portion of the uninstallers don't clean up properly).
Assorted stuff I do sometimes: Lemuria.org
An old idea around for some time was to design an install user that is similar to root but with limitations then limit root's power.
The extras depends on the system and how far you'd want to go to protect the system.
root could lose some access (ie: read-only OS.)
the install user would be limited to mostly disk related activities. This is just 1 example of the features that could be possible by singling out the whole process of system level software installation.
Democracy Now! - uncensored, anti-establishment news
I think installing software packages is difficult to get right by its very nature. You usually want software you install to be available to all users. A lot of software also modifies the way OS components work, e.g. which application the file manager will use to open certain types of file, or programs that are run when the system boots. On top of that, some packages provide or depend on libraries that should be available to more than just that software.
/etc/init.d, whatever). The problem that is being pointed out here is that, on OS X, installers can obtain that access without requiring a password from the user. However, I think that misses the point: even if you are asked for a password, are you going to decline giving it? You want to install the software, after all.
If any of the above are true of the package you're installing, the installer needs to have write access to some of the important places in the system (e.g. Applications directory, registry,
Even if you would do a thorough investigation of what the installer did, how many other users would? And even if you did that investigation and everything looked ok, how do you know the application itself, or the commands it registered for running at boot time don't do anything undesirable? You could inspect all the code that comes with the package (which would often require you to disassemble it, which may actually be illegal in your jurisdiction) and hope you didn't miss anything. Now, how many users would do _that_? Is it even practical? Of course, all this applies not just to software installed on OS X, but also on GNU/Linux, the BSDs, Windows, or pretty much any other operating system.
In the end, I think we just have to trust software to not do anything nasty. However, the great amounts of spyware and trojans that plague Windows users demonstrate that this trust isn't always deserved. So, some degree of inspection is still desireable. What I propose (and I've been advocating for a while) is to set up trust authorities that do whatever they deem necessary for verifying that a software package is trustworthy, and then digitally sign it. Systems would then be configured to trust any number of these trust authorities (the freedom to select what trust authorities to trust is important). The system verifies that a software package is signed by one of these authorities before running it (and should at least scream bloody murder if the package isn't trusted, but better would be to refuse to run it altogether).
The scheme above could make it much more difficult to get malware to execute on users' systems. Many GNU and BSD users already have a similar system in place: as long as you only install software through the package manager, you will only get software that your distributor apparently trusts. Often, the software is also digitally signed, verifying that the version you get is the same one that was approved.
Please correct me if I got my facts wrong.
(I posted this in another thread a while back)
Why did they use the "all or nothing" approach of requiring the admin password to install some things? Why not introduce a new model where everything in the filesystem is an object of one of the following types:
- operating system
- hardware
- hardware configuration
- program
- program configuration
- interface configuration
- data
Have the option of using different passwords for access to operating system, hardware, and program objects. When you run a program installer, it wouldn't be able to mess with your hardware or OS that way. The admin password would basically never be needed unless you were doing OS updates.
Dunno where you got this idea, but it's just plain wrong. Most Mac OS X applications are installed via drag-and-drop, just like on Mac OS 9. Some are installed via installers, but that has been the case since at least System 7.
Nothing has changed.
UNIX has finer grained security than Apple's using. It's easy enough to set it up so that you have people with printer rights, backup rights, and so on. Windows has even finer grains, though they're clumsier to use because they don't have setuid.
And you still have pretty much a root vs user model in both. On the Mac you only get privileges when you need them, on Windows you have to have them all the time, but either way splitting things up further requires a knowledgable system administrator to run things, because eventually you get some program that doesn't have quite the privileges it needs, and your choices come down to griping or charging off hell-for-leather into rootsville.
Are you trolling or something? Any Linux application that wants to touch the contents of /bin or /lib is abysmally poorly designed.
If I had said more specifically that it gets installed in $USR/bin or $USR/lib would you be less outraged? You still need root for all the common values of $USR. As a result installs on linux are ubiquitously done as root. On mac's its not common to install as root. Sure sometimes you have to. But you expect the installer to ask for the password in those cases. It's not. That's unexpected. Whereas if you always grant root to the installer as a matter of course, as you do in Linux, it would not be surprising it used root privs to do the install. Hence it's not a situation you usually have on linux. At least with Linux you know your pants are around your ankles. With the macs, they were down too, you just did not know it. Surprise!
Yes you are being blunt. Do you run as a Privileged user or unprivileged user when you do your installs? If you are like most people you run as privileged. So once again it's like Linux. Most folks installer is running privileged by default.
But even if I were wrong, that is that there is some hypothetical way to set up a Windows machine so it's similar to macs in regard to allowing everyday unprivileged installs. The essential point I was making remains unchanged an undeserving of your antipathy. That it would be surprising to find you that your installer was assuming root privileges on you.
Some drink at the fountain of knowledge. Others just gargle.