Blame the UI: Why Linux is Not Immune to ILOVEYOU-style Worms
 by Joe Pranevich, in Editorials - Sat, Jun 10th 2000 23:59 UTC

It's easy for Free Software users to laugh at the misfortunes of their Windows-using colleagues as they suffer through the virus du jour, but if you can set your superiority complex aside for a moment, can you point to anything in Melissa/ILOVEYOU/etc. that couldn't be accomplished by a badly-written MUA running on Linux? In today's editorial, Joe Pranevich urges the programming community to learn from Outlook's mistakes if they want to continue having the last laugh.

And the users exclaimed with a laugh and a taunt:
It's just what we asked for but not what we want.

-- Unknown (Well, someone probably knows.)

These days, it seems as if everyone likes a good "Microsoft is Evil" story. I'm not going to agree or disagree with that statement in general, but this recent (and continuing) wave of email worms has given the media and the users plenty of room to criticize. Largely, these complaints have revolved around a general lack of security in Microsoft's products -- a historical truth. Adding to this anti-Microsoft inferno does not improve Linux as a whole and I believe that our time is better spent working towards ensuring that these kinds of attacks can never happen on Linux.

Linux's Security Model

The Linux kernel has an excellent reputation for security-conscious computing. Security bugs, when found, are squashed exceedingly quickly. Linux's low-level security is based on the classic UNIX model of users and groups. In brief, this ensures that one user can never harm another user's files or any system files without explicit permission. Additionally, Linux ensures that no user is capable of denying service to any other user through crashing the machine, resource depletion, or a number of other more subtle approaches. There is currently work being performed to add a "capabilities" system to the kernel to make it even more fine-tunable. This model is good and very powerful, but it does not and cannot protect the user's own files from himself or application stupidity.

The security bugs currently being seen in Microsoft Outlook are of the latter variety: application stupidity. One does not necessarily need to be running under a Windows environment to write or use stupid applications. In fact, nearly all security problems discovered on Linux systems are caused by application programmer mistakes. The Linux kernel's excellent security helps to minimize problems caused by these mistakes (through its low-level security policies) but will never be a substitute for smart application programming and a peer review process. (In fact, some patches to the Linux kernel have actually been rejected because they provided a false sense of security despite making certain kinds of attacks harder to pull off.)

Of particular concern are either programs that are regularly granted administrative rights (such as an X Server) or programs that deal with untrusted data (such as your Web browser or email client). As Linux does not have any internal conception of "trusted" vs. "untrusted" data, application programmers must be fairly smart about it. Microsoft's Web browser manages to deal with this dilemma at a high level, but obviously wasn't ingrained enough to uniformly combat the problem. On the Linux side, it will be up to the GNOME and KDE development teams to make sure they deal with this issue, as they will be Linux's flag-bearers into the future.

The Interface's the Thing

It's very tempting to leave the problem at that. "It's a high-level issue caused by the march of progress into the point-and-click world of modern GUIs." Pine users will complain, of course. The idea that one should blindly migrate from one time-tested UI model (the relatively dumb world of Linux mail readers today) into the more complicated point-and-click world seems absurd to many people. The recent events with Outlook work to further underscore that there may be fundamental defects in the way modern GUIs view the world.

The underlying metaphors of today's most common GUIs are relatively similar. Although each OS provides a different view into the world, the fundamental building block remains the same: the mouse click. Click once to select. Click twice to open. Even when Microsoft attempted to Webify the desktop with one-click activation, it didn't change the problem, only changed the number of clicks necessary to activate it.

The fundamental problem with this system is that it's association based. When you activate a file icon (Using the generic verb "open" under Windows), you are performing the action associated with the file-type that you are dealing with. With HTML files, this is often opening a Web browser. With an MP3, you open a player. This tends to work out very well; with any type of document, open the viewer associated with that document type. But notice the key assumption there: It is generally implied that when you activate a file that you don't recognize, you'll get a viewer that shows you what it is. There's an underlying (and incorrect) assumption that viewing a file is a read-only operation. With executable files (such as scripts), "open"-ing can be a dangerous and deadly thing!

The Document Model

Resolving the danger isn't something that can be done at a low level. I believe that the "association" model is the real culprit in Microsoft's recent problems, not Outlook. Users are clicking on the file (which appears to them to be a text file thanks to its misleading name) and getting exactly what they requested: executable activation. Some have pointed their fingers at the "security faults" in Microsoft's VisualBasic scripting language, but one could easily imagine a situation in which the same damage could be inflicted with a Perl script or any other common scripting language. Having a powerful language for script writing is an asset to any OS, not a detriment. Should we ignore all the positive nail-driving features of a hammer just because you could mistakenly smash your fingers?

As a replacement for the association model, I would like to propose evaluating a "document" model instead. 90% or more of the work done by ordinary users involves documents. By "documents", I mean the HTML files and the MP3s of the previous example; essentially anything that you would imagine could be "viewed" in the present model. Instead of clicking on an application when you want to start a new word processing document, you could click on a zero-byte read-only file of the appropriate type -- essentially a template. Most users may never know the difference. Instead of executing an application when it is viewed, it makes much more sense to display it in a text or hex viewing program. It should still be possible to execute an old application with the mouse (put it on the right-click menu, for example), but that action does not belong as a default.

Unfortunately, most applications were not designed with this type of thing in mind. I have serious doubts that the Linux desktop applications of today could work this way without some tweaking. There are likely to be conceptual stumbling blocks as well. I should also say that I'm not a UI expert; there are quite likely better ways to view the world. I have decided to share this thought for the purposes of discussion. There may be other, better, ways to accomplish the same thing. Please feel free to respond to me in email or (preferably) use the feedback section of this site. I'd especially like to hear thoughts from current GNOME and KDE developers because you are the ones leading the charge into our future as a community.

Together, I hope, we can learn from Microsoft's mistakes.

Joe Pranevich, a "Linux Writing Person" on the side for the past 2 years, currently works in Ops for a large search portal. He occasionally dabbles in programming but lately has been writing far too much. He can be emailed at jpranevich@linuxtoday.com (@ Home) or jpranevich@lycos.com (@ Work). If you insist, you can visit his homepage at http://jpranevich.tripod.com/, but ignore the bad picture.

T-Shirts and Fame!

We're eager to find people interested in writing editorials on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an editorial gets a freshmeat t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

[Comments are disabled]

Referenced categories Topic :: Security

 Comments

[»] Linux is not as vulnerable. Microsoft's objective was internet monopoly.
by David Pace - Jun 12th 2000 15:01:47

...and their use of attachments, that require Microsoft executables, was their main way of targeting internet dominance. If they succeed at establishing Word-format attachments and VisualBasic attachments and other attachments as the main way of communicating on the internet then they can control the standard data formats by withholding specs and forever changing the standards. This would also require the dominant operating system to be MSWindows because no other operating system would be able to execute the attachments as reliably as Microsoft systems. Proof #1: How often do recruiters require your resume in MSWord-format attachment instead of an HTML document? Can Netscape produce a nice word-processing document with complete spell checking and complex formatting? Yes, in HTML. Can it do it in MSWord-format? No. So, you better buy MSWord and MSWindows. Proof #2: Why did the Melissa virus not prompt Microsoft to produce an OFF switch in Outlook. Answer: Because turning off attachments would foil the grand plan to dominate internet communication with Microsoft attachments. So the delayed decision (delayed until ILOVEYOU) was because the embarrasment of the virus was too great and giving up the executable-attachment strategy was difficult. Eventually they gave in and produced the OFF switch.

[reply] [top]

[»] the user factor
by michael bartlett - Jun 11th 2000 07:40:04

lets not forget this! i am pretty much forced to run nt in my office environment (refer back to a previous post about the lack of office workgroup tools such as exchange:outlook which open source still neglects!). at 8:20am on ILOVEYOU day, i sent a mail to all users in the office to NOT open any email with the subject ILOUVEYOU in it.
sure enough, 10 minutes later my email box received 6 mails from one of the lusers in the office with *suprise.suprise* ILOVEYOU in the subject. i had to physically run to every desktop in the office and make sure that everyone else on the network who received mails from this particular luser didn't open them. fortunately most people in the office are developers and only one desktop (the original lusers') was infected.

now linux usage is characterised by more expert users who understand the difference between what may or may not be an untrusted script. as linux moves deeper into a mainstream environment and *IF* linux developers start focusing on the luser (which it really should start doing outside of the standard desktop installation) then we do indeed face the possibility of exploitation. we could be even more at threat than windows users as small open source projects are not always as rigoursly managed as windows and large open source projects. i believe that office productivity software which will be the gateway to luser virus infections need to be closely planned and managed by our bigger developers such as valinux and the boys at redhat and K.

[reply] [top]

[»] Security is always the opposite of users laziness
by salek - Jun 11th 2000 04:17:17

The problem with security is, that the user can't be lazy in any way. And admins often nows that users aren't happy when they are forced to change their passwords on a regular basis (because they have to remember the new password), and using really secure passwords is another thing, too. This makes introducing a new security scheme to the desktop a problem, since security needs not only the users intelligence, but his/hers understanding of why there needs security and why this means to abandon a good part of luxurity. So the question is, at least in my point of view, if there can be any security model that satisfies users wishes, or if it would be the best to prevent users from certain actions by simply disallowing them. Lets have an example: An user opens a page containg a huge java application that needs to access system resources. Javas security model is, when I'm not mistaken, based on the concept that such apps/applets are disallowed to access them. In such cases a window is opened, displaying a message "...needs access to..." or something like that, giving the user the oportunity to grant or deny this privileges. But if the page say "Simply grant all access...", what will the user do? At least this would be a possibility: To grant untrusted files certain privileges, and to deny others. Using mimetypes would be another choice, but I don't know if this is the best in general, since it is focused on just a few actions. I would tend to a fine-grained kernel based security model, too. Let's say with installing a package out of a distro the install-scripts maintained by the package maintainer registers the application at a demon or any other instance, defining rules of what this app is allowed to do. For mail-apps this could be accessing the users mailfile /var/spool/mail/$LOGNAME and a directory where several mail-directories reside, for example ~/Mail/. If any incoming mail would contain a desctructive script, this script would try to access system relevant files, such as /etc/passwd or would try to run an exploit. But it would definetly break the rules defined for the application that originally launched the script. Additionally, I wouldn't focus on extensions, since they can be (as some others said before) misleading and wrong. Why not implement file as a function, scanning any attachments before they are processed? Authors of mail readers (etc...) can define a set of files that are allowed to be processed, maybe mailcap-based. This list might be redefined by the SysAdmins, too. But only with another security model behind.

[reply] [top]

[»] Microsoft has had plenty of warnings
by djand - Jun 11th 2000 00:13:08

Yes, I know for sure that microsoft chose the path that led them to create products with wide open security holes. How do I know? A microsoft mid level employee told me so. Their ( the employee ) contention was that MS knew what their main core of users wanted and needed. That concerns about security and stability only effected the top 5%; what he called their "power users". According to him, the rest of the MS users were only concerned with more and more features.

Many people that are gloating now are not ignorant of the possibility that something similar could happen on Linux/FreeBSD/Mac or other platforms, they are happy that something seems to finally be forcing MS to really address these issues. Now I have heard the same message in MS press releases and trade journal articles for years, so I don't think it was really unique to the fellow I exchanged ideas with. He said that after they had the important features integrated, that then they would return to shore up some of the stability and security concerns.

My point with this post is simply that MS left the security doors wide open for quite a long time. The "melissa" trojan/virus of a year ago didn't really change their focus. Sure, this type of attack could work on almost any operating system if the operator is willing or ignorant enough to subject the system to dangerous behaviour.

A long running joke/pseudo-virus was the "Good Times" email (use a good search engine if you don't understand). I first saw this over ten years ago in BBS/Fido mail and have seen it make several rounds via the internet. The joke at that time was that the simple act of reading an email couldn't destroy your computer. Now, thanks to the marvelous 'innovations' of MS, it is possible.

The most frustrating part is that many people have warned MS and tried to promote change in their approach to making products and have had almost no success. Until now, maybe they will change approaches. They have a pretty unstable foundation to launch from now though.

[reply] [top]

[»] good ideas but....
by topaz - Jun 10th 2000 22:51:09

First, I'd like to point out that the author's main premise is a little off-base. Yes, it is true a user program under Linux can be just as painful as one under Windows. But one reason people use Linux is that there are few horribly written programs - when was the last time you saw a Linux MUA that would unconditionally run a script attachment as the current uid? Pine certainly doesn't run shell scripts that come by mail by default.

The author also mentions document-based UIs. I totally agree that a well-designed DBUI (to coin a new acronym) can be a total joy to use - I am writing this on StarOffice for Windows, using the IE plugin (they say Mozilla will be available soon...) Anyway, I can do all sorts of crazy stuff, like embed a Web page in a StarWrite document, or create a drawing and decide it really should be a spreadsheet and convert it with a click. Why is it that nobody is using DBUIs? Because there aren't any GAMES! It's very hard to think of a way entertainment would fit into StarOffice's interface, and since games (not including Solitaire) are something like half of all computer usage, few pure DBUIs have been much of a success. That's my personal explanation.

Ciao, Dan

P.S.: We really could use an MTA that filters out VB scripts around here. Does one exist?

[reply] [top]

[»] ./configure; make all; su root; make install... untar backups...
by the grugq - Jun 10th 2000 21:40:11

The major point that seems to have been missed (or possibly not known about) is that virus' are popular on Window9x and DOS because there is so little else that can be done with those OSes. With a Unix box, far more is possible, because there is just more power to be used. Of far greater importance than deleting someone's files is getting root shell access. Of course everyone is familiar with using an exploit to gain remote access to a box, blah blah blah, but not everyone is aware of another approach, "application based social engineering" (newly coined term, perhaps a better one exists?). People seem to trust implicitly everything that they have to "./configure".

Were I an evil hacker with intentions of gaining a large number of shell accounts, I would use Freshmeat. It has a large ammount of traffic and I am likely to get a huge cross section of Unix users (including coveted Cable modem and DSL users :), so that would clearly be the prefered route of infection.

I write "vi-rus", a neato app that does something innocous (maybe draw ascii pr0n). I can expect most people to install it as root (all I need to do is put that in the README), I have it email me `uname -a; ifconfig -a; ifconfig; netstat -a`, append a new line into /etc/passwd (and possibly /etc/shadow), and next thing you know, a ton of shell accounts. Very simple to perform, possibly a couple days of coding (I still need a real app for "cover")

It might be days before it is noticed that this isn't a legit app. The people at Frshmeat would remove it, everyone would pat themselves on the back for their quick reaction time, and I would keep my root shells :) Everyone is happy (well, almost everyone ;).

But, there are other attack methods with Linux that require less coding (i.e. "shorter time to market"). My tarball could contain a symlink to /etc/passwd, and then overwrite that file during the untaring proccess (see Mixter's site for a proof of concept). I could just have the Makefile "rm -rf $HOME 2>1& >/dev/null ", I could put that in the configure script, I could have my perl script application do that on the first run. All these attacks require someone to trust that the package isn't malicious. As they say in the military: "its a target rich environment". These attacks don't even start to explore the .rpm or .deb package formats (mostly because I don't know about them).

Finally, there do exist several Unix viruses, Silvio Cesare is the world's leading expert (I would assume :). Indeed numerous means of infecting ELF binaries exist (PLT redirection, DATA pad byte over writeing, etc.) it is foolish to think that Linux will save you from viruses.

There are now way too many home users running Linux who think they are secure from viruses, but have no idea what other horrors await them :)

Think twice before you su root and type "make install".

[reply] [top]

[»] Re: ./configure; make all; su root; make install... untar backups...
by GuruBonz - Mar 17th 2001 01:49:22


> I write "vi-rus", a neato app that
> does something innocous (maybe draw
> ascii pr0n).
> I can expect most people to install it
> as root (all I need to do is put that in
> the README),
> I have it email me `uname -a; ifconfig
> -a; ifconfig; netstat -a`, append a new
> line into
> /etc/passwd (and possibly
> /etc/shadow), and next thing you know, a
> ton of shell accounts.
> Very simple to perform, possibly a
> couple days of coding (I still need a
> real app for "cover")
>
> It might be days before it is noticed
> that this isn't a legit app. The people
> at Frshmeat
> would remove it, everyone would pat
> themselves on the back for their quick
> reaction time,
> and I would keep my root shells :)
> Everyone is happy (well, almost everyone
> ;). Nice idea except for a couple of major flaws :)
Flaw number one The only thing I do as root when installing a package is make install.

Flaw number two. I have a router which I never install new software on. It has a real ip, but all my developmental machines are masqueraded through this box making direct access from outside my LAN impossible :)

Flaw number three. How many unix users have /etc/securetty
/etc/hosts.allow setup to allow them to telnet/ssh in from outside there own authorised network?

But yes I also was thinking of shaking up some redhat users by writing a small rpm to awaken them up by showing how easy it is to remove data. Something like Danger Will Robinson, A virus has infected your computer flashing across there screen on bootup, or replacing there lilo.conf with something that don't boot backing up the original of course & have all this explained in the documentation knowing full well most linux wanabee redhat users probably wouldn't read it till after installing and having there computer disabled.
However I'm not likely to write such a package.
too much work :(

But yes I appreciate & agree with the point being raised :)


[reply] [top]

---

[»] Virus
by You - Jun 10th 2000 21:25:12

Even if you make it tough to activate a virus by requiring more than a double-click...it still can be a problem. Check this link, at the bottom of the page, "still spreading the love":
http://www.computerworld.com/home/print.nsf/all/000515df6a


Another note, on changing associations. Under windows, the user is able to change the 'default' action to use when double-clicking an icon. I have .bat, .sh, and .pl files set to open under notepad by default. It shouldnt be tough to do under linux, though I rarely use X except for netscape.

[reply] [top]

[»] Virii
by f0oG - Jun 10th 2000 18:09:26

I was fascinated by virii since several years. I studied near 400 virus, almost were the most harmful ones on Dos and Windows.
I read all the comments and I found in them some good arguments but I think there's some points I can add. The frist thing I want to discuss is what is a virus?, the second one is What should be a virus-safe OS?

1- What's a virus?

2- What should be a virus-safe OS ?

Then, how should we protect data files from virii?

Theoretically, this is pretty harder than protecting the OS itself. In fact, when a user execute a program the program will gain the user ID and will pass through permissions. Was it Linux, Windows or Dos, the program will be able to do anything with user's data files. Hence, two immediate solutions exists: backups and awareness.
-Make backups is something every PC holder should pray for. It isn't an annoying task, it is a common sense habit.
-Be sure of what the program will do and what it won't do before executing This is something essential too. Is this possible? No! A solution should be trusted companies that insures programs won't contain viruses.
Furthermore, if the source is open, users will be able to look through the code lines, if they can't, they must control the community feedback. If someone isn't able to know if something is harmful or no at a good average of truth, it is better he don't execute a program.

Well I hope I helped this discussion providing not only fundamental realities about virus, but also imaginary solutions OS developpers and computer's users should know.

Best Regards.

--
from nowhere -- f0oG

[reply] [top]

[»] Stupid Users vs. Stupid Software
by NichG - Jun 10th 2000 14:26:28

To some extent, making software more user conscious also makes
the software less powerful, or more annoying to use. Having a
reminder not to run untrusted files pop up every time you try to
access a file would itself be as much as nuisance as the 'are you
sure you want to delete' and recycle bin' on other systems. One
must take into account who a program is created for, and what level
of user is intended to use it. Many things are created for the needs
of the creator, not in an attempt to mainstream linux. Such people
shouldn't be discouraged from programming just to prevent user
error.

[reply] [top]

[»] Users may be as stupid as they want
by Guido Tack - Jun 10th 2000 13:05:45

In my opinion a good application must be able to deal with every kind of "stupid" input.
I learned to use the computer (and btw coding too) in a "learning by doing" way. The main thing is "if you don't know what it is, try it!", and possible security problems should be dealt with by the system.
For example the mailcap approach is quite effective, just as the executable flag.
Today everyone must be able to use a computer without understanding anything about it. I can drive a car without being able to repair the motor. Nevertheless I know from personal experience that the next time that red light flashes indicating that there's not enough engine oil left I'll stop immediately.
That's real user stupidity: ignoring the obvious warnings. But no one should be blamed if there aren't any warnings.
We shouldn't try to make users better, we should improve the systems until they're fool proof. ;-)

[reply] [top]

[»] Social Engineering
by Tarnar - Jun 10th 2000 12:48:58

All you *need* to do is convince someone they need to run it.

tar zxf some-cool-sounding-epplet.tar.gz
cd some-cool-sounding-epplet
./configure
make
./cool-epplet
cool-epplet: this must be run as root
su
Password:

./cool-epplet


Well crap. You're hosed. Not everyone knows enough to review all of everyone's code. While cool-epplet would never make it to a distro, that's not the point. It just needs to spread itself. And it could find ways.

[reply] [top]

[»] RE: The problem is not the association..
by Andy Wiggin - Jun 10th 2000 12:15:05

I wholehartedly agree.

Using airtight, low privledge execution environments seems to me like the way to go. Java was designed to deal with these problems, and consequently Java VMs have the necessary fine grain control to disallow specific things for specific programs, like writing to disk.

With CPU cycles and memory so abundant these days, emulation environments with low privleges should be cheap and easy to setup. Perhaps the user-mode linux project could be used for this.

A more extreme way to go would be to always run in a VMware-style virtual machine, and not commit any changes to disk until you're logging off. Didn't like the way that session went? Virus delete all your files? Just don't commit those changes to disk.

[reply] [top]

[»] It's more of a user education problem
by Michael Chaney - Jun 10th 2000 11:26:41

I, too, tire of people who act like this problem is unique to Microsoft operating systems. The reason it's not hit Linux yet (note: yet) is that 1) there aren't as many Linux users and 2) they're far more educated, on average, than most Windows users.

Even under Linux, though, folks download and execute programs all the time. A great example is a Makefile. How easy would it be to wipe out the user's home directory from a poison Makefile? How often do you check those when you download software?

Better yet would be to modify the user's .profile to scan their inbox and send annoying email to all their friends every time they log in. Better than that would be to send a copy of the original program, complete with poison Makefile, to all your friends and a subject line of "check out this cool bot that I wrote". It's a couple more steps than ILOVEYOU, but the point is that it would be just as easy, probably easier to program.

When I first started playing with the Internet 12 years ago, we passed our programming efforts around in shar files, or uuencoded tar files. A shar file is an executable shell script that recreates all the original files when you run it, and stores them in a format that can be mailed, posted to newsgroups, and split apart (kind of like an executable uu). While rare, there were cases of poisoned shar files that would wipe a system if executed as root. There was even one for VMS systems that would build the command "del sys$system:*.*" piece by piece and execute it at the end. For those of you lucky enough to be unfamiliar with VMS, that's the rough equivalent of "rm /bin/* /sbin/* /usr/bin/* /usr/sbin/*".

The point is that the ILOVEYOU worm, and similar worms, are not unique to Windows. It would be helpful if Microsoft made it more difficult to execute email attachments, but in the end, it's a user education issue, and Microsoft has been exceedingly lax in that area. A Microsofty, when pressed for comment on the ILOVEYOU worm, actually said (paraphrased) "as we've said before, people should only open attachments that come from an acquaintence." And yet ILOVEYOU worms almost always come from an acquaintence.

For now, Linux users are more educated. If Linux starts making inroads on the corporate desktop, things could get interesting. If you think Linux mail clients are smarter than that, remember that many will automatically decode a uuencoded file, and uuencoded files keep the permissions. The mail client can be made smart enough to not set the x bits, but are they now?

[reply] [top]

[»] Re: It's more of a user education problem
by Damian Cirelli - Dec 25th 2004 10:44:37

I'm just a plain user, but here's a thought... Wouldn't the whiping out of the user's home dir be solved by having a special user with nothing in their /home just for program compilation? If the Makefile is malicious it wouldn't have anything to destroy... my $0.00000000002 :-)

[reply] [top]

---

[»] Don't discount user stupidity...
by bluetea - Jun 10th 2000 10:31:49

Some key words in this editorial are "when you activate a file you don't recognize." Whoa. It should be obvious to anyone who is reasonably security concious that this is a big no-no. A cardinal rule of learning to use a computer (and most other things) is "if you don't know what it is, leave it alone." I'll certainly agree that a well-designed application shouldn't make this rule quite so easy to violate, but I think a large measure of responsibility for the success of ILOVEYOU rests with the users who were careless enough to open an unsolicited email attachment of a type they didn't recognize. Granted, clever social engineering can make hacks like this difficult for some people to spot, but success still depends on getting lots of people to do something that is fundamentally stupid. The only way to fix this sort of thing is by making sure your users understand that they should never run a program or open a document unless they can be sure that the source is trustworthy. Good application security can help, but it's not going to solve the problem entirely.

[reply] [top]

[»] Executable Permissions
by Peter Todd - Jun 10th 2000 10:24:29

One of the big advantages of UNIX-like OSes is the idea of the executable permission. If email clients (and other like programs) are written so that files never get the executable flag set when they are saved we can prevent users from mistakenly executing a script they think is, say, a MP3 file. This has been exploited by a number of worms. A file with a innocent name such as Nirvana.mp3.vbs is clicked on by the user thinking that it will play a MP3. The script is then run and can do whatever it likes. If Windows didn't execute based on extension but instead used a UNIX-style executable flag this wouldn't happen.

[reply] [top]

[»] Virus Creation
by perl_warrior - Jun 10th 2000 10:20:28

It is the opinion of a number of my friends/associates that in the short-term virus creation would be stemmed should Linux use increase rapidly since there seems to be an affiliation between virus-coders and the Linux OS / Community.

But then again, I feel that new demons would simply come along. In my personal opinion I feel the motives behind virii are 50% cause and 50% general intent to cause problems

Excellent article, by the way, very well written and thought-provoking. I suppose it stopped a lot of us being quite so cocky.

"head"
=----=

[reply] [top]

[»] The problem is not the association..
by witten - Jun 10th 2000 09:32:54

The problem here is not the association itself, but rather the lack of fine-grained security on most operating systems. Imagine that when you clicked on a document, its associated program ran, but instead of running with the full capabilities of the current user account, it instead runs with the most minimal privileges required. In other words, it has no access to the user's home directory, zero ability to read the user's email address book, and no way of connecting to the network. A system that worked as such would be adhering to the "principle of least authority," which if you think about it for a second, makes complete sense. Why should any arbitrary script be able to access everything that I can access, unless I specifically grant it permission?

If more operating systems were written with this kind of thing in mind, a whole class of trojans and worms would be wiped out of existence.

[reply] [top]

[»] Associations.
by Iso-9660 - Jun 10th 2000 08:39:34

Another approach which email clients have taken under unix (and in particular Linux), is to use a 'mailcap' which has the associations of mime-type to application. This is seperate to your 'usual' associations and only contains applications which are 'safe' to run, a mp3 player, a picture viewer etc. The Microsoft model falls down because it uses the same associations as the 'desktop', so things that are "safe" to do on the desktop (run a trusted visual basic script) is concidered "safe" to do in email. By having a distinction between the two under unix much more saftey is gained. If a file is not in 'mailcap' then the only option that the mail agent can provide is 'save' as it doesn't (and shouldn't) know anything else about the file.

Capibilities should also help as a 'mailagent' can drop all of it's capibilities before it runs an external program.

[reply] [top]