Weekly Edition
Return to the Front page
| |||||||||||
Just another Microsoft worm
Certainly the "MyDoom" worm has gotten our attention. By some accounts it
is the fastest-spreading email-based worm ever; there is no doubt that it
has filled our mailboxes with garbage - both the worm itself and the
inevitable piles of "virus notification" spam that this sort of worm
generates. Interestingly, claims
have appeared in the media that this worm does not actually exploit any
Windows security holes. We know better, of course; the fact that a worm
like MyDoom can exist at all is a clear vulnerability.
So far, this episode just looks like yet another in the interminable series of worms hosted by the Microsoft computing environment. The story gets more interesting, however, with the fact that this worm seemingly contains code to execute a denial-of-service attack against the SCO Group's web site on February 1, thus ruining Darl McBride's Super Bowl experience. This attack has, of course, been widely reported in the mainstream media as an act carried out by the Linux community in retaliation for SCO's attempts to steal or destroy our work. (SCO itself, in its press release offering a bounty for the worm writer's head, took a relatively neutral tone: "We do not know the origins or reasons for this attack, although we have our suspicions.") You knew this paragraph was coming: the free software community does not and cannot go for attacks of this sort. This worm is an act of vandalism which does not help our cause in any way. It will not affect SCO's legal campaign, and can only help the company's PR campaign. Rather than try to silence the company's web site, we need to let SCO's words be distributed as widely as possible. The more they talk, the deeper they dig themselves in. It is not for nothing that this picture was recently circulated with the caption "SCO's legal team in action." Trying to shut down SCO's web site via DOS attacks is morally wrong and simply counterproductive. The fact is that this worm almost certainly has nothing to do with SCO or Linux. The SCO attack has does a good job of covering over a few other little details about this worm: it does, after all, install a keystroke logger, a spam relay, and an open port which can be used to feed arbitrary code into the compromised system. MyDoom turns the system into a general attack platform; the DOS attack looks thrown in as an afterthought. This worm is not primarily a machine for attacking SCO; it is constructing a large-scale distributed network of compromised systems. The media likes the "SCO attack" story, however, and thus the damage is done. The community has been portrayed as a set of outlaw crackers trying to settle a grudge. In fact, we, too, are victims of this worm. Our networks are flooded and our mailboxes are clogged, even though our Linux systems are, as usual, immune to the worm itself. And our reputation has taken a hit because it suits some people to portray this worm as furthering our agenda. There is nothing about MyDoom which has been good for the community. There is little we can do to respond to this worm that we have not been doing for some time. We can and will deplore this sort of attack, regardless of who the victim is. We can try to raise awareness of the fact that these worms are very much the product of one set of proprietary operating systems with designed-in security problems, and we can let the world know that we have an alternative which is not a worm-breeding platform. This message may just be heard: companies dealing with the consequences of MyDoom and its countless predecessors have suffered far more than SCO will; they cannot help but be increasingly receptive to alternative systems. And, most of all, we can continue to work to improve our own security so that we have a chance of actually living up to our promise of being a worm-free alternative. (Log in to post comments)
complacency? Posted Jan 28, 2004 20:04 UTC (Wed) by stevenj (subscriber, #421) [Link] ... we can let the world know that we have an alternative which is not a worm-breeding platform. In some ways, it's true that GNU/Linux is currently less susceptible to these sorts of attacks than Windows. However, I worry a little that developers will become too complacent about problems that exploit "stupid" users, since it doesn't affect them personally. For example, there is one near-universal design flaw that most of these social-engineering worms exploit:
Take GNOME, for instance: double-clicking a file opens it, and ditto for an executable (or a desktop shortcut), thoughtlessly imitating Windows and MacOS. Moreover, it is quite easy to social engineer people into creating executables: quite often, I have received email viruses that were Every part of the OS that presents a similar interface for opening a file and launching an executable needs to be rethought, not just the email program. A shell like Nautilus should at the very least pop up a big warning dialog the first time a user tries to launch an executable (or shortcut to one) by double-clicking, with the option to disable the warning for that file in the future (with the warning disabled for system-installed executables). This is just one example...has anyone systematically thought about social-engineering attacks under GNU/Linux?
complacency? Posted Jan 28, 2004 21:45 UTC (Wed) by zone (guest, #3633) [Link] Amen. Shame on LWN for classifying this as just another Windows worm. There is nothing inherent about Linux that would prevent an identical worm from spreading through it.The entire detail at issue in this case is the interface the email client presents to the user. I suspect Outlook's approach is particularly bad (= default action is to execute), but that doesn't mean we're any better off at the moment. I tested this earlier tonight out of curiosity by sending myself /bin/ls and a GTK app and seeing how different email clients handled them. This is on Debian unstable with a clean user account. KMail 3.1.5: Dialog box prompt. Default is save, but Open is an option. In my case it tried to run it under Wine. Complete disaster. Sylpheed 0.9.7: Has Open option, which apparently opens it with the default external application. Looks ok. Evolution 1.4.5: Only option is Save when a binary application is detected. Looks ok. Mozilla Mail 1.6: Only options are Open With... or Save. Looks ok. Each of the four handled a shell script as a plain text attachment. The bottom line is that the only line of defense we have now is the email client itself, and currently that's a hodgepodge of methods with each client using it's own best judgment and interface. We need a standard method of sandboxing untrusted executables. Maybe SELinux has that capability; certainly removing network access and filesystem access is essential when running untrusted executables. Of course this applies equally to web browsing, instant messaging, and any other application that receives untrusted input, be it executables, HTML, images, or anything else. You can never guarantee that an application won't be compromised and forced into executing arbitrary code, and the security has to be implemented at a higher level. But I'm stating the obvious now. The point is, this worm didn't exploit a Windows-only vulnerability, and it doesn't help anyone to pretend Linux is inherently any better in this regard currently. Of course, we'll get there, and that's the difference that counts in the long run, but let's not start pounding our chests prematurely.
complacency? Posted Jan 28, 2004 23:43 UTC (Wed) by stevenj (subscriber, #421) [Link] Of course this applies equally to web browsing, instant messaging, and any other application that receives untrusted input... Every input, and especially every executable, that was not installed by root should be untrusted by default. Sandboxing executables is a hard problem to solve completely, but my point is that the first step is just to distinguish launching from opening. Currently, Evolution et al. saving the executable (do they set the execute bit?) is not "ok" if the user can be tricked into launching it thinking he is only opening a file.
automatically running from a double-click is a good thing Posted Jan 30, 2004 11:36 UTC (Fri) by giraffedata (subscriber, #1954) [Link] the first step is just to distinguish launching from opening.You're thinking like a computer engineer, not an average user such as is involved in spreading Mydoom. An average user doesn't see an icon as having a file behind it. "open" and "launch" mean nothing. "go" is probably the most appropriate verb. Whether clicking causes a picture to display, text to display, or software to be installed is all the same thing. For computers to be as usable as they ought to be, we must allow painless running of programs by clicking on an icon in a mail reader. The solution is to be able to place parameters on what the click can do. It would not be unreasonable for the click to respond with, "this operation may modify your system settings, read your mail file, and send mail. OK?" If you thought you were just going to display a picture of someone's naked girlfriend, you'd say "no." Today, some systems go so far as to break the clicks into 2 categories: 1) those that display stuff on the screen; and 2) those that have full run of your system. We need to get finer granularity.
complacency? Posted Jan 28, 2004 23:44 UTC (Wed) by freethinker (guest, #4397) [Link] There is nothing inherent about Linux that would prevent an identical worm from spreading through it.Well, yes, there is. It's called a user account. If you don't do email or other risky things as root, the worm may spread, but its teeth will be pulled; you won't get "a keystroke logger, a spam relay, and an open port which can be used to feed arbitrary code into the compromised system", because your user account can't do any of that. My understanding is that, in Windows, you're root all the time. Or at least, malware can hack its way up to root with all the security holes that Microsoft won't fix because it would mean discontinuing spiffy features.
complacency? Posted Jan 29, 2004 1:38 UTC (Thu) by anselm (subscriber, #2796) [Link] It is certainly possible for a malicious executable to install akeystroke logger in your X session, or a spam relay on a non-privileged port, using only the privileges of your user account. It could also try to exploit any of the well-known local root holes to obtain administrator privileges. Complacency is misplaced.
complacency? Posted Jan 29, 2004 7:33 UTC (Thu) by freethinker (guest, #4397) [Link] ...I was not aware of the first two issues. Can anyone provide more details or a link to information on dealing with these risks? Thanks.
complacency? Posted Jan 29, 2004 8:36 UTC (Thu) by hppnq (subscriber, #14462) [Link] The two observations are rubbish, but anyway, here you can find some information on securing X.There might be more up-to-date information elsewhere of course.
complacency? Posted Jan 29, 2004 11:49 UTC (Thu) by oak (guest, #2786) [Link] Magic cookies prevent only *other* users and remote users from spying your X session.If a program is run within your X session, it can do above described things. Without X session program can still open unpriviledged port to network and start relaying stuff coming from elsewhere. Untrusted binaries really should be sandboxed. I've myself thought to try out Systrace ported from BSD to Linux when I've got time (just google for systrace).
complacency? Posted Jan 29, 2004 12:54 UTC (Thu) by pflugstad (subscriber, #224) [Link] Actually, you'd still get the spam relay, and you'd still get the open port, as the ports opened were not reserved ones (somewhere in the 3000 range IIRC). And someone else addressed the keylogger issue.Nothing this worm did really required Admin access on Windows - Admin access just made it easier. And nothing this worm did couldn't be trivially targeted at a Linux box instead of Windows. And I can trivially think of ways for it to set itself up to be auto-executed the next time the user logged in (.bash_login, .bashrc, .xsession, and so on). Imaging mailing someone a statically linked exec that when executed forks itself into the background (maybe doing something fun in the foreground to distract the user) then saves itself somewhere in the users home dir as something innocuous (such as an emacs autosave file) then stuffs a call to restart itself into .bashrc or .xsession. Then it goes on to open up the same ports MyDoom does ( and do the exact same things, including mailing itself to others. With a little bit of careful coding, this is easily done and could probably be easily hidden as well. The moral of this story is that there is NOTHING preventing a virus just like MyDoom from working on a Linux box just as easily as on a Windoze box, even running as a normal user. The thing that makes MyDoom really work is naive users and poor mail tools that make it way to easy to execute something. Nothing inherent to Windows helps it. As Linux moves into the Desktop, we have to be even more careful that we keep making it hard for users to do stupid things, no matter how much they complain. A real sandbox type environment for mail tools to use would help a lot as well.
complacency? Posted Jan 29, 2004 7:52 UTC (Thu) by corbet (editor, #1) [Link] Interesting. Anybody who has read LWN for any time at all knows that we have run a long, tiresome series of articles arguing against complacency. I do believe that, one of these years, there will be a nasty Linux-borne worm, and I've said so many times.That said, such a thing has yet to happen. There are things we simply do better. Somebody may yet succeed in writing an email-based worm for Linux, but it will not be an easy thing to do. Nobody has ever even circulated a proof of concept. Complacency is certainly not warranted; we're not that good. But why not take come comfort in, and credit for, being better?
complacency? Posted Jan 29, 2004 9:47 UTC (Thu) by smoogen (subscriber, #97) [Link] Well that was the part that took me by suprise. For years, you have been on the 'dont let your defenses down', and then this article was the opposite with 'no need to worry, we are superior.' I found it chilling and was wondering if someone other than Corbet had written it.The issue is that it can happen... and it will happen in a large linux environment because users are the weakest link. It may be an email that says "Hey look at this.. its so cool that I had to gzip it. You will need to save it and then execute it with XYZ [insert broken app.]" It then fires up a bunch of dancing hamsters, forks off a program that creates a ... directory and then daemonizes itself at port 31773 or some such thing. The proof of concept has been written several times.. and I will admit that I got taken by something like it in 1997 on a Vax. Thankfully, the sysadmins were the ones that wrote it to find out who needed security training.. but it didnt need to be.
complacency? Posted Jan 29, 2004 15:54 UTC (Thu) by hingo (subscriber, #14792) [Link] Nobody has ever even circulated a proof of concept.How's this for a proof of concept: "To watch naked women, type "echo rm -Rf / >> ~/.bashrc" on your command line." From my experience with people using computers, some will do it! Ok, it's not a virus if it's not spreading, but you get the point. One good question arising from this discussion is, why are we using the same command to open a file and to launch an application? If these were two different commands, we could undo a lot of problems. But what should the commands be? Double click to open, middle click to launch? henrik
commands to open vs. launch Posted Jan 29, 2004 20:44 UTC (Thu) by stevenj (subscriber, #421) [Link] I think double-click to launch is not too bad, as long as it pops up a scary warning the first time that it is an executable (or a shortcut to one) and not an ordinary file.But maybe that's not hard enough. Maybe, by default, double-clicking a user-owned executable should pop up a scary warning with the instruction that if you really want to launch it you have to right-click and select Launch Possible Evil Virus from the menu. =) Well, I'm not entirely joking. There's really not much reason to make it easy to launch executables owned by the user; most software should be installed as an explicit administration task via a package-installation tool. Some sysadmins may want to disable launching of user-owned executables entirely (at least from the graphical desktop).
commands to open vs. launch Posted Jan 30, 2004 1:56 UTC (Fri) by hingo (subscriber, #14792) [Link] A scary warning doesn't help, because people don't read them! They will just hit the default button, and if that doesn't do what they want they will try all the other buttons next. I've seen this happen so much, I think it's more of a rule than an exception. Sometimes even I don't read the warnings, because I think I know what it says and don't see that now it's really trying to tell me something.The point is, people could be taught, that you can always double click on an attachment or on a file. For launching programs you would use the menu or the panel, or if you have shortcuts you would "do some other command" (middle click, right-click and choose from a menu...). That way, people would know what they are doing. henrik
Better use of the executable bit Posted Jan 30, 2004 4:10 UTC (Fri) by bockman (subscriber, #3650) [Link] I think all user-interactive programs should make a better use of the executable bit:- Downloaded files shall always have the executable bit not set; - No software shall run files with the executable bit not set (and this should include all the script interpreters, bash python perl etc... ). This would require the user to be aware of the difference between a data file and a program and to mark a program as such (and thush declaring it 'safe to be executed').
Better use of the executable bit Posted Jan 30, 2004 10:58 UTC (Fri) by stevenj (subscriber, #421) [Link] You can't trust this bit; there's too many ways for the user to be tricked into creating a file with the execute bit set (e.g. by uncompressing an archive).There's really no reason to trust any user-owned executable.
Not much difference between "open" and "execute" Posted Jan 30, 2004 12:32 UTC (Fri) by spitzak (subscriber, #4593) [Link] In reality a script starting with "#!/usr/bin/perl" is really a "perldocument" and you are opening it. Well, you could make the claim that that counts as an execution. But
Not much difference between "open" and "execute" Posted Jan 31, 2004 13:22 UTC (Sat) by stevenj (subscriber, #421) [Link] Of course there will be bugs. There are plenty of them now. The point is that they are recognized as such, and are fixed promptly. The problem is that doing something that seems like opening a file but actually results in the execution of foreign code is not currently considered a design bug.(Yes, of course executing a file constitutes opening a file, but the reverse is not generally true, or at least it should not be. e.g. the GIF format does not implement a Turing-complete programming language, barring bugs in the viewer.)
Not much difference between "open" and "execute" Posted Feb 6, 2004 7:20 UTC (Fri) by Wol (guest, #4433) [Link] WordPerfect beats Word hands down, and the only WordPerfect viruses there are rely on VBA being enabled!The WordPerfect Macro Language can't be virus-enabled... Cheers,
Just another Microsoft worm Posted Jan 29, 2004 2:27 UTC (Thu) by beejaybee (guest, #1581) [Link] Yes. If the authors had really intended to damage SCO, they wouldn't have given a week's notice of their intentions. They would either have released with an immediate attack, or postponed release until 23:59 on January 31.The conclusion can therefore be only that the SCO attack is an attempt to discredit linux users. Conspiracy theorists may therefore be correct in assuming that Darl's money is safe given that he is the most likely author. BTW the press is correct in their claims that no specific Windows vulnerability is present. The vulnerabilities used by this virus are in the Windows version of Kazaa and in the heads of the people using Windows, who appear to be incapable of resisting enticement to click through potentially dangerous e-mail attatchments, or configuring their systems so that e-mail attatchments will not execute.
Just another Microsoft worm Posted Jan 29, 2004 3:17 UTC (Thu) by pointwood (subscriber, #2814) [Link] Quote:
Just another Microsoft worm Posted Jan 30, 2004 13:08 UTC (Fri) by beejaybee (guest, #1581) [Link] Stop speculating, just see what happens Sunday am.The code analysis I've seen states that 1 in 4 systems infected with MyDoom-A will start to DoS www.sco.com. That's enough to be _very_ disruptive but might explain why some people who have infected systems & advanced the clock have seen nothing happen.
Just another Microsoft worm Posted Jan 29, 2004 6:16 UTC (Thu) by utidjian (subscriber, #444) [Link] Some months ago on the comp.sys.mac.advocacy Usenet group a discussion came up (as they always do on such forums) about the inherent security of Mac OS X vs Windows. The discussion was "ignited" by the, now common, weekly major Windows worm. It was the usual thing with Windows advocates claiming that such an exploit could just as easily affect Mac OS X if someone would simply write one. It also follows that if Mac OS X were as commonplace as Windows it would spread as easily. The Mac advocates denied that this sort of thing was possible because "Mac OS X is Unix" (or some such). Sound familiar?The upshot of the discussion was someone actually wrote a little trojan for Mac OS X. He published the source code for the trojan and using his code I adapted it to Linux. The results for Linux are at: http://tinyurl.com/2quhp I also tested it on Mac OS X and it works as designed with a default installation of Mac OS X (up to and including Panther). The basic differences between the various OSes is the default behavior when encountering an executeable attachment. Windows (typical): Will execute attachment, sometimes by merely opening the email, sometimes requuiring the user to open the attachment. Windows ("secure"): Requires the user to open the attachment but will warn them that such an action might be dangerous. Mac OS X (typical): Requires the user to open the attachment but will warn the user that such an action might be dangerous. Linux (typical): Requires the user to save to disk. Saves as mode 0600. The user then has to change the mode to get it to run. As far as I know (only tested with Mozilla Mail) all Linux email clients save attachments without the execute bit set. As long as this practice continues there will be a considerable hurdle for the average user ( I mean Windows/Mac type of average user) to overcome before the attachment can be executed. For many Linux users this is not that big of a hurdle but it is still a checkpoint. In short, the current default behavior of Linux email clients, more or less, effectively prevents the kind of exploits that use email as the transport. Let us hope that this does not chnge. However, we have had problems with some file formats. I seem to remeber that there was a possible exploit from certain graphics file formats last year. IOW one could "run" an exploited JPEG file or PDF file simply by opening it in the default viewer. -DU-...etc...
execute bits Posted Jan 29, 2004 13:39 UTC (Thu) by stevenj (subscriber, #421) [Link] As far as I know (only tested with Mozilla Mail) all Linux email clients save attachments without the execute bit set. As long as this practice continues there will be a considerable hurdle for the average user ( I mean Windows/Mac type of average user) to overcome before the attachment can be executed. ...Unless the attachment is compressed, in which case your average friendly untar/unzip tool will happily set the execute bit for you. Not to mention that certain things like desktop shortcuts on GNOME are just files and don't need an execute bit at all to be usable in dangerous ways. (This is not even getting into actual bugs, mind you, just potential design weaknesses.)
execute bits Posted Jan 29, 2004 20:20 UTC (Thu) by utidjian (subscriber, #444) [Link] Unless the attachment is compressed, in which case your average friendly untar/unzip tool will happily set the execute bit for you. Not to mention that certain things like desktop shortcuts on GNOME are just files and don't need an execute bit at all to be usable in dangerous ways.True. File Roller (or whatever) will unpack it "correctly"... but the email application will not. The user has to save-to-disk, navigate to where it was saved (perhaps on the desktop), doubleclick on it, navigate to where the executeable was saved (perhaps on the desktop), then doubleclick on the executeable. This not a lone feature of Linux or Gnome. The default KDE would be even easier... just singleclicks. There is no "warning" either. -DU-...etc...
Just another Microsoft worm Posted Jan 30, 2004 20:20 UTC (Fri) by bronson (subscriber, #4806) [Link] Has anybody thought of always launching user-owned executables with asandboxed/defanged glibc? It could pop up a dialog any time something potentially dangerous was requested. "BabyDance is trying to read file "AllMyAddresses.lwp [allow] [deny]", "SpringBreak is trying to open a network connection to listen on port 21129. [allow] [deny]", etc. Seems like that would be the best of both worlds: reasonably secure and very functional. (obviously some linker work would need to be done to ensure that more libraries could be used without being able to get around the restrictions). The only alternative that I can see is just to ban launching user-owned executables outright. Anything short of that is simply a hole waiting for an exploit. Currently *any* user-owned app can write to any file also owned by the user, flood the network with all sorts of traffic, launch symlink/tmpfile exploits, etc. At the moment, market share is the single largest virus protection that Linux has.
Just another Microsoft worm Posted Feb 2, 2004 14:29 UTC (Mon) by Vaughn (guest, #19145) [Link] That would be useless as long as the worm writer could call Linux directly. There is no way to get around someone doing that; SELinux or similar systems is the only practical way to sandbox anything that doesn't want to be sandboxed.
Just another Microsoft worm Posted Jan 30, 2004 22:49 UTC (Fri) by stock (subscriber, #5849) [Link] Its sure is a worm targeted at SCO and Microsoft :"W32.Mydoom.B@mm SECURITY RESPONS" http://securityresponse.symantec.com/avcenter/venc/data/w32.mydoom.b@mm.html "W32.Mydoom.B@mm is a mass-mailing worm that arrives as an attachment with the file extension .bat, .cmd, .exe, .pif, .scr, or .zip. When a computer is infected, the worm will set up a backdoor into the system, which can potentially allow an attacker to connect to the computer and use it as a proxy to gain access to its network resources. In addition, the backdoor can download and execute arbitrary files. The worm will perform a Denial of Service (DoS) against www.microsoft.com starting February 3, 2004 and www.sco.com starting February 1, 2004. It also has a trigger date to stop spreading on March 1, 2004. These events will only occur if the worm is run between or after those dates. While the worm will stop spreading on March 1, 2004, the backdoor component will continue to function after this date. " Well now, thats does not leave much room for discussion. As i saw in other news : "MS posts $250,000 MyDoom worm bounty" http://www.theregister.co.uk/content/56/35244.html : "Microsoft yesterday put up a $250,000 bounty for information leading to the arrest and conviction of the author of the MyDoom-B worm. The reward follows a similar offer $250,000 offer from SCO for information leading to the capture of MyDoom-A, which is programmed to launch a DDoS attack on SCO's web site from infected computers. MyDoom-B attacks the web sites of both SCO and Microsoft.com. "
Just another Microsoft worm Posted Feb 5, 2004 9:14 UTC (Thu) by alext (guest, #7589) [Link] Surely the people who keep getting themselves stuffed with these andspreading them around need to be considered partially as harmful as the actual authors? I have some sympathy because I did once open a virus by accident (open with and open being next to each other on the right click menu when I decided I would have a look at the actual virus source). That was back when I worked on a Window system of course.
|
|||||||||||
