Playing in the Sandbox: How Linux can continue to avoid ILOVEYOU-type attacks

[ The opinions expressed by authors on Linux Today are their
own. They speak only for themselves and not for Linux Today.
]

By Alastair JW Mayer
(AJWM)

In the wake of the recent (and as I write this, ongoing) wave of
ILOVEYOU, Joke, and Mother’s Day e-mail virus/worm attacks sweeping
Windows sites on the internet, many Linux/Unix users are sitting
back with smug expressions because “it couldn’t happen to them”
(and in some cases “that’s what you get for running Microsoft
software”).

But it can happen. Indeed, the infamous Morris Internet Worm of
the late 1980s did happen, although granted that was a sendmail
exploit and not an executable content attack. A few voices have
been warning that yes, anything that runs downloaded or emailed
content (ie, attached scripts) could potentially do the
same on a Unix or Linux system, and the danger will rise as they
become more prevalent on the desktop.

To be sure, on a properly configured system, the only
files that might be damaged are the user’s. That’s small
consolation to the user, and the recent apache.org crack (described here)
shows that even the best can sometimes leave configuration holes.
And it doesn’t address the potential swamping of email systems and
mail spools by the explosive propagation of messages. (Even a
nuclear reaction only produces two free neutrons for every atom
split; with Melissa we were seeing up to 50 new messages for each
one read, and the Love Bug targeted the full address book.)

The Attack

The basic attack path that Mellisa and Love Bug used is to take
advantage of features of Visual Basic scripting that’s built into
Microsoft Office applications like Outlook, Word, etc. This
facility gives users of these apps the ability to automate all
sorts of things, giving access to most of the functions of these
apps plus most of the functions of the Windows operating system.
Including a malicious VBS script in an e-mail along with some
innocuous message to entice a user to execute it — with a simple
mouse click — starts the trouble.

“But Linux doesn’t support Visual Basic”, you protest.
Quite true — although StarOffice does include something similar.
But more to the point, Linux (and *BSD and other unixen) support
shell scripts, and Perl, and Python, and TCL, and a host of other
scripting languages, any of which is easily as powerful as, or more
so, than Visual Basic Script. Right now, as far as I know, no email
or browser client for Linux etc supports one-click
execution of an attached script. But that could very easily change
with the rush to produce more and better desktop applications and
suites. And that could leave a Melissa or Love Bug just waiting to
happen to Linux.

The Defense

Fortunately, some very smart people have already given a fair bit
of thought into protecting systems from executable downloaded
content. The Java promise of “write once, run anywhere” programs
that can run in your browser is a clear invitation for crackers to
have their way with your machine by linking to a malicious applet
in an attractive web page. But the Java folks at Sun also came up
with a defense against this, the “applet sandbox”. Without going
into too much detail here, any Java program running as an applet
(ie started from within a browser or applet runner, rather
than as a main) has severe limits placed on it by the Java Virtual
Machine (the Java bytecode interpreter, if you will). It can’t
write any files locally, it can’t read any files locally (without
some prior arrangement), and so on. (It can read and write back to
the internet host it was download from.) In some sense this is
similar to running programs in a restricted shell, which somewhat
restricts your actions.

Restricted Scripts

Applying this concept to the various popular Linux scripting
languages would require adding some sort of “restricted mode” to
the language interpreters, such as perl, tcl, python, and so on.
When running in such a restricted mode, the interpreter would limit
how the script could access files, beyond the limitations imposed
by filesystem security. (After all, filesystem security would
normally already prevent a user-level script from touching any file
that the user had no permission to access, but it wouldn’t prevent
it from, say, deleting all that user’s files.) Totally eliminating
any read, write or execution of another file would certainly be
safe, but it wouldn’t be particularly useful,
either.

One possibility might be to create a playpen or sandbox
directory — call it “.sandbox” — in the user’s home directory and
have any untrusted script run in that directory, while imposing the
restriction that no files above that are touchable (in effect,
.sandbox becomes a virtual root directory as far as that script is
concerned, this is something like what “chroot” does.) More
elaborate protection schemes and sandboxes can no doubt be thought
of, my main point is that they do need to be thought of, and
implemented. (I’d also warn against making any scheme too
complicated — that way lies unforseen security holes.)

Conclusion

Linux and Unix are, for now, relatively safe from these sorts of
attacks. Part of that is due to Linux’s relatively low profile
compared to Windows (go for the bigger target if you want to make a
splash), especially on the destop, partly it’s due to Unix’s
inherently more secure design than Windows (the latter is what’s
known as a “soft target”). Extending desktop applications, browsers
and e-mail clients to simplify the running of executable content
will reduce that inherent security, at least for the user
concerned, unless developers consider now what sorts of
protections to build in to such extensions. Let’s not repeat
Microsoft’s mistakes.