Having been a “pro-level” user of the OS since System 6 and a developer since 8.5, I’ve paid close attention to the help technologies in the OS as they came and went. Some were pure genius, others not so much. When I look back on the many, many ways Apple’s provided help to the user over the years, I can easily see how this recent help attack issue came to be and why no one paid much attention to it until someone realized it could be used for ill. It’s been used for so many things that were constructive that few, if any, ever thought about using it destructively.
So, to see how and why this could have made it out the door, let’s look at Apple’s help technologies over the past ten years or so.h2. Macintosh Guide
Well before there was any real system-level help there was a Macintosh Guide HyperCard stack at the root of all new computers’ hard drives. This gave you a short and pixelated introduction to the Mac way of computing. It was very well done for the time, first teaching the user how to use the mouse, and then pointing at all the parts of the screen and describing them. Really, it was very useful for the newcomer. Unfortunately, after that there was no more help within the system. All other topics were either in the program’s help (if it had it, and few did) or in the manual (which was made of a material we call paper and bound with little metal wires in an interesting spiral shape).
Balloons
!(right)/myimages/balloon-menu.gif 150×70!
Apple’s system-level help really started with Balloon Help in System 7 (1992). This feature resembled very large and absurdly quick tooltips. Turn on Balloon Help, mouse over something, and then you get a (sometimes long) explanation of what it did (as opposed to the one or two words on a tooltip). It was so annoying that you had to toggle it on and off … and you wanted it off, mostly. The few times I remember wanting the feature on were the first time I installed System 7 and then to view the “easter egg” tip on the QuickTime extension:
time n. A nonspatial continuum in which events occur in apparently irreversible succession from the past to the present to the future.
!(left)/myimages/balloon-help.gif 227×168!
The thing about Balloon Help was that people started to see that they could integrate assistance with the actual user interface element and, thus, let the user learn about the program from within the program. This led to people putting very large amounts of text in the balloon rather than just going over what the item is. In some cases, it was treated with the same copy the manual would have for that icon or menu item. This led to it becoming a bit more than was intended for some programs. What they needed was an electronic manual.
Of course, like all things Mac, Windows copied it five years later, found a way to make it more annoying, and then made it more obvious.
!/myimages/windows-balloon.gif 231×201 (windows-balloon)!
Guides
Around Mac OS 7.5 Apple came out with Apple Guide. Apple Guide had a significant advantage over Balloon Help as a help system (though it was not designed as the electronic manual it was used for) in that it allowed for a per-application comprehensive help system (complete with contents, glossary, and index). In short, it was where you went with your questions, be they “How do I …” or “What is …” or whatever else.
!/myimages/apple-guide.gif 480×336!
The programmer was required to learn an HTML-like language called Guide Script that would define sections and link them to questions or glossary entries. When compiled, a binary Apple Guide file was created and all the developer did was drop it in the same folder as the program.
Apple Guide was a major step forward in user assistance as a developer could basically create a very large FAQ list and turn it into a help file. Apple Guide alone led to the demise of more than one paper manual. However, above and beyond even these features, it was significant because of two more features:
- It could show users where the user interface element was that was needed to complete the task.
- It could optionally do it for them, using AppleScript.
!/myimages/apple-guide-marker.gif 403×240!
Guide Script had a way of locating specific user interface elements and the author could cause Apple Guide to circle or point to the elements on-screen as they were talked about. It was even smart enough to know if the proper preference window wasn’t open. If that was the case, then you could click on the “Do it for me” button and it would run an embedded AppleScript that would tell the program to open the proper window and get into place so that it could circle the right item. It was a borderline tutor.
Help Viewer
Apple Guide lives on for the users of Mac OS 8.1 and below as the primary means of getting support for their computers. When Mac OS 8.5 came out Apple included a Help Viewer program to replace Apple Guide. Instead of Guide Script, Help Viewer used HTML pages and a very limited HTML viewer to display them. The idea was that people could take help content already in HTML and then just convert it over to Help Viewer. Also, using Sherlock’s Content Indexing, Help Viewer could perform a content-based search of its database rather than relying on the help author to manually link questions, answers, and glossary items together.
Help Viewer could also perform tasks for the user, if needed, by running an AppleScript. The problem was that Apple Guide embedded the script in a data file, and it knew it could handle AppleScript. Help Viewer was more standards-based in that it was using HTML and URLs and so on to make its content. It even had it’s own registered protocol called help so that you could link to individual help pages. So to run an AppleScript for the user in something other than a binary database the help protocol was expanded to include the RunScript command which would run scripts from within the help file folders. Now Help Viewer was almost 100% feature-equivalent to Apple Guide (though I still miss the little red markers…).
Carbonization
After Mac OS 9 came Mac OS X 10.0, a disaster of epic proportions. As a part of this glacier of an operating system Apple carbonized Help Viewer into Help Viewer.app. It’s not the same beast we have in Panther by any means, but it was the start. Part of that port, of course, was it handling the help protocol and, yes, the RunScript command as well.
Time passed and then Apple announced they had adopted a real HTML rendering library (KHTML) and would include it as a part of the operating system (WebCore) with Safari as the consumer browser using it. Now that the system had a real web display system, Help Viewer was updated in Panther to use it instead of the limited HTML rendering library it inherited from Mac OS 9’s Help Viewer. With it came the assignment of the help protocol and the RunScript command.
Holy Security Oversight, Batman!
So, now we have a problem. The Mac help system has used AppleScripts to perform much of its assistant-like tasks since System 7.5 and retained that all the way to Panther. In theory, the system is closed and the help protocol only used within the Help Viewer program. However, since the help protocol is registered with the system URL handler, any program at all, even Mail, could call it. And there we have the issue at hand. This issue, actually, has been in the operating system since Help Viewer was introduced in 8.5, but it’s only with the possibility of knowing the exact path to a file after download (auto-mounting disk images) that this has become a real threat.
The fix is easy enough: Help Viewer should simply disallow any program but Help Viewer from using the RunScript directive. On that note, we await the update that will do that (or something else Apple cooks up).
thank you very much for explaining this.
finally i know how this was made possible.
Yes I agree with lixlpixel, thanks for explaining this when most other sites are clamoring about how Apple is trying to dodge this issue. I guess Apple and Apple users never really try to make destructive programs. Sure there have been a few exceptions, but that was over 10 years ago. Looks like the hackers who do this can now afford a Mac. Good thing they don’t know a whole lot about Unix….. yet.
Today Apple released a security update for Help Viewer that ought to fix the RunScript problem. That’s not too bad of a turnaround on the problem.
You’re on the front page of apple.slashdot.org. I hope you too your vitamins this morning!
Thanks for an informative explanation.
This is part of a bigger problem. The URI passing scheme has
no notion of trust: no way to distinguish between scary
unvalidated data and clean data, and no way to distinguish
between hardened paranoid applications and soft chewy naive
applications.
URI handlers should tell the URI registry whether they’re willing
to handle untrustworthy data. Programs like Safari and
RealPlayer should say “yes”. Programs like Help Viewer and
Terminal should say “no”. The default should be “no”.
Programs that invoke URI handlers should flag the passed data
as trustworthy or untrustworthy, a la IE’s security zones, or
Java’s sandbox. The default should be “untrustworthy”, at least
for data from the web!
The system should not allow untrustworthy data to be passed to
an application which isn’t prepared to handle it. The other three
combinations should be allowed: clean data to a naive app, dirty
data to a paranoid app, and clean data to a paranoid app are all
acceptable.
This is no magic bullet, obviously, but it would establish a
sensible framework to address this class of problems.
It’s not the operating system’s problem, it’s the application’s. If the application is stupid enough to accept data that’s untrustworthy then so be it, as far as the OS is concerned. That is not the problem of the program running the program (which is all an OS should be).
The designers of programs that handle external data needs to be improved. If you allow for a URI scheme to get data, verify it as you would human input, or text files, or STDIN. If you’re not verifying, or at least rendering harmless, all data a user creates then you’re not programming correctly.
your image server has apparently died from being slashdotted
Images loading fine here. Page is a tad slow now and again, of course. This thing’s getting spread like butter …
I would say that the correct fix is for only Help Viewer to be able to use help: URI’s. Why would any other program even want to try and load these – especially if someone other than the user can instruct the program to. The runscript directive isn’t the real problem – it just makes it the issue soo much sweeter.
“It’s not the operating system’s problem, it’s the application’s.” …
Actually in this case, it is the OS’s problem. There’s another component to this not discussed here; LaunchServices and its automatic registration of URL handlers for untrusted applications.
All I have to do is write an app capable of handling, say, the “evil:” URL scheme, and LaunchServices makes a note of that and will hand off evil: URLs to my evil application.
I can program my evil application quite “correctly” to handle untrusted data in a very destructive way, without being at all remotely stupid. Just evil!
The operating system should monitor the boundary between the so-called “trusted zones” and “untrusted zones” and exercise some sort of user-interactive caution before allowing any application to move from one zone to another. The Paranoid Android is slapdash, but serves this gatekeeper role in a fundamental way quite nicely.
Basically, the old Internet control panel needs to make a comeback, this time with options to specify not only how known URLs should be handled, but how unknown URLs should be handled, embedding a mechanism similar to the Android’s.
deet: Actually, it’s not a fault of Launch Services, it’s a fault of the
disk:URI handler. There’s another article coming out that will explain this for those of you that have read all the false speculation about this. Hopefully it will clear things up.