Mac Browser Security Hole

I just got Apple's latest security update, and all it says is that it is an update to helpViewer, but the documentation doesn't say exactly what was updated or why.

Does Apple new security update solve the problem with help viewer scripts? Can I change my default help:// URL back to the Help Viewer?

[In theory, yes, but it's now looking like the problem may be deeper than just the help:// URLs mapping to Help Viewer. At the moment, I'm thinking that it's a good idea to download and install Paranoid Android from Unsanity, a free application that tells you whenever an unusual URL scheme is requested (and allows you to cancel the action). -Adam]

<http://www.unsanity.com/haxies/pa/>

David Weintraub Support me in the Tour de Cure! <http://www.weintraubworld.net/tour> davidweintraubworld.net

On 5/24/04 11:57 AM, "Kirk McElhearn" <kirklistswanadoo.fr> wrote:

> This goes back to all the old Windows 'trojans' that plagued Windows > for so long until people (lets hope they still do) stop 'double > clicking' on files they shouldnt trust. > > This isnt a Mac OR Windows security issue, its a HUMAN security issue.

Many people have said this, as if it exonerates Mac OS X. But it doesn't matter if it's a "human" issue or not. Many people double-click files with abandon, because that's the way we interact with computers. Only a tiny majority of people actually think twice before double-clicking; though in the Windows world it has gotten better.

[Moved this to the Mac Browser Security Hole thread, since the AppleScript Trojan discussion is different. -Adam]

There's no difference. It's a set of errors that result from no one sitting in a room and trying to break this stuff, or pervert it.

I get the feeling that there's not a lot of chat between the launch services teams, the people who did the help system, etc.

I also get the feeling that there's no one looking at this with the job of "perverting for evil".

This is why anyone doing any sort of programming that deals with networking needs to have a team, even if it's one person, of "IT ArseHelms", who answer only to the CEO, and whose entire purpose is to attack network code like a bunch of evil flying monkeys. Just throw crap at it and see if anything sticks. If it does, then give the coders a detailed write up so it can be fixed.

It's not that the programmers are dummies, although I think Apple as a whole is looking pretty stupid here. (Gee, let's allow remote file systems to mount with NO USER APPROVAL). Oy.

It's that the kind of thought processes that say "Hey, you know...with disk: and help:...ooooh, I could do some eeeeeevil crap here" are NOT the thought processes that are writing that code. Nor should they be. That's why you have a team of really evil bastiges. It's THEIR job to sanity - check stuff.

And Apple really needs a team of evil flying monkey bastiges ready to attack.

john

-- John C. Welch Writer/Analyst Bynkii.com Mac and other opinions jwelchbynkii.com

On 5/24/04 11:57 AM, "David Weintraub" <davidweintraubworld.net> wrote:

> [In theory, yes, but it's now looking like the problem may be deeper than just
> the help:// URLs mapping to Help Viewer. At the moment, I'm thinking that it's
> a good idea to download and install Paranoid Android from Unsanity, a free
> application that tells you whenever an unusual URL scheme is requested (and
> allows you to cancel the action). -Adam]
>
> <http://www.unsanity.com/haxies/pa/>

Paranoid Android would be a much nicer option if it didn't require APE to
function. Sorry, but there's no way I'm running a background app that
patches every single process via undocumented APIs to monitor network
traffic. There are other, admittedly less convenient ways to deal with the
other holes. Not using the Finder for FTP handles the FTP problem quite
nicely.

john

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 5/24/2004 9:57 AM, "David Weintraub" <davidweintraubworld.net> wrote:
> [In theory, yes, but it's now looking like the problem may be deeper than just
> the help:// URLs mapping to Help Viewer. At the moment, I'm thinking that it's
> a good idea to download and install Paranoid Android from Unsanity, a free
> application that tells you whenever an unusual URL scheme is requested (and
> allows you to cancel the action). -Adam]

For an opposing viewpoint:

<http://daringfireball.net/2004/05/help_viewer_security_update>

The author agrees with Unsanity's summation of the problem, but contents
that you can protect yourself by simply disabling particular URL helpers
using RCDefaultApp.

<http://www.rubicode.com/Software/RCDefaultApp/>

Keep in mind that the old "safe" solution, on any platform (some
versions of KDE on Linux have a hole very much like some of the ones we're
discussing here) is to leave the computer in its shipping box and lock it
up.

Most of us aren't willing to go that far. It's a "little inconvenient".

But a business must find a way to avoid the problem shown in a recent
commercial in which malware got by a company's firewalls, to great
wonderment, and then the boss' daughter emerges from his office saying what
a great game she downloaded onto his machine.

So many infections are primarily people problems, not computer problems.

  --John

At 09:57 -0700 UTC, on 2004/05/24, David Weintraub wrote:

[...]

> Does Apple new security update solve the problem with help viewer
> scripts?

Yes.

> Can I change my default help:// URL back to the Help Viewer?

Yes.

> [In theory, yes, but it's now looking like the problem may be deeper than
>just the help:// URLs mapping to Help Viewer.

You sure got that right. Things are much, much worse. The only good news so
far is that no reports have been made of an actual malicious exploit.

Security Update 2004-05-24 *only* fixes the Help Viewer exploit. Not the much
worse stuff that turns out to be behind it. Without ParanoidAndroid (or any
of the other fixes I suggest, but *only* for people who know wtf they're
doing) you are currently most definitely not safe.

I'm trying to keep track of all this, in hopefully not too technical jargon,
at <http://www.euronet.nl/~tekelenb/playground/security/URLschemes/>. So far,
to keep track of this, in 4 days I've had to do 17 updates ranging from major
to serious to enormous.. Not counting the minor ones. This is very much a
work in progress.

I advice people to keep good track of the developments and be very critical
of the source you use for that. The only 2 I've found thus far that provide
only correct information and good advice are 2 german websites:
<http://heise.de/> and <http://www.macnews.de/> (which happen to be the 2
sites that seemed to have reported this first, already on May 14 - apparently
it took 3 days for the translation to make it to slashdot ;)). The forums on
macnn.com is where the real action is, but to follow that you need to
understand the tech stuff that's going on, or else you won't be able to
discriminate between crap and good stuff.

Every other Web site I've looked at (dozens of them) lists, at least
partially, nonsense and/or bad advice. Apparently it is not only hard to
write half-way decent HTML, but even content is a problem :(

> At the moment, I'm thinking
>that it's a good idea to download and install Paranoid Android from
>Unsanity, a free application that tells you whenever an unusual URL scheme
>is requested (and allows you to cancel the action). -Adam]
>
> <http://www.unsanity.com/haxies/pa/>

Note that there appears to be a bug in ParanoidAndroid1.1. If it applies to
you, you need ParanoidAndroid1.0, not available from unsanity but through my
site:
<http://www.euronet.nl/~tekelenb/playground/security/URLschemes/#paranoid_bug>.
If it applies to you, and you're still stuck with Jaguar, you're out of luck,
as ParanoidAndroid 1.0 requires Panther. If that's your situation, follow my
advice to use RCDefaultApp and/or LittleSnitch, but be warned that that
approach really requieres you to understand what you're doing.

[I don't quite understand the bug. I have neither ShapeShifter nor RealOne Player installed, and Paranoid Android seems to work as advertised on my PowerBook. -Adam]

The author of ParanoidAndroid1.0 is working on a new version.

--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

on 5/24/04 12:57 PM, David Weintraub at davidweintraubworld.net wrote:

> [In theory, yes, but it's now looking like the problem may be deeper than just
> the help:// URLs mapping to Help Viewer. At the moment, I'm thinking that it's
> a good idea to download and install Paranoid Android from Unsanity, a free
> application that tells you whenever an unusual URL scheme is requested (and
> allows you to cancel the action). -Adam]

1. I've been using Little Snitch to detect and control unusual attempts to
generate outgoing messages and a security router from NetGear which has
stateful packet inspection and NAT to block unwanted incoming packets. Would
Paranoid Android do anything additional that would be useful in my
situation?

[My impression at this point is that Little Snitch is a fine tool that is equally as successful, if more generic. -Adam]

2. I used the haxie "Xounds" for a while, but I then became uncomfortable
using haxies because I had read somewhere that they extend OS-X in an
unusual way. Is that a real concern?

[Some people are bothered by the technique Unsanity uses to patch applications; my feeling is that it's an acceptable tradeoff in the short term to use Paranoid Android, and if you notice problems, you can always uninstall their code. -Adam]

Dick

At 14:19 -0700 UTC, on 2004/05/24, John C. Welch wrote:

[...]

> Paranoid Android would be a much nicer option if it didn't require APE to
> function. Sorry, but there's no way I'm running a background app that
> patches every single process via undocumented APIs to monitor network
> traffic.

Unless I'm grossly mistaken ParanoidAndroid does not monitor network traffic.
Looks to me like it monitors AppleEvents.

Hm... That makse me think. It that's true, then the same must be possible
without APE, given that there are other tools available to monitor
AppleEvents, such as AEMonitor: <http://software.oxalyn.com/aemonitor/>.
AEMonitor doesn't aim to be a security tool though, so I doubt it already
offers an easy way to stop or blacklist certain events.

Unless my brain is malfunctioning, it may be worth it for those of you who
dislike APE to look at AEMonitor. See what's possible (or what its author
can/is willing to add).

> There are other, admittedly less convenient ways to deal with the
> other holes. Not using the Finder for FTP handles the FTP problem quite
> nicely.

How about afp? Is there an alternative app for that? If not, then without
either LittleSnitch or ParanoidAndroid your only option appears to be to
disable afp completely (using RCDefaultApp for instance), or take the risk.

--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

On 5/24/2004 14:19, "John C. Welch" <jwelchbynkii.com> wrote:

> This is why anyone doing any sort of programming that deals with networking
> needs to have a team, even if it's one person, of "IT ArseHelms", who answer
> only to the CEO, and whose entire purpose is to attack network code like a
> bunch of evil flying monkeys. Just throw crap at it and see if anything
> sticks. If it does, then give the coders a detailed write up so it can be
> fixed.

AND that team should have the power to veto shipments (subject to CEO
override perhaps, but no lower). It does little good to report such
problems and have the error get to the field anyhow.

  --John

On 5/24/04 7:16 PM, "John W. Baxter" <jwblistolympus.net> wrote:

>> This is why anyone doing any sort of programming that deals with networking
>> needs to have a team, even if it's one person, of "IT ArseHelms", who answer
>> only to the CEO, and whose entire purpose is to attack network code like a
>> bunch of evil flying monkeys. Just throw crap at it and see if anything
>> sticks. If it does, then give the coders a detailed write up so it can be
>> fixed.
>
> AND that team should have the power to veto shipments (subject to CEO
> override perhaps, but no lower). It does little good to report such
> problems and have the error get to the field anyhow.

Oh yeah...they'd have to be STEVE'S Evil Flying Monkey Arsehelms. That's the
only way that kind of thing works.

john

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

If I understand it correctly, the damage from any malicious code would be limited to the files the current user has access to. In that case creating a separate user account with very limited access and using *only* that user to browse the web would be another "work around" for this security hole until Apple releases a fix. It might be less convenient (especially in Jaguar since that doesn't support fast user switching), but you won't have to install any additional software.

Can anyone confirm this is indeed true?

[I believe that's so, and I considered saying that in the article, but it struck me as potentially unrealistic. I can't separate my Web use from email, for instance, and once I have my email in that unprivileged account, it's at risk. But yes, if you create a completely unprivileged account, and don't enter your admin password if prompted by a potentially malicious application, I would think your risk would be minimal. -Adam]

At 14:19 -0700 UTC, on 2004/05/24, Adam, wrote:

        [<http://www.euronet.nl/~tekelenb/playground/security/URLschemes/#paranoid_bug>]

> [I don't quite understand the bug. I have neither ShapeShifter nor RealOne
> Player installed, and Paranoid Android seems to work as advertised on my
> PowerBook. -Adam]

Contrary to to PA 1.0, version 1.1 whitelists the guikit and pnm schemes.
guikit is a scheme used by another product of the same author (ShapeShifter).
pnm is for RealPlayer. He has every reason to consider them safe, but forgot
that not every user out there has these 2 apps installed, in which case no
default application will be assigned to it on your machine. Thus when a
malicious app claims to be able to handle either of these URL schemes, it
will be automagically registered as the default. ParanoidAndroid 1.1 doesn't
warn you, because it has these schemes whitelisted.

It's a minor bug really. My apologies if I made it look like more than that.
It only affects PA's second line of defense. The malicious app should never
make it through the first: being fetched and registered by LaunchServices.
But if you mistakenly allow it through the first defense, PA1.1 is slightly
less safe than 1.0.

Rumour has it the next versin wll allow you to edit the whitelist.

--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

Dear Adam and Matt!

First thanks a lot for your (as always) good coverage this time of the URL-Based Mac OS X Vulnerability issue. It sure sounds as a potentially nasty one and one that's obviously tricky to combat. I'm a long time Mac user but I'm not a computer geek and I believe that many users out there now ask themselves the same kind of questions that I'm going to ask you. They may seem trivial to the experts, but I'm sure educating answers will may be appreciated by many. Let's try to keep the use of MacOS X as simple and as free of "computereze" as possible. We don't want to be caught in the same type of intimidating technical jargon that is so plaguing the average Windows user.

First "Safe Surfacing". This is an expression used by some writers who all seem to take for granted that everybody understands and knows what it means. Can you please explain to us what "safe surfacing" really means in practical terms. What is it we have to do (not be logged in as administrators when we surf?) and what is that we should avoid doing?

Second, disabling certain URI protocols. What exactly will happen if I use eg RCDefaultApp to disable afc, disk, disks and telnet? How will this affect my work? What will I have to do differently?

Third, browsers. I believe that the better portion of those Mac users who don't use Safari use Internet Explorer. In Safari you can (and obviously should uncheck the "Open "Safe" Files After Downloading" option but what about IE?

Can you please help out!

Thanks!!

Best regards,

Ingvar Ericson

When the news of the browser (etc.) security problem first appeared, I tried summarizing the vulnerability and remedies in plain English:

<http://www.penmachine.com/journal/2004_05_01_news_archive.html#108525202812671205>

Of course, it got more complicated as people discovered what was really going on. I'd like to thank Matt Neuburg for the best and clearest summary of the problem so far:

<http://db.tidbits.com/getbits.acgi?tbart=07680>

It seems to me -- and has been pointed out by a number of others, including some TidBITS Talk subscribers -- that the fundamental problem with Apple's conjoining of various file-handler schemes in Mac OS X is that it treats untrusted content (from websites) the same as relatively trusted content (local files).

Now, it's true that you can't always trust things on your local hard drive or local network, especially if you don't know how they got there, but I think most people would agree that an arbitrary web URL is less trustworthy than a file you put on your Desktop.

What has impressed me is the rapid, continuous, and widely distributed effort in the Mac community to find ways to deal with the problem. John Gruber of daringfireball.net, Jay Allen (jayallen.com), MacNN (or those in its user forums), Unsanity, TidBITS, and even Apple itself have done a lot of work in a short time to address it, and the bloggers in particular have shared all their information freely, to help minimize any potential damage.

There has been some disagreement about the best solutions, but only a few days after the vulnerability became known, we also had several different and similarly effective ways to protect ourselves. That's good.

I hope Apple can quickly create additional patches to prevent any aspects of this vulnerability from being exploited. I think Mac OS X users are more likely to keep their systems up-to-date, using Software Update, than Windows users with Windows Update, so I hope the problem can be nipped in the bud before any serious exploits appear.

-- Derek K. Miller - dkmillerpobox.com Writer, Editor, Web Guy, Drummer, Dad - Vancouver, Canada Penmachine Media Company | http://www.penmachine.com The Neurotics - Fab Rock | http://www.theneurotics.com

Matt Neuberg writes: "Part of the reason may be that Apple seems to have a great deal of trouble making up its mind how to specify a file in general. In Cocoa, for example, a file may be specified either as a pathname or as a URL; on the whole, Mac OS X seems to be trying to break down the distinction between a file and a URL-in-general. This works nicely from one point of view, because it means that for the programmer the command to open a remote file via http is exactly the same as the command to open a text file on the same machine. In any case, though, the thing to understand is that under Mac OS X, a URL becomes a file specifier possessing the same status as a pathname."

I wish this were true. If you have a web page with an http:// link to a directory on WebDAV enabled web server, and you click on that link using Internet Explorer in Windows XP, the XP file browser opens at the directory (and you can edit the files in that directory as though the directory was local). If you do exactly the same using Safari and MacOS X, all you'll get is a directory index on a web page. In this case, the XP behaviour seems much neater and more useful. (Note that there are no additional security implications here; what you get by clicking the link with XP is exactly equivalent to entering the link address in the Finder's Connect to Server, but without the need to copy from the web page into a Finder dialog box).

On 5/26/04 9:01 AM, "Frans Moquette" <fransmoquette.nl> wrote:

> If I understand it correctly, the damage from any malicious code would be
> limited to the files the current user has access to. In that case creating a
> separate user account with very limited access and using *only* that user to
> browse the web would be another "work around" for this security hole until
> Apple releases a fix. It might be less convenient (especially in Jaguar since
> that doesn't support fast user switching), but you won't have to install any
> additional software.
>
> Can anyone confirm this is indeed true?

If that user is an admin, then you can silently create startup items in
/Library/StartupItems/ that, upon the next boot, will run unrestricted as
root. At that point, your box is owned.

john

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 07:01 -0700 UTC, on 2004/05/26, Ingvar Ericson wrote:

[...]

>Let's try to keep the use of MacOS X as simple and as
>free of "computereze" as possible. We don't want to be caught in the same
>type of intimidating technical jargon that is so plaguing the average
>Windows user.

Here's an attempt:
<http://www.euronet.nl/~tekelenb/playground/security/URLschemes/letter_to_mom.html>

;)

> First "Safe Surfacing". This is an expression used by some writers who all
>seem to take for granted that everybody understands and knows what it means.
>Can you please explain to us what "safe surfacing" really means in practical
>terms. What is it we have to do (not be logged in as administrators when we
>surf?) and what is that we should avoid doing?

The essential thing to at least understand is that differentiating between
"viewing a Web page" and "downloading something" is fooling yourself.
Anything that a Web browser shows you *is* downloaded. It's just downloaded
to a temporary space on your harddisk, the browser's cache, because you are
not expected to want to actually interact with the files. The browser opens
them, interprets them, and _that_ is what you see in your browser window.

So in order for the browser to be able to show you anything, that anything
needs to first be fetched and stored (however shortly) on your machine.

So the word "downloading" is misleading.

Once you understand that, and you know that a "Web page", is mostly not 1
single file, but a collection of files (the HTML file, a CSS file, images,
scripts, cookies, a Flash file, a QuickTime movie, etc.), then you know that
there might be parts there that you don't want - assuming you understand how
they work, technically, and you know how that could be used in a way you
dislike. That can apply to something as harmless but annoying like unrelated
advertisements in a Web page. (If they are animated, they may even in fact be
physically dangerous to some people.)

In that vein, some people don't like cookies or even sending out HTTP
referers, which can be used to keep track of your surfing behaviour. They
don't like javascript because it can be used for that too as well as to open
unwanted new windows for example. They don't like iframes because they are
aware that those can be absued to even hide such things (iframes and regular
frames can in fact be abused to launch an attack through the URL scheme
security hole everybody is now talking about). Etc.

Some of us have been aware of those things for a long time and use a browser
like iCab, which gives you numerous options to protect you from such
annoyances, whithout breaking functionality on Web sites where you _do_ want
these techniques to work. But the only way to configure all that is of course
to know about each issue and to decide for yourself if it matters to you.

(Btw, that iCab offers this is such a logical consequnec from the fact that
it closely follows the original intent of the Web: a system to exchange
information without having to worry about compatibiliy, achieved by
separating content from presentation. In other words: the user i salways in
control of what he receives and how that is displayed. The user is in
control, not the author. Most other Web browsers tend to behave more like
televisions.)

> Second, disabling certain URI protocols. What exactly will happen if I use
>eg RCDefaultApp to disable afc, disk, disks and telnet? How will this affect
>my work? What will I have to do differently?

Depends on your work :)

I doubt anyone would notice anything about disabling the disk: and disks:
schemes. Until a week ago most of us, me included, weren't even aware they
existed and probably never used them.

ftp in general is mostly used to download files, or to upload them (mostly
web publishers). Unless you _know_ that you never need it, I would suggest to
not disable it, but have it point to a dedicated ftp client, such as
InterArchy or Fetch, or Tramsmit, etc.

Disabling afp only affects those who mount disks on remote Macs. I think most
home users don;t do that, but in an office situation with manu Macs it is
very likely to be used constantly. If I understand correctly, if you disable
afp in RCDefaultApp, you can still mount those same remote Mac volumes by
Finder's "Connect to server..." menu.

That shows that the word "disabling" might be confusing... ;) It applies to
"disabling the URL scheme" and thus makes sense for RCDefaultApp to call it
that. It does not mean your Mac cannot do afp at all anymore.

And well, if this isn't clear enough for you, then you are much better served
by Paranoid Android because that doesn't disable anything. It just warns you
of suspect actions, informs you which application is trying to do something
(since version 1.2) and gives you the choice to stop it, or allow it.
Hopefully at that point you are aware of what you clicked and whether you
have a good reason to allow.

> Third, browsers. I believe that the better portion of those Mac users who
>don't use Safari use Internet Explorer. In Safari you can (and obviously
>should uncheck the "Open "Safe" Files After Downloading" option but what
>about IE?

If IE has such an option (I don't think so) you should of course disable that
too. Then again, I don't really see why people who care about security would
use IE in the first place now that Micxrosoft has declared it dead. Is there
any reason to expect Microsoft will repair security problems in Mac IE?

--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

On 5/26/04 at 7:01 AM, ingvar_ericsonmac.com (Ingvar Ericson)
wrote:

<snipped first question since I don't know anything about "safe surfacing">

>Second, disabling certain URI protocols. What exactly will happen
>if I use eg RCDefaultApp to disable afc, disk, disks and telnet?
>How will this affect my work? What will I have to do differently?

A couple of comments. If you are to use RCDefaultApp as your protection you also need to reset app designated to handle ftp calls to something other than Finder. In my case, I use Interarchy and have it set as my default ftp app.

The effect of disabling these protocols as launch services via RCDefaultApp is insignificant. Essentially all this does is prevent you from mounting a volume by clicking on a URL using one of these protocols. It does not prevent you from initiating that action.

For example, if you don't have afp disabled, you could create an html document with a link of the form afp://xxx. Then you could open that document in Safari or another browser and initiate the action by clicking on the link. When such a link is clicked on, the request is passed to launch services since the browser doesn't deal with the afp protocol. Launch services then passes the request to the designated application which takes the appropriate action. Disabling afp using RCDefaultApp simply tells launch services there is no app to handle afp which causes an error message to be generated. But since RCDefaultApp does nothing to the app that can really handle afp (Finder), there is nothing to prevent you from using Connect to Server to initiate that connection directly.

More detail can be found at

<http://daringfireball.net/2004/05/ounce_of_prevention>

When all is said and done, I doubt most users would create a html document with a link of the form afp:\\xxx and use a browser to initiate a connection. Rather I would expect most users to initiate a connection directly from the Finder. That means disabling afp via RCDefaultApp would have no effect on the workflow form most users.

Similar comments apply to the other protocols with the possible exception of ftp. Many files someone might want to download are availble via ftp rather than http. Often, there is a clickable link to initiate the download. In this case, most users would want the download to proceed automatically. Using RCDefaultApp to redirect ftp to Interarchy or some other third party ftp software ensures the download proceeds automatically. But since Interarchy and others do not mount a volume on the desktop like Finder, these programs don't give you exposure to the security hole.

>Third, browsers. I believe that the better portion of those Mac
>users who don't use Safari use Internet Explorer. In Safari you can
>(and obviously should uncheck the "Open "Safe" Files After
>Downloading" option but what about IE?

For any browser, you want to disable features that automatically open files and mount volumes to the desktop. But beyond this, the security hole isn't an issue with any browser. It is a hole in the Mac operating system and results from any app passing to launch services URIs the app doesn't handle. If a browser didn't pass URIs in this manner, it would be broken.

On May 26, 2004, at 8:01 AM, Frans Moquette wrote:

> If I understand it correctly, the damage from any malicious code
> would be limited to the files the current user has access to. In that
> case creating a separate user account with very limited access and
> using *only* that user to browse the web would be another "work
> around" for this security hole until Apple releases a fix. It might be
> less convenient (especially in Jaguar since that doesn't support fast
> user switching), but you won't have to install any additional
> software.
>
> Can anyone confirm this is indeed true?

Even an unprivileged account has more-or-less full access to its ~/
directory. The exploits in the Unsanity whitepaper all work when using
a "Limited" user account, or even a "Simple Finder" user. Apparently,
the ability to register a new URL helper works for anyone, provided
that it is only registered for that user.

So yes, you can prevent a server from being readily taken down by
having all users unprivileged on it, but you can still lose all of that
user's files when the program fires off.

Additionally, FWIW, LittleSnitch and Paranoid Android are very
different programs. LittleSnitch creates a sort of whitelist of which
applications are allowed to make network requests, whereas 'Android
does the same for URL handlers. As most suspect URL handler exploits
invoke known-safe requests (Safari or the Finder mount a disk image)
followed by a suspect request to a local file, this first request would
be okay'd by 'Snitch and 'Android, but the second request would only
turn up on 'Android's radar.

>> Third, browsers. I believe that the better portion of those Mac users who
>> don't use Safari use Internet Explorer. In Safari you can (and obviously
>> should uncheck the "Open "Safe" Files After Downloading" option but what
>> about IE?
>
> If IE has such an option (I don't think so) you should of course disable
> that too. Then again, I don't really see why people who care about
> security would use IE in the first place now that Micxrosoft has declared
> it dead. Is there any reason to expect Microsoft will repair security
> problems in Mac IE?

IE 5.2.3 on OS X allows you to turn on and off individual handling of
various Protocols. In fact it adjusts the same system level options as
RCDefaultApp. Changes I made in IE showed up in RCDefaultApp and vice-a
versa.

To get to these settings: Open IE, go Explorer menu, Preferences. Scroll
down the list of preferences on the list until you see Protocol Helpers
(it's under the Network section, you may have to turn down the triangle
next to Network to see it). Select a URL protocol (i.e. afp), click the
checkmark to turn off URL handling for that protocol (I believe this part
affects IE only). Click the change button at the bottom to change which
application is set to handle the protocol.

Under the Receiving Files option you might set the Always download files to
the download folder, instead of Always use the download location from
appropriate file helpers (not sure of the effect of this). and turn off
Automatically decode MacBinary and BinHex files.

Finally, IE's security zones offer a great deal of options for controlling
which sites you can or cannot download files from. You can set the default
Internet Zone to disallow file downloading from everywhere. And then in
your trusted sites zone specifically list sites you do want to download
from.

I've got more info on using security zones here:
<http://www.vanhaaren.net/~kevin/stoppop.shtml>

I wrote that a long time ago before pop-up blockers were common so you can
disregard the info about stopping pop-ups and use the generic security zone
info to enable/disable other features.

I long ago gave up using IE as my default browser because I consider it
seriously broken in areas such as CSS support, however in this area, for
this problem, IE actually offers superior options for preventing such
problems. Of course, as with most Microsoft products, the default settings
are not set for security.

Kevin