So are you ever going to release a patch or even a comment about the vulnerability in Application Enhancer described at MOAB 01-08-2007? Your trash talk has dropped off rather suddenly...

Posting this here because the comments for the appropriate post (the previous one) seem to have been disabled. This is a call (again) for Unsanity to post a public comment on the latest Month of Apple Bugs post, detailing a serious hack based on APE itself. Again, please do the responsible thing and spread the word omn urging users to disable APE until a fix is available. This is a dangerous bug and it's likely that someone is working hard to create a delivery mechanism that takes advantage of it. Regardless of what you think of MOAB, the issue is real.

This is a privilege escalation from local admin to local root, and APE is only one of several ways to do so (the simplest of which is just to type in your password!) So, really, it's an issue of Apple not properly setting, or documenting (depending on your point of view) the default permissions of /Library, which allow users in the "admin" group to write into it. Nothing to do with APE other than it being one of many ways to take advantage of this "feature".

Just as it's always been, don't let people you don't trust be admins on your machine, and remember that if ANYONE has console access to your machine, there are plenty of other physical ways they can do whatever they want to it.

Is there some reason APE can only be installed in an admin-writable path? And doesn't this still rely on APE running as root out of that directory and doing a setuid to the admin user, rather than running as the admin user from the start?

Obviously, the attack is useful for compromised admin accounts where the admin's password is not known to the attacker, and no console is involved. Obviously.

This MOAB thing .... shouldn't they be out looking for girls or something? The attack vectors are weak, very weak. They obviously need girlfriends or boyfriends, or perhaps just an escort agency. I was expecting some shock-horror OS X exploit that would require no user intervention .... instead I must lift a finger and do something. Oh well, I wonder if panic and hysteria has ensued over at MSJ yet ...

Note: The MOAB #8 seems to be some kind of rootkit!

(The example exploit downloads an undocumented helper that seems to open TCP port 8080, seems to disable the firewall, seems to create a new user that is member of the admin group and seems to send a email to a GMail account)

I have sent an email with more details to jason (at unsanity, is this right?)

Based on our research, the local vulnerability issue discussed 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.

In addition, it's important to mention that we were not contacted by the person who discovered this exploit at all. Rather, he elected to put your machine at risk in order to feed his ego. The individual who discovered this issue obviously has a big brain - it's too bad that his morals aren't on the same par as his intelligence.

Daniel, I didn't get an email from you. The email address is my first name at unsanity.com.

OK, .com not .org :-)
Sent again.

Tipped off by Daniel above, I did some digging into the binary that this supposed "demo exploit" installs. I'm not going to go into any detail at all on what the backdoor does, but it goes way beyond what one might expect for a sample exploit. I definitely do not recommend testing the exploit unless you know how to set up a sterile environment for it.

More to the point: The individual who published this exploit has now gone firmly in my mind from white-hat security researcher to black hat hacker. He is not helping the OS X community in any way. White-hat security researchers do not install root kits that attempt to obfuscate themselves onto other people's machines.

Having never seen a Mac OS rootkit before, I'm curious: what specifically does this exploit do--other than the back door that is stated up front in the MOAB advisory--that leads you to characterize it as a rootkit? Is there a kernel module, shared library replacement, or other traditional rootkit tactic going on?

The binary installed by the person publicizing this exploit attempts to obfuscate itself via self-modifying code and attempts to prevent reverse engineering by lamely denying a GDB attach. At that point, I don't need to see anything else - unless the sample exploit is intended to be a "sample of obfuscation" ala the Mac OS X Expert Challenge, obfuscating a sample exploit rings gigantic alarm bells in my mind.

Further, the binary uses "daamon" to detach itself from its shell, and opens and binds an internet port to the outside world. We are well beyond "sample exploit" at this point - a sample exploit creates "I was here" in a file on your desktop, it doesn't open communications ports to the internet at large.

I have not verified this for myself, but I am told that the "sample exploit" forks multiple sub-processes that call various system utilities and sends various communications over the internet. I'm not going to go into detail because I don't want to give ammo to future script kiddies.

The most generous possible explanation of this functionality is that the "sample exploit" informs a remote party that your machine has been exploited. Non-generous possibilities should be fairly obvious, and none of them are nice.

Again, a responsible individual would have brought this to the attention of the developer responsible before placing this in the wild. A responsible individual would not be disabling firewalls and opening INET ports. A responsible individual would apply his brains towards making the world a better place, rather than one in which anti-virus companies have a reason to exist.

It's possible that the person who publicized this exploit is not aware of what the exploit actually does (lame, but possible). If so, he or she should probably find out, and pull it, now. I certainly don't want to escalate some stupid battle of hacker-penises on this. We'll fix the privilege escalation on our side - please replace your binary with something that prints "I was here" to the console on yours.

Finally, I don't work on APE coding, I'm not a security researcher, and I have no clue who "proton" on #macdev is. I'm a developer who's supposed to be on vacation for a week in San Fran at Macworld working on a software demo and is instead having to screw around with security vulnerabilities. Displeased doesn't even begin to cover it.

The exploit downloaded by the sample exploit has changed - it now has less self-modifying code and does less forking of processes. I haven't gone through it in detail because all I need to know is that it has self-modifying code, attempts to deny attempts to attach via gdb, and opens an internet connection to the outside world.

The original download (which I've deleted, unfortunately) was 38,200 bytes. The new one is 33,964 bytes, md5 a345c1c6433e112777302ccae4e39ab2.

Did I mention I'm not a fan of this game?

@Rosnya:

MOAB wanted to collaborate with you but YOU nixed the collaboration. So don't whine like the wee whiner we all know you to be.

RIP APE.

@Jason:

Your arrogance and hypocrisy almost overreach Rosnya's.

Xune: are you by any chance one of the 14 year old script kiddies with something against the Mac that is doing this whole Month of Apple Bugs? Just because developers are doing the right thing and saying that releasing a sample that does damage to you system is wrong doesn't mean you should complain. It is MOAB that is in the wrong, not unsanity. Unsanity have accepted there is a bug and are working to fix it, MOAB are the ones childishly gloating that they've found 9 bugs in various pieces of software on the Mac.

Xune, you are clearly an idiot. MoAB offered to collaborate with Landon Fuller, who is not associated with Unsanity. He declined, and was right to do so. Even if he had agreed, there are no guarantees that MoAB would have worked with him in good faith - indeed, all of their actions so far indicate that they would have done otherwise, and then probably boasted about how fantastic they were and how stupid everybody else is. As it happens, they already tried to smear him.

Awww, c'mon Xune! My arrogance and hypocrisy way overreach Rosyna's! And I'm devilishly handsome, too! :)

wow looks like my predictions about what could come out of those anti social, end user having life hater nerds at various places turns out to be right.
I think those people begging for advertisement on their site so they can afford a mini can do lots of things for better money.
as a side note you can inform authories if anything suspicious happens on your bank accounts or credit cards.
you know the suspect at least.

I swore, to myself, that I would become a Neo-Luddite in 2007, but this is getting interesting...

Jason Harris, your physical looks or the record breaking success of APE based goodies and general profile of people using Unsanity products (having life,likes design etc.) could be the entire reason of this.

If you hire a security consultant, make sure you hire a good criminal psychologist which may be helpful solving THEIR issue.

They should be treated as virus and construction kit developers after remotely downloading files and disabling firewall.

BTW after these happenings I have personally added their IP range (thank you Pair networks!?!) to my firewall's block list, that is where black hat haxors belong.

PS: The site starting with R famous for their cheapo shell scripts and beginner level ObjC file explorer which serves as an extra PR department and helper(?) to these psychos is also hosted at Pair networks, what a co-incidence! (it could be, really)

I'm almost amused that those MoAB guys got funding in the form of donations. Especially after their malicious 'sample".