Yay! Thought Id check and see what you had to say about it, and I'm glad to hear that PA can be retired. Thanks Jason.

Just wanted to add my thanks to you, too, Jason, for keeping us safe in the meantime, for all your knowledge, time, and caring. Malware Ratz don't stand a chance with MacHead Angels such as you on watch. ::::applause::::

Well, I'm off to kiss our beloved Android good-bye!

"Klaatu berada nicto."

[lol]

<jason> "As far as I can tell based on a quick read of the ReadMe and the associated technote, this resolves all of the issues that Paranoid Android was created to protect against."

It doesn't seem that it would have provided any protection against the basic flaw that allowed web pages to use LaunchServices protocols to launch applications with untrusted data. I strongly recommend not applying this fix and continuing to depend on Paranoid Android until Apple addresses the underlying design flaw in the way applications interact with LaunchServices.

It does protect against web pages that would launch an application that could damage your system, unless you have already ran that program.

You mean... unless you have already run that program, or that program came from Apple.

Now what's the program that was abused in the latest security update?

Why, it was the help viewer... which is not only a program that everyone would already have run, but it's also one that was shipped by Apple.

The other patches protect against the specific holes in existing software that this specific attack used, but this one is pointless... what good is a security enhancement that's been proven to be faulty weeks before it came out?

Paranoid Android does a much better job because it doesn't automatically trust the programs because the vendor is considered beyond reproach, or because they've been used once from some other context. It's not perfect (I'd like to see a couple of additional buttons that say something like "Always allow Butler to use the 'file:' protocol") and it's not as good as a real fix in LaunchServices, but it's better than Apple's fix.

Have a look at my "Open Letter to Apple" at http://www.scarydevil.com/~peter/io/apple.html and think about it. Remember, Microsoft ran into the same problem almost a decade ago and they've been plugging one hole after another instead of fixing the underlying design flaw... and there was a hole in *their* help viewer discovered just this year!

Peter, while I agree that Apple's fix doesn't patch potential exploits in "trusted" apps, I don't think that it should. I believe that putting the onus of protecting against all possible exploits onto Apple is an unreasonable expectation. More importantly, I think that the only way that Apple could do it would impair user friendliness pretty extensively.

Applications are going to contain potential security vulnerabilities - that's unavoidable (at least, with current programming practices). Apple can take three approaches - they can lock it down so that it's not possible to exploit them at all (and severely impact user-friendliness along the way). They can lock it down a bit so that new vulnerabilities can't be introduced. Or they can leave it wide open.

They went for the middle choice, and I think they made the correct one. It's a philosophical argument - I prefer a laisse faire approach to my computer, while you seem to be arguing for a rigid lock-down. Neither one of us is correct, it's a subjective argument.

(Of course, I have two shipping apps that register their own URI schemes, so I have a vested interest in Apple not following the rigid-lock-down model. It would remove features that my users have come to expect.)

Anyway, I didn't intend to say that you shouldn't continue to keep running Paranoid Android if you like it - by all means, keep it rocking! And, as I mentioned, it's now open-source, so if you feel like coding in the changes you're talking about, you can.

"Peter, while I agree that Apple's fix doesn't patch potential exploits in "trusted" apps, I don't think that it should. I believe that putting the onus of protecting against all possible exploits onto Apple is an unreasonable expectation."

I'm not sure where you get the idea that I believe they should prevent all possible exploits.

I haven't suggested nor argued that they should attempt to prevent every possible exploit in every possible application.

In fact what I'm arguing is the opposite... that they can't possibly secure all applications they ship, and they certainly can't secure third-party applications. Therefore, they should make it possible for an application to be registered in LaunchServices without having to make that application secure against hostile attack from the Internet.

"they can lock it down so that it's not possible to exploit them at all (and severely impact user-friendliness along the way)"

On the contrary, dividing the list of applications into those that are trusted to deal with hostile input, and those that aren't, would improve user-friendliness. Right now any application that's registered with launchServices HAS TO be hardened. Hardened applications have to be more restricted and less capable than applications that merely have to defend against user error. A hardened application, to be precise, is less user-freindly.

By having a separate set of helper applications for "WebServices", then, they wouldn't have to disable "dangerous" things like having Finder handle "ftp:" completely.

No, no, this wouldn't make things less user-freindly, it would make things *more* user-freindly, and allow applications to still take advantage of useful things like ftp: and disk: URLs without opening up the possibility of a bad guy hiding them in a web page.

And, again, I'm not just hypothesising. I've watched Microsoft step by step reduce the capabilities of local applications and local resources because remote attacks were using them. By maintaining a "sandbox" for untrusted documents you don't hinder the user: on the contrary, NOT having an explicit sandbox means you have to force everything into the equivalent of a sandbox, because anything has to be treated as a bad guy.

Security Update appears not to be protecting me. I ran one of the exploit tests on MacFixIt and it says I have been exploited. I got no Apple warning. I guess its time to go back to Paranoid Android and RCDefaultApp.

Greg, go read this: http://daringfireball.net/2004/06/misregistered to understand what's happening on your machine.

Now that I've deleted the Paranoid Android module, how do I remove all the other stuff Paranoid Android installed throughout my system?

If you could list the files it installed and their locations I would really appreciate it.

Thanks.

I read Fireball. He was not comforting. As other posts here attest, Apple leaves some holes open. Not acceptable. One hole in a ship can sink it.

The Apple Security update appears to do an incomplete job.

I think Unsanity should do more than make Paranoid Android open-source. They should keep it updated and current. Apple is just not doing all that needs to be done.

Here is another analogy. The French built fortresses of artillery to keep the Nazi tanks out, but it was not a complete barrier, it did not cover the difficult terrain of forests, because the Tanks allegedly couldn't penetrate. Guess what, the resourceful Germans were able to penetrate and they literally went around the French fortresses.

Should Unsanity decide they need to pursue more of PA, then it is only right that they charge for their efforts....the free ride is over.

Mongoose, if you'd like to uninstall the APE framework, you can do so by downloading the dedicated APE installer, running it, and pressing the "Uninstall" button. It's available from
http://www.unsanity.com/haxies/ape/

You can also uninstall it from the APE Manager preference pane if you have at least one module currently installed.

Note that if you have any APE modules installed, they won't work after you've done this, since APE itself will no longer be installed.

I don't have any big objections to continuing to work on Paranoid Android, but since it's a free project that works well enough for me, it's not a priority.

The only thing I'd really like to see it do is add the ability to specify default actions for URI schemes based on the app the request originates from. So, for example, you might always allow 'disk' URIs that come from Finder, prompt if they come from Safari, and never allow them from FireFox.

I've updated the open-source site, btw, and there's now a tar distribution of the source available. http://paranoidandroid.sourceforge.net/

Between PA and Chicken of the VNC, ShapeShifter has been on the back-burner for a month or so, and I'm going to bang on it for a bit before I do anything further with PA.

Greg and Peter, and what security holes has Apple left open, pray tell? Please, post a demonstration of a single vulnerability that is not closed.

Guys, I disabled PA last night, installed the Apple security update and shut down for the night.

APPLE'S FIX DOES NOT PROTECT YOU.

I returned to the PA site and tried out the two Unsanity-supplied examples. The FTP exploit ran. It mounted the FTP site, opened the disk image, LAUNCHED the Malware app and wrote the owned.txt file to my home directory. The warning came up from the malware app telling me it had run.

Again, I have the Apple fix installed. Something is awry. I think I'll stick to PA. Perhaps Unsanity can verify this? And inform the right people? :(

Joshua, just run some of the test exploits from various sites, including Unsanity & MacFixIt.

Guys, Apple's fix prompts you only for URI schemes that have _never_ been run before. If you've run any of the sample exploits before you installed Apple's fix, they'll run perfectly fine afterwards. Apple fix would, however, protect against a new exploit.

More info at Lucien's Daring Fireball link: http://daringfireball.net/2004/06/misregistered

Apple's "Fix" is a load of garbage.

First of all, I had run the URLs before, but with PA installed. It blocked them. I had never run the Unsanity examples unprotected.

Second of all, what if a URL's contents change? What if a safe website is compromised with an exploit, or the developer does something malicious? A previously safe URL becomes bad, but is still permitted by Apple's 'fix'?

"First of all, I had run the URLs before, but with PA installed. It blocked them. I had never run the Unsanity examples unprotected."

Just in case....

The 10.3.4 Update includes the 2004-04-05 and 2004-05-03 Security Updates, but it does *NOT* include the 2004-05-24 Security Update

If you haven't installed the separate sec update, you can grab it here -

http://www.apple.com/support/downloads/securityupdate__2004-05-24_(10_3_3).html

A note from http://docs.info.apple.com/article.html?artnum=61798 -

"This update can also be installed on Mac OS X 10.3.4 and Mac OS X 10.3.4 Server"

Since it's normal for Launch Services to allow previously-run apps to automatically fly again, you'll no doubt need to dump its caches...

Library -> Caches -> trash the "com.apple.LaunchServices.6B.csstore" file

&

Users -> [yourusername] -> Library -> Caches -> trash the "com.apple.LaunchServices.UserCache.csstore" file

...then restart immediately (before emptying the Trash).

(The above info is from the http://daringfireball.net/2004/06/misregistered page that Jason referred to a couple posts ago. There's more info there.)

HTH

I downloaded the OSXMalware program and changed the bundle ID to immitate Address Book, something Rosyna said might fool the Apple fix. When I alunched the guardian handler via Safari it warned me that OSXMalware in Applications would launch.

Additionally I belive LaunchServices wont register an application and overwrite an already set protocol handler.

kwyjibo:

Me thinks you misunderstand the exploits. Read Daringfireball.com. Jason Gruber's got it down.

Also, Apple's fix doesn't block URLs. Apple's fix blocks apps from launching under certain circumstances. It keeps bad apps from running, so it doesn't matter what website you go to.

PA blocks URLs. And, yes there is the possibility of a previously safe URL becoming bad but only if a bad app is installed on your machine somehow.

Anyway, hope that helps.

Peter da Silva:

Wow, I'm stoked to finally see you on the boards discussing the OSX exploit. Did you ever see the MacNN thread where the deeper LaunchServices exploit was discovered. I didn't see you post there.

I read your letter very early on, when the world still only knew about the helpviewer exploit. After the MacNN thread discovered the LaunchServices flaw, I pointed everyone there to your open letter to Apple. I tried to summarize and explain, but it didn't go very far.

There are a few questions on implementation I had. Could you flesh out how your scheme would be implemented, and how that would change the Mac user experience?

What would be really awesome is if you could post on the MacNN thread that started it all. The thread is still alive and is having a great conversation on these ideas. I think people would be really open to your thoughts, and serious about evaluating Apple's fix. What do you say?

It wouldn't make much difference for the user if Apple had separate "LaunchServices" and "WebServices" lists. Some applications would need to be manually entered in WebServices intil the developers updated them, but really there just aren't that many non-Apple protocols and helper applications are a convenience: you may need to save a few files to disk then open them manually. On the upside, you could do things like leaving Finder as the FTP handler for LaunchServices and Cyberduck for WebServices, or write an application that *only* replaced the web-side helper for some protocol... like, make help: URLs go to Google or Wikipedia or the Apple knowledge base.

Don't know if you'll be alerted to an update this deep in your blog, but...

PLEASE update Paranoid Android, especially if you can use it to replace that stupid June 2004 fix with a REAL fix...

Read the latest update on Apple's "fix" in the page linked to my name ... scroll down to the January 2005 update...

It was funny in retrospect...