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
course it doesnt take one to see that this in no way recreates the extention problem
"Slashdot, where telling the truth is overrated but lying is insightful."
Refutes? Oh, you mean because now it takes down applications and not the system.
Oh. Better.
No.
If you install a buggy application on your system, then it crashes, and you likely loose work. How is this different to if you install a buggy APE module on your system, then it crashes, and you likely loose work.
Bob
and last time I heard.. nobody put a gun to your head to install it. -- this sig withheld for environmental reasons
savethedollhouse.com
Because one buggy APE module will possibly kill all programs (one at a time) rather than the whole.
I mean, really, anything that makes the computer, at any level, unstable is not worth using.
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
Don't be an idiot. I do not run programs that modify other programs on the fly, which is what this does.
Insightful!? He didn't RTFA! But neither did the jerk of a moderator, so who's the real culprit? Propose a new word: jerkmod.
Maybe someone could explain the enigmatic "tellytubby-like" comment? Like, please don't say something like that and just assume everyone knows what the funk you're talking about? Like, especially when a google doesn't enlighten?
LIKE, YOU KNOW???
#19845
Since you didn't read the article, I am assuming that you don't run any Input Managers, QuickTime Codecs, Contextual Menu Modules, or Internet Plugins?
No flash in Safari for you?
So you run no plugins? No flash, no java? No frameworks at all?
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.
...we find that no one cares about this topic. Thirteen posts, all scored 1 or lower -- this must be a record for disinterest!
--
Don't like it? Respond with words, not karma.
I did read the article, actually. A bit before it hit Slashdot, as a matter of fact. His analogy is rather incorrect on that mark. QuickTime does not insert code into every program that runs, regardless of what it does. A buggy codec can't take down every program, even if it does not use QuickTime. APE modules can because they are blindly inserted into any program you don't explicity exclude.
So while the module types listed are indeed external pieces of code that can cause a crash, they don't run in every program you run. Things like Shapeshifter or Ice Coffee do (screw camel-caps).
I said modify programs ON THE FLY . Flash is a plugin, not a piece of code that modifies how every program runs.
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.
..of a very bad idea.
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.
There are no trails. There are no trees out here.
I bought a TV tuner card recently and the software included uses APE. I also own windowshadeX (which is better than exposé in a lot of ways)..
Somewhere in their code, Unsanity does include spyware for WSX, I'm not sure if it's WSX or APE, but it's in there somewhere. Me and Rosnya (why does he pose as a russian female?) debated whether or not Unsanity was breaking the law by not telling anyone about their spyware.. (despite what he tells you, he's wrong).
If it were anyone else, I'd probably say this long drawn out PR was just a bunch of cover-their-ass crap, but Unsanity is a good group of guys and until Windows trips over its big fat ass and Apple takes over, we need all the skilled developers we can get. In addition I know this particular redheaded weirdo who calls himself Rosnya, and though he is capable of doublethink, he's not a liar, and I for one now feel relieved that I have one less base to cover when debugging OS X.
Latewire
Sigh, this is the idiotic kind of posting that the author was trying to defend against. People that don't realize you can do this stuff with A QUICKTIME COMPONENT. How do I know? I HAVE DONE IT!
You'd still have to install that QT component, and I have trouble believing it could access the memory of apps that don't make use of the QT framework. Personally, I wouldn't install APE or the unholy QT component of which you speak...
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.
Another Carbon Framework.
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.
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)
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.
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.
Because the APE module attaches to every running application, if it is itself unstable, it can make all your applications unstable.
I'm glad Ken Thompson is still alive, because if he wasn't, he'd roll over in his grave if he heard that.
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?
Parent is NOT flamebait, and the moron mod who marked it so should be shot and tortured slowly to death.
How can Slashdot have such bleating morons doing their modding?
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.
A buggy codec can't take down every program, even if it does not use QuickTime.
True, though from personal experience I can tell you that a buggy codec can make your machine pretty much unusable. There was a version of DivX that was buggy on dual-processor G4's after a QuickTime upgrade. This made it completely impossible to run Finder, and hence to launch any other apps.
That sucked. Thank goodness for a second machine and a running ssh daemon. I finally got backtraces and figured out the problem.
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.
I'd be wary of a hand-coded bios running on a Mac, but even if it were *perfect* it would be susceptible to EMI. No, the only way to make sure your computer is stable is to turn it off and place it flat on the floor.
While Paranoid Android can increase security, so can RCDefaults which has the added benefit of being very unobtrusive.
I was very clear that my points were entirely theoretical and that I had no reason to believe that there were any current security issues with APE/APE modules. I don't think Unsanity is shipping their software with malicious intent.
But you make one point that is entirely false that I have to address:
"as far as security goes, there's nothing that APE can do that a sneaky application can't do"
That is true in a sense that a malicious app could do the same thing that APE does, though it would be complicated to get all those pieces set up. The thing that APE provides a convenient framework for that. What most apps can't do is to look around in any user's running app's memory space and do whatever it wants with what it finds. Normal apps can't go poking around in another app's memory space at all. APE lets you write code to do that and a malicious coder could use this for lots and lots of bad things.
I don't think it is too likely to be exploited since there aren't a lot of systems out there running APE. But the very fact that when installing APE one is installing a program that opens yourself up to that degree of a serious sercurity hole makes it untenable. Expecially when installing a haxie doesn't require much work, and is easy to hide for a clever developer, so it would be easy to exploit. APE make a complicated and difficult exploit requiring root prive really easy to run in user space.
It is analogous to creating a new app that runs as a daemon to do some cool peer to peer file sharing thing you really like, though it also allows remote users to run any commands on your system with no authentication. Even if you really like what the app does, the app is uncommon, and only runs on an obscure platform, it is still insecure by design.
Hyperbole is the worst thing ever.
True, but I counter the instability by sticking a folded napkin under one of the corners. So far so good!
Badly coded apps do not make anything but themselves unstable. A badly coded module makes every program unstable.
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!
Well, can somebody explain why OSXVNC's GUI portion refuses to function due to APE? The developer seems to think that the blame lies at the door's of Unsanity, and I sure as hell can't get the GUI part of it to work for more than 5 minutes.
t ml
Why is that?
http://www.redstonesoftware.com/osxvnc/OSXvnc.h
"But you make one point that is entirely false that I have to address:
"as far as security goes, there's nothing that APE can do that a sneaky application can't do"
That is true in a sense that a malicious app could do the same thing that APE does, though it would be complicated to get all those pieces set up. The thing that APE provides a convenient framework for that. What most apps can't do is to look around in any user's running app's memory space and do whatever it wants with what it finds. Normal apps can't go poking around in another app's memory space at all. APE lets you write code to do that and a malicious coder could use this for lots and lots of bad things."
What I said is clearly true, both Silk and WindowShadeX, did exactly what you talk about without the APE framework, long before it was invented. It's been proven possible, nothing to see here, move along.
"It is analogous to creating a new app that runs as a daemon to do some cool peer to peer file sharing thing you really like, though it also allows remote users to run any commands on your system with no authentication. Even if you really like what the app does, the app is uncommon, and only runs on an obscure platform, it is still insecure by design."
No, that would be something which allows people to remotely run commands, APE has never been accused of anything like that. In fact, with Paranoid Android it does the exact opposite of what you just talked about.
A more valid analogy might be something like lookupd which serves a useful purpose but can in the event of a local compromise be used to modify the behaviour of applications so that they can perform malicious tasks.
Lookupd doesn't even need to inject code into programs to perform evil, should I be more or less scared because of that fact? The OS X/NeXT pasteboard server can inject characters into the input buffer of any running application, that's also pretty scary.
I'm sure if I sit here thinking about all the applications on my system I can come up with all sorts of paranoid theoretical fantasies about ways in which applications on my machine could be compromised.
The fact remains that if someone can get a piece of malware onto my system it's too late whether I have APE installed or not, and it's been proven by the unsanity hacks written before APE came into being that it's possible to inject code into running applications without APE's presence.
Neither APE nor any other method seem to be able to inject new modules into running applications without restarting them, so there's no advantage to using it for malware. Plus APE always brings up it's preference pane when it registers a new module, further decreasing the chance that someone is likely to use it for malware.
I'm not trying to argue that APE is inherently safe, but that it's not in any way equivalent to opening the door and throwing away the key to your computer. That's bullshit. All of the methods of exploiting it that you've mentioned would require a local compromise anyway. Which would be disastrous since my only Mac is a laptop, so the offender could simply walk off with it.
Finally, RCDefaultApp doesn't solve the problem of registering arbitrary URL handlers, leaving you possibly exposed to the worst variant of the latest bunch of security risks. The only way to protect yourself against that is to use Paranoid Android. Ironic that you're promoting security as a reason for remaining insecure.
FWIW, I use both RCDefaultApp and Paranoid Android, because the combination of both apps provides both proactive and reactive security should my disabling of protocol handlers turn out not to be enough. I recommend that everyone else do the same at least until Apple fix the problem properly.
APE, along with an older version of ASM (the MenuCracker part specifically) on 10.2 caused the finder to quit and restart repeatedly ad infinitum. I removed all modules, still caused the problem. removed APE, the problem stopped. Spoke to him about it, he denied it was the cause, but it's hard to deny.
He can say what he wants, but APE does things it's not "supposed" to be able to do, and this can cause conflicts. I've removed all "hacks" and I haven't had any trouble since.
"That is true in a sense that a malicious app could do the same thing that APE does, though it would be complicated to get all those pieces set up. The thing that APE provides a convenient framework for that. What most apps can't do is to look around in any user's running app's memory space and do whatever it wants with what it finds. Normal apps can't go poking around in another app's memory space at all. APE lets you write code to do that and a malicious coder could use this for lots and lots of bad things." You ever hear of mach_inject? http://rentzsch.com/mach_inject/
I haven't, though I would be interested to see what it does. Unfortunately I think you misspelled that URL since I can't resolve rentzsch.com.
Hyperbole is the worst thing ever.
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.
"But you should quit downplaying the fact that it is a security problem."
Oh come on, you're also exaggerating just how much of a security problem it is given that there has never been an exploit that uses APE.
I'm not trying to downplay the fact that it's a possible security problem. I'm saying it is not a security problem at present, and in fact is working to actively increase security for me at the moment.
What I am saying is that if someone can get malicious software onto my machine, that is all that's required for me to regard it as completely compromised and that APE is not going to make a bit of difference to that.
If someone can install malicious software in my user account, they will have already circumvented my machine's security to such a level that I would not feel comfortable until I had wiped the hard drive and reinstalled the operating system and changed passwords on the websites I visit as well as replacing my public keys on the many machines I have to SSH to.
A local compromise of any type would allow the attacker to retreive my cookies, the serial numbers to all my registered applications, and various documents related to my employment that contain trade secrets and other potentially valuable information. Simply accessing that information is damaging enough, regular rsync backups ensure that deleting all my files or doing other things requiring root privilege would pale in comparison to the damage that can be done without root access.
It can only reassign existing ones. How will it protect you from spam:// URL handler registered by opening an ftp URL? Since the problem is in a shared library, it's only logical to use fix it by injecting code into every process. Just like for other things haxies are doing, like global UI changes.
If you can't make the operating system work better, write to the vendor (Apple). Don't do anything yourself.
Come on, Apple was contacted in Feburary about URI exploits and didn't do anything until now. Should I just sit, do nothing and invite "software" that will really break down my protection barriers or should I download a fix that works in the only possible way - by patching existing software.
As for other haxies like UI skins - well if it's your personal machine, the defaults hurt your eyes and you are willing to accept some risk of instability, go for it. If your Mac is supported by other people, well they might uninstall your skin haxies if you get unusual crashes. But they should leave this one in until Apple has a fix.
Troll?
/. painfully needs more and better meta-moderation. The current moderators would seem to be descendants of the book burners in the Germany of the 1930s.
Who's the moron?
Parent is a technically correct assessment.
This reminds me of the debacle over AnalogX's Proxy Server - a product many anti-spam experts contend is one of the biggest sources of spam relays in the world.
The product ships 'wide open' and users don't bother RTFM and if over a third of all spam relays are due to this product - who's at fault then?
Security experts say AnalogX is, because he ships his product wide open. Security experts have also been hounding Microsoft for years for shipping net tools that leave a user again 'wide open'.
Sorry, but merely giving a user an option to corrupt a local machine and then blaming the user for using this option is not a way out of the corner.
They are one of nicest "companies" I met so far. I am only 5 month mac user, I mailed them about a program of theirs (theme thing) and how much time it will be supported on Jaguar (osx 10.2) and one of the coders gave me answer with all details.
Its nothing I am used in PC world (windows) or Linux.
Tried to delete the first bit of this but apparently I missed. So I end up responding to the same part of a post twice. Teach me not to proofread.
Well, what I wish it would teach me is to get a sufficient amount of sleep. But that doesn't seem likely right at the moment.
-fred
Sign #11 of Slashdot overdose: You see the phrase 'moderate Republican' and you wonder if that would be a +1 or a -1.
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.
Probably because it doesn't slow the system down on thousands of systems. Or prehaps you still can't differentiate between the APE framework versus an APE module. I've been using APE for years, and their is no noticeable difference in my system speed. Of course I don't use one of the popular, but known unstable APE modules--ShapeShifter. I would expect ShapeShifter to slow the computer down, its modifying the whole frekkin interface.
That said, I LOVE FruitMenu, MenuMaster, and now Paranoid Android. In fact, I think the combo of Paranoid Android and Little Snitch (different vendor) are hard to beat if you value security and privacy.
I'm posting now from a completely fresh install of Mac OS X because these vunerabilities have been "in the wild" for quite some time. Time enough for keystroke loggers and and other nasties to be installed in supposely the most secure operating system available.
I have my RCDefaultApp installed and disabled all my unused URL handlers, some folks go as far as reassigning to a rarely used application that pop's up in front of their face, thereby warning the user that a exploit has been attempted. This way a alarm can be sent out about a particular web site.
Since we cannot prevent the exploits, we can halt the program is uses to do damage.
I have considered Paranoid Android, problem is I hear it can be tricked, all a malicious person has to do is download PA and test it's defenses in the safety of their own home.
With RCDefaultApp, a malicious person has to take a chance distributing the exploit hoping one didn't reassign their URL handlers, so I think this approach is a better measure of security. They have to expose themselves to see if their exploit works.
Also I also installed Little Snitch, (there are "other" exploits which can intiate a download), which monitors all outbound network traffic and halts it for my review.
And Apple, don't even think about charging for "Tiger"
>>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.
/Library/Frameworks/ like a good framework should be.
/Library/Frameworks, rather than specifying both.
OK. According to the Apple software specifications, any application that follows Apple's guidelines should request an Admin password, insuring that the user is authorized to install applications onto the system. Technically speaking, I have more of a problem when installers DON'T ask for a password, since it means anyone could have installed it on my system, something I expressly do not want.
>>It is installed in
Unsanity haxies default to a single user, and provide the option of selecting for ALL users on the system, as part of the installer. I would imagine she was just being lazy and referring to 'all' modifiable
>>security
I'm certain someone with enough skill and time could hack APE and take advantage, but as it stands, to install a haxie using APE, the developer must first register their haxie with Unsanity. So its not currently as if I could just script something, take advantage of APE and then perform malicious tasks.
you may want to look at Jack and Soundflower too.
[|]
Sorry, but merely giving a user an option to corrupt a local machine and then blaming the user for using this option is not a way out of the corner.
Yeah, and don't get me started on all the Unix vendors who are so irresponsible as to include the incredibly destructive tool "rm" preinstalled.
Come on. First of all, "corrupt" is a ridiculously loaded term. You may not like what APE does; in fact neither do I in principle, but I consider it an acceptable tradeoff to protect against the *confirmed* threat of malicious URL handlers. Second, the default is in fact to install for the local user only. Third, since the large majority of OS X systems don't have multiple user accounts, it usually makes no difference at all.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
Microsoft Windows doesn't cause the blue screen of death, badly written drivers do.
So how do you debug things? I take it as given that you're definitely not a LISP fan...
I'm a part of several independent software development projects (on the PR side, mostly), and can vouch that APE is a piece of shit, and should not be installed by anyone who cares about stability and data integrity. When users get crashing problems and send us their crash logs, APE modules are usually to blame. As such, we just tell our users that we won't support them as long as APE is installed, and get them to uninstall it whenever we see it active in logs users send us. We might even have to add code to our app to prevent it from running if APE tries to insert its threads in our app's memory. I sincerely hope that Apple makes this kind of software impossible by preventing arbitrary third party code from being inserted into apps' protected memory (with explicit exceptions for valid plug-ins, of course). I don't care what Unsanity says, they're full of crap. APE has got to be the #1 source of crashes on MacOS X. Congratulations, Unsanity, for millions of dollars worth of lost work and time. I say we get the torches and rope!
"I like systems, their application excepted", George Sand (French)
The gay thing about Rosyna's little rant is that it doesn't address my number one complaint with APE; that is slows the system down.
Ironically, that used to be the major complaint about graphical user interfaces. And it's true. A nice user interface slows the system down. Fortunately, in many cases, a substantial increment in usability and convenience can be obtained with only a tiny effect on speed.
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
The concern about the URL vulnerability is that your computer can be attacked as a result of merely clicking on a link, even though these theoretical exploits do nothing worse than could be accomplished by the most trivial trojan--like the recent "Office 2004" trojan. So yes, a haxie could be a trojan, just like any other program you choose to install and run. And the only defense against trojans--haxie or otherwise--is still to only install software from a trusted source.
I still don't get why people are installing Ape + PA to counter the handlers problem when the obvious solution is to point the handlers to non-dangerous objects using something like RCDefault.app. Why not just write a set of good, non vulnerable rules once, and then be done with it?
One god, one market, one truth, one consumer.