Slashdot Mirror
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."
Bob
Bob
I mean, really, anything that makes the computer, at any level, unstable is not worth using.
So can I take this to mean the only thing you're running on your computer is a hand coded BIOS that you have personaly coded to ensure that there is no possible way it could cause a crash?
T Money
World Domination with a plastic spoon since 1984
Hmmm... check one for didn't read the key point of the parent post: "it inserts code into every running program. Blindly."
That is the point that Rosyna didn't touch in his article. He just pretends that since it is the particular module's code that is injected and not APE Framework that this is somehow okay. If you think it is acceptable to let essentially arbitrary code be injected into every running application, that is your business, but critics are right to point out that it is a security nightmare, and it will destabilize all apps on the system by design.
Rosyna pretended that since there was one bug filed against the APE framework that this means that it would not destabilize apps. But no apps were not designed to have additional code injected into them via APE, and most were generally not tested in that environment. The behavior of the framework is the issue not the fact that the framework and daemon itself are stable.
Hyperbole is the worst thing ever.
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.
Hyperbole is the worst thing ever.
Why would I not say that just by reading a man's opinion? You do realize that's what the "article" is, right? His opinion. His whole point is because the APE modules cause the crashes that the idea of APE is a good one. It works like OS 9 extensions at a fundamental level, only for programs. It's begging for a crash. Indeed, it does. Often.
I support Macs for a living. APE is banned. Every single time we have chronic problems on a Mac, we trace it back to someone using Shapeshifter or some other hack. Does it mean APE is buggy? No, it means it's a bad idea. Unsane, if you will.
I don't know what that's about, Rosyna looks pretty ordinary to me....
Interesting that you bring up protected memory. In a way APE defeats the purpose of protected memory since it injects code into every running application. Here is the scary part about what that means - once someone has APE running all haxies can poke around anywhere they want in any running apps memory space, so they can know every application password used, they can read anything out of your keychain that an app is allowed to read prompting you on behalf of the app for the keychain password, and so on. APE is a serious security nightmare. I have no reason to think that this has been exploited as yet, but installing APE opens the door for the abuse, especially if you are running closed-source haxies.
While there are no known cases of APE based spyware at this point, APE could potentially be exploited a very effective vector for spyware (and viruses).
Hyperbole is the worst thing ever.
This is the key point that Unsanity is missing. We removed trap patching (as a supported extensibility mechanism) and all the insanity that goes with it in Mac OS X for a reason. That shit destablizes everything. - a former Carbon developer at Apple
A lot of this came about because of the rash of URL handler exploits in Mac OS X recently.
u rity_update
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_sec
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.
If you don't like it, don't use it. Plain and simple.
Some of us, for example, route audio from different applications to different places; when I play music or games, it comes out through my audio system and the amplified speakers - when an e-mail dings at me, it comes out through an internal speaker.
Haxies like Detour, which provide real, interesting function, which is useful for any pro-audio guy with a lot of very loud audio hardware that you don't want system beeps playing over, is fundamentally interesting - moreso if you've got more than one set of audio outputs.
So, before people go off badmouthing how awful it is, they should think twice: that same code injection technology enables everything from Shapeshifter to reskin your UI to useful functions like being able to reroute your audio away or into your pro-audio equipment on an application-by-application basis.
In other words: despite everyone's nasty opinions, it provides a useful service to those of us with unusual requirements of our systems.
-- A mind is a terrible thing.
critics are right to point out that it is a security nightmare, and it will destabilize all apps on the system by design
/Library/Frameworks/ like a good framework should be.
/Library/Application Enhancers - again, this is an area which affects all users on the same machine. The fact that Unsanity use daemons also points to all users being affected by what one user wishes to do, and preferably in user mode.
This is correct. Some people know the Mac, but few people know Unix. Ken Thompson, one of the fathers of Unix, said emphatically:
Keep your hands off the drivers.
The whole idea of Unix is not only security but respect - a respect that enhances security.
The very thought that code in a 32-bit protected mode system would be able to do things like this - correct me if I am wrong, but APEs require your administrator password, right? That means that even though they are 3rd party code they want to go where they have no right going.
APEs and everything like them depend on 'hacks' as their name implies. They're going to break easily as what they're doing is not officially supported by the operating system, and yes they are dangerous.
I would also like to cite a few pieces of the Unsanity article.
It is installed in
This is patently not true. Good frameworks should be installed in ~/Library/Frameworks, your own directory. The directory Unsanity chooses automatically affects all users on the same machine.
Another directory exploited is
One of my favourites is:
Since Apple does not provide a way (other than with kernel extensions) to change the behaviour of different applications, we had to engineer one on our own.
Oh wow. Perhaps - just perhaps - Apple did not provide this for security reasons? And comparing an APE with gdb is just silly: gdb is meant to be used in testing, not on secure stable end user machines.
I also note the following:
They do not break down the barriers of protected memory.
Ah - let me just say that without a more technically substantial run-through, most of us are going to remain unconvinced. And it's fairly obvious, at any rate, that barriers somewhere are being broken down.
Finally, I don't think APEs are spyware, but I get what the complainers are going on about: they feel uneasy because they know there's something 'illicit' going on in their systems.
Remember what Ken Thompson said. Unix didn't get so far and do so well because Bell Labs specialised in application enhancers. Keep your hands off the drivers, and keep your hands off software that won't keep its hands to itself.
If the software isn't coming from Apple and still wants your administrator password, reject it. That software has no business going into areas of your disk where it doesn't belong. That is your security involved.
A good example of what can happen is Interarchy. It wants your adminstrator password and then leaves about 1.5 MB of junk in areas even you can't ordinarily get to, and all without telling you. That's what these freaks find tantamount to 'spyware': 'illicit' things going on in your machine, without your express approval.
If you can't make the operating system work better, write to the vendor (Apple). Don't do anything yourself. If you want apps on top of the operating system, fine - just play by the rules.
I suspect the Unsanity programmers are very good at what they do, but what they're doing is definitely not Unix. Not even close.
Interesting that you should mention security, considering that so far the only APE plugin that has anything to do with the subject actually improves security.
You're arguing against a tangible increase in security (Paranoid Android) in favour of a theoretical decrease in security that no one has yet figured out how to exploit.
There is, as yet no reason to believe that APE makes your system insecure in any way, and it's hardly the sort of thing that Virus/Spyware writers could depend on being pre-installed.
So if you're suggesting that a malware author is going to use it as a road into the system internals, are you also suggesting that they are going to install APE, and then have APE register their APE module and restart every application so that the new module and APE can take effect, entirely without the user noticing?
While it's almost certainly possible that someone could exploit via APE, it seems impractical and improbable without an easy method to target APE users. Hyperbole and hysteria aside, there is really no reason for the bad rap that this very useful app has been given.
I'm not convinced that APE makes my system unstable/insecure. In my experience I've had no reduction in stability or speed, and an increase in security and convenience directly attributable to APE.
Finally, as far as security goes, there's nothing that APE can do that a sneaky application can't do; Silk and WindowShadeX were working long before APE came into being.
After all, APE is just a convenient framework for legitimate applications to access that same functionality without needing to worry whether their low level hooks are buggy or are going to interfere with other hacks that might be installed.
It's much more likely that malware would simply access those functions provided by APE directly rather than relying on the user installing some third party software.
After all, why would they limit their potential audience in that way?
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.
T Money
World Domination with a plastic spoon since 1984
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.
Let's hope after WWDC people see the trend of less Carbon and more Cocoa that Apple is committing to, now and the long-term.
Enough already with the Cocoa fanboy stuff - if you like the API, you do neither it nor yourself any favors with this kind of post. Bits of the system are implemented in Carbon, bits are implemented in Cocoa, and neither are going away.
Apple have committed to maintaining both Carbon and Cocoa as equally valid frameworks for application development within the system - that's been the message on stage from the last 3 WWDCs, and I see no reason to think it'll be any different this year.
Nae bother
That's a pretty weak analogy - those plug-ins are plug-ins that the host application designed itself to be able to support. An app developer may not have anticipated exactly what QuickTime codecs the user was planning to install, but they're aware that the list is extensible and may change over time.
A haxie is injecting completely arbitrary code into the app, code that the app developer had no way of planning for. E.g., I call MoveWindow to move the window - and your code replaces my call with one to a FunkyMoveWindow that snaps it to some other position. Except that elsewhere in my code I assumed (quite reasonably) that MoveWindow(100,100) would do exactly what I expected it to - and wasn't anticipating it leaving the window at (30,100) instead...
Moving a window to the wrong place might not be a problem (then again, who can tell) but that level of redirection can easily get you into trouble - a haxie just doesn't know what assumptions the app code is making that it might be changing from under it. And that's not even touching on the fact that my app has no idea what your code is doing: if it scribbles over my address space and makes me crash, how am I supposed to debug something like that?
Nae bother
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
You can take my Haxies from me when you pry them from my cold, dead hands.
:-)
Yes, it would be better if Apple provided clean(er) hooks for things like Windowshade and FruitMenu. But they don't, and I'll take Unsanity's implementations over nothing at all and day of the week and twice on Sunday. They make my computing life so much better that they are, by far, the best investment I have ever made in software, dollar for dollar (I bought when they were $7 too
Lots of "code that you didn't write" runs in your application's process space. I don't see how Apple or the DivX guys or anyone else are any better or more trustworthy than Unsanity in this regard. If a QuickTime plugin causes a crash, disable it. If an APE Module causes a crash, disable it (or exclude that app using APE Manager). IMO, Unsanity's record is impeccable thus far, and they are certainly a lot more responsive than a big company like Apple.
Yes, being a developer is hard. Sometimes you have to debug problems caused by other people's code. Sometimes new versions of the OS break your app. How dare those users upgrade their OS! How dare they install software that runs in your process space! Sorry, but that's the right of the user.
If you want to blame anyone, blame Apple for not providing "nicer" ways to do the things that so many users so obviously want to do. Unsanity would have been out of business long ago if there wasn't a real demand for the services they provide--despite the particular way they are forced to implement them.
OK, so the problems are not in the APE framework, but in the modules that run under it. However, the framework is useless without modules to run under it. The equation is clear enough: install haxies and incur a significant risk of problems. The benefits may, in a sensible person's mind, outweigh the risks, just as was true of extensions in OS 9 and TSR's in MS-DOS, but the risks are not negligible. To say that they don't matter because they're not the fault if the APE framework itself is silly.
Please spare me the enthusiasts for whom no failure is ever the fault of the object of their enthusiasm. For example, Windows advocates who insist that bluescreens don't count because they're caused by "drivers," while ignoring the fact that you needed to install drivers to get your display hardware/Adaptec SCSI card/whatever to work.
True story. Circa late seventies. A friend was praising his NorthStar computer to the skies. I asked if it was reliable. He said it had been 100% reliable and he'd never had any problems at all. I asked him to demonstrate it to me. He said, "Oh, sorry, I can right now, the power supply burned out and I'm waiting for a replacement." I said, "But I thought you said it was 100% reliable." He replied, "The computer works fine--it's just the power supply that's out."
"How to Do Nothing," kids activities, back in print!
I tried Paranoid Android 1.2; accumulated immediate crashes from AbiWord and TextSoap, when doing anything involving a large block of text between them, whether by drag'n'drop or copy/paste.
Removed APE, rebooted, problem gone.
Reported to developer.
Last time I tried APE, a year ago, similar problems persisted til I removed it. Reported it then too.