Please, a nice distinction needs to be kept in mind between those who are not focused on computer technology, and those who actually are "stupid".
Fair enough. I was just continuing the terminology of the article I was replying to. I don't necessarily believe that people are really stupid just because they are not computer smart.
I thought the mailbox format was quite standard across mail programs -- they all use a single text file with standard headers separating the messages. No, many of the different email clients for Linux store the mailbox in different directories and/or file formats. Some put it in ~/mail, some in ~/Mail, some in ~/nsmail, etc. Several of the clients allow you to split mailboxes into seperate 'folders'. At least one package I've seen stores the mailbox in a binary format. There is a lot of diversity in Linux email clients, and there are at least a dozen different clients available out there. Typical distributions typically ship with at least 4 or 5.
They all read the same inbox, anyway.
That is true, although normally the inbox isn't nearly so dangerous as the user's stored read messages (due to volume), their sent messages, or their address book (obviously). All of those are stored in different directories and sometimes different formats by different Linux mail clients.
Not really. I don't believe that perl scripts need execute bits set for "perl " to run them. So if someone were to write a unix mail client that automatically ran "perl " on attachments where has a.pl extension, it would be rather dangerous.
That is true, although as far as I know there is no such mail program, and it is highly unlikely that one with such an obvious security flaw would ever become popular in the Linux world.
Of course, I'm increasingly an advocate of using CVS for *any* project that involves extended development time, which would save the user's ass if such a thing happened on unix. But AFAIK, VC tools aren't really ready for nonprogrammers, just yet.
You might want to check out gCVS and/or Cervisia, which are (Gnome and KDE respectively) GUI based front ends for CVS. They are both rather recent products, but they do give a more point-n-drool user interface to CVS.
I'd like to add, however, that most computers are single-user devices now and there aren't typically "other users files" on your computer.
That is true of most office computers or home computers of single people, but far less often true of home computers that are used by a couple or a whole family. Some offices have some people sharing computers for various reasons (shift-splitting, receptionists, etc), so the statement isn't 100% true in the office world either.
I also read somewhere that with Win2K it's not possible to overwrite system files.
Its less likely under Windows 2000, supposedly even more so than NT, but most desktop users are using Windows 9x, and the upgrade path for most of those people for the immediate future will be to Windows ME, as Windows 2000 is not really targeted at that audience.
(although I suppose a virus could just as easily destroy non-system applications).
Very true. Unfortunately, security in the Windows world is normally set so that any user can write into program files.
As has been thoroughly hashed out in the threads of the articles following the last virus/worm outbreak, Linux isn't 100% immune from viruses/worms, but it is much more resistant due to a few reasons:
First, executability is determined by access bits, not by file extension. This means that normally downloaded files like attachments get saved un-executable, meaning that users have to intentionally try to change the access bits on the files to execute them, not just click on them.
Secondly, unless the root user is the one reading the email and running attachments, the virus/worm is limited by security/permissions rights to what it can do. While it can do damage to a single user's files, it can't very easily blast other user's files or system files. On Windows 9x, there is basically no security, so viruses/worms like ILOVEYOU are free to twink with the registry, etc. Thirdly, the homogenous nature of the Windows world makes it a much easier and more attractive target for virus/worm authors. It is pretty safe to assume that virtually all Windows 9x clients will have Outlook and all the associated DLLs on their system. There is no single email client in the Linux world that is so ubiquitous. That makes it more difficult to write viruses/worms that will affect a large percentage of Linux users because the virus/worm creators can't make the kind of assumptions about how to read things like address books, etc. that they can under Windows. This is unlikely to change any time soon, because the Linux world is much more diverse than the Windows world.
While you are right up to a point that in many ways it is the users that are stupid, Outlook and Windows make the problem worse by making it so much easier for the users to shoot themselves in the foot. And to a certain extent, Windows is plagued with a much higher percentage of stupid users because it intentionally caters to the least common denominator. To a certain extent, as Linux gets easier to use, it may start to see more of the semi-stupid users.
While I'd agree that Linux on S390 doesn't need CICS to be useful, CICS isn't strictly a mainframe thing. IBM has versions of CICS for AIX and OS/2. There are 3rd party software developers who do products like UniKix which is a CICS emulator for many of the commercial UNIXes. There isn't any reason why one of those couldn't be ported to Linux on S390.
Many of the newer IBM mainframe machines are air cooled (no water chiller needed) and could probably be run in a normal house with a decent air conditioning system.
One of the main things the ILOVEYOU virus does is wonk around with the registry. Under Linux/UNIX the equivalent would be messing around with files in/etc for example. It could still be destructive to a single user without doing that, but one of the things it was trying to do with the registry hacks was to try to sniff passwords, which could be used to compromise a lot more things.
it's arguable that the spread of Melissa and ILOVEYOU had nothing to do with security exploits.
Well, that is a matter of perspective I suppose. One way of looking at it is that both of them rely on the fact that there is little or no security in Windows 9x.
So, addressing the original poster's comments, just because they've got 4 mail programs on their system doesn't mean they're "safe", if they all have essentially the same API's
I think that if an API is standard and multivendor, then it, in itself is less likely to be the target for attack because it will be under the scrutiny of a much larger number of eyes. Specific implementations can of course have their own problems, but that is a slightly different issue.
or similar address book files (perhaps XML), etc.
The address books, or their access methods are only part of the problem, in that it is only related to the propagation of viruses/worms, not necessarily to their destructive potential. It also doesn't take into account that Melissa/ILOVEYOU also rely on the ease with which code from outside can get executed under Windows. For the problem to be as bad under Linux/UNIX as it is under Windows, all three things would have to come together on a significant number of desktops. As long as the Linux developer community and the distribution vendors are aware of this potential problem, it is not nearly so likely to happen.
Yes, it is. It isn't the only issue, but it is still an issue.
It still comes down to how braindead your mail client is.
The difference is that an email client on Linux/UNIX would have to go out of its way to be as braindead as Outlook is in this case. Just because a file comes down under Linux/UNIX with a certain extension, it isn't immediately going to be executable as it is under Windows. Let's say a company called Macrosoft made this unix email reader called Inlook, and by default it was configured to execute ".pl" attachments under perl if you double clicked on them.
It would have to intentionally set the execute bits on files based on their extension. That would be an extra effort. If the 'Inlook' email client was open source, something like that would certainly get noticed and fixed quickly. If it wasn't open source, that would seriously limit the number of users who have it on their system, since most of the Linux/UNIX distributions wouldn't include it by default.
Let's say this particular perl program would sit around and watch your mailqueue to grab addresses, and send itself off to all those addresses. The same type of spreading would be accomplished.
This is of course true, but this is only a fraction of what the ILOVEYOU virus, for example, does. It also goes out and wonks around with the system registry, and deletes files. These parts would be less likely to cause problems on Linux than on Windows 9x due to permissions.
This would be possible if as many dumb people used linux as windows,
That isn't quite true, as Linux/UNIX still has a certain amount more security than Windows 9x, and thus will even to a certain extent protect dumb users from themselves.
and if as many people used Inlook as Outlook.
For reasons I've stated before, it is highly unlikely even if Linux/UNIX had the same size user base as Windows that any single email client would ever get the installed base of Outlook.
My point is simply that if we make things "close enough", or if we use
a specification that allows interoperability between products from different vendors.
then we're still vulnerable to a virus.
Possibly, but not necessarily.
You won't find me to be someone who is saying that viruses/worms are impossible on Linux/UNIX. I do believe they are less likely and less likely to cause as much damage, but I do believe and have been advocating that we make sure to keep vigilant to insure that they don't happen on Linux/UNIX or are at least dealt with as quickly and permanently as possible if they do. Unlike Microsoft, I don't think the Linux/UNIX world should put its head in the sand or live in denial.
On the other hand, history has shown that two products which are similar, and conform to many of the same standards may have very different security issues. For example both Netscape Navigator and Microsoft Internet Explorer have somewhat similar user interfaces. If you can use one, you can probably figure the other out pretty easily. They both implement many of the same standard interfaces. HTML, Java, Javascript, etc. However, both have had at least a few security problems (in general, it seems like IE has had far more and far more serious security related bugs), but in most cases, the security problems they have had have not been the same. Exploits which work against one browser don't necessarily work against the other. The same thing is true of many other types of software. I think it is stretching to say that implementing a common interface or API necessarily puts you at the same risk of 'inbreeding' that having everyone rely on the same vendor's products does (as we see now with products like Outlook).
If it's a close enough interface, then I can probably code something to work with multiple variations.
Maybe, maybe not. I have little doubt that in many cases it makes it far more difficult to create a single virus/worm which can afflict multiple platforms. It very definitely rules out many sorts of binary coded viruses, as they are generally tied to a specific hardware platform or OS API.
I'm not advocating homogenaity of implementation (heck, not even MS purports to do that - multiple system elements may expose the same functionality, even though they are implemented in many different ways (e.g. drivers, etc)), but that if we have near identical interfaces, we're still stuck with the problem.
I'm not saying that there isn't any shred of truth in what you are saying, I just think that you grossly exaggerate the risk that is involved in following open, industry standard interfaces. I think you have a lot more of a point when interfaces are partially secret or totally proprietary, as they are not then exposed to nearly the level of independant review.
I saw something on Freshmeat.net the other day called Outlook2Ical that purports to be able to convert Outlook calendar messages to Ical calendar entries. Might be just what you are looking for.
While this is true, and indeed a heterogeneous population is indeed more resistant to infection (biologically and otherwise), at what cost? Like it or not, the current push, fueled in no small part by Microsoft, is to have the same look, feel, and, yes, interface, everywhere.
There is a downside to the push to try to make everything homogenous. One is that it promotes stagnation. Another is evidenced by what we've been talking about here in that lack of diversity can make a system vulnerable to any small weakness that might be found. We need to find a way to allow options for the same interface everywhere, while also allowing for flexibility for people to do things differently.
One thing to think about is that we can have a similar enough look and feel and 'interface' to allow users to use different software without necessarily being forced to all use the exact same products. For instance, if I can drive a Ford or a Toyota, I can adjust to driving a Chevy or a Honda or whatever pretty easily. They aren't exactly the same, the controls may look a little different or be placed slightly different, but it isn't going to keep me from driving. By the same token, if I know how to run one GUI, it doesn't take me long to figure out how to use another.
Having a certain level of diversity in the software community is a good thing. If we had file formats and network formats that were not controlled by vendor interests and fighting, we would be a lot further along here. We could have compatibility to talk to each other without having to be exact clones of each other.
Look at Netscape - they want the same user experience everywhere. This thought process occurs in progamming as well (look at Java - hey, and C!),
The direction that C has gone, and hopefully Java will (and probably would have if it weren't for Microsoft's attempts to derail cross-platform Java) is that it is standardized not on individual products, but on a specification that allows interoperability between products from different vendors.
where if the same interfaces exist in multiple places, it'll be easier to interoperate.
One of the problems the computer world faces is that we need to promote vendor and platform independant standards where they are possible and make sense, while still allowing innovation (as opposed to Microsoft's 'immovation' (immitation)). We (in the sense of the industry as a whole) should change standards or create new standards when there is a good technical reason for doing so, not for vendor specific marketing reasons.
So when LINUX becomes a common desktop OS user are going to have to save their email attachments that are to be executed.
Sending executable content indiscriminantly in email is what has caused this virus/worm problem in the first place. Most of the things that are sent as executables are pretty worthless easter-egg type things anyway.
They're going to have to figure out that the file is to be executed in some way, with no pretty icon
You can have iconic file managers under Linux/UNIX. Both KDE and Gnome do so. Nothing stops Linux/UNIX email client from doing an iconic representation of attachments, in fact there are a few that do so.
(not to mention an extension).
The extension, or lack thereof is determined by whomever sent the file. Under Linux/UNIX they are just optional, and aren't what determines executability, but there is nothing prohibiting people from adopting a convention for using them.
They're even going to have to run chmod on the file to get a script to run. These limitations are all perfectly reasonable on a server OS. They obviously make the system considerably more secure. But if you think that Joe and Jane user who use this as a desktop OS at work or at home are going to figure all this out, I think your overly optimistic.
Given how much problems that Joe and Jane user cause themselves, maybe it is a good thing if they can't figure this out.
Companies can probably afford a few minor disasters from viruses than losing the productivity they gain from clicking on e-mail attachments and having them do what the sender intended.
The question is, how much productivity do they really gain from this? Is it really worth all of the problems that this type of virus/worm can cause to get a few little animated toys? How many legitimate executables are sent via this type of 'push' through email that can't as effectively be sent through a 'pull' and just sending the users a link to a place to download from?
I know this is a huge security hole which requires the user to determine if the attachment is safe based on who they think sent them the message.
The problem is that user's have a hard time doing that when the virus/worm attacks address books. The message may appear to be from someone that the user knows and trusts if that person's computer is an unwitting host for the virus/worm. Unless you impose some sort of digital signature on attachments which this type of user would probably have just about as much of a hard time with as figuring out how to make files executable, you aren't going to be able to trust any executable attachment, regardless of who it appears to be from.
The question is how much ease of use you want to trade for security.
The question is really, how much purported ease of use are you really getting for the unquestioned security you are trading off here?
I think the solution that many have suggested of showing a dialog box before outlook lets an application send an email is a good place for MS to start.
That is a start, but is pretty much a band-aid. Viruses/worms will find a way to disable or bypass that if they can run in a Windows 9x environment where there is little to no OS security. Also too many users will just blindly click through warnings like that, especially after the first few times they see them.
However, it appears they have made some patches to fix some of their security problems, and that sys admin are very lax in applying them.
Part of the problem is that Microsoft has promoted Windows as 'any idiot can administer it'. So - idiots are administering it. Microsoft hasn't done a very good job of informing and educating their user base, so they are part of the problem. They spend too much time trying to spin-doctor and downplay any problems that happen rather than trying to make sure as many people know about problems and apply patches as possible.
Hopefully both MS and those sys admins have learned their lessons.
You are much more optimistic than I. I am not convinced that it will be possible for Microsoft to retrofit security on their existing infrastructure in any kind of short timeframe. I am convinced that anything less than that will not be effective in stopping the virus/worm threat.
The su to nobody fails because nobody's password is typically *'d out in/etc/shadow. That doesn't necessarily mean that the suid ownership of a mail client can't be set to nobody, although that would effectively present a challenge to find a secure way to read a user's mailbox. Not saying it can't be done though.
It is also not true that 'only root can change their user id'. Only root can do so without knowing what the password is. I often log in as one user and su to another without ever being root, so I know that is possible. If the user id's password is starred out, then only root can su to that user id.
I think their OS share is a little smaller than that, like 70-80
Everything I've read states that 90+ percent of x86 based PC's sold ship with a MS OS installed. Now, whether that means that more than 70-80% actually run a MS OS once they are put into service may be another thing, since a lot of servers are purchased to run Linux, BSD, commercial UNIX, Novell Netware, OS/2, etc, and a growing number of desktop machines are going to other OSes as well, albiet not nearly as many as the server market.
I think in terms of desktop machines, you'd be hard pressed to push Microsoft's market share numbers down much below 90% even if you counted in all of the non-x86 machines like Macs and RISC UNIX workstations.
Its hard to tell though, as Microsoft tells different stories depending on who they are talking to. When they talk to the DOJ and/or the court, they have major competition, but when they talk to their shareholders and business partners, they don't have any serious competition. When they are talking to themselves, then they are worried about OSS, but only a little, and mostly only because they have difficulty understanding it.
That could be a workable, albiet inconvenient workaround in the Linux world, where it is possible to run programs under different user ids without logging out. I don't think it would be considered an acceptable alternative in the Windows world due to the fact that their ability to deal with simultaneous multiuser sessions is non-existant to awkward.
I think the sandboxed environment for executing scripts would be a good move for Microsoft to implement, but would be very difficult for them to retrofit at this time. It is definitely something that any Linux/UNIX email clients should think about doing ahead of time so that they aren't faced with having to try to retrofit later.
I am not that sure that signing documents will really help that much, as too many users will be too lazy to bother with setting up encryption or to understand how it works.
Your posting doesn't seem to be as incompatible with what I was saying as you seem to think it is.
The mere fact that the Linux community is varied, is changing, and is incredibly dynamic is exactly what will probably insure that no single email client ever becomes as ubiquitous in the Linux world as Outlook is in the Windows world. There are very few software packages other than the kernel itself that are truly universally accepted, let alone something as high-level as an email client.
The Windows world is different, because it is a monoculture dominated by a single vendor which has an amazing ability to control what software gets bundled with machines. No single entity in the Linux world has that kind of power. Not Red Hat, not Mandrake not SuSE, not Caldera, not Corel, nobody. The fact that there are many different distributions out there insures that there will be diversity in what packages will be used. The fact that it will probably be a long time (if ever) before the KDE/Gnome split is unified likely insures that no single GUI email package will ever become dominant on Linux the way that Outlook is on Windows.
And as I said before, the thing that will really make sure that something with inherent security problems never gets pervasively deployed is that in order for something to be widely accepted in the Linux world it must be open source, which means problems such as these get dealt with quickly.
As for talking about 'the community', that means something different here on Slashdot than it does if I am talking to someone in a different forum. You are reading something into my words that isn't there if you think I use that terminology to be divisive rather than inclusive.
Your points are valid up to a point. Recreating user files is worse than system files. Recreating every user's files is worse than just a single user's files though, which is what you get when there isn't effective multi-user security. With Windows you probably have to fix user files, system files registry files, etc.
The other problem is that unrestricted access to system files makes what a virus can do more dangerous, because it can infect itself into lots of other things. Thankfully, few viruses so far have been really insidious and sophisticated enough to pervasively infect a system and slowly (or at least delayed) start to do things. Think how much more damage these viruses might have done had they only slightly propagated themselves at first so they weren't noticed as quickly, but thoroughly infected the systems, so that at some later point they could go full bore once they had been spread all over the place? Doing this effectively would require that a virus/worm be able to infect system files and not just user files.
No, I still wouldn't be happy with Windows even if they did that. There is a lot more wrong with Windows. Those things would be a small start in the right direction, but the inherent architecture of Windows (yes, even NT and 2000) is poor, and you can't easily retrofit that.
We'd probably be no better or worse off with custodians running nuclear plants than with a 'technician' like a Homer Simpson. Seriously, you aren't giving sysadmins enough credit here. Sure, there are lots of MSCE type idiots running around, but there are a lot of highly skilled people working as admins as well. Admins are the people who are ultimately responsible for the security of their networks, who else should be able to control them?
Its not the assumption that people using Outlook must be using Windows 9x, but more that the vast majority of them are. Also, I think it would be more fair to say that NT security can be a bit tighter. Most of the type of desktop users who would be likely to fall for this type of virus/worm are probably not with it enough to tighten up their security, or worse, probably would loosen things up 'to make things easier'. I've run into a lot of NT users that spend most, if not all of their time using NT logged in as 'administrator'.
Worse than that, they sell the fact that any idiot who can spend a lot of money and memorize multiple choice answers can get certified as a feature rather than a bug.
Vendor sponsored accreditation programs are generally designed with the primary purpose to enrich the pockets of the vendors, and it is more profitable to just certify the idiots than to make the standards high enough that only the people who really understand things rather than just barfing back fixed answers to known problems can pass the tests. Plus by making it easy and pumping up the numbers you can advertise things like 'there are 14 billion certified idiots out there who can administer your network'.
Making things 'so easy any idiot can do it', at least on a superficial level, is not necessarily the best thing in the long run.
I would agree that the underlying architecture of Outlook is the fundamental problem. Disabling the scripting host will only prevent a very certain class of Outlook-related viruses/worms, but won't cause the whole system to be safe. Your suggestions about allowing the admins to control the API at that level would be a much better approach to solving this problem, but I somehow doubt that Microsoft will ever really bite the bullet and do the right thing with this.
Slashdot Mirror
Please, a nice distinction needs to be kept in mind between those who are not focused on computer technology, and those who actually are "stupid".
Fair enough. I was just continuing the terminology of the article I was replying to. I don't necessarily believe that people are really stupid just because they are not computer smart.
I thought the mailbox format was quite standard across mail programs -- they all use a single text file with standard headers separating the messages.
No, many of the different email clients for Linux store the mailbox in different directories and/or file formats. Some put it in ~/mail, some in ~/Mail, some in ~/nsmail, etc. Several of the clients allow you to split mailboxes into seperate 'folders'. At least one package I've seen stores the mailbox in a binary format. There is a lot of diversity in Linux email clients, and there are at least a dozen different clients available out there. Typical distributions typically ship with at least 4 or 5.
They all read the same inbox, anyway.
That is true, although normally the inbox isn't nearly so dangerous as the user's stored read messages (due to volume), their sent messages, or their address book (obviously). All of those are stored in different directories and sometimes different formats by different Linux mail clients.
Not really. I don't believe that perl scripts need execute bits set for "perl " to run them. So if someone were to write a unix mail client that automatically ran "perl " on attachments where has a .pl extension, it would be rather dangerous.
That is true, although as far as I know there is no such mail program, and it is highly unlikely that one with such an obvious security flaw would ever become popular in the Linux world.
Of course, I'm increasingly an advocate of using CVS for *any* project that involves extended development time, which would save the user's ass if such a thing happened on unix. But AFAIK, VC tools aren't really ready for nonprogrammers, just yet.
You might want to check out gCVS and/or Cervisia, which are (Gnome and KDE respectively) GUI based front ends for CVS. They are both rather recent products, but they do give a more point-n-drool user interface to CVS.
I'd like to add, however, that most computers are single-user devices now and there aren't typically "other users files" on your computer.
That is true of most office computers or home computers of single people, but far less often true of home computers that are used by a couple or a whole family. Some offices have some people sharing computers for various reasons (shift-splitting, receptionists, etc), so the statement isn't 100% true in the office world either.
I also read somewhere that with Win2K it's not possible to overwrite system files.
Its less likely under Windows 2000, supposedly even more so than NT, but most desktop users are using Windows 9x, and the upgrade path for most of those people for the immediate future will be to Windows ME, as Windows 2000 is not really targeted at that audience.
(although I suppose a virus could just as easily destroy non-system applications).
Very true. Unfortunately, security in the Windows world is normally set so that any user can write into program files.
As has been thoroughly hashed out in the threads of the articles following the last virus/worm outbreak, Linux isn't 100% immune from viruses/worms, but it is much more resistant due to a few reasons:
First, executability is determined by access bits, not by file extension. This means that normally downloaded files like attachments get saved un-executable, meaning that users have to intentionally try to change the access bits on the files to execute them, not just click on them.
Secondly, unless the root user is the one reading the email and running attachments, the virus/worm is limited by security/permissions rights to what it can do. While it can do damage to a single user's files, it can't very easily blast other user's files or system files. On Windows 9x, there is basically no security, so viruses/worms like ILOVEYOU are free to twink with the registry, etc.
Thirdly, the homogenous nature of the Windows world makes it a much easier and more attractive target for virus/worm authors. It is pretty safe to assume that virtually all Windows 9x clients will have Outlook and all the associated DLLs on their system. There is no single email client in the Linux world that is so ubiquitous. That makes it more difficult to write viruses/worms that will affect a large percentage of Linux users because the virus/worm creators can't make the kind of assumptions about how to read things like address books, etc. that they can under Windows. This is unlikely to change any time soon, because the Linux world is much more diverse than the Windows world.
While you are right up to a point that in many ways it is the users that are stupid, Outlook and Windows make the problem worse by making it so much easier for the users to shoot themselves in the foot. And to a certain extent, Windows is plagued with a much higher percentage of stupid users because it intentionally caters to the least common denominator. To a certain extent, as Linux gets easier to use, it may start to see more of the semi-stupid users.
While I'd agree that Linux on S390 doesn't need CICS to be useful, CICS isn't strictly a mainframe thing. IBM has versions of CICS for AIX and OS/2. There are 3rd party software developers who do products like UniKix which is a CICS emulator for many of the commercial UNIXes. There isn't any reason why one of those couldn't be ported to Linux on S390.
Many of the newer IBM mainframe machines are air cooled (no water chiller needed) and could probably be run in a normal house with a decent air conditioning system.
One of the main things the ILOVEYOU virus does is wonk around with the registry. Under Linux/UNIX the equivalent would be messing around with files in /etc for example. It could still be destructive to a single user without doing that, but one of the things it was trying to do with the registry hacks was to try to sniff passwords, which could be used to compromise a lot more things.
it's arguable that the spread of Melissa and ILOVEYOU had nothing to do with security exploits.
Well, that is a matter of perspective I suppose. One way of looking at it is that both of them rely on the fact that there is little or no security in Windows 9x.
So, addressing the original poster's comments, just because they've got 4 mail programs on their system doesn't mean they're "safe", if they all have essentially the same API's
I think that if an API is standard and multivendor, then it, in itself is less likely to be the target for attack because it will be under the scrutiny of a much larger number of eyes. Specific implementations can of course have their own problems, but that is a slightly different issue.
or similar address book files (perhaps XML), etc.
The address books, or their access methods are only part of the problem, in that it is only related to the propagation of viruses/worms, not necessarily to their destructive potential. It also doesn't take into account that Melissa/ILOVEYOU also rely on the ease with which code from outside can get executed under Windows. For the problem to be as bad under Linux/UNIX as it is under Windows, all three things would have to come together on a significant number of desktops. As long as the Linux developer community and the distribution vendors are aware of this potential problem, it is not nearly so likely to happen.
Executability isn't an issue.
Yes, it is. It isn't the only issue, but it is still an issue.
It still comes down to how braindead your mail client is.
The difference is that an email client on Linux/UNIX would have to go out of its way to be as braindead as Outlook is in this case. Just because a file comes down under Linux/UNIX with a certain extension, it isn't immediately going to be executable as it is under Windows.
Let's say a company called Macrosoft made this unix email reader called Inlook, and by default it was configured to execute ".pl" attachments under perl if you double clicked on them.
It would have to intentionally set the execute bits on files based on their extension. That would be an extra effort. If the 'Inlook' email client was open source, something like that would certainly get noticed and fixed quickly. If it wasn't open source, that would seriously limit the number of users who have it on their system, since most of the Linux/UNIX distributions wouldn't include it by default.
Let's say this particular perl program would sit around and watch your mailqueue to grab addresses, and send itself off to all those addresses. The same type of spreading would be accomplished.
This is of course true, but this is only a fraction of what the ILOVEYOU virus, for example, does. It also goes out and wonks around with the system registry, and deletes files. These parts would be less likely to cause problems on Linux than on Windows 9x due to permissions.
This would be possible if as many dumb people used linux as windows,
That isn't quite true, as Linux/UNIX still has a certain amount more security than Windows 9x, and thus will even to a certain extent protect dumb users from themselves.
and if as many people used Inlook as Outlook.
For reasons I've stated before, it is highly unlikely even if Linux/UNIX had the same size user base as Windows that any single email client would ever get the installed base of Outlook.
My point is simply that if we make things "close enough", or if we use
a specification that allows interoperability between products from different vendors.
then we're still vulnerable to a virus.
Possibly, but not necessarily.
You won't find me to be someone who is saying that viruses/worms are impossible on Linux/UNIX. I do believe they are less likely and less likely to cause as much damage, but I do believe and have been advocating that we make sure to keep vigilant to insure that they don't happen on Linux/UNIX or are at least dealt with as quickly and permanently as possible if they do. Unlike Microsoft, I don't think the Linux/UNIX world should put its head in the sand or live in denial.
On the other hand, history has shown that two products which are similar, and conform to many of the same standards may have very different security issues. For example both Netscape Navigator and Microsoft Internet Explorer have somewhat similar user interfaces. If you can use one, you can probably figure the other out pretty easily. They both implement many of the same standard interfaces. HTML, Java, Javascript, etc. However, both have had at least a few security problems (in general, it seems like IE has had far more and far more serious security related bugs), but in most cases, the security problems they have had have not been the same. Exploits which work against one browser don't necessarily work against the other. The same thing is true of many other types of software. I think it is stretching to say that implementing a common interface or API necessarily puts you at the same risk of 'inbreeding' that having everyone rely on the same vendor's products does (as we see now with products like Outlook).
If it's a close enough interface, then I can probably code something to work with multiple variations.
Maybe, maybe not. I have little doubt that in many cases it makes it far more difficult to create a single virus/worm which can afflict multiple platforms. It very definitely rules out many sorts of binary coded viruses, as they are generally tied to a specific hardware platform or OS API.
I'm not advocating homogenaity of implementation (heck, not even MS purports to do that - multiple system elements may expose the same functionality, even though they are implemented in many different ways (e.g. drivers, etc)), but that if we have near identical interfaces, we're still stuck with the problem.
I'm not saying that there isn't any shred of truth in what you are saying, I just think that you grossly exaggerate the risk that is involved in following open, industry standard interfaces. I think you have a lot more of a point when interfaces are partially secret or totally proprietary, as they are not then exposed to nearly the level of independant review.
I saw something on Freshmeat.net the other day called Outlook2Ical that purports to be able to convert Outlook calendar messages to Ical calendar entries. Might be just what you are looking for.
While this is true, and indeed a heterogeneous population is indeed more resistant to infection (biologically and otherwise), at what cost? Like it or not, the current push, fueled in no small part by Microsoft, is to have the same look, feel, and, yes, interface, everywhere.
There is a downside to the push to try to make everything homogenous. One is that it promotes stagnation. Another is evidenced by what we've been talking about here in that lack of diversity can make a system vulnerable to any small weakness that might be found. We need to find a way to allow options for the same interface everywhere, while also allowing for flexibility for people to do things differently.
One thing to think about is that we can have a similar enough look and feel and 'interface' to allow users to use different software without necessarily being forced to all use the exact same products. For instance, if I can drive a Ford or a Toyota, I can adjust to driving a Chevy or a Honda or whatever pretty easily. They aren't exactly the same, the controls may look a little different or be placed slightly different, but it isn't going to keep me from driving. By the same token, if I know how to run one GUI, it doesn't take me long to figure out how to use another.
Having a certain level of diversity in the software community is a good thing. If we had file formats and network formats that were not controlled by vendor interests and fighting, we would be a lot further along here. We could have compatibility to talk to each other without having to be exact clones of each other.
Look at Netscape - they want the same user experience everywhere. This thought process occurs in progamming as well (look at Java - hey, and C!),
The direction that C has gone, and hopefully Java will (and probably would have if it weren't for Microsoft's attempts to derail cross-platform Java) is that it is standardized not on individual products, but on a specification that allows interoperability between products from different vendors.
where if the same interfaces exist in multiple places, it'll be easier to interoperate.
One of the problems the computer world faces is that we need to promote vendor and platform independant standards where they are possible and make sense, while still allowing innovation (as opposed to Microsoft's 'immovation' (immitation)). We (in the sense of the industry as a whole) should change standards or create new standards when there is a good technical reason for doing so, not for vendor specific marketing reasons.
So when LINUX becomes a common desktop OS user are going to have to save their email attachments that are to be executed.
Sending executable content indiscriminantly in email is what has caused this virus/worm problem in the first place. Most of the things that are sent as executables are pretty worthless easter-egg type things anyway.
They're going to have to figure out that the file is to be executed in some way, with no pretty icon
You can have iconic file managers under Linux/UNIX. Both KDE and Gnome do so. Nothing stops Linux/UNIX email client from doing an iconic representation of attachments, in fact there are a few that do so.
(not to mention an extension).
The extension, or lack thereof is determined by whomever sent the file. Under Linux/UNIX they are just optional, and aren't what determines executability, but there is nothing prohibiting people from adopting a convention for using them.
They're even going to have to run chmod on the file to get a script to run. These limitations are all perfectly reasonable on a server OS. They obviously make the system considerably more secure. But if you think that Joe and Jane user who use this as a desktop OS at work or at home are going to figure all this out, I think your overly optimistic.
Given how much problems that Joe and Jane user cause themselves, maybe it is a good thing if they can't figure this out.
Companies can probably afford a few minor disasters from viruses than losing the productivity they gain from clicking on e-mail attachments and having them do what the sender intended.
The question is, how much productivity do they really gain from this? Is it really worth all of the problems that this type of virus/worm can cause to get a few little animated toys? How many legitimate executables are sent via this type of 'push' through email that can't as effectively be sent through a 'pull' and just sending the users a link to a place to download from?
I know this is a huge security hole which requires the user to determine if the attachment is safe based on who they think sent them the message.
The problem is that user's have a hard time doing that when the virus/worm attacks address books. The message may appear to be from someone that the user knows and trusts if that person's computer is an unwitting host for the virus/worm. Unless you impose some sort of digital signature on attachments which this type of user would probably have just about as much of a hard time with as figuring out how to make files executable, you aren't going to be able to trust any executable attachment, regardless of who it appears to be from.
The question is how much ease of use you want to trade for security.
The question is really, how much purported ease of use are you really getting for the unquestioned security you are trading off here?
I think the solution that many have suggested of showing a dialog box before outlook lets an application send an email is a good place for MS to start.
That is a start, but is pretty much a band-aid. Viruses/worms will find a way to disable or bypass that if they can run in a Windows 9x environment where there is little to no OS security. Also too many users will just blindly click through warnings like that, especially after the first few times they see them.
However, it appears they have made some patches to fix some of their security problems, and that sys admin are very lax in applying them.
Part of the problem is that Microsoft has promoted Windows as 'any idiot can administer it'. So - idiots are administering it. Microsoft hasn't done a very good job of informing and educating their user base, so they are part of the problem. They spend too much time trying to spin-doctor and downplay any problems that happen rather than trying to make sure as many people know about problems and apply patches as possible.
Hopefully both MS and those sys admins have learned their lessons.
You are much more optimistic than I. I am not convinced that it will be possible for Microsoft to retrofit security on their existing infrastructure in any kind of short timeframe. I am convinced that anything less than that will not be effective in stopping the virus/worm threat.
The su to nobody fails because nobody's password is typically *'d out in /etc/shadow. That doesn't necessarily mean that the suid ownership of a mail client can't be set to nobody, although that would effectively present a challenge to find a secure way to read a user's mailbox. Not saying it can't be done though.
It is also not true that 'only root can change their user id'. Only root can do so without knowing what the password is. I often log in as one user and su to another without ever being root, so I know that is possible. If the user id's password is starred out, then only root can su to that user id.
I think their OS share is a little smaller than that, like 70-80
Everything I've read states that 90+ percent of x86 based PC's sold ship with a MS OS installed. Now, whether that means that more than 70-80% actually run a MS OS once they are put into service may be another thing, since a lot of servers are purchased to run Linux, BSD, commercial UNIX, Novell Netware, OS/2, etc, and a growing number of desktop machines are going to other OSes as well, albiet not nearly as many as the server market.
I think in terms of desktop machines, you'd be hard pressed to push Microsoft's market share numbers down much below 90% even if you counted in all of the non-x86 machines like Macs and RISC UNIX workstations.
Its hard to tell though, as Microsoft tells different stories depending on who they are talking to. When they talk to the DOJ and/or the court, they have major competition, but when they talk to their shareholders and business partners, they don't have any serious competition. When they are talking to themselves, then they are worried about OSS, but only a little, and mostly only because they have difficulty understanding it.
That could be a workable, albiet inconvenient workaround in the Linux world, where it is possible to run programs under different user ids without logging out. I don't think it would be considered an acceptable alternative in the Windows world due to the fact that their ability to deal with simultaneous multiuser sessions is non-existant to awkward.
I think the sandboxed environment for executing scripts would be a good move for Microsoft to implement, but would be very difficult for them to retrofit at this time. It is definitely something that any Linux/UNIX email clients should think about doing ahead of time so that they aren't faced with having to try to retrofit later.
I am not that sure that signing documents will really help that much, as too many users will be too lazy to bother with setting up encryption or to understand how it works.
Your posting doesn't seem to be as incompatible with what I was saying as you seem to think it is.
The mere fact that the Linux community is varied, is changing, and is incredibly dynamic is exactly what will probably insure that no single email client ever becomes as ubiquitous in the Linux world as Outlook is in the Windows world. There are very few software packages other than the kernel itself that are truly universally accepted, let alone something as high-level as an email client.
The Windows world is different, because it is a monoculture dominated by a single vendor which has an amazing ability to control what software gets bundled with machines. No single entity in the Linux world has that kind of power. Not Red Hat, not Mandrake not SuSE, not Caldera, not Corel, nobody. The fact that there are many different distributions out there insures that there will be diversity in what packages will be used. The fact that it will probably be a long time (if ever) before the KDE/Gnome split is unified likely insures that no single GUI email package will ever become dominant on Linux the way that Outlook is on Windows.
And as I said before, the thing that will really make sure that something with inherent security problems never gets pervasively deployed is that in order for something to be widely accepted in the Linux world it must be open source, which means problems such as these get dealt with quickly.
As for talking about 'the community', that means something different here on Slashdot than it does if I am talking to someone in a different forum. You are reading something into my words that isn't there if you think I use that terminology to be divisive rather than inclusive.
Your points are valid up to a point. Recreating user files is worse than system files. Recreating every user's files is worse than just a single user's files though, which is what you get when there isn't effective multi-user security. With Windows you probably have to fix user files, system files registry files, etc.
The other problem is that unrestricted access to system files makes what a virus can do more dangerous, because it can infect itself into lots of other things. Thankfully, few viruses so far have been really insidious and sophisticated enough to pervasively infect a system and slowly (or at least delayed) start to do things. Think how much more damage these viruses might have done had they only slightly propagated themselves at first so they weren't noticed as quickly, but thoroughly infected the systems, so that at some later point they could go full bore once they had been spread all over the place? Doing this effectively would require that a virus/worm be able to infect system files and not just user files.
No, I still wouldn't be happy with Windows even if they did that. There is a lot more wrong with Windows. Those things would be a small start in the right direction, but the inherent architecture of Windows (yes, even NT and 2000) is poor, and you can't easily retrofit that.
We'd probably be no better or worse off with custodians running nuclear plants than with a 'technician' like a Homer Simpson. Seriously, you aren't giving sysadmins enough credit here. Sure, there are lots of MSCE type idiots running around, but there are a lot of highly skilled people working as admins as well. Admins are the people who are ultimately responsible for the security of their networks, who else should be able to control them?
Its not the assumption that people using Outlook must be using Windows 9x, but more that the vast majority of them are. Also, I think it would be more fair to say that NT security can be a bit tighter. Most of the type of desktop users who would be likely to fall for this type of virus/worm are probably not with it enough to tighten up their security, or worse, probably would loosen things up 'to make things easier'. I've run into a lot of NT users that spend most, if not all of their time using NT logged in as 'administrator'.
Worse than that, they sell the fact that any idiot who can spend a lot of money and memorize multiple choice answers can get certified as a feature rather than a bug.
Vendor sponsored accreditation programs are generally designed with the primary purpose to enrich the pockets of the vendors, and it is more profitable to just certify the idiots than to make the standards high enough that only the people who really understand things rather than just barfing back fixed answers to known problems can pass the tests. Plus by making it easy and pumping up the numbers you can advertise things like 'there are 14 billion certified idiots out there who can administer your network'.
Making things 'so easy any idiot can do it', at least on a superficial level, is not necessarily the best thing in the long run.
I would agree that the underlying architecture of Outlook is the fundamental problem. Disabling the scripting host will only prevent a very certain class of Outlook-related viruses/worms, but won't cause the whole system to be safe. Your suggestions about allowing the admins to control the API at that level would be a much better approach to solving this problem, but I somehow doubt that Microsoft will ever really bite the bullet and do the right thing with this.