Welcome to the MacNN Forums.

alphasubzero949 · Mar 6, 2006, 05:38 AM

Let's say that you download some application X from Version Tracker or MacUpdate. Or maybe you download an innocuous JPEG (e.g. Oompa Loompa). Whatever the case, an innocent-looking script is placed into /Library/StartupItems/ upon user interaction. Somewhere down the line, you reboot...

In Tiger, you're (possibly) warned that the permissions are incorrect for the new startup item, so you go and fix it. Reboot...

Now let's pretend that this StartupItem places something into your ~/Documents/. You get info on this file and it's marked root:staff 0644 ('system' as the owner with read and write privs, staff as the group with read only privs, and everyone else with read only privs).

Do you see where I'm going with this?

Basically, a root process created that file. That process was the executable in /Library/StartupItems. And remember that the person who installed that file doesn't have to be root.

Now what if as a precaution to Oompa you locked down /Library/InputManagers/ via chflags? To undo it, you would have to boot into single user mode. Now let's say this nice little script in /Library/StartupItems/, running as a root-owned process, undoes the lockdown without ever requiring booting into single user mode (think "Opener").

If the processes in /Library/StartupItems/ run as root, even though they may have not been placed there by the root user, the ramifications are staggering to say the least.

The possibilities the script can do running as a root process is endless. Begs the question: do you really feel safe? Oompa may have been just the tip of the iceberg.

Of course, the obvious solution is to (A) not run as admin and (B) be suspicious of all untrusted software, but we all know that these are empirically not the case in the real world.

Discuss away.

JLL · Mar 6, 2006, 06:49 AM

Originally Posted by alphasubzero949

The possibilities the script can do running as a root process is endless. Begs the question: do you really feel safe?

It will take me 10 seconds to write a script that deletes you whole hard drive - and that threat has been there forever and can't disappear.

ism · Mar 6, 2006, 07:39 AM

As you said the solution is for Apple to make the default user a non admin. Perhaps mac sites should take a greater responsibility in educating users: When I first got a mac I ended up here pretty quickly, so perhaps a sticky showing a few basic steps to security would be a good idea.

Millennium · Mar 6, 2006, 08:11 AM

Apple could do a bit better in wording its "This requires a password..." dialogs as well. Although what it says is technically accurate, it doesn't really say why it's important. It should say something more along the lines of this: "This application is trying to install a StartupItem. Are you sure that this is OK? If so, please provide an Administrator password so I'm sure that my owner is OK with this. If not, just click Cancel, and the application will not be installed."

OK, so the text I provided is pretty bad, and I hope Apple wouldn't ever use it verbatim. But I hope it illustrates the concept: don't just say it requires authentication, but phrase it in a way that makes it clear why it's important.

Maflynn · Mar 6, 2006, 08:37 AM

Originally Posted by alphasubzero949

Let's say that you download some application X from Version Tracker or MacUpdate. Or maybe you download an innocuous JPEG (e.g. Oompa Loompa).

I'm not about to type in my password after downloading in an image from the net. That would be a dead giveaway that something hinkey is going on.

As for an application, I generally try to download items that have been mentioned here and have a good track record. Basically, I'm really pickey about what goes on my computer. While that will not completely remove the risk of viruses it does minimize my exposure greatly.

I think OSX's infrastructure is such that it protects the user to a great level. That doesn't mean there are no security holes to plug, or that viruses cannot infect a mac but I think its a lot harder and so far requires the user to acnkowledge a dialog box and/or type in their password. This beats windows where applications can be installed blindly w/o the user knowing it.

Maflynn · Mar 6, 2006, 08:39 AM

Originally Posted by Millennium

Apple could do a bit better in wording its "This requires a password..." dialogs as well...
"This application is trying to install a StartupItem. Are you sure that this is OK?

Excellent idea. I'd love to see something that tells me that x application is going to put items in the library folder, startup, etc before I allow it to install.

Big Mac · Mar 6, 2006, 09:09 AM

Millennium, is the permissions-escalation model granulated enough that the system could actually determine what folder the application intends to modify when it prompts for permission? I think this came up before (in the thread I posted about the Installer's initial prompt) and I recall you indicated there was nothing Apple could do to determine what an application will do with escalated privileges. But if it's possible for the OS to determine such a thing, Apple should have it do so.

Person Man · Mar 6, 2006, 11:27 AM

Originally Posted by Big Mac

Millennium, is the permissions-escalation model granulated enough that the system could actually determine what folder the application intends to modify when it prompts for permission? I think this came up before (in the thread I posted about the Installer's initial prompt) and I recall you indicated there was nothing Apple could do to determine what an application will do with escalated privileges. But if it's possible for the OS to determine such a thing, Apple should have it do so.

Well, typically applications ask for the password BEFORE making the changes that require the password, so the only other thing that could be done is to make the process more onerous by watching all the folders where malicious software could be installed and intercept each change and then say "X is being changed. To continue, enter your password."

We're going down the path of warning about every little thing, such that people will just blindly click past the dialogs and we're left with the same situation we had before.

This is getting ridiculous. We need to educate users about the risks of running unknown software. The proposed solutions do not strike a balance between convenience and security.

alphasubzero949 · Mar 6, 2006, 01:11 PM

Originally Posted by JLL

It will take me 10 seconds to write a script that deletes you whole hard drive - and that threat has been there forever and can't disappear.

Yes I know that, but you're missing the point.

The StartupItems folder - like the InputManagers folder - is NOT safe, especially when those processes are owned AND running as root. As an admin user, you don't even have to use an installer to place something there, you could just move it there physically.

In the example from the OP, even if you were to apply Open Firmware Password to lock down the machine to prevent anyone from physically altering the chflags, a root owned process in StartupItems can easily undo your changes, thereby even making OF Password useless. This is exactly how Opener was able to escalate privileges.

Social engineering arguments aside, I do not feel comfortable with these processes that should have been owned by me or whoever placed them there running with root privileges. All the worse if those processes can be placed there without any user interaction required.

As stubborn as I have been after Oompa ad nauseam, after thinking of this scenario, I'm actually seriously considering disabling my admin privileges and making an account specifically for admin duties.

The ultimate problem is how to address the fact that Apple allows the first user (usually Little Johnny with his brand new iMac or even Grandma) admin privileges and on top of that, fails to warn them about the consequences of running as admins. Even for those who know what they're doing as admins, this should be a warning to them as well especially if a proof-of-concept can be done without any interaction required from them whatsoever.

Try explaining this stuff to the average Joe you see on the official Apple forums, really.

Tyre MacAdmin · Mar 6, 2006, 01:38 PM

Yes. this is an issue... if you get your app you downloaded from an untrusted source... What's the solution? Write your own software.

Chuckit · Mar 6, 2006, 01:48 PM

There's really no need to run as an admin all the time. Authenticating in OS X as a normal user isn't particularly more painful than authenticating as an admin. Though honestly, if you ask me, admins should not have access to all those folders either without entering a password.

alphasubzero949 · Mar 6, 2006, 06:58 PM

For those of you still in denial, here's a proof of concept of what I discussed in the OP by the guys at Rixstep:

http://rixstep.com/1/20060306,00.shtml

It's harmless, but it should serve as a wakeup call as a deadly variant could have easily been substituted. Enjoy.

CharlesS · Mar 6, 2006, 08:10 PM

Um, I think this information is a bit out of date. This used to be a problem under earlier versions of Mac OS X, but at least on my install of OS X, my BaseSystem.pkg's BOM file has this in it:

./Library/StartupItems drwxr-xr-x root wheel

which means that StartupItems will be owned by root, and non-writable by everyone else. And sure enough, I'm not able to drag stuff in without authenticating, even from an admin account.

alphasubzero949 · Mar 6, 2006, 08:40 PM

Sure, it used to be a problem under earlier versions, but what about all of those people out there still running Panther? Or Jaguar? Or even...heaven forbid...Puma? They don't have the luxury of the system detecting changes to /Library/StartupItems/ that will cause an alert dialog to be thrown up.

I tried the POC on a Panther system and sure enough it worked as advertised. Matter of fact, the OP was another POC using Opener where the rtx file in ~/Documents/ did have root:staff 0644.

Authentication or not, the problem is that someone or something can just gain root access just like that. Not using sudo, mind you, but having root access on STARTUP.

goMac · Mar 6, 2006, 08:54 PM

People running older versions can lock it themselves. People buying new machines aren't affected. You're saying someone is going to target not only Mac OS X, but an old copy of Mac OS X? Seems to me to be the same case as someone running a copy of OS X behind on security patches.

CharlesS · Mar 6, 2006, 09:08 PM

Plus, the topic of your thread was "Think You're Safe?" Why, yes, I do feel safe from this particular exploit, since I'm running 10.4.5, which seems to have fixed it.

alphasubzero949 · Mar 6, 2006, 11:32 PM

Actually, I am retracting my comment about running as a non-admin because ultimately this will send you back to square one.

CharlesS, of course you feel 'safe' because you are a programmer and already know the ins and outs of OS X.

What about those who have no clue about what I am talking about here? I'm talking about Joe User who could care less as long as it works.

I believe that there needs to be some serious education about computer security and as these recent issues have shown, we need to be less complacent and more aware of knowing what is going on with our systems.

CharlesS · Mar 6, 2006, 11:39 PM

Originally Posted by alphasubzero949

CharlesS, of course you feel 'safe' because you are a programmer and already know the ins and outs of OS X.

Um, no, it's just because this particular security issue has been fixed.

There are other problems that I do not feel safe about. This is just not one of them.

alphasubzero949 · Mar 7, 2006, 12:06 AM

Actually, you are correct.

Comparing the two, StartupItems in Tiger is root:wheel 0755 while in Panther (at least on my machine), it is root:admin 0775. /Library for both is root:admin 0775 but in Tiger it has a sticky bit where only the user can remove what (s)he specifically placed in there.

So while Tiger users are safe, those who have yet to (or cannot) make the upgrade are still vulnerable.

yugyug · Mar 7, 2006, 12:21 AM

One of the things I read about this Oompa thing is that it requires terminal to work - and hard links to that app. When I read that I moved my copy of terminal (which I almost never use) into a new sub-directory in the utilities folder. Opinions? Is this an effective safeguard?

Big Mac · Mar 7, 2006, 07:46 AM

Originally Posted by alphasubzero949

So while Tiger users are safe, those who have yet to (or cannot) make the upgrade are still vulnerable.

So a very small portion of users may at some point be bitten by such an exploit. That's life in the big city. Apple cannot force people to update their systems.

goMac · Mar 7, 2006, 01:08 PM

Originally Posted by yugyug

One of the things I read about this Oompa thing is that it requires terminal to work - and hard links to that app. When I read that I moved my copy of terminal (which I almost never use) into a new sub-directory in the utilities folder. Opinions? Is this an effective safeguard?

I don't think that's right... Launch services (which is the problem iirc) shouldn't care where terminal lives.

Tyre MacAdmin · Mar 7, 2006, 01:42 PM

Originally Posted by alphasubzero949

'm talking about Joe User who could care less as long as it works.

What's Joe user doing on his computer in the first place? Could care less as long as it works? Wouldn't that be just a super world to live in where you could just go running around hoping things work and caring less how!

gambo · Mar 7, 2006, 03:13 PM

My library/startupitems/ folder is empty, is ths normal? I opened this in finder, if i did the same in terminal(witch i have no clue how to do) would i find hidden items?

Chuckit · Mar 7, 2006, 03:21 PM

There won't be anything in /Library/StartupItems unless you've installed something in there.

CharlesS · Mar 7, 2006, 03:55 PM

Originally Posted by goMac

I don't think that's right... Launch services (which is the problem iirc) shouldn't care where terminal lives.

You could put the Terminal inside a disk image, and leave the disk image unmounted when you're not using the Terminal.

Or you could edit the Terminal's PkgInfo and Info.plist files to change its bundle ID and app signature.

Chuckit · Mar 7, 2006, 04:07 PM

Originally Posted by CharlesS

You could put the Terminal inside a disk image, and leave the disk image unmounted when you're not using the Terminal.

I thought LaunchServices was smart enough to mount a disk image if you try to open an application that's inside one.

CharlesS · Mar 7, 2006, 07:24 PM

Originally Posted by Chuckit

I thought LaunchServices was smart enough to mount a disk image if you try to open an application that's inside one.

I just tried putting TextEdit in a disk image, dismounting it, and double-clicking an RTF file (with TextEdit set as the default app). The file opened in SummaryService.app instead. FWIW...

I guess if you wanted to be really thorough, you could password-encrypt the image. Or you could tweak it with one of those "license agreement" things so you'd have to click Agree to mount it...

alphasubzero949 · Mar 7, 2006, 09:36 PM

Originally Posted by Tyler McAdams

What's Joe user doing on his computer in the first place? Could care less as long as it works? Wouldn't that be just a super world to live in where you could just go running around hoping things work and caring less how!

Uh, try being the Mac go-to person in IT. You'd be surprised how dumb computer users can be. Even Mac users.

Tyre MacAdmin · Mar 8, 2006, 04:06 PM

Originally Posted by alphasubzero949

Uh, try being the Mac go-to person in IT. You'd be surprised how dumb computer users can be. Even Mac users.

I'm not surprised, I am trying to convey that the problem is not *always* the computer and it's the user that is causing issues. If their computer is not secure then it might be that they're not using it correctly. People have a way, me included, of wanting to twist things in to a state that is not natural in order to find an "easy way" for their solution. What I am implying is that these people are decieved in to thinking that they can simply hop on a computer and it's all good. When in reality they need to know how it works in order to use it correctly.

Zubir · Mar 8, 2006, 06:27 PM

Originally Posted by Tyler McAdams

What's Joe user doing on his computer in the first place? Could care less as long as it works? Wouldn't that be just a super world to live in where you could just go running around hoping things work and caring less how!

Do you know how to tear down a car engine? Do you know exactly how to repair a refrigerator? A DVD player? A hot water heater? See where I'm going with this? To most people, computers are a tool, not a sacred cow.

Tyre MacAdmin · Mar 9, 2006, 11:20 PM

Originally Posted by Zubir

Do you know how to tear down a car engine? Do you know exactly how to repair a refrigerator? A DVD player? A hot water heater? See where I'm going with this? To most people, computers are a tool, not a sacred cow.

Yes. So lets make it offical then that it's a tool for me. Speak now or forever hold your peace!

krove · Mar 10, 2006, 12:27 AM

Moving Terminal.app or placing it inside a disk image is pointless: there are other 'hooks' that malicious applications could use to execute shell scripts, namely AppleScript, which does not require Terminal.app.

alphasubzero949 · Mar 10, 2006, 03:00 AM

It is pointless. However, that's not the end of it:

1. Tiger marketshare is nowhere near over 50% or whatever the hell the figure Jobs put out. Seems more like the usual RDF crap pumped out of Cupertino. Whatever the number, it means that the remainder of the OS X user base (Cheetah to Panther) is wide open for this vulnerability and Apple doesn't seem to be in a hurry to fix it. Most labs I know aren't even running Tiger. Some have JUST upgraded to PANTHER. I really don't know that many people running Tiger other than myself and a few friends.

The Rixstep POC works as advertised on a 10.3.9 system with all of Apple's security updates and everything else there is for Panther.

2. Apple claimed that fixing this issue in Tiger is sufficient. The remaining ~50% or so of the OS X user base cannot or won't upgrade to Tiger. What do they do? Buy new hardware? (Don't you just love planned obsolesce?) Shell out $129 for a security fix?

3. This is not entirely about social engineering. This is about any arbitrary code placed there by some user other than root running as a root process upon reboot. Of course, you can lock the StartupItems folder down to match the permissions on a vanilla Tiger install (root:wheel 0755). Unfortunately, however, a malicious script or even an innocent installer can go back and undo the job if it has your admin password.

Tyre MacAdmin · Mar 10, 2006, 09:51 AM

Wouldn't a good ACL keep this kind of thing under control?