TidBITS#731/24-May-04
=====================
This week's security vulnerability is real, and cuts to the core
of Mac OS X. Read on for Adam's look at the problem and how to
protect yourself, along with Matt Neuburg's explanation of how it
happened. Joe Kissell then explains Apple Mail's spam filter with
an excerpt from his new "Take Control of Spam with Apple Mail,"
ebook, and Adam introduces Envision, a program that turns a Mac
into an Internet picture frame. In the news, we cover a minor
Apple reorg and the releases of Office 2004 and SubEthaEdit 2.0.
Lastly, no issue next week!
Topics:
MailBITS/24-May-04
Getting to Know Apple Mail's Spam Filter
Visualize the Internet with Envision
URL-Based Mac OS X Vulnerability Revealed
Explaining the URL-Based Mac OS X Vulnerability
Hot Topics in TidBITS Talk/24-May-04
<http://www.tidbits.com/tb-issues/TidBITS-731.html>
<ftp://ftp.tidbits.com/issues/2004/TidBITS#731_24-May-04.etx>
Copyright 2004 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: <[EMAIL PROTECTED]>
---------------------------------------------------------------
This issue of TidBITS sponsored in part by:
* READERS LIKE YOU! Help keep TidBITS great via our voluntary <------ NEW!
contribution program. Special thanks this week to Jim Wickman,
Clarence Ching, and Irving Alan Sparks for their kind support!
<http://www.tidbits.com/about/support/contributors.html>
* SMALL DOG ELECTRONICS: Xserve RAIDS On Sale!
Xserve RAID 2.5 terabytes $7149! Xserve RAID 1.2 terabytes
only $5149! Xserve RAID 720 GB Only $4249!
Visit: <http://www.smalldog.com/tb/> 802-496-7171
* GET FETCH FOR FREE! Fetch Softworks makes Fetch, the original <---- NEW!
Macintosh FTP client, free for educational and charitable use.
Apply today at <http://fetchsoftworks.com/edapply>!
* Dr. Bott, LLC: We got into this business because we love
computer stuff. We now have the chance - the DUTY - to sit and
geek out with technology every day under the guise of "work."
And if it's cool enough, we sell it. <http://www.drbott.com/>
* Web Crossing: Did you know Web Crossing does Blogs?!? Used for
workgroup reports, entertainment, advice columns, politics, or
whatever, Web Crossing's Blogs can integrate w/discussions,
access lists, etc. Try it! <http://www.webcrossing.com/tb-504>
* iPod Armor takes the abuse, so your iPod doesn't have to! <-------- NEW!
Rugged aluminum construction keeps iPod safe from scratches
and other random daily hazards. Your iPod is always safe in
iPod Armor. <http://ipodarmor.com/index.php?refID=5>
* Bare Bones Software TextWrangler 1.5 -- General-purpose tool for <- NEW!
composing, modifying, and transforming text. Now with full
AppleScript support! US$49. For more info, to download a demo,
or to purchase a copy, visit <http://www.barebones.com/>.
---------------------------------------------------------------
MailBITS/24-May-04
------------------
**No TidBITS Issue 31-May-04** -- After this week's extra-long
TidBITS issue, we're taking a week off for the U.S. Memorial
Day holiday, which coincides with Managing Editor Jeff Carlson's
birthday celebrations and the days I'll be spending at the
MacDesign conference. TidBITS Talk should continue unabated,
and watch our home page for breaking news that can't wait
(although we're hoping for a couple boring weeks). We'll return
with the 07-Jun-04 issue. [ACE]
<http://www.macdesignconference.com/>
<http://www.tidbits.com/>
**Microsoft Office 2004 Ships** -- Microsoft has officially
released Office 2004 for Mac OS X, a significant revision to the
near-ubiquitous suite of productivity tools. We plan to look more
closely at the changes in Word, Entourage, Excel, and PowerPoint
once we've received the software and evaluated whether the new
features and fixed bugs in the final versions of each program are
worthwhile. For now, suffice to say that you can purchase it
for $400 (list price) or $150 (educational); upgrades cost $240.
Individual products are also available if you don't want the full
suite. You can also download a test drive version (186 MB) that
works for 30 days, but keep in mind that Office 2004 requires
Mac OS X 10.2.8 or higher. [TJE]
<http://www.microsoft.com/mac/products/office2004/office2004.aspx>
<http://www.microsoft.com/mac/products/office2004/howtobuy/howtobuy.aspx>
<http://www.microsoft.com/mac/default.aspx?pid=office2004td>
**SubEthaEdit 2.0 Refines Collaboration** -- The Coding Monkeys
have released version 2.0 of SubEthaEdit, their unique real-time
collaborative text editor. This release adds several editing
features such as regular expression-based search and replace, text
auto-completion, a split-window view, conversion of line endings,
and read-only access. It also enables you to invite other people
on your local network to your shared document using Rendezvous.
Developer-friendly features include AppleScript and ActionScript
syntax highlighting, and per-mode preferences. SubEthaEdit 2.0
is not compatible with version 1.0, so each collaborator must be
running the latest version to share documents. The program is a
1.2 MB download, and is free for non-commercial use; a commercial
license costs $35. [JLC]
<http://www.codingmonkeys.de/subethaedit/>
**Apple Creates New iPod Division** -- Highlighting the importance
of its digital music player to Apple's bottom line, the company
has formed a separate iPod division headed up by Vice President
Jon Rubinstein, who previously ran Apple's hardware engineering.
A separate Macintosh division has also been created, with Tim
Cook, head of worldwide sales and operations, at its helm. Some
pundits have tried to make much of this move, but to us, it sounds
like standard corporate restructuring to reflect the reality of
Apple's markets. [JLC]
<http://www.reuters.com/newsArticle.jhtml?type=topNews&storyID=5198496>
Getting to Know Apple Mail's Spam Filter
----------------------------------------
by Joe Kissell <[EMAIL PROTECTED]>
Like most people who use Apple Mail, I had high hopes that its
improved Junk Mail filter, a much-touted benefit of upgrading to
Panther, would live up to Apple's hype. After months of diligently
training the filter, I was still less than satisfied with its
results. Based on the hundreds of messages I've read on Apple's
discussion forums, my experience is not unique. Rather than live
with the spam, though (or trade Mail for another application),
I decided to look into the problem more deeply. Armed with an
ever-increasing personal collection of many thousands of spam
messages, I experimented with Mail's Junk Mail settings, compared
it with other filters, and tried to discover how it really works -
and why it sometimes fails. I discovered that at least some of
the problems I'd been having were due to a misunderstanding of
the application's design, which is not as self-explanatory as
some of Apple's applications.
I have some good news and some bad news. The good news is that
Mail's Junk Mail filter, when properly configured, can be a
reliable tool for keeping spam out of your In box. The bad news
is that even if the Junk Mail filter is working as well as it
possibly can, you may still see more spam than you would like.
Luckily, other applications and techniques can make up for the
Junk Mail filter's deficiencies. You'll be able to make better
decisions about how to use (or supplement) the Junk Mail filter
when you know what happens behind the scenes.
I've distilled innumerable hours of research and experimentation
into my latest Take Control ebook, "Take Control of Spam with
Apple Mail," from which this article is excerpted.
<http://www.tidbits.com/takecontrol/spam-Apple-Mail.html>
**How Mail's Junk Mail Filter Works** -- Mail's Junk Mail filter
has two modes: Training and Automatic. (You can also disable it
entirely.) Exactly what happens in these two modes can confuse the
uninitiated. In particular, many people wonder whether the filter
continues to learn if you switch to the Automatic mode. (It does
indeed, though Apple's documentation obscures this fact.) Here are
the details.
When a message arrives, Mail runs a built-in rule - a rule that
does not appear in the Rules list. In order to minimize false
positives, this special junk mail rule runs after all other rules.
But it doesn't run if one of your other rules includes the "Stop
evaluating rules" action, and it applies only if a given message
has not already been moved or deleted by some other rule.
You can see the special junk rule by opening the Junk Mail
preference pane and clicking the Advanced button at the bottom
of the window. Depending on the options you choose, this rule
optionally checks to see whether the message's sender is in your
Previous Recipients list or your Address Book, and whether the
To field of the message contains your full name - since spam
often does not. (The Previous Recipients list is a useful adjunct
to the Junk Mail filter, although as I explain in detail in the
ebook, incorrect data can easily creep into it, rendering it
counter-productive.) If the answer to any of these questions is
yes, the rule stops and your message is left alone. If all three
conditions are negative, though, it checks one final condition:
"Message is junk mail." If this final condition is true, the
filter takes the action you specify: in Training mode, it changes
the color of the message subject to Brown; in Automatic mode, it
moves the message to your Junk mailbox. (This action is one of
only two differences between Training mode and Automatic mode.
The other is that in Automatic mode, Mail consolidates the Junk
mailboxes for all of your accounts under a single Junk icon in
the Mailbox list.
The "Message is junk mail" condition sounds rather mysterious,
but it means that, if true, Mail's latent semantic analysis filter
(discussed just ahead) has assigned the message a value beyond its
arbitrary threshold for spam. You cannot modify this threshold,
but if you later mark the message as Not Junk, you decrease the
probability that Mail will consider a similar message to be spam
in the future.
The Panther version of Mail added yet another criterion for spam
checking: headers inserted by a spam filter running on your ISP's
mail server. Many ISPs use server-based spam filters such as
SpamAssassin or Brightmail. If such a filter identifies a message
as potentially spam, it tags it by adding to the message a special
header, such as X-Spam-Flag. (These special headers are normally
hidden, but you can display them by choosing View > Message > Long
Headers [Command-Shift-H].)
If a message contains this header, this means your ISP's spam
filter - which may be more advanced than the one built into Mail -
suspects the message to be spam. As long as the checkbox Trust
Junk Mail Headers Set by Your Internet Service Provider is
selected in Junk Mail preferences, Mail marks such messages as
Junk Mail (unless they were exempted for some other reason, such
as being sent by someone in your Address Book). Some server-side
spam filters use other headers besides X-Spam-Flag to identify
spam. The only way to tell Mail to look for a different header
is to edit its preference file manually; I give full instructions
in the ebook.
**About Statistical Filtering** -- Because of the constantly
evolving nature of spam, tools that attempt to filter out messages
based on a fixed list of keywords, patterns, or rules become less
effective as time goes on. Statistical filters address this
problem by making up their own rules (in a sense) as they process
your mail. The most frequently used statistical spam-filtering
method is Bayesian filtering (found in Eudora, SpamSieve, and
SpamAssassin, among others).
Apple Mail uses a related technique known as Adaptive Latent
Semantic Analysis (LSA). Both methods compute the probability of
a given message being spam based on an analysis of the contents
of existing spam and non-spam messages. And both methods become
more accurate as they are exposed to new samples of good and bad
messages. Although from a user's perspective Bayesian and LSA
filters are similar, they differ in some important ways.
**Bayesian Filters** -- To oversimplify tremendously, think of a
Bayesian filter as consisting primarily of two lists: "good" words
and "bad" words. You build these lists dynamically as you use the
filter. Every time you indicate that a message is spam, the filter
adds all the words in that message to its Bad Words list; every
time you indicate that a message is legitimate, all its words go
onto the Good Words list. Of course, most words appear on both
lists, so the filter determines the probability that each word
is a spam indicator based on the proportion of times it appeared
in bad versus good messages.
When a new message comes in, the filter calculates the average
spam score of its words, and if that score exceeds a predetermined
threshold, the message is deemed to be spam. Bayesian filters are
highly dynamic, adapting themselves not only to the type of mail
each individual receives (since one person's spam is another's
ham) but also to the changing tactics of spammers. Although the
system is not perfect, it means that if next month a new scam
emerges for selling real estate on Mars, a Bayesian filter will
learn to reject such messages after you manually mark a few
examples as spam. Most Bayesian filters also take into account
email headers and other message attributes in order to avoid being
fooled by spam messages containing long (but often hidden)
passages of ordinary prose.
**Latent Semantic Analysis in Mail** -- Where Bayesian filters
are based on a relatively straightforward computation of word
frequency, LSA filters go further by identifying spam-like words,
phrases, and messages based on their similarity in meaning to
text you've already identified as spam. Instead of assigning
simple weights to each word individually, an LSA filter takes
into account the overall context in which a word appears. For
example, the word "enlargement," when it appears in a discussion
about photography, would not normally be an indicator of spam -
whereas the same word in the context of cosmetic surgery or low-
cost prescription medicine would be a very good indicator of spam.
(Again, this is an oversimplification. For more details on latent
semantic analysis, see part 2 of Francois Joseph de Kermadec's
three-part series "The Fight Against Spam" at MacDevCenter.)
<http://www.macdevcenter.com/pub/a/mac/2004/05/18/spam_pt2.html>
Like a Bayesian filter, an LSA filter keeps learning as you use
it. This assumes, of course, that you diligently correct all its
mistakes. In Mail, this means marking all spam messages the filter
misses as Junk Mail, and marking all incorrectly identified
legitimate messages as Not Junk Mail.
On paper, LSA seems to be a more sophisticated technique that is
less likely to be foiled by clever spammers. In practice, however,
Mail's implementation of LSA leaves something to be desired. In my
own tests, it learned more slowly than Bayesian filters. It also
tends to err on the cautious side, with no way to adjust its
threshold for what it considers spam. And because it looks for
patterns of words rather than patterns of characters, lots of
seemingly obvious spam messages get through undetected.
Mail stores its statistics of good and bad message characteristics
in a single file: ~/Library/Mail/LSMMap2. (LSM, by the way, stands
for "least square method," a mathematical algorithm used in latent
semantic analysis. I could tell you were wondering about that.) If
this file becomes damaged - which unfortunately can happen pretty
easily - junk mail filtering stops working correctly.
You can't repair the LSMMap2 file, but you can delete it manually
or reset it by clicking a button on Mail's Junk Mail preference
pane. Doing so solves the most serious junk mail problems, but
also eliminates all the training you have given your junk mail
filter, so its accuracy will probably be poor until it has
processed enough new legitimate and spam messages to rebuild
its database.
What can damage Mail's junk statistics file in the first place?
In addition to the usual things (such as crashes while the file
is open, directory errors, or shutting down improperly), LSMMap2
can occasionally suffer damage in the course of ordinary
activities such as filing a message or marking it as Junk Mail,
if the message itself contains certain kinds of errors. Although
you can't prevent damage from occurring, you can take steps to
make recovery easier (see the ebook for more information).
**Marking a Message as Junk Mail/Not Junk Mail** -- Because
statistical filters increase their accuracy gradually as you use
them (and because spammers constantly learn new tricks to thwart
them), spam sometimes gets past the Junk Mail filter and appears
to be ordinary mail. (This is known in the lingo as a "false
negative.") You could just delete such messages, but if you
do, you actually increase the probability that similar messages
will sneak through in the future. Instead, you must select each
unmarked spam and manually mark it as Junk Mail (choose Message >
Mark > As Junk Mail [Command-Shift-J]).
Note that merely moving a message to your Junk mailbox is not
enough; only if the Junk Mail flag is set, as shown by the "paper
bag" icon in the message list, does Mail consider the message
junk mail. When you mark a message as Junk Mail, you modify the
filter's statistical lists and remove the sender's address from
the Previous Recipients list if it was there.
Conversely, Mail may incorrectly mark a legitimate message as Junk
(a "false positive"). After all, statistical filters only judge
probabilities. If someone sent you, say, an article discussing the
sorts of words that spammers often use, that might tip the scales.
(This problem of overzealous spam filters has caused no end of
problems for TidBITS and the TidBITS Talk mailing list.) So you
must always mark such messages as Not Junk (choose Message >
Mark > As Not Junk Mail) to tell Mail they are legitimate.
Surprisingly, though, marking a message as Not Junk also adds the
message's Sender to your Previous Recipients list! This guarantees
that no message from that sender will be marked as spam in the
future (assuming you use the default settings), which may or may
not be what you want. This is just one of many surprises I
encountered with the design of the Previous Recipients list.
**Take Control of Spam with Apple Mail** -- I've tried to explain
the basics of how Mail's Junk Mail filter works here, but in my
full 59-page "Take Control of Spam with Apple Mail" ebook, I go
much further, providing detailed, practical steps Mail users
can take to eliminate spam, prevent false positives, and solve
problems with the Junk Mail filter. The ebook includes a great
deal of additional background information, plus extensive
discussions of add-on filters and other techniques that go beyond
Mail's built-in anti-spam capabilities. If you've been suffering
from spam in Mail, I'm confident my advice will reduce your
frustration level and help you avoid wasting so much time dealing
with junk mail. "Take Control of Spam with Apple Mail" costs $5,
and as with all Take Control ebooks, purchasers are entitled to
receive all minor updates for free.
<http://www.tidbits.com/takecontrol/spam-Apple-Mail.html>
[Joe Kissell is a San Francisco-based writer, consultant, and Mac
developer who kicked off the Take Control series with the best-
selling "Take Control of Upgrading to Panther." His Interesting
Thing of the Day Web site returns with daily articles beginning
01-Jun-04.]
<http://www.tidbits.com/takecontrol/panther/upgrading.html>
<http://itotd.com/>
Visualize the Internet with Envision
------------------------------------
by Adam C. Engst <[EMAIL PROTECTED]>
A year or so ago, I realized that LCD monitors were coming down
in price sufficiently that it would be feasible to mount one
on a wall and use it to display photos and other digital art.
It turns out I wasn't alone in this, and Alan Oppenheimer of
Open Door Networks had wanted to do much the same thing. Alan
was responsible for the creation of AppleTalk while at Apple,
and since leaving the company, Open Door has released a variety
of network-related programs including ShareWay IP (which enabled
Personal File Sharing to work over IP instead of just AppleTalk),
a personal firewall called DoorStop that Symantec bought and
turned into Norton Personal Firewall, another utility for better
understanding and reacting to access attempts detected by your
firewall, and several server log analysis programs.
I say all that by way of showing how Open Door's latest program -
currently available for free as a public beta - is a bit of a
departure from the world of geeky network and security software.
Envision is essentially an Internet-based slideshow program that
Alan and his team started writing to display images from the
Astronomy Picture of the Day archive on an old iBook. You point
Envision at a Web site that offers public access to its images,
and the program goes out, finds the image URLs, and downloads
the pictures that meet your criteria for size, name, and so on.
(Envision comes with a selection of pre-defined slideshows for
museums, currency, comics, and much more.) As soon as it has
downloaded images that match, it starts displaying them in a
simple slideshow, moving from image to image on user-defined
timing.
<http://www.opendoor.com/envision/>
<http://antwrp.gsfc.nasa.gov/apod/astropix.html>
Envision is an intriguing program for browsing the Web visually
without constant clicking, and I felt it was worth covering even
in its public beta phase because Open Door is extremely interested
in feedback from users about how Envision should be focused and
what it needs to do better. There's no question that Envision's
current capabilities are somewhat limited, sometimes intentionally
so: it won't crawl past the top level of sites other than the one
it starts on, and it fails with sites that use tricks like weird
redirects or JavaScript pop-up windows to prevent people from
viewing images too quickly. I also prefer Mac OS X's photo screen
saver, with its panning and zooming effects, for displaying
photos; luckily you can drag photos out of Envision's thumbnail
view to save them to disk if you want to feed them to Mac OS X's
screen saver. It's likely a future version of Envision will have
an option to save images to specific folders for immediate use
with Mac OS X's screen saver.
There's also no question that Envision will be controversial.
The prurient will undoubtedly use it to download and display
naughty pictures, but of course, that was equally as possible
with a normal Web browser. Some webmasters will be upset that
their banner ads aren't displayed along with the images, but
again, there are Web browsers and other utilities that can prevent
banner ads from loading. And designers and site authors will likely
express dismay that users won't see their images in context and
with any supporting text. That said, double-clicking a photo
immediately takes you to its original Web page, and Envision can
optionally show each picture's URL, a link to the original site,
and its caption in an Info pane. (The caption - created from the
image's ALT tag - can optionally appear over the image itself in
Envision.) Who knows, perhaps someday webmasters will even start
to make slight coding changes for Envision so their sites can
more easily be displayed on what's essentially a large digital
picture frame.
<http://www.opendoor.com/envision/envisionWebmaster.html>
Despite Envision's somewhat rough status, I've started watching
the dealnews postings for cheap LCD monitors and thinking about
where and how I'd mount such a monitor for displaying not just
the thousands of digital photos I've taken, but also images from
Envision. I think I'll start with some of those amazing space
pictures from NASA.
<http://www.dealnews.com/>
URL-Based Mac OS X Vulnerability Revealed
-----------------------------------------
by Adam C. Engst <[EMAIL PROTECTED]>
It's not a Trojan horse, but a recently revealed security
vulnerability does appear to be a very real concern. The exploit
relies on unsafe actions that Apple allows for certain URL schemes
(such as the http, ftp, or mailto bit at the beginning of a URL)
and makes it possible for a malicious code to be delivered and
executed silently, without the user realizing anything has
happened.
The problem was initially thought to revolve around only two of
these URL schemes: disk and help. When you combine the capability
to download and automatically mount a disk image (which could
contain a malicious AppleScript script) and the capability to
run that AppleScript (because it's in a known location) via Help
Viewer, you end up with a recipe for trouble. Turning off
Safari's Open "Safe" Files After Downloading option in its General
preference pane isn't sufficient protection (and the vulnerability
is even present if you use some other Web browsers).
<http://secunia.com/advisories/11622/>
Apple responded within days, issuing Security Update 2004-05-24.
Although Apple's description was terse, as always, it appears
that the security update installs a new version of Help Viewer
that presumably eliminates that program's capability to execute
AppleScripts sent via help URLs. (The security update also
included a fix to URL processing within Terminal for users
of Mac OS X 10.2 Jaguar; again, Apple provided no details.)
Unfortunately for everyone involved, Apple's fix was merely a
band-aid on what now seems like a much more involved and deep-
seated problem, which I'll let Matt Neuburg explain separately
elsewhere in this issue. Suffice to say, the concern over Help
Viewer was merely a special case of the overall vulnerability,
which revolves around an attacker being able to post a disk image
containing a malicious application that registers a special URL
scheme. When a user clicks the link (which would of course be
obscured to look like something else), the disk image is
downloaded, mounted, and the special URL scheme is registered with
Mac OS X. The server providing the URL waits a short while (until
the disk image is mounted and URL scheme registered) and then
automatically redirects the user to another URL that uses the
just-registered scheme. That subsequent URL tells Mac OS X to
launch the malicious application. To quote from Maurice Sendak,
"'And now,' cried Max, 'let the wild rumpus start!'" Kudos to
TidBITS Talk reader Sander Tekelenburg for a coherent page
explaining this process.
<http://secunia.com/advisories/11689/>
<http://www.euronet.nl/~tekelenb/playground/security/URLschemes/>
<http://db.tidbits.com/getbits.acgi?tlkthrd=2233>
Without in any way detracting from the serious nature of this
vulnerability, it's important to clarify a few things. This is
not a Trojan horse, it's not a virus, and although several people
have posted proofs-of-concept, I'm not aware of any reports of
any actual malicious software that uses this technique.
I'm certain Apple is working furiously to come up with a fix;
until they do, the best advice for normal users (other than to
keep good backups!) seems to be to download and install Paranoid
Android, a free utility developed by Unsanity. Once installed,
Paranoid Android watches for unknown URL schemes and displays a
warning dialog that lets you cancel the action before your Mac
can be compromised. Unsanity and Jason Harris deserve significant
credit for developing Paranoid Android and releasing it for free.
To learn a bit more about how Paranoid Android works, read Jason's
white paper at the second link below.
<http://www.unsanity.com/haxies/pa/>
<http://www.unsanity.com/haxies/pa/whitepaper/>
Some people are bothered by the technique Paranoid Android (like
Unsanity's other Haxies) uses; my take is that you can either
follow John Gruber's advice on his Daring Fireball for eliminating
the need for Paranoid Android or consider it a temporary solution
until Apple releases a fix. John recommends using Rubicode's
RCDefaultApp utility to disable potentially dangerous default
URL handlers. Others have also recommended using Objective
Development's Little Snitch to alert you to potentially harmful
network behavior.
<http://daringfireball.net/2004/05/help_viewer_security_update/>
<http://www.rubicode.com/Software/RCDefaultApp/>
<http://www.obdev.at/products/littlesnitch/>
It's worth keeping in mind that any action you take with your
computer is potentially unsafe; a bug in a totally legitimate
program could cause as much havoc as malicious software. Although
there's no reason to become entirely paranoid, we recommend that
you exercise reasonable caution when evaluating the sources of
files you download and links you click. And the most important
thing to remember is that regular backups that maintain multiple
versions of changed files will help you recover from almost any
disaster with minimal effort.
Lastly, although Apple is undoubtedly aware of the seriousness of
the situation, it's still a test by fire. After a somewhat rocky
start, Apple's security group seems to have done a good job of
dealing with the relatively minor exploits so far, most of which
revolved around the Unix tools bundled with Mac OS X. This,
however, is a new thing, a Mac OS X-specific vulnerability that
exists purely because of Apple's design decisions. More concerning
is that it wasn't discovered inside Apple and fixed before anyone
had a chance to discover it. That implies that Apple's security
group may be more reactive than proactive; I would have hoped that
at least part of the job description of the security team would be
to probe constantly at Mac OS X and Apple's bundled applications
for potential vulnerabilities.
Explaining the URL-Based Mac OS X Vulnerability
-----------------------------------------------
by Matt Neuburg <[EMAIL PROTECTED]>
Exactly what is it about Mac OS X that is responsible for the
security vulnerability currently being discussed? The situation
is a little confusing, and I may be muddling some of the details,
but here's my current understanding of the situation.
As you know, when you double-click a document in the Finder,
the application that "owns" that document starts up and opens
the document. For example, if you double-click a Word document,
Word starts up. This requires that your computer have a notion
of "types of document," and that it draw an ownership association
between a particular document type and a particular application.
Before Mac OS X, this association was performed by means of
four-letter creator codes hidden in the meta-information for
a file (the "desktop database"). But on Mac OS X, it's done
in a new way, by a part of the system called Launch Services.
Apple documents the entire situation on this page of the developer
documentation about Launch Services.
<http://developer.apple.com/documentation/Carbon/Conceptual/
LaunchServicesConcepts/LSCConcepts/chapter_2_section_4.html>
Here's what to notice about what that Web page is saying. In
addition to the old system of four-letter codes, Apple, in an
attempt to improve cross-platform compatibility, added to the mix
the notion of the file extension, a several-character code at the
end of every filename that provides the clue as to what sort of
document the file is. At the same time, Apple also introduced yet
a third way of signifying a "document" type, namely by means of a
URL scheme. An application can specify that it responds to certain
schemes; it is then eligible to be messaged by the system when
such a scheme is encountered.
I don't quite know why Apple did this. 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.
There are various ways in which the system can become aware of
an application, and of the fact that an application can respond
to a scheme. As noted in the first paragraph of that document,
this does _not_ require that you launch the application; merely
copying the file to your hard disk is sufficient. This seems
like a sensible design decision, because after all, when you
first receive a new application (Microsoft Word, for instance),
you would not want there to be an arcane rule that says you must
first open Word itself for the operating system to know what to
do with the various .doc files included with the installation.
You would prefer the user to be able to double-click a .doc file
in the Finder and have Word open the file, even though Word has
never run before on this machine.
So far, so good. But now, keeping all of that in mind, consider
what happens when you're browsing the Web in Safari and you click
on a link. For example, when you click a mailto URL in a Web page,
something needs to happen. Therefore, something needs to associate
the mailto URL scheme with your default email client. Way back
in the bad old days, Apple had no solution to this problem. But
eventually a third-party solution called Internet Config appeared,
and Apple later adopted it and built it into the Mac OS.
<http://db.tidbits.com/getbits.acgi?tbart=01718>
But a moment ago, you may recall, I said that any application can
now simply declare that it "owns" a certain URL scheme, just as
it can claim to "own" a certain document type. That point is
reinforced by this page from Apple's developer documentation.
<http://developer.apple.com/documentation/Carbon/Conceptual/
LaunchServicesConcepts/LSCIntro/chapter_1_section_1.html>
In other words, Apple has folded together in Mac OS X's Launch
Services two very different mechanisms from the classic Mac OS:
the Desktop Manager (which pairs documents with applications) and
Internet Config (which pairs URL schemes with applications). All
of that sounds reasonable enough, since in both cases we are using
something (a document or a URL scheme) to launch an application,
but the two notions are arguably not parallel. One does not expect
the set of URL schemes to be infinitely extensible. It's one thing
to click on an email address that's a mailto link and have Mail
open; it's another to click on a link and have Help Viewer open,
or to have Script Editor open, or to have a hidden application
you've never heard of download and mount a disk image.
The upshot, if I'm an evildoer, is that if I can get you to
download my evil application and make Mac OS X aware of it, then
I may be able to get you, through a mere Web page, to send that
application a message that causes it to launch and do its evil
deed. My malicious application declares to the system that it
responds to the "evil://" URL scheme, so if I can get you to click
on an "evil://" link, my application will launch. Furthermore,
as Adam explains in his article elsewhere in this issue, the real
trickery comes about if I can manage to deliver a one-two punch
without your realizing what has happened. Using a page containing
a redirect or even frames, I can effectively make your browser
visit two URLs one after the other: the first uses a technique
like the disk URL scheme to download the application to your hard
disk and to make the operating system aware of it, the second uses
my "evil://" protocol to cause Mac OS X to launch it.
If the overall thrust of the above discussion is right, then the
problem we're facing is rather deep-seated. Part of the trouble,
of course, is that URL schemes (such as disk) can cause an
application to appear on your machine before you know what is
happening; but another part of the trouble is that a mere URL
in a Web browser can be sufficient to launch that application.
Therefore it is impossible to defend against this mode of attack
merely by defeating certain individual schemes, because the number
of possible schemes is infinite. That's why Unsanity's Paranoid
Android is an effective patch: it warns the user about all
unknown schemes that might have been registered by a malicious
application, rather than focusing on any known schemes. But if
I'm right in suggesting that the root of the trouble is the
folding of Internet Config's functionality into Launch Services,
then plugging this hole completely might require Apple to adjust
the architecture of Mac OS X at a level so fundamental that doing
so could break some capability to which we've become accustomed.
<http://www.unsanity.com/haxies/pa/>
Hot Topics in TidBITS Talk/24-May-04
------------------------------------
by TidBITS Staff <[EMAIL PROTECTED]>
The second URL below each thread description points to the
discussion on our Web Crossing server, which will be much
faster, though it doesn't yet use our preferred design.
<http://emperor.tidbits.com/TidBITS/Talk/>
**Mac Browser Security Hole** -- Readers discuss the reality of
the recently reported Mac OS X security hole and what should
be done about it. (4 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2233>
<http://emperor.tidbits.com/TidBITS/Talk/99/>
**New AppleScript Trojan Horse** -- Does fault lie with the person
who writes a Trojan horse, or with the outlets that publicize
the fact and thereby encourage others to do so? (8 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2236>
<http://emperor.tidbits.com/TidBITS/Talk/98/>
**Thoughts about WriteRight** -- Readers contribute their ideas
and opinions about an ideal Mac word processor. (31 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2235>
<http://emperor.tidbits.com/TidBITS/Talk/101/>
**Discussing Mellel** -- Tune in on a conversation about Mellel
between Adam and the CEO of the company that makes the word
processor. (5 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2237>
<http://emperor.tidbits.com/TidBITS/Talk/102/>
**Problems with Disc Labeling** -- After we wrote about the
release of disclabel 2.0, a reader points out the problems
that applying disc labels to CDs and DVDs can cause.
(4 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2234>
<http://emperor.tidbits.com/TidBITS/Talk/100/>
$$
Non-profit, non-commercial publications may reprint articles if
full credit is given. Others please contact us. We don't guarantee
accuracy of articles. Caveat lector. Publication, product, and
company names may be registered trademarks of their companies.
For information: how to subscribe, where to find back issues,
and more, see <http://www.tidbits.com/>. TidBITS ISSN 1090-7017.
Send comments and editorial submissions to: <[EMAIL PROTECTED]>
Back issues available at: <http://www.tidbits.com/tb-issues/>
And: <ftp://ftp.tidbits.com/issues/>
Full text searching available at: <http://www.tidbits.com/search/>
-------------------------------------------------------------------
