Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Is MS security REALLY THAT bad Compared to Open S? 3

Status
Not open for further replies.

Spirit

Technical User
Jul 12, 2002
1,150
GB
Is MS security / coding rally as bad as the media try to make out and is Linux / Sum etc really that secure or is it a case of;

"I found this way to crash a server via a vulnerability in MS Exhchange 2003" Answer "you da man / you go go girl"
and
"I found this way to crash a server via a vulnerability in RedHat Linux" Answer "Redhat whatnow?"

Due to these "flaws" in MS I now have in place excellant patch management, firewalls with server locked down but should it be a case of opening it rather than locking it down?

Just a nice one to debate in the runup to xmas......

Iain
 
Personally I don’t have the time or the energy to argue a thing like this to the end.. but I will just say that I use MS products every day and i have for many years. Sometimes things don’t work right... what do you do when things don’t work right? Fix them. If everyone wrote perfect code.. all of us non-programmers would be out of a job.

Basically, linux/open source, Microsoft.. whatever there is no golden child. Each has its issues of varying severity.. but I will make one assumption that I will stand behind and that is if Linux ran 90% of the worlds desktop computers and be it open source or not.. it no doubt have the same issues.
 
I would love to be able to use open source OS like linux every day and be able to have the productivity and ease of use i experience now. however due to my own ignorance i never took the time to really learn how to use linux. some say its easy.. some say its hard. some day I will just make a linux box for nothing other than learning purposes but it seems every time i try linux its when i want somthing done NOW.. so i always install it.. mess with it for a day or so.. and end up going back to the easy click click 1-2-3 solution.

as for being able to fix bugs on my own.. ive never been a programmer. i knew that i never would be after the first few times i messed with qbasic on my old tandy tl2000 from radio shack. i just dont have what it takes i guess. the only programming i can handle is some web dev. html, php, perl/cgi.. and even with those its mainly only configuration and other small changes to modify scripts for certain uses.

(got a bit off track there)
 
"That way, if you find bugs, you can fix them yourself."

Do you realise that 99.99% of the population that uses these apps doesn't have the knowledge to fix the bug or even want to fix the bugs?

Its like saying all programs should be writen in C so its cross platform compatible when 99.99% of programs don't have to be cross platform compatible. Even when writing them in C you still have issues.

The statement is idealistic and not realistic and that idealistic view is not very ideal. I'd love to see someone tell Joe Bloggs, who is a PA for some CEO, "Hey the program you use is open source, you can fix that bug yourself." and watch the blank stare Joe Bloggs gives them wondering what world they are from.
 
And your argument is like saying that since 99% percent of car owners can't fix their own cars, no one should consider doing it.

The entire rationale of the open-source development model can be summed up by Linus Torvalds' famous quote, "Given enough eyes, all bugs are shallow".

You don't have to fix the bug yourself. Most open-source projects have excellent public bug-reporting and public bug-tracking. Where Mi¢ro$oft allows a user to report a bug, there is no mechanism where a user can see the disposition of the report.

Want the best answers? Ask the best questions: TANSTAAFL!!
 
To me that's one of the things about Open Source that is often brushed under the rug.... namely: Popular, widely used products benefit from the paradigm, specialty software for your company, or your niche group does not necessarily benefit. Or to adapt Torvald's quote, only a certain number of Open Source projects have enough eyes. And then of course there are a couple programs which are just too complex for most eyes.

It may seem obvious, but it's exactly the programs with a lack of eyes which anti-open source individuals focus on, claiming lack of support, or lack of debugging or structured code or whatnot. Comments like "Most open-source projects..." get troublesome, because the potential (and the reality) of it is, there are thousands of open source projects which are already dead in the water, have no public tracking etc... the difference is, the code stays out there in case someone wants to pick up on it in the future, if it were a closed source project, it would be bankrupt and unavailable at this point.

Anyway, my two cents.

-Rob
 
sleipnir214 "... no one should consider doing it."
You've put words into my mouth once agian that where not there. I didn't say "no one should consider doing it." I said 99.99% of the population either can't or don't have the resources to do it. By resources I mean time, personel, tools, money.

To take your analogy I've rebuilt a few of our F150's engines when I was younger but when the bottom end of my engine went I had a mechanic do it because it was more practical as I didn't have the time, tools or desire to do it myself.

Please don't try to fish for meaning that I haven't put into my comments.

I agree with you about their bug reporting system but they have a policy of don't admit to a bug until their is a patch or workaround for it. This limits the dmg bugs that can cause exploits will do. Do I agree with it in all cases? no. But then I don't agree with full discloser of bug that on open source that have high risk of being exploited. You don't have to agree with me on this as this is just my opinion.

Don't get me wrong. Dispite what some may believe I like open source products. I like closed source products. The desciding factor of which I'll choise in a given case is based on a number of factors. I will not pick a open source package for the fact that if there is a bug the end user can fix it. I will not pick a closed source product if it doesn't meet our needs and can't be fitted into the overall design. I won't pick a open source product because its open source and modifyable by use to do what we need if a closed source product can be fitted in to do the same functionality at a lower cost. Don't get into cost over time or that open source is free (as I've proven not all open source is free) because what I concider cost initial cost, development cost, cost of maintenance and support and cost associated with risks.
 
Just a note SemperFi, 99.99% of users may not consider spending the time/resources/personnel etc.... and more power to them... but when you're running a business with big bucks, and you want to roll out an enterprise level tool, it's nice to now that if that company goes belly up and you find a critical bug, or if that product gets discontinued, you have the option of hiring expensive developers to fix it for you rather than just being out of luck. I had this unpleasant experience on a much smaller scale not so long ago.... doctor's office running a system from the mid 80's, developer who created it had long since retired and the code had been lost. Just some binaries floating around... about 6 weeks of 4 people manually entering data, and the error rates, and whatnot... and like I said that's a tiny scale. Imagine a system with specialized hardware.

Personally, I think the fix for that is a mandate for source to be released when the owning company goes belly-up or discontinues a product... but that opens up a whole can of worms, especially on the discontinue/upgrade path issues.

I completely agree though, there are times for each, I love'm both too.
 
I've held off commenting in this thread up untiol now because a percentage of it has been dogmatic. Without specifically saying who has been the more dogmatic, I think it worth pointing out that "Given enough eyes, all bugs are shallow" is not a famous Linus Torvald quote. It is actually a quote from Eric Raymond in his 1997 book 'The Cathedral and the Bazaar' (although he later credited Torvald, in 1999, with inspiring the concept). So that's fallacy number 1. Fallacy number 2 is the immediate follow up in the same post that Linus's Law somehow makes Open Source better because MS users find it difficult to report bugs transparently. Well, the Bazaar model that Raymond (and Linus) were referring to was the developer model, not the user model. Now, I'm quite prepared to agree that a peer-review process is a good idea, and the more peers involved the better (from one point of view anyway), but the leap to suggesting that non-peers are a) a good thing and b) that a lack of a non-peer process is a bad thing is a leap too far for me (and not what Raymond or Torvalds were trying to say).

There are a number of other assertions in this thread that are based on dogmatic belief rather than the facts as they actually occurred or are. Can the thread get back to discussing security issues, and not fighting the 'Micrsoft are evil/open source is the light at the end of the tunnel' wars?
 
" but when you're running a business with big bucks, and you want to roll out an enterprise level tool, it's nice to now that if that company goes belly up and you find a critical bug, or if that product gets discontinued,"

This falls under the "cost associated with risks."
I don't concider MS going belly up a risk. I do concider life span of products when evaluating them. The "business with big bucks" would fall under the .01% I was talking about. I and the companies I work for might fall under that .01% to. It just depends.

If I goto a director and say "We can use this open source solution but it will cost about 50k in development cost and we'll have to deploy this product to all desktops which will cost est 30k and we'll have retrain all the users in the new product which will cost another 150k, and because of this if there is a problem we can spend a bit more money to fix it because we have the code or we can stick with the exsisting product, development cost is estimated at 15k. The risk of the exsisting product having a critial bug that our coders can't handle and the products manufacture won't fix over the expected lifespan of this product is minimal but I recomend the first option because I #&$@ed in the head." I'd loose my job before you could laugh at my last statement.

As for systems you are talking about you are looking past the lifespan of that product. They got into a very risky area. I don't expect systems to last that long and if we do we design them so they will work. I have contracts with hardware manufactures to support machines that are over 5 years old. These machines, because of the support contracts for the extended life span, cost about 6 times more then generic machines that probably could have done the job but after 5 years if one broke it would have been impossible to get the required parts. If I'm dealing with a CoTS product I look at the manufacture and figure in life span and support to said product. If I'm dealing with a 3rd party developer I make sure that clauses go into the contract that we hold code bases for the product. If at all possible we purchase the IP of the product to. If we can't purchase the IP then another clause goes in stating that if said company folds IP is transfered. I also get support contracts for the expected lifespan of the product.

I agree about the belly up issue you have and that is why I make sure the contracts are writen up properly and followed through with. But this all has to be factored in the "risk" catagory and you mitigate it accordingly. BTW the situations described above I've gone through.... all but me suggesting that we use a open source solution for a component that would have cost the organisation a additional $200k+. It was documented that we concidered it along with a cost benifit analysis. Don't even go there about if they used the open source solution they wouldn't have to pay for licenses in the future etc. All that was factored in and in actualality the TCO went throught the roof because the numbers went through the ceiling because of redevelopment costs of a large number of other systems.
 
Learnt the definition of a new word thanks strongm.....I'll limit myself to the originial post from now on.

Personally I don't know what what the review process withing MS are. I do know what the review process in some branches of IBM are along with review in Motorola. I also know the review processes in many smaller organisations and been involved with a few open source projects. I can tell you they are all different. Even with IBM different branches/offices have different review processes. I've seen stuborness in all cases and I've seen exceptional acceptance in most cases. Design tend to be a bit more stuborn then coding. Its easy for me to say "Why don't you do this code like this and it should be better because of this" and get exceptance then "I don't think you should design it so it can do this that way because of x". This last statement has been hard to get through on both sides of the open source fence.

Code review has a good opertunity to stop code based bugs. Open source means that more people can review this code. But as other have put it actual features of open source project, like the linux kernal, are not really open for many to say "Hey I don't think you should impliment that because of ....". So really like strongm has pointed out we have to look at this 2 different levels.

1) Is the review process available in open source generally better then closed source as far as code based bugs. This would include things like buffer overflows etc.

2) Is there more chance of effecting actual design and addressing possibility of design based flaws in an open source project.

Lets take the issue of outlooks preview pane as an example of a closed source issue. The issue is that because of outlooks ability to recieve html formated mail and outlook wanting the feature of being able to display a small preview of that mail to the users and not have to write their own HTML renderer they went with the decision to use the IE component that is already developed. I admit having more eyes on the design of that project would have had someone point out the risk of the said component in it then current state to automatically execute code even if the user didn't want that. But the same can be said for opensource projects that have implimented scripting into their product. Its a danger of implimenting scripting into items that used to never have any type of executible code.

Its also interesting to note the open source projects on SourceForge.net and what OS they target.

It would be interesting to look through these projects and see 1 what the bug rate is and what types of bugs they are encountering and 2 how much these project are acceptant of design changes do to potential issues that have been thought up. It is not possible to do this to closed source projects on any scale. Note this feature is doable on opensource because of Source Forge. Not all open source projects feature this. Many closed source projects include knowledge databases of their products showing what bugs have been found and what their status is.

Note that MS have recently put in the following feature "Windows Error Reporting has a new feature. With this feature, you can automatically view responses to Windows error reports. After you submit an error report, you can immediately view any available information that relates to the issue, such as hotfixes, workarounds, or other relevant information. "

Its really hard to answer this questions because of apples and oranges etc. You would have to find 2 like products with like feature sets and compair them. But then that wouldn't be enough because that is only 2 projects and statistically that isn't a good sample. So you'd have to continue to find matching products and continue and what one person considers a design feature another may concider it a bug and useless.

 
SemperFiDownUnda:
Code review is a good idea. But when you have code integrated to the level of Mi¢ro$oft's, you have to review a lot.

I recall the time Mi¢ro$oft had a progamming stand-down in 2002 to perform a "code scrub". Good idea, but one number I've read is that Windows 2000 alone consists of 50 million lines of source code. And to their credit, they found a bunch of bugs that they then released patches for. And you can review that much code in the 6 weeks Mi¢ro$oft devoted to the project -- but you can't also review all of Office and Mi¢ro$oft's other products in that time. And when you have code that integrated, you have to look at everything, else some bad design decision in another product rear its ugly head. Like the preview pane code execution bug.

strongm:
"fallacy number 1"...
So you're saying that because I attributed the quote incorrectly, it's not true? I don't follow your logic.

"fallacy number 2"...
So end-users are not part of the review process, and not listening to their complaints it not necessarily a bad thing? I don't get this one, either.

Want the best answers? Ask the best questions: TANSTAAFL!!
 
Regarding the statements that both Windows with proprietary code and open source code such as Linux have had numerous yet roughly equivalent vulnerabilities found and fixed in recent months, I'd like to add one small comment.

Everyone can freely examine open source code whereas few if any outsiders are allowed to do the same with closed source code. So while we may see vulnerabilities discovered and fixed in both camps, the fact remains that there is a major difference between the two:

On the one hand, everyone including lots of bad hacker types have scrutinized the open source code and yes they've found vulnerabilities.

On the other hand, we've seen similar results concerning closed source code but presumably that was possible only by either decompiling it on the sly or pounding bad or unexpected input against the routines. I wonder how many more undetected vulnerabilities would be discovered if that code were freely available...
 
Meriam-Webster
Fallacy
2 a false or mistaken idea
3 an often plausible argument using false or invalid inference

The first fallacy was the mistaken idea that Torvald's made the quote, not that the world view the quote itself espouses was necessarily mistaken

The second fallacy was to make a plausible argument concerning the inability of users of Microsoft software to make use of an effective bug-reporting mechanism and thus be unable to contribute to making the software better from the false or invalid inference that this is what the quote was about. It wasn't. It was about developers and the developer environment.
 
The incorrectr citation, however, neither makes the statement false nor was it an invalid inference.

And if the developers don't know about a bug, it doesn't really matter what their depths are. Thus the need for adequate bug reporting and tracking.




Want the best answers? Ask the best questions: TANSTAAFL!!
 
dbMark - Thats kind of the point of the debate (though it has veered OT a few times).
The question we're looking at is basically: Is MS (closed source) security worse than Open Source security.

The flaw I find it odd that no one has pointed out yet was that the comparison is MS products versus Open Source products. A lot of people have trimmed down the general term "Open Source" and are answering the new question "Is MS Security that bad copared to the most secure Open Source projects you can think of", and of course this also led to the ever-present "MS Windows vs Linux Debate"...although debate may be the wrong word because generally the people involved are _Right_ and it would require a new ice skating rink in a particularly hot place before they could consider actually changing their mind.



[sub]01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111[/sub]
The never-completed website:
 
dbMark, I agree with you in part. I also think that if it was "more cool" to hack linux that you would see more bugs found on that side of the fence.

Tarwn I know in my responces to posts I've focused on MS because that was the closed source getting bashed. But I've all along had a broad definition of open source to include open source projects on the windows platform. Closed source I continue to refer to other companies both large and small like IBM and Motorola. Thank you for pointing out that this shouldn't be made into a MS vrs Opensource as you pointed out we are talking about Open Source compaired to Closed Source.

If I wanted to slant the view I'd point out the best written software in the world generally comes from Motorola using six-sigma quality methods. For those of you that don't know this means that there is only 1 bug to every million lines code produced. Most of Motorola's software is closed source. I don't know a single Open Source project that has that level of QC. Does this mean that closed source is better? No it means that Motorola's quality control is better. The fact that it closed source is irrelivant.

I like this quote
"Open source thesis that thousand of eyes looking thu the code increases software quality is completely wrong. The amount of bugs per line of code is an universal constant. The bazaar model only achieves a quick bug turnover."
I know the "universal constant" usually refers to bugs per line of code when compairing languages....I just find the statement above funny.

Which led me to think of another article I read over a year ago, thanks slashdot,
If Redhat only packages up and distributes other peoples programs, sleipnir214, why would their distro be SOOOO much buggier then others? They must have really bad QA practices compaired to Slackware.....thats it.



2 a false or mistaken idea

The first fallacy was the mistaken idea that Torvald's made the quote,


with strongm spelling it out exactly it amazes me that you still either do not get his meaning or you are trying to twist it so other people look at it the wrong way from your statement of "The incorrectr citation, however, neither makes the statement false nor was it an invalid inference."

Strongm never said it was a false statement just that the quote was mistakenly credited to Torvald's
 
What I thought was funny about the string of posts that followed was the one that referred to bugs/LOC as a measurement. Take a look at their math real quick and see if you can see the slant in their logic.

Basically the (il)logic goes something like this:
If MS Windows has 30,000,000 LOC Then
you can expect 120,000 to 180,000 bugs
be nice and drop by 50% to 60,000 to 90,000 bugs
pretend only 10% are noticed - 6,000 to 9,000 bugs

RH only has 250 (it quoted 2000, but this number was wrong) and must have close to 30,000,000 LOC so it is therefore less buggy than MS Windows

So all of the logic here falls down on one factor: He was guessing the number of lines of code, guessing how good the debuggers were, guessing how many bugs are found and reported...which causezs the entire string of logic to be meaningless.

For the record, I wasn't pointing out anyone in particular with my previous post. Also I work with Windows and run a Win2k Server box, a Mandrake 9.2 box, and a laptop dual booting to Win2k Pro and RH 8.x (it's my own personal build, who knows what it qualifies as).

And I'm not sure that whether or not companies make money on their products has anything to do with the question at hand, but:
Redhat is publicly traded. They make money off x% of people that install their product through sales and support. That money is then partially used to support OpenSource projects. If a project receives enough money to pay for programmers to live, but not to profit it could be considered non-profit. This doesn't mean they don't make money, only that they don't have money in the "profit" account, they put it in the "R and D" acct...and while they probably don't actively sell their project, they likely go to meetings with large distro companies (like RH, Suse, Slackware, etc) and explain how for x amount of funding they would be willing to let them include their free project in a commercial product...which is sales when you come down to it.


Anyways, I've rambled off topic but that covers 3/4 of this thread so i figure i won't get in to much trouble ;)

-T

[sub]01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111[/sub]
The never-completed website:
 
SemperFiDownUnda:
I'm just taking issue with strongm because he calls the my statement fallacious...but then uses the quote to support his own arguments.


All:
My contention is simple. In my experience, the larger a program, the harder it is to get all the bugs out of it.

I haven't been able to find out how many lines of source code exactly, but this site , which provides training to Windows source code licensees, uses the phrase "tens of millions of lines of code". The Wikipedia ( puts W2K at 35 million and WXP at 40 million.

I have made no claim as to the number of actual bugs, nor have I claimed that the number of bugs was linear. I have simply claimed that the larger the program, the more bugs it will have. At least, this is my experience as a professional programmer.


Then there is the API question. Suppose I want to compare apples to apples, in terms of functionality between Win32 and Linux. On the Linux box, I would install the Linux kernel, Samba, XWindow (or more precisely XFree86), and one of the more complex desktop managers such as KDE or Gnome. On the Win32 side, I'd have to install XP with Terminal Services to duplicate XWindow's multiuser GUI capabilities.

But with open-source OSes, I am not required to install Samba, XFree86 and a desktop manager unless I need it. Regardless of the distribution of the bugs, if you do not install the code, that code's bugs do not affect your system. Unfortunately, I do not have the luxury of not installing a GUI and desktop manager in Win32. I can choose to not install Terminal Services, but I have no choice over the monolithic core system.


Another factor in determining whether a product is secure is how reactive the producers are to fixing defects. Mi¢ro$oft is notoriously slow in fixing defects in code. Although they are better than they used to be, their turnaround time is, they still are taking weeks for some bugs. Turnaround time in the opensource community is much quicker -- typically measured in days and sometimes hours for open-source projects.

In the bad old days, it was sometimes months before Mi¢ro$oft would even admit that a bug existed, then months more before a patch was released. With open-source code, it's pretty easy for any programmer to verify the existence of the bug, and difficult for the author to deny that it's actually a bug.


Want the best answers? Ask the best questions: TANSTAAFL!!
 
sleipnir214 - The issue you've described about modular subsystems is not unique to open sorce. Agian you focus on Microsoft but if you follow Microsoft's development plan you'll see that Microsoft is looking at doing the same thing. That is letting the user Select what sub systems that you install. But to MS's current system you CAN choose not to install many systems.

By your logic we should not try to design large systems be they open source or not. I agree large systems are more prone to bugs because of their complexity. But I don't think that we should stray from developing these applications if the perform a needed function.

Lets try to keep this out of the MS bashing areana. I'll focus on solid and proven closed source projects developed by companies like Motorola and IBM. IBM is a great example because they deal with both sides of the fense. I would not put IBM's opensource projects as more bug free. I would say that Open Source does let anyone fix a bug but if you've worked on large systems it is quiet possible to create another bug by fixing one. In a closed project you have responsible people for different systems. You go through a controled procedure to fix a bug because if you go in and cowboy code there is a chance that you'll make things worse even if you fix the bug.

If we take Linus as an example even he doesn't use only GPL opensource software. As I remember it he uses Bitkeeper as the source control software for the kernal. Why doesn't he use CVS? It is open source.....It is free......I think it is safe to say that he has the ability to build in the features he would want. So why does he use a commercial product? Because the product provides him with the features he needs so he doesn't have to worry about fixing/modifing it himself.

As far as strongm all he said was "...is not a famous Linus Torvald quote".

You say "he calls the my statement fallacious"
He does not.....he calls who you credit the quote with fallacious. He never says the statement if false. Seriously you read other things into peoples comments. Around here you should try to read peoples lines and take the meaning from them and not try to read between the lines.

"Do not try to read between my lines. You will not find anything there besides a sea of white. All meaning inferred are for all to see in the words I write."

Thats a not so famous quote from me from about 10 years ago
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top