[goMac]

Originally Posted by Person Man 

And you are missing his point, too.

He's not talking about the security issues. He's talking about APE itself, which is doing what it is designed to do: alter the function of the operating system by patching things in memory. His point is that people (developers) shouldn't be going around saying "APE is evil! NEVER use it under any circumstances!!!!!1111111oneoneeleven"

APE and Input Managers need to be patched, period. I'm not going to go the route of "APE is evil", because Apple ships the same security hole. But the problem needs to be fixed by all vendors who make this sort of patchery possible.

Originally Posted by Person Man 

Yes, the presence of APE has been known to interfere with applications in unknown ways (such as CharlesS' Pacifist). But to say that APE is evil and should never be used is too much. What's wrong with asking the user if APE (or any other third party system like an Input Manager, etc) is on the system and to try disabling it and see if the bug is still there?

Because it opens a way for unauthorized code to obtain root privileges, which is a massive nono. See my example above.

Originally Posted by Person Man 

Also, someone else said he couldn't believe that APE was being used to fix the bugs. (And implied that using APE was irresponsible because "APE is teh devil's child.") This is only TEMPORARY, and they are third party patches. This is actually the best way to fix it right now because they don't change the files on the disk. Patching the actual files may interfere with any official fixes that come from Apple later.

APE has known security holes according to Month of Apple Bugs. Now, there are no 0 day exploits at this point. But using a piece of software to fix a denial of service bug, when that piece of software itself has a bug that allows unauthorized code to obtain root privs is kind of backwards.

Originally Posted by Person Man 

Also, they released third party patches to protect people from the irresponsible way that the bugs were disclosed. "This is a bug and this is how to exploit it. And oh, Apple just found out about it the same way you did, just now." (With an implied "go out and have fun and do bad things because NOBODY is protected!")

See above.

Originally Posted by Person Man 

So, what does the average person do to protect themselves until Apple releases their official fix? Use APE and the third party fixes.

See above again.

[Person Man]

Originally Posted by goMac 

APE has known security holes according to Month of Apple Bugs. Now, there are no 0 day exploits at this point. But using a piece of software to fix a denial of service bug, when that piece of software itself has a bug that allows unauthorized code to obtain root privs is kind of backwards.

Yes, and I believe they are addressing that security hole, if I'm not mistaken.

EDIT: According to Rosyna of Unsanity, there is a fix in the works, and there is a workaround until then:

Originally Posted by Rosyna in a comment on the January 8 post in the Unsanity Blog

Based on our research, the local vulnerability issue discussed (MOAB #8) above is valid, and the /Library/Frameworks/ permissions bug it describes affects multiple vendors, not just us.

Disabling APE is not necessary in order to prevent this issue. Slava has a fix in the works while installing APE, and since we're currently at MWSF (what this post was about), we're going to try to discuss with Apple the best course for addressing this bug long-term.

To prevent the issue for all vendors, open the terminal (/Applications/Utilities/Terminal) and run:

sudo chmod g-w /Library/Frameworks/

This closes the Mac OS X issue that makes this specific vulnerability possible. The default permissions in /Library have made similar issues possible in the past (Widets and Kernel Extensions are two examples). A long-term solution to this is something we hope to discuss with Apple employees this week.

You shouldn't repair permissions until Apple has resolved this issue on their end, because it'll undo the workaround described above.

[goMac]

Originally Posted by Person Man 

Yes, and I believe they are addressing that security hole, if I'm not mistaken.

EDIT: According to Rosyna of Unsanity, there is a fix in the works, and there is a workaround until then:

a) The fix still doesn't cover the possibility of a compromised application being able to put an APE into /Library/Application Enhancers or ~/Library/Application Enhancers.
b) Until a fix is out it's still silly to use APE as a security tool when APE itself opens a larger security hole.
c) Unsanity shouldn't be putting executable daemons in the Frameworks directory anyway. The reason this is a security hole is because of misuse of the directory structure. The shifting of the blame to it being an Apple problem doesn't apply when you're not following Apple's guidelines. The daemon should be a startup or login item, and the daemon itself should be should not be in the Frameworks folder.

[Chuckit]

Originally Posted by goMac 

These are controlled by Apple. If Apple is not trusted, you might as well get off of OS X.

Once again, Apple has wiped several people's hard drives. I don't recall Unsanity having done so. I don't distrust Apple because they made a mistake once, and I don't distrust Unsanity for no reason at all.

Originally Posted by goMac 

Patching is the only way to accomplish this sort of attack. If by "affect other apps without using APE" you mean stuff like Mach_Inject, yes, Mach_Inject apps also need to be secure. But simply switching around a few dock images or swapping some icon files is not going to open you to an attack where malicious code can take root privs.

Root privileges were not the sole topic of conversation here.

Originally Posted by goMac 

New RAM would not likely allow someone to wipe your hard drive.

There's nothing inherent about APE that allows someone to do this either.

Originally Posted by goMac 

a) The fix still doesn't cover the possibility of a compromised application being able to put an APE into /Library/Application Enhancers or ~/Library/Application Enhancers.

So? If an application is compromised, your system is already compromised. It could already wipe your drive. Heck, it could already inject code without APE — only then you wouldn't be able to turn the injected code off as easily as APE allows you to.

Originally Posted by goMac 

b) Until a fix is out it's still silly to use APE as a security tool when APE itself opens a larger security hole.

APE doesn't actually open the security hole, it's just another victim of a security hole that already exists. The security hole "identified" by LMH is actually a well-known security hole in OS X itself — he was just targeting APE to be spiteful. Having the /Library/Frameworks directory writable means that if you have any frameworks installed there, there's a door for arbitrary code execution. While this vulnerability affects APE, it's a flaw in the system as a whole. However, the fix is simple: change the permissions on your /Library/Frameworks folder.

Originally Posted by goMac 

c) Unsanity shouldn't be putting executable daemons in the Frameworks directory anyway. The reason this is a security hole is because of misuse of the directory structure.

Eh, Apple does this all the time. For instance, guess where SystemUIServer and the window server are! It wouldn't make anything insecure if Apple got their permissions right.

[Hal Itosis]

Originally Posted by goMac 

a) The fix still doesn't cover the possibility of a compromised application being able to put an APE into /Library/Application Enhancers or ~/Library/Application Enhancers.

If there's someone who still hasn't done sudo chmod -R g-w * on that folder (and /Library/Frameworks, and
/Library/InputManagers, and /Library/Receipts, and... etc./etc./etc.), then they haven't been paying attention.

Originally Posted by goMac 

b) Until a fix is out it's still silly to use APE as a security tool when APE itself opens a larger security hole.

I can't speak for others, but I closed whatever holes I could myself (including patching boms*
so that permissions "repair" would enforce the changes I made!!!) No... I only use ApE for the
same things I have since Jaguar (or maybe 10.1?): i.e., FruitMenu, ShapeShifter and Silk.

Oh yeah... and Paranoid Android.

Originally Posted by goMac 

c) Unsanity shouldn't be putting executable daemons in the Frameworks directory anyway. The reason this is a security hole is because of misuse of the directory structure. The shifting of the blame to it being an Apple problem doesn't apply when you're not following Apple's guidelines. The daemon should be a startup or login item, and the daemon itself should be should not be in the Frameworks folder.

By Apple's "guidelines", I guess you're not referring to MOAB #5, MOAB #15, etc., etc.,etc.

--

* [BTW: Tho I laboriously did mine by 'hand', I notice this link has not been posted here yet: Carrel.ORG
Looks to be a very elegant solution... to a few of the issues anyway.]

[goMac]

Originally Posted by Chuckit 

Once again, Apple has wiped several people's hard drives. I don't recall Unsanity having done so. I don't distrust Apple because they made a mistake once, and I don't distrust Unsanity for no reason at all.

That isn't an excuse for leaving a security hole open.

Originally Posted by Chuckit 

Root privileges were not the sole topic of conversation here.

The APE exploit is all about getting root privs.

Originally Posted by Chuckit 

There's nothing inherent about APE that allows someone to do this either.

APE makes it possible for someone to wipe an entire driv without root privs. This is a security hole.

Originally Posted by Chuckit 

So? If an application is compromised, your system is already compromised. It could already wipe your drive. Heck, it could already inject code without APE — only then you wouldn't be able to turn the injected code off as easily as APE allows you to.

Applications do not have root privs. This is why they would leverage app, so through another app bad code could gain root privs. So no, a compromised app could not normally wipe your drive.

Originally Posted by Chuckit 

APE doesn't actually open the security hole, it's just another victim of a security hole that already exists. The security hole "identified" by LMH is actually a well-known security hole in OS X itself — he was just targeting APE to be spiteful. Having the /Library/Frameworks directory writable means that if you have any frameworks installed there, there's a door for arbitrary code execution. While this vulnerability affects APE, it's a flaw in the system as a whole. However, the fix is simple: change the permissions on your /Library/Frameworks folder.

It's not a security hole. It's called, they put an app that runs as root in a place where it's not owned by root. It's opening a new security hole. I'm aware Unsanity is not the only company to do this, and it's a dumb idea for whoever does it.

Frameworks are much harder to take advantage of, and can't be used to compromise every app on the system. Running a root daemon from /Library/whatever? Dumb idea.

Originally Posted by Chuckit 

Eh, Apple does this all the time. For instance, guess where SystemUIServer and the window server are! It wouldn't make anything insecure if Apple got their permissions right.

In /System/Library. Which is owned by root. Your point?

[goMac]

Originally Posted by Hal Itosis 

If there's someone who still hasn't done sudo chmod -R g-w * on that folder (and /Library/Frameworks, and
/Library/InputManagers, and /Library/Receipts, and... etc./etc./etc.), then they haven't been paying attention.

A better solution would be not putting daemons that run as root in those folders to begin with. I'm not trying to target Unsanity in particular here. I'm just annoyed at this Microsoft style security fix mentality. Instead of actually fixing the problem, patching it to death is a better idea? How about the problem gets fixed and the daemons get moved? The problem is not that they are executable code. It's that they are automatically executed as root.

Originally Posted by Hal Itosis 

By Apple's "guidelines", I guess you're not referring to MOAB #5, MOAB #15, etc., etc.,etc.

And these locations should be fixed too. Moving stuff like diskutil into the correct directory is the right solution, not just simply re-priving it. The /Library/Frameworks thing is really not Apple's fault at all. Developers should have known better, just like the Disk Utility devs should have.

[TETENAL]

MOAB appears to be one bug short. There doesn't seem to be a bug for the 31st. Either that or I don't get it.

[CharlesS]

Originally Posted by Chuckit 

Just because something could happen in the far-flung reaches of Bizarro World doesn't make it right to defame a perfectly serviceable product. Lots of people use APE, and their computers do not explode or go on a murderous rampage through downtown Tokyo.

Uh, I have encountered a lot of problems with APE modules causing my app to crash or produce other unexpected behavior. I've had to answer a lot of support e-mails blaming me for various problems that turn out to be caused by APE modules. Now granted, I've been luckier since version 2.0 (after it was released, I got a bunch of e-mails from people saying "congratulations, you fixed the bug with xyz haxie that makes it crash!), but it wasn't due to anything that I did. It's pure random chance, and who knows if the upcoming version that will support Leopard will get all screwed with by the haxies again. There's no way to tell, since I have no idea what those haxies are doing to my code, and they don't know what my code does, so there's no way to ensure that these two things are going to get along.

[Person Man]

Originally Posted by CharlesS 

Uh, I have encountered a lot of problems with APE modules causing my app to crash or produce other unexpected behavior. I've had to answer a lot of support e-mails blaming me for various problems that turn out to be caused by APE modules. Now granted, I've been luckier since version 2.0 (after it was released, I got a bunch of e-mails from people saying "congratulations, you fixed the bug with xyz haxie that makes it crash!), but it wasn't due to anything that I did. It's pure random chance, and who knows if the upcoming version that will support Leopard will get all screwed with by the haxies again. There's no way to tell, since I have no idea what those haxies are doing to my code, and they don't know what my code does, so there's no way to ensure that these two things are going to get along.

I guess Chuckit's point is that he's tired of hearing developers (in general) slamming APE every chance they get. It's a system addon that has the potential to cause problems with apps, yes. You may get (unfairly) blamed for problems caused by APE, but that doesn't make it as "evil" as some people claim it to be.

For the record, I have had APE installed for years, and I never had problems with Pacifist 1 (which I used to use on a rare basis... maybe once or twice more out of curiosity than anything). But then I only use two haxies, and maybe those are compatible with Pacifist.

[Hal Itosis]

Originally Posted by Person Man 

For the record, I have had APE installed for years, and I never had problems with Pacifist

Ditto.

And for any app which may not play well with ApE, it's just a matter of
adding it to the exclude list. [Though I'll grant that, it's not always the
first thing a user might think of when troubleshooting... so some may
send accusatory emails, before discovering the simple solution].

[alphasubzero949]

I'm surprised that no one has commented on MOAB #21.

For those who need to refresh their memories:
MOAB-21-01-2007: System Preferences writeconfig Local Privilege Escalation Vulnerability

Although they mention the possibility of tampering with the $PATH environment variable, they do not expand on what kind of evil can be done by doing so.

For instance, code wrapped in AppleScript inside a Cocoa app - or better yet - a disguised executable (just like Oompa) that relies on social engineering can tamper with your ~./bash_profile and place a fake sudo into a world-writeable directory. Once your $PATH has been poisoned, the malware will wait until you are prompted for your admin password, log that information, and toast your box however it wants while at the same time destroying any trace of its existence. I've tested a POC and found it to work in 10.4.8 (fully patched) as well as Ubuntu Dapper 6.06-1 with a few modifications to the POC.

Rixstep: Sudo Fun

This is not an OS X-specific issue but rather with BASH. A hypothetical situation like this was discussed over at the Ubuntu Forums. Unfortunately, it seems that the folks at BASH aren't in a hurry to resolve this issue.

[wingdo]

Well the month of Apple bugs is over. I though I'd post a comment from Bill Gates in an MSNBC interview (If MS is in the name you know it won't be biased).

"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." Quoth the Bill (who lives in a cave).

[Hal Itosis]

Originally Posted by alphasubzero949 

I'm surprised that no one has commented on MOAB #21.
:
[ snip ]
:
This is not an OS X-specific issue but rather with BASH. Unfortunately, it seems that the folks at BASH aren't in a hurry to resolve this issue.

That is an interesting one. (Both your Rixstep and Ubuntu links were excellent).

If I understand it, then... what's needed is for users to lock down all possible purveyors
of their customizable $PATH (like ~/.bashrc ~/.bash_login ~/.bash_logout ~/.bash_profile
~/.profile and ~/.MacOSX/environment.plist). [By "lock down" I mean chown 0:0, chmod 444,
chflags 02, etc.] And... for programs (scripts/tools/binaries/etc) to explicitly declare their own
$PATH (rather than blindly inheriting one), or... to specify an absolute path for each command.

I was looking at /usr/sbin/periodic, and noted that it does **not** declare any $PATH:

cat -n /usr/sbin/periodic | grep -i PATH
8 # periodic /absolute/path/to/directory - run periodic scripts in dir

So, if a user (whose $PATH was poisoned) were to issue sudo periodic weekly for example...
then any commands which periodic calls on could be over-taken.

Looking at a cat -n /usr/sbin/periodic,
I see at least 4 commands that could be targeted:

28 host=`hostname`
30 tmp_output=`mktemp ${TMPDIR:-/tmp}/periodic.XXXXXXXXXX`
94 [ $output = TRUE ] && { cat $tmp_output; empty=FALSE; }
107 rm -f $tmp_output

If the malware provides its own versions of hostname, mktemp, cat or rm... they would run.

So periodic should (follow basic security guidelines and) declare its own PATH='/bin:/usr/bin' ,
and/or use full pathnames for any outside calls:

file $(whereis hostname mktemp cat rm)
/bin/hostname: Mach-O executable ppc
/usr/bin/mktemp: Mach-O executable ppc
/bin/cat: Mach-O executable ppc
/bin/rm: Mach-O executable ppc

Have I got the gist of MOAB #21 ?

[Person Man]

Well, looks like Apple has fixed the following MOAB bugs so far:

1/1/07, 1/9/07, 1/20/07, 1/22/07, 1/29/07

The following non-Apple MOAB bugs have been fixed (I think):

1/2/07, 1/7/07, 1/16/07, 1/18/07, 1/19/07, 1/27/07

This leaves 18 reported bugs left for Apple to fix. We're still waiting for Unsanity to tell us that 1/8/07 has been fixed (which may depend on Apple to fix a privileges issue). Several of those Apple bugs left appear to be fixable by changing privileges.

How long do people think before the rest of them are fixed?

[Hal Itosis]

What's left?

Seems like #5, #15 and #21 are still exposed.. but I'm not 100% sure.
Maybe there's some other way(s) of thwarting attacks in those areas?
I guess since those are (likely) "local" vulnerabilities that no one cares.

Any others?