I've been using Linux for a few months now. I've been speculating on things and I wonder if I've come to the right conclusions.

I have heard it said that MSwindows (of any variety) is the least secure operating system. Weaknesses in MS email client software are severe but apart from this is it fair to say MSwindows is less secure ?

Consider: in order to (elegantly) trojan a commonly used app under an open source OS (OS OS?) it is a matter of doctoring and recompiling the provided sources. This could even be a cut and paste combination of two commonly used apps and a little bit of stitching code (for example). To (elegantly) trojan a commonly used MSwindows app would require the same process to be done in x86 assembly, after disassembling (easiest way). Obviously the second path is less inviting and as a bonus the c could be recompiled for a number of architectures (highlighting MSwindows inflexibility - but true still).

Consider: that as an OS for attacking with *nix are extremely popular and the black-hats are likely to be intimate with their environment of choice. To be blunt, unless a black-hat is actively examining MSwindows and apps for weaknesses he probably doesn't even have the time of day for them. He will look for weaknesses in *nix because the search may yield knowledge about the environment in which he operates even if he finds nothing exploitable (he has more chances to find "useful" information to him).

Yes it's true script kiddies are more of a threat *but* script kiddies follow in the footsteps of black-hats ... script kiddies may also go for MSwindows vulnerabilities because of the target volume (security through obscurity is not a strong case for an OS).

It seems that MSwindows has serious worm vulnerabilities and *nix have serious trojan vulnerabilities. MSwindows no doubt also has "stupid user" vulnerabilities to a much greater extent (but again this is not much of a case for the security of the OS per se). Linux has more "inexperienced user" vulnerabilities I suppose if I want to look at it that way.

Don't misunderstand me - I'm solidly in the Linux camp here, this is not flamebait. In fact I'm becoming quite enamoured of Linux - I just wanted some opinions on the points I have raised.

having the source available cuts both ways, easier to insert malicious code, easier to find it. always download from trusted locations,and md5sum the package before extracting it. SuSE and others have started using pgp signatures as well, to allow you to verify the package is actually from them.

As a consultant, I am forced to "ride the fence" when it comes to choosing sides. I can't be swayed in either direction for fear that my next job could be working on Windows servers. Aside from that my personal preference is *nix environments due to the fact that I find them extremely easy to work with. They are just plain easy to understand for me.

My observation has been that Windows is unsecure mostly because the programmers there were told "put up or shut up" in terms of features and security was not important as it just slowed them down. This was the reason that most software that comes from them does no bounds checking on variables or input. That is why you see the rash of buffer overflow vulnerabilities come from them.

And I think (in my personal opinion) that there are only a handful of black-hats that are actually any good. The fact is that you don't have to be. Just simply begin passing extremely large arguments to an application and see if it crashes. Or go out and download a fancy little virus writer and begin tweaking the code until you crash something. (hence script kiddies)

When you open your source, you allow others (programmers, black-hats, grey-hats, and white-hats) to see your code and then you get feedback on where there might be a buffer that doesn't check its input or any other weaknesses. Then you take this feedback and you insert it into your code and you re-release. You do this as often as needed (eXtreme Programming) instead of simply patching or waiting till the market is ready for a new release (Microsoft). Not that patches are a problem, but the truth is, a good majority of the computer using world doesn't care about patching their systems (mostly home-users).

<disclaimer>
the views expressed here are the opinions of the author and do not represent anything at all.
</disclaimer>

just my $(square root of .0004)
Jeremiah

So MSwindows is also very vulnerable to buffer overflows. I had (for some reason) assumed that since they bring out a new release every year they would have addressed this. What was I thinking ? They fooled me with the shiny GUI.

As for forcing an app to fall over with a buffer overflow, how pathetic is that ? Petty vandalism, not hacking. In the words of police chief Wiggum, "Suspect is hatless, repeat, hatless". Or perhaps a new category : Black hat, Grey hat, White hat, Reverse baseball hat.

Weaknesses in MS email client software are severe but apart from this is it fair to say MSwindows is less secure ?
Yes. For instance you can easily make NT4 loose it's C2 security rating by simply connecting it to a network. Ok, that's a bit lame argument since no one has put forward the money to have Linux tested as comparison, but still it shows that in itself the OS is considered less trustworthy in the security sense when networked.
Since I've been working with Linux in both the personal and professional context I've come to respect Mockery$oft for what they do best: handling the "difficult parts" of users' productivity apps wrapped behind the GUI, which in most cases works flawlessly. Drawback is the needed sharing and tight integration of functionality also brings to light it's vulnerabilities. Like for instance simple HTML-rendering or scripting capabilities users seem to have wanted. Flaws in the code then do not only affect MSO and MSOE, but WMP as well as any 3rd party dependent apps like for instance Qualcomm's Eudora, and since MSIE/Windows Explorer... ah well, you get my point.
Throw in the Mockerysoft invented way (IIRC) of releasing software of beta status, happily forcing users to be their guinea pigs for software development. Granted, Open Source software does the same, but here it's you being a guinea pig of your own volition plus the added bonus you can help extend functionality or help make it more secure.
Another simple example is the ancient reliance on file extensions instead of proper file magic. You *know* what tricks you can pull by renaming files. Here Linux seems to be heading the wrong way for some projects as well. I can't remember what Gnome app it was. I think it may be a versatile X cutbuffer app, but it relied on another project's libs that help determine file contents from their extension names. If this is going to be a std item because developers haven't learnt from mistakes, then I feel sorry for the users that think they're safe on Linux.

Consider: in order to (elegantly) trojan a commonly used app under an open source OS (OS OS?) it is a matter of doctoring and recompiling the provided sources.(etc)
This touches the core of Open Source software development. We don't have strict auditing caps like openBSD has, not all Open Source projects are supported by tens of knowledgable developers and thousands of users who keenly scrutinize each piece of SW that comes along, we don't have a central clearing house for something like software signatures (admittedly would be very hard), not all developers/vendors use GPG signed packaging or even MD5sum it like Rshaw points out, and not all software depots are guarded very well. Popular examples include an Irc client, Venema's TCP Wrappers, and lately OpenSSH and Sendmail, of which only the TCP Wrappers package wasn't compromised on it's official server. And let's not talk about other devious ways to spread backdoored SW like Squid cache poisoning :-]
I don't have to make a case against closed software I think. Essentially I don't think the means of compromising software are that interesting here, it's the goals compromised software have that are (to me).

Btw, IMO "security by obscurity" never is good unless you have carefully weighted it's purpose against it's drawbacks and have incorporated it in your plans only as it is: a simple deterrant to filter the experienced from the more experienced.

It seems that MSwindows has serious worm vulnerabilities and *nix have serious trojan vulnerabilities.
If you for instance define "worm" as "a self-replicating, self-propagating application" and a "trojan" as "an application posing as another application", then both platforms suffer from them, but *nix systems suffer easier because of wrong/bad/not timely maintenance. In any case the amount of "rewtings" doesn't matter to me, the possibility suffices.

MSwindows no doubt also has "stupid user" vulnerabilities to a much greater extent (but again this is not much of a case for the security of the OS per se). Linux has more "inexperienced user" vulnerabilities I suppose if I want to look at it that way.
Even if you mean "stupid user" as in "spineless GUI-spoonfed wetware package w/o implemented cerebral functions" (also called "account manager", or "director of sales", or even worse "vice president of development") you still have to find out if the errors are those of the SW (and if it takes the supporting OS with it) or solely those of the OS. Brings to mind the Yorktown Smart Ship "incident". Basically what the discussion centered on was if the error was caused by I. a human error (the dba entered a zero), II. an application error (application should not have accepted an error in particular field, also should not have propagated "false" info over the LAN) or III. an OS error (exception situation should not have killed all backup PPro's on the LAN).

If I reword jdc2048's remark about input validation etc, I would consider the fact a lot of Open Source software is made because it's developers have an itch to scratch about *nix missing some functionality. The core for having this itch exists in everyone but the knowledge to (and practice of) coding securely does not. Also for some apps developers are forced to decide wether to rewrite code to dump less secure legacy code in favour of more secure code at the expense of having to invest much more time, or happily live on with legacy code at the expense of having SW that has a one in a million chance it's gonna be b0rken. In any occasion, feeding an app output like zero or from "perl -e 'print "0" x 100000'" shouldn't break the app in question, and certainly not the supporting OS.
Closed software development, IMO, is driven more by "external" factors like the time-to-market, share-holder and (expanding) marketshare value the application adds to the company. These in turn can cause a short-circuit in mgmnt decisions leading to leaving out a few iterations of proper technical design, peer reviews, prototyping, quality control, bugfixing or userbase testing in favour of achieving goals that are good for the company at the expense of both product and users (as I've experienced).

On a sidenote, if you have followed the last few great incidents you'll notice that buffer overflow detection and the resulting fall-out like sharing procedures for reproducing or testing, vulnerability reports, exploitable code and fixes have been (are still?) "held hostage", even by "respected" "firms" like ISS (Apache/OpenSSH cases). In "black hat" cases protecting circulating code among peers to gain Mana is important, but for firms having to sell solutions to their clients (like ISS does) before alerting the public in full is IMNSHO despicable beyond words. In the case of Sendmail it was stupidity beyond words on Sendmail Consortium's site to not communicate instantly to the developer to shut down his server. doubt also has "stupid user" vulnerabilities to a much greater extent (but again this is not much of a case for the security of the OS per se). Linux has more "inexperienced user" vulnerabilities I suppose if I want to look at it that way.[/i]
Even if you mean "stupid user" as in "spineless GUI-spoonfed wetware package w/o implemented cerebral functions" (also called "account manager", or "director of sales", or even worse "vice president of development") you still have to find out if the errors are those of the SW (and if it takes the supporting OS with it) or solely those of the OS. Brings to mind the Yorktown Smart Ship "incident". Basically what the discussion centered on was if the error was caused by I. a human error (the dba entered a zero), II. an application error (application should not have accepted an error in particular field, also should not have propagated "false" info over the LAN) or III. an OS error (exception situation should not have killed all backup PPro's on the LAN).

If I think about jdc2048's remark about input validation etc, I would consider the fact a lot of Open Source software is made because it's developers have an itch to scratch about *nix missing some functionality. The core for having this itch exists in everyone but the knowledge to (and practice of) coding securely does not. Also for some apps developers are forced to decide wether to rewrite code to dump less secure legacy code in favour of more secure code at the expense of having to invest much more time, or happily live on with legacy code at the expense of having SW that has a one in a million chance it's gonna be b0rken. In any occasion, feeding an app output like zero or from "perl -e 'print "0" x 100000'" shouldn't break the app in question, and certainly not the supporting OS.
Closed software development, IMO, is driven more by "external" factors like the time-to-market, share-holder and (expanding) marketshare value the application adds to the company. These in turn can cause a short-circuit in mgmnt decisions leading to leaving out a few iterations of proper technical design, peer reviews, prototyping, quality control, bugfixing or userbase testing in favour of achieving goals that are good for the company at the expense of both product and users (as I've experienced).

On a sidenote, if you have followed the last few great incidents you'll notice that buffer overflow detection and the resulting fall-out like sharing procedures for reproducing or testing, vulnerability reports, exploitable code and fixes have been (are still?) "held hostage", even by "respected" "firms" like ISS (Apache/OpenSSH cases). In "black hat" cases protecting circulating code among peers to gain Mana is, but for firms having to sell solutions to their clients (like ISS does) before alerting the public in full is IMNSHO despicable beyond words because this shows 'em put profit before public security. In the case of Sendmail it was stupidity beyond words on Sendmail Consortium's site to not communicate instantly to the developer to shut down his server.

Anyway , I think this is what Orwell meant to make 'em beasties say in Animal Farm: opinions ggghhhoooood, facts beeehhhhtter.