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."
and last time I heard.. nobody put a gun to your head to install it. -- this sig withheld for environmental reasons
savethedollhouse.com
Bob
..of a very bad idea.
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
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.
Because the APE module attaches to every running application, if it is itself unstable, it can make all your applications unstable.
Because its not run in kernel space it can't cause a kernel panic and make the OS unstable BUT having all your apps crash out regularly fits most definitions of an unstable system.
(I'm not saying that APE modules *are* unstable, just that if one was it would cause problems)
I believe you, and I can't believe Apple would let this happen. We have - or are supposed to have - totally secure 32-bit virtual memory systems here. The actual memory addresses used by one application are supposed to be irrelevant to any other - and most importantly: only the kernel is to be able to execute privileged operations which allow you to get to either physical memory or the system itself.
Knowing Unix as we do, we know this is impossible unless:
1. The application has installed something in system territory; and
2. The installer has had root access, even through being a member of the 'admininstrators' group.
If you can 'root' a Unix box, you can get at anything. But I suspect most APE users are not really sensitised to what they're giving away when they install an APE. They've basically opened the front door and thrown away the key.
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?
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
Except of course that when an APE module goes awry it doesn't destabilize the base system, I don't have to reboot to remove the offending hack, it doesn't affect other user accounts, and APE modules can be safely enabled/disabled on the fly for testing.
What was the similarity with extensions again?
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
Badly coded apps do not make anything but themselves unstable. A badly coded module makes every program unstable.
I tried to install WindowShadeX to see if it required root privileges to install. It turns out it requires APE...
I then tried to install Silk. It turns out it requires APE... I expect that in earlier versions they were standalone apps and required root privileges to install. A Haxie can be installed without root privileges which is one of the problems with it, as I have pointed out previously.
RCDefaultApp alone can protect you from the exploits as described, which I have verified. While Paranoid Android might in theory afford some extra level of protection in some respect, it is not needed to protect against the current exploits as they are described.
My analogy was not perfect, but it is not analogous to lookupd either since that requires root privileges to exploit while an APE based exploit would not. OTOH a malicious Haxie could be used to elevate privileges.
I think that APE has a pooor design security wise. That is really all I have been saying. Theoretically it could serve as a vector for malware. Exploits that took advantage of it would most likely be trojans that sneak in a malicious haxie. In the same way that spyware installed on Win boxes comes from many and various sources, often from installers of other products, many of those same methods could be used to install a Haxie. It isn't being done, but that doesn't mean it can't be done.
Malicious Haxies are theoretical, but then again there are no known malicious exploits in the wild against the URL handler that you installed two apps to protect yourself against. Good security is about protecting yourself from theoretical exploits before they are actual exploits. If you like the benefits of APE enough to leave that theoretical hole open that is your business, I really don't care. But you should quit downplaying the fact that it is a security problem.
Hyperbole is the worst thing ever.
Allowing APE modules access to programs is the job of the APE framework, which is the one trusted aspect of the system. Yes, modules could probably get around this by executing under the framework and not using its constructs but SO COULD ANY OTHER PROGRAM.
SECURITY ALERT! All executable files are insecure because when launched they are given access to your files without user intervention, can launch daemons, hijack new executables, and spy on the user!!!
My only argument is that APE framework is simply a way to execute haxie code in a way that is more efficient for the programmer than in a stand-alone daemon. In addition, when the developer uses the features provided by APE framework, the user is allowed to control which apps a module is allowed to touch (and here's the key) through the framework. Saying APE modules are insecure is like saying any executables are insecure; which is also like saying that actually DOING anything physically is dangerous because you could be killed, spied on, etc...
Everything is a matter of trust: from running closed-source applications to going outside each day. There is nothing wrong with the APE framework just like there is nothing wrong with your car. Both have the potential for abuse (hell, a car can kill people) but you have to have some level of trust.
You are free to be wary of all untrusted content but honestly, you sound like a conspiracy theorist. If you don't like the idea of APE modules (I personally don't simply because I don't trust that programmers outside of Apple will be able to guess at how a program works well enough to not cause it to crash) then don't use them but please don't spread FUD about their being inherently insecure. Because they're about as insecure as drinking a glass of orange juice (it can choke you! how ever did they get FDA approval!).
> 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.
Do you really not see how Apple is better in this regard? It seems unlikely that anyone could be that thick, but I'll give it a go:
Apple uses talented programmers, has a QA department, doesn't allow commits without thorough code reviews (or at least, didn't in my department when I worked there), and tests in a multitude of different environments. Plus they have guidelines for acceptable programming.
People who write 'haxies', by and large, have none of these advantages. Some of them are actively incompetent, but not very many.
> 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.
I can address this one. At Apple, they have a fellow (poor fellow) whose job it is, almost entirely, to sit there taking the bug reports that they get for QuickTime from external testers, developers, and users (via Feedback), and figure out which ones are known bugs, which ones are new bugs, and which ones are bugs caused by third-party products.
Most shareware developers don't have this luxury. (I except groups like Ambrosia, who can at least spread the work around a little.) They have to poke around at every trouble report that they get until they figure out what happened with it, or risk being panned as 'unresponsive'. If the problem is caused by, say, a new version of the MacOS which breaks an API you were depending on (which has happened to me several times), you will typically see the same problem over and over and be able to classify them pretty easily. With 'haxies', it's a guessing game, and not one that I would particularly enjoy.
There's a simple answer, of course. APE adds a thread to every application that it infects. It's trivial to detect this thread and put up a dialog box that says, 'Sorry, this program is not compatible with 'haxies'. Please uninstall APE or disable it for this program.' And then exit. And some people will uninstall APE. And some people will disable it for my application. And some people will decide not to use my software. And some people, people with an attitude like yours, will find some way around my safeguards, and then will still send me crash logs with APE in them and expect me to fix them. And it is they, and only they, whom I will tell to blow me.
If I ever release any of the Cocoa apps that I whipped up for my own use to the general public, that's probably what I'll do. I don't see any compelling reason to release them right now... it would take dozens of hours of polishing, and then some sort of a volunteer beta program, all so that 0.1% of my users can send me $10 and 80% of my users can expect me to fix my bugs for them even though they haven't paid me. (I'm not a big fan of cripple-ware.) Add haxies (which I've run afoul of before, when I was doing contract work) and their ilk to that mix, requiring me to fix OTHER PEOPLE'S BUGS for free, and you'll probably never see my apps out there. They work for me, and that's all I need.
> 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.
It is the right of the user to do whatever he damn well pleases with an app he bought, aside from giving away copies or reselling them for profit. (Well, it isn't, in the US, but I agree that broadly speaking it probably should be.) It is the right of the developer not to have to support it if the user uses it in a way that makes such support impossible.
Sign #11 of Slashdot overdose: You see the phrase 'moderate Republican' and you wonder if that would be a +1 or a -1.
>>The equation is clear enough: install haxies and incur a significant risk of problems.
That's not true. This is all dependent on which haxies you install. Many of Unsanity and other companies haxies have cause no issues to date. It doesn't mean that they couldn't, but thats a little like saying install software and incur a significant risk of problems.
A slew of user problems are caused by bugging applications, and without those pesky little applications its far more likely your computing experience would be problem free (well at least on a Mac), but typical your OS itself doesn't allow you to get the work you need to do done.
I could install APE and some haxies to work with it, and experience problems (with the Finder, Contextual Menus or other Applications) or I could install Microsoft Office and experience printing problems, Eudora crashing when grammar menu is open, unexplainable application shutdowns, whatever.
A system without risks is a system not in use.
No ones claimed APE was perfect, though Unsanity does claim the APE framework has generally been bug-free. But they acknowledge that haxies (APE Modules), even some of their ow haven't always been stable (hence version releases).
And where is it written that all drivers need to reside in kernel space? Isn't this determined by the OS design, and isn't it a legitimate target for critique?
Why should buggy code in a device driver bring down the OS as a whole? Why should it affect anything but the operation of that specific device?
What is there, exactly, about a SCSI device that requires the specific driver for that specific device to have full, unrestricted access to space? Is it logically impossible to think of any other architecture at all?
Or is this a deliberate tradeoff of performance and convenience against stability?
"How to Do Nothing," kids activities, back in print!
Let's just say there's not all that much to say about Carbon.