Don't you think it's about time that MS comes out with a freakin' security patch that stops scripts from broadcasting across your entire contact list?
That might treat the symptom (sometimes) but it doesn't treat the problem. Contact lists are easily accessible through COM objects, from a trusted process. Untrusted code (like scripts on web pages) are not allowed to access address books.
The root problem is that people run attachments with the same privileges that their user account has. Therefore the attachment runs as a trusted process. As long as A) people still run executable attachments, and B) those attachments run with the same level of access that the user has, there is absolutely no way to prevent the attachments from impersonating the user and flooding the net with virus mail.
As a side note - Eudora and Netscape Mail both allow users to run executable attachments. The reason that their address books are not targeted is not that it's impossible (it is definitely possible to write a program to read them; I have seen it done) - it is because Outlook is the most popular program out there and it's easy to code a virus that accesses Outlook contact lists. If M$ had not driven Netscape into the bit bucket in the 90's and everyone used Netscape Mail today, these virusus would work just the same for that client. (That's not to say that Outlook doesn't have plenty of other faults - it does.)
I'm sure a lot of people here are going to go out and blame Microsoft for the Outlook-virus-of-the-week. But the fact is, Microsoft is just giving the user what they want. Users want the ability to double-click on executable attachments in order to open them, and email software needs to honor that request to stay competitive.
The underlying problem here is that people have come to accept executable attachments as the norm. Years of silly Flash greeting cards, "snowball fight" games, and Joe Cartoon crap sent across offices since the mid-1990's have hooked Windows users on native-binary attachments. The only way that this sort of activity can be stopped is by making it socially unacceptable (improper netiquette) for anyone to send executables through email. Think about what would happen if one of your colleagues sent you a random Linux binary through email and claimed it was a greeting card - would you run it? Well, the drooling masses will run any.exe that a "known" source sends to them, and that is the crux of the problem.
Unfortunately, it is in content producers' best monetary interest not to change their distribution strategy to use a format that requires less trust (such as.swf or even.html). That would artificially limit the quality of their goods, and closes the door to including "value-added features" (like spyware) to their attachments. Therefore, the situation shows few signs of changing anytime soon, and users will simple work around any stopgap measures in their email software so that they can continue to play their "frog in the blender games" in perpetuity.
isn't this nothing that can't be done with the skills learned in that "Learn Perl in 24 hours" book?
Actually, this is an immensely useful tool in a couple of circumstances (especially involving static pages). Consider any of these cases:
You run a "host your own web site for free" system like GeoCities and you want to stick your JavaScript ads on the top of each page. This is far more elegant than running a cron job to hack every user's page each night.
You maintain some sort of reference system that accepts html files from a third party, html files that are automatically generated by some other system, or html files that are maintained by a different person than the rest of the web pages. This module makes it extremely easy to add a "contents/up/back/about/..." header or footer to every page, and not have to worry about changing the header on a couple hundred documents when you want to change it (e.g. change "up" into an up arrow icon).
You use some perl cgi's here and there, and you don't want to make them even less maintainable than they already are.
This module will work wonders for site maintainability. I know that the webmaster where I work is going to be implementing it next week for parts of our intranet.
Here in the Midwest, we often have the displeasure of driving through heavy rains and blinding snowstorms. When you're driving in nasty weather at 55 mph and scanning the road ahead of you for black ice, you don't want any sudden distractions from the task at hand. This "computerized passenger" could be such a distraction if it suddenly starts telling knock-knock jokes while you're driving and you scramble to shut it off (or need to divert your attention to ignore it).
Slashdot Mirror
That might treat the symptom (sometimes) but it doesn't treat the problem. Contact lists are easily accessible through COM objects, from a trusted process. Untrusted code (like scripts on web pages) are not allowed to access address books.
The root problem is that people run attachments with the same privileges that their user account has. Therefore the attachment runs as a trusted process. As long as A) people still run executable attachments, and B) those attachments run with the same level of access that the user has, there is absolutely no way to prevent the attachments from impersonating the user and flooding the net with virus mail.
As a side note - Eudora and Netscape Mail both allow users to run executable attachments. The reason that their address books are not targeted is not that it's impossible (it is definitely possible to write a program to read them; I have seen it done) - it is because Outlook is the most popular program out there and it's easy to code a virus that accesses Outlook contact lists. If M$ had not driven Netscape into the bit bucket in the 90's and everyone used Netscape Mail today, these virusus would work just the same for that client. (That's not to say that Outlook doesn't have plenty of other faults - it does.)
-all dead homiez
The underlying problem here is that people have come to accept executable attachments as the norm. Years of silly Flash greeting cards, "snowball fight" games, and Joe Cartoon crap sent across offices since the mid-1990's have hooked Windows users on native-binary attachments. The only way that this sort of activity can be stopped is by making it socially unacceptable (improper netiquette) for anyone to send executables through email. Think about what would happen if one of your colleagues sent you a random Linux binary through email and claimed it was a greeting card - would you run it? Well, the drooling masses will run any .exe that a "known" source sends to them, and that is the crux of the problem.
Unfortunately, it is in content producers' best monetary interest not to change their distribution strategy to use a format that requires less trust (such as .swf or even .html). That would artificially limit the quality of their goods, and closes the door to including "value-added features" (like spyware) to their attachments. Therefore, the situation shows few signs of changing anytime soon, and users will simple work around any stopgap measures in their email software so that they can continue to play their "frog in the blender games" in perpetuity.
-all dead homiez
Actually, this is an immensely useful tool in a couple of circumstances (especially involving static pages). Consider any of these cases:
- You run a "host your own web site for free" system like GeoCities and you want to stick your JavaScript ads on the top of each page. This is far more elegant than running a cron job to hack every user's page each night.
- You maintain some sort of reference system that accepts html files from a third party, html files that are automatically generated by some other system, or html files that are maintained by a different person than the rest of the web pages. This module makes it extremely easy to add a "contents/up/back/about/..." header or footer to every page, and not have to worry about changing the header on a couple hundred documents when you want to change it (e.g. change "up" into an up arrow icon).
- You use some perl cgi's here and there, and you don't want to make them even less maintainable than they already are.
This module will work wonders for site maintainability. I know that the webmaster where I work is going to be implementing it next week for parts of our intranet.-all dead homiez
Just my 2 cents...
-all dead homiez