Unsanity Developer Comes to APE's Defense

beelsebob writes "Rosyna, the famously tellytubby-like Unsanity Developer has spoken out in the defense of their Application Enhancer (APE) framework. The framework has taken a beating since it came out, being accused of being spyware, or of crashing computers. In fact Unsanity have only received one bug report about APE itself, which was promptly fixed. The article is a very good defence of the product, and a very good read."

Comments

Re:Extensions for Mac OS X

[beelsebob]

Hmmm... check one for didn't RTFA, if you'd read it you would realise that rosyna refutes that claim in there!

Bob

Re:Extensions for Mac OS X

[moof1138]

It is pretty poor analogy to compare APE to QT Codecs or Internet Plugins. Their behavior is for the app to dynamically load and run their code when needed, and they will not be loaded unless they are called. When I launch TextEdit there is no DivX or Flash code loaded into TextEdit's memory space. APE inserts code into all running apps. That is quite different.

Input Managers are a better analogy, and honestly I do not install 3rd party Input Manager since I understand their behavior.

I don't know enough about CMMs to comment.

Re:tel{e,ly}tubby-like whaaaa?

[Meowing]

I don't know what that's about, Rosyna looks pretty ordinary to me....

Flack about the URL handler exploits

[SailfishMac]

A lot of this came about because of the rash of URL handler exploits in Mac OS X recently.

In the mad rush to secure Mac OS X, two groups emerged. The Paranoid Android (based upon APE) and the RCDefault/More Internet side.

Unsanity (makers of PA) had a incomplete product at first that could not keep up with the rapid new discoveries. It was designed to check the URL handlers for you for suspicious behavior, problem was it didn't cover all the URL handlers.

v 1.1 was no good and finally unsanity came out with v 1.2 which covered them better.

Now on the other side of the camp is the RCDefaultApp and More internet crowd, which schooled people to turn off/reassign the URL handlers themselves with a very easy to use program.

Their argument was that one didn't need to install a "haxie" (in their own words) "injects code in all your programs" &

"they do their thing by violating the boundaries of protected memory."

http://daringfireball.net/2004/05/help_viewer_secu rity_update

Either way, I'm glad the Mac community turned out in force to solve these problems in a jiffy, Apple should be ashamed of themselves, being warned over 4 months ago about them.

If using Paranoid Android was the only option to prevent these exploits, I'm sure everyone would be happy using it. But it seems to me just disabling the URL handlers manually until needed or reassigning would have been a better option.

I'm glad we had a choice, so kudos to both and thanks.

Re:Flack about the URL handler exploits

[rixstep]

Now on the other side of the camp is the RCDefaultApp and More internet crowd, which schooled people to turn off/reassign the URL handlers themselves with a very easy to use program.

RCDefaultApp can't turn off a thing. The use of the string '' within this program is very unfortunate.

RCDefaultApp 'redirects' things. When you want a protocol 'disabled', it actually redirects to another app hidden within its own application package. A package in turn called 'Do Nothing'.

This method might work in a pinch, but it is not a clean solution. The clean idea is to disable the protocols completely. Damage your plist file where RCDefaultApp proclaims its ownership of your protocols, or remove RCDefaultApp because you think you're finished with it, and you may become vulnerable again.

RCDefaultApp does not turn anything off - it redirects. Big diff.

Re:Extensions for Mac OS X

[MoneyT]

Er, the only reason it would want you Administrator password is if you tried to install APE to /Library/Frameworks or a module to /Library/Application Enhancers.

Both APE and the modules allow you to choose whether you install localy or for all users on the machine.

APE: Neither Blind nor Unique

[ZackSchil]

Don't think that APE is a security nightmare on its own. Sure, it provides means by which to inject code into programs that were launched after the code injector became present, but that's not a unique ability. Technically, any daemon can inject code into a program as it is being launched. The APE framework is not doing anything more than calling existing (but undocumented) APIs used in debugging Mac OS X. APE modules cannot poke around into any program they wish, they may only poke around in the applications in which they have been told to reside (something YOU have control over). They may not touch any other program. Sure, you can call APE a bad idea, and yes it can crash applications or spy on the user, but not more than any other piece of malware could, entirely separate from APE.

Re:Extensions for Mac OS X

[Anm]

You don't understand. APE doesn't have access to physical memory nor the 'system' itself. By system, I mean operating system/kernel. APE uses the same user level techniques as debuggers. You know, break, step, continue...

This isn't strictly inserting new code, but does give allow an outside APE module to act like it was called from another piece of code: a code break pauses and notifies APE which calls an APE module and then returns control to the original module. I would guess one could also do variable introspection, but I assume this is harder without debugging markers.

It is perfectly possible to do this sort of thing on other Unixes.

Does this have potential to break things? Yes.
Does it break often between versions of code being hooked? Yes.
Is there potential for spyware? Yes.
Has anyone shown any evidence of problems from the standard licensed releases on the appropriate platforms/versions (i.e., non-development versions)? Not to my knowledge.

Anm