Linux Today: Linux News On Internet Time.

More on LinuxToday

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

May 05, 2000, 23:14 (29 Talkback[s])
(Other stories by Alastair Mayer)

WEBINAR: On-Demand

No-Size-Fits-All! An Application-Down Approach for Your Cloud Transformation REGISTER >

[ 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 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.)


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.

Alastair Mayer has been in the software development field for over twenty years. His best claim to fame is his authorship of the computer conferencing system CoSy, used as the basis for BIX (BYTE Information eXchange) and similar systems in the pre-Web days. Since then he's been primarily involved with large in-house projects for a variety of companies, and currently lives near Denver where he occasionally finds time to work on free software between doing contract work and helping his wife look after their daughter and twin toddler sons. His personal home page is

Related Stories: