A different kind of bad week [LWN.net]

Another week, another email worm. Your editor initially wondered how he had managed to get put on a Microsoft security mailing list, but it didn't take too long to figure out what was really going on. A quick tweak to a SpamAssassin rule made the visible part of the problem go away; after all, very few messages of interest contain Microsoft executables anyway. But, of course, the "Swen" worm continues to chew up bandwidth.

Swen seems to have two ways of attacking a system:

a two-year-old Internet Explorer bug, which allows code execution through malicious HTML mail.
Convincing users to run the attached executable.

As we have warned many times in this space, Linux is not immune to worms and viruses. We will almost certainly have a bad security day sooner or later. But Swen is a classic Microsoft worm, and, perhaps, Linux users have the right to feel just a little smug.

Exposed Linux systems with two-year-old vulnerabilities are rare. Fixing problems is sufficiently easy, and Linux administrators are sufficiently aware that vulnerabilities tend to be closed quickly. Keeping patching levels high as Linux expands into more desktop and consumer-oriented uses will be a challenge, however. We have all the tools we need to keep such systems current; it's mostly a matter of ensuring that those tools get used.

Imagine, however, that a widespread bug exists which, when exploited, could allow the running of arbitrary code from malicious email. The variety of mail user agents in the Linux world will restrict any such exploit to a fraction of the deployed Linux systems. The number of distributions in use will also make a universal exploit difficult. But, even if the attacker succeeds in running code on a target system, that code will be unable to kill the system's defensive processes, make "registry" (i.e. configuration file) changes, or engage in most of the other unpleasant activities carried out by Swen. To obtain that level of access to the system, the exploit code would have to find and take advantage of another, different vulnerability.

Then, there is the issue of convincing users to run a malicious executable sent to them in the mail. One of the real strengths of the Linux development model is that it is highly unlikely to result in the creation of mail utilities which allow the direct execution of programs received as email attachments. Any developer or distributor who tried to release a tool with that sort of vulnerability would not soon forget the reception they would get on the net. There is simply no excuse for extending such trust to the world as a whole. A Linux utility that was so trusting would be fixed within hours. Microsoft systems have remained vulnerable - in the face of overwhelming proof of the damage caused - for years.

Linux systems suffer from a constant stream of vulnerabilities, like other systems out there. The real difference, perhaps, is that our problems get fixed - almost always before they ever reach a point where they can be widely exploited. As a happy result, it is, once again, not Linux systems which are spamming the net with worm-laden email.

to post comments

A different kind of bad week

Posted Sep 25, 2003 2:51 UTC (Thu) by smoogen (subscriber, #97) [Link] (3 responses)

---
Then, there is the issue of convincing users to run a malicious executable sent to them in the mail. <snipped for brevity>
---

I think the user is a too smug here. The problem here is user training and not how poorly the program is. Even when people have mailers that do not allow the program to be executed but has to be saved.. they will save the attachment, and then go to their desktop, double click and infect themselves. The really sad thing is that when they do that it doesnt need to have any 'root' priveledges.

If/when Linux gets to be popular, watch the number of these types of virii show up because too many users are not as trained in how social engineering works (or dont care enough to know)

It's a bit harder...

Posted Sep 25, 2003 12:51 UTC (Thu) by dion (guest, #2764) [Link] (2 responses)

I think the situation on Linux is a bit different, because programs need more than just a magic filename to be executed, they need the execution bit to be set and it isn't by default.

This means that if a user clicks a file named loveletter.jpeg.exe then all that happens is that they are told that no program is available for viewing .exe files.

The user would need to set the execute bit to actually run the file and the clueless user will never have done that before because it's something that only programmers do (when having created a script for example), everyone else just installs software from an rpm or using make install.

... but it depends on what the GUI actually does to view/execute file, if it's at all sane then it shouldn't run code from files without the execute bit set, no matter what the last part of the filename is.

It's a bit harder...

Posted Sep 26, 2003 1:18 UTC (Fri) by giraffedata (guest, #1954) [Link] (1 responses)

Hmm. So if Linux is safer because Linux users don't know how to (or are too lazy to) detach a file and run it (by the way, there doesn't have to be an execute bit involved. The Swen analogy would be an RPM attachment that you would rpm -i), then it must also be less safe because users don't know how to or are too lazy to install real security updates.

I don't think Linux can win here.

It's a bit harder...

Posted Oct 2, 2003 16:46 UTC (Thu) by Baylink (guest, #755) [Link]

> I don't think that Linux can win here

On the contrary, I suspect it already has.

The Deep Thought in Jon's commentary here is really "defense in depth",
one of the most important approaches to any type of security... and
exactly what you get from the fact that there are *so many* places in
which to deploy genetic diversity: different kernels, different
distributions, different mail clients, different desktop managers. It
rapidly becomes difficult to pick a sweet spot to target as a malware
author.

But, of course, this is largely *because* of the lack of "consumer"
deployment of Linux.

Figuring out how to continue to take advantage of that as Linux
penetrates more deeply into the "consumer" market will be the big
question.

A different kind of bad week

Posted Sep 25, 2003 3:00 UTC (Thu) by StevenCole (guest, #3068) [Link] (3 responses)

If you're the type who likes to start campfires by rubbing two sticks together, here is a way to pre-filter your email:

[billg@buxnmorbux billg]$ telnet mail.microsoft.com 110
Trying 131.107.34.141...
Connected to mail.microsoft.com (131.107.34.141)
Escape character is '^]'.
+OK <85934.1064457736@microsoft.com>
USER whgates3
+OK
PASS crushm$all
+OK
LIST
+OK
1 157888
2 145219
3 145139
4 6964
.
DELE 1
+OK
DELE 2
+OK
DELE 3
+OK
LIST
+OK
4 6964
.
QUIT
+OK
Connection closed by foreign host.

Then, quickly download your mail before another one comes in. Of course, slightly more sophisticated tools exist for this, but that would be like using matches or a lighter, right?

A different kind of bad week

Posted Sep 25, 2003 5:09 UTC (Thu) by ghane (guest, #1805) [Link] (1 responses)

I have seen these suggestions, but this is overkill. You are getting rid of all mail between 14k & 15k.

--
Sanjeev

A different kind of bad week

Posted Sep 25, 2003 6:51 UTC (Thu) by StevenCole (guest, #3068) [Link]

Bzzzt. Off by ten. That example got rid of messages 145K or so, which is exactly the size of the swen worms. In actual practice, I use a mail previewer, which allows me to choose to download the odd large, but desireable email. My cutoff is at 50K, which results in very few false positives, and those few can be selected out. Thanks for participating.

Swendeleter - works for me...

Posted Sep 25, 2003 6:47 UTC (Thu) by seanpor (guest, #2564) [Link]

http://www.hashref.com/prj/swendeleter/index.html

"SwenDeleter tries to identify email messages infected with the Swen.A worm in POP3 mailboxes and delete them on the server. It applies some heuristics to the headers and size of the messages, in order to avoid downloading the actual email, thus making retrievals less taxing. It has both interactive and nonstop modes."

A different kind of bad week

Posted Sep 25, 2003 3:00 UTC (Thu) by yem (guest, #1138) [Link] (1 responses)

Try being the admin for one of the domains that Swen uses to spoof the "From" header.
I'm still getting bounces, autoresponses and complaints to abuse@. Can't simply remove the MX records because some people still use it :-(

A different kind of bad week

Posted Sep 25, 2003 3:42 UTC (Thu) by StevenCole (guest, #3068) [Link]

Speaking of the "From" header, notice how all the swen messages so far use "FROM" all in upper case? I haven't seen any other MTA do this. Looking at the actual executable with the strings command, you'll see that FROM is in there in upper case only, as well as TO and SUBJECT, plus a bunch of other interesting stuff. Anyway, you can use procmail to filter on this rather unique property of the swen mails.

A different kind of bad week

Posted Sep 25, 2003 11:01 UTC (Thu) by Wout (guest, #8750) [Link] (5 responses)

Fixing problems in code is not the solution. At some point someone will write a virus that exploits an unfixed bug. Also, as we know, users are lax in applying fixes to their systems.

In Linux the user - system seperation protects most of the system from actions done under a user's id. It also protects users from each other. For desktop systems this is not enough though. On a desktop system, there is usually one user. The most valuable files on such a system are probably owned by that user. This means that a virus that damages those files has achieved just about the worst that could happen - from the user's point of view.

What we need is some kind of seperation between user programs that receive untrusted (possibly malicious) input (eg. mail clients) and the user's files. I don't know how that could be implemented without annoying users though. Another way of protecting user files from destruction by malicious code is using a filesystem that supports snapshots (it remembers the state of files at the time of the snapshot and records changes in such a way that older version(s) of the files are still available). A daemon could then make (daily/hourly) snapshots of the /home partition. That way a virus could destroy the files it sees, but would not be able to touch the files as they were at the last snapshot. Looks like I've just reinvented backups. ;-)

A different kind of bad week

Posted Sep 25, 2003 21:30 UTC (Thu) by lakeland (guest, #1157) [Link]

Separating users from themselves sounds like a great idea, but I wouldn't know how to
implement it without upsetting users.

Snapshot filesystems are fairly easy to simulate using hard links. Google should find you
examples if you're interested.

A different kind of bad week

Posted Sep 26, 2003 11:02 UTC (Fri) by cross (guest, #13601) [Link] (2 responses)

> On a desktop system, there is usually one user.

Depends. Many households have one PC which is used by more than one user. It's sensible for each of them to have their own accounts, settings, preferences etc.

> The most valuable files on such a system are probably owned by that
> user. This means that a virus that damages those files has achieved
> just about the worst that could happen - from the user's point of view.
>
> What we need is some kind of seperation between user programs that
> receive untrusted (possibly malicious) input (eg. mail clients) and the
> user's files. I don't know how that could be implemented without annoying
> users though.

It's fairly simple. Create a new account solely for the email program. Put yourself and that account in the same group (creating it for the purpose). For the sake of argument, "mymail". Make sure that the "mymail" account is group readable and writeable, make sure that your account isn't. Now even a malicious executable that your email client actually executed wouldn't be able to cause any damage under your home directory let alone systemwide. It does mean that if you want to send a document or other attachment you first need to copy it to the mymail's home directory. But that's why we made it group writeable.

A different kind of bad week

Posted Sep 26, 2003 12:51 UTC (Fri) by Wout (guest, #8750) [Link] (1 responses)

>> On a desktop system, there is usually one user.
>
>Depends. Many households have one PC which is used by more than one user.
> It's sensible for each of them to have their own accounts, settings, preferences etc.

Yes, but my point is that user files are the most important thing on a desktop system. Yet important as they are, they are also the most vulnerable to viruses and such.

>> What we need is some kind of seperation between user programs that
>> receive untrusted (possibly malicious) input (eg. mail clients) and the
>> user's files. I don't know how that could be implemented without
>> annoying users though.
>
>It's fairly simple. Create a new account solely for the email program. Put yourself and that account in the same
>group (creating it for the purpose). For the sake of argument, "mymail". Make sure that the "mymail" account
>is group readable and writeable, make sure that your account isn't. Now even a malicious executable that your
>email client actually executed wouldn't be able to cause any damage under your home directory let alone
>systemwide. It does mean that if you want to send a document or other attachment you first need to copy it to
>the mymail's home directory. But that's why we made it group writeable.

This is the kind of solution that techies can use, but that are impractical for most other people because they don't understand file ownership, accounts and groups. What you need is protection that is invisible until the user requires it, which is exactly what a snapshot based system can provide. It even provides protection against the quite common case of people accidentily deleting or overwriting their files.

A different kind of bad week

Posted Sep 26, 2003 14:46 UTC (Fri) by cross (guest, #13601) [Link]

> Yes, but my point is that user files are the most important thing on a
> desktop system. Yet important as they are, they are also the most
> vulnerable to viruses and such.

We agree completely on this point.

> This is the kind of solution that techies can use, but that are
> impractical for most other people because they don't understand
> file ownership, accounts and groups.

If you can't explain it simply, you don't understand it well enough (Albert Einstein). The analogy I use is rooms in a house. Even very young kids understand "this is Jamie's room, you don't go in there unless he says it's OK". It's trivial then to grasp "this is Jamie's directory, you can't go in there".

> What you need is protection that is invisible until the user requires it

Which basically means that the installer should take care of it. When you choose "create new user" in your GUI tool and check the "setup mail" box it should create the "jamie" account, the "jamiemail" account and the "jamiemail" group, make a link in Jamie's home directory to "/home/jamiemail" so that Jamie can see it and knows that's where he puts things he wants to email to someone else, or save things some else sent him. You do need to explain that he doesn't leave things there if he wants to be sure they'll still be there tomorrow, but using the previous analogy, that's the difference between putting things away in his room and leaving them out in the back garden. Chances are nobody will come into the garden that night and take them, but they might. It's a concept easily grasped.

Is this non-obvious? Do you think it's non-obvious enough that I could get a patent on it? ;-)

> which is exactly what a snapshot based system can provide. It even
> provides protection against the quite common case of people accidentily
> deleting or overwriting their files.

It's a very good idea, and something that should also be done. But it's a solution to a different problem.

The Unix security model could help also desktop users.

Posted Sep 27, 2003 10:18 UTC (Sat) by bockman (guest, #3650) [Link]

A secure-minded desktop distro (or a secure-minded desktop user, if any exists) could be configured to run any browser and e-mail program (or other program's accessing the 'Net) with a dedicated account, which can only read files, but with write-access only to a specific home directory subfolder. Files owned by this account should be readable/writable by the normal user account. This would annoy only sligtly the user, since he can still upload/download stuff without too much hassle. The problem is that there should be different such accounts for each created user, e.g. to keep dowloaded stuff by one user not readable by others, if so he chooses.

A different kind of bad week

Posted Sep 25, 2003 12:31 UTC (Thu) by arcticwolf (guest, #8341) [Link] (2 responses)

Given the vulnerabilities that occured in OpenSSH, sendmail and ProFTPd, I don't think it's a week where we have reason to be even a little smug. Granted, Linux (and most other unices) are much more secure by default than anything that comes from redmond, but it's not like we don't have our own share of problems.

A different kind of bad week

Posted Sep 25, 2003 19:48 UTC (Thu) by dlapine (guest, #7358) [Link]

That's the point of the comments. These are vulnerabilities, and they get patched before they become exploited, for the most part. The scale of our problems is also smaller, as no one bug will effect all linux users.

A different kind of bad week

Posted Sep 25, 2003 21:43 UTC (Thu) by freethinker (guest, #4397) [Link]

True, we had several vulnerabilities. Fixes were quickly issued and no doubt widely applied. What we did not have was a widespread exploit of those vulnerabilities.

Contrast with the M$ world, where the vulnerability has been out there for two years, and the fix apparently has not been widely applied. They had (yet another) widespread exploit. The net was (once again) clogged as a result.

What does this tell us about the future? Linux systems will continue to be diverse; they will continue to have user/system separation; they will continue to eschew email clients that automatically run attachments. These things will be true even if the typical user becomes one who is clueless about applying patches and clicking on attachments.

More important, Linux will continue to be an open system, not controlled by any one entity. Those who care about quality and can deliver it will continue to create Linux. Those who don't or can't will not.

The bad time ahead

Posted Sep 25, 2003 17:17 UTC (Thu) by maney (subscriber, #12630) [Link] (1 responses)

If Linux catches on in the consumer market, it too will acquire agarware that trades security for user convenience. It will always be possible to use, eg., mutt rather than Prospect (Tinysqueeze's port of a well-known virus breeding ground), but the agarware will come, because, as Grimmelman put it, insecure systems do what people want and people make secure systems insecure because secure systems don't. Linux at least gives you the choice of avoiding the agarware.

"Agarware"

Posted Sep 25, 2003 21:47 UTC (Thu) by freethinker (guest, #4397) [Link]

Good word, hope it catches on :)