Slashdot Mirror
Is Netscape's Code Falling Apart At The Seams?
bobby writes: "There a commentary on SecurityFocus that has me thinking: they argue that the infamous Brown Orifice holes in Navigator are examples of a new type of security hole that results, not from bad coding practices, but from coders haphazardly interconnecting disparate components without considering how they'll work together. 'The most dangerous, well-concealed, complex, and noteworthy security flaws in the future will be of this sort,' they write, adding that only the Mozilla project can save Netscape. "
but doesn't AOL more or less own netscape? I have never heard AOL even *mention* netscape since their "partnership" (or whatever it is) took place. This seems like a pretty good sign that AOL doesn't expect anything worthwhile out of netscape. Or perhaps they're just waiting for mozilla? Either way, netscape is in poor shape, a nd I'm distraught over what seems to be its impending doom. I really *don't* want to have to use IE.
"It is well that war is so terrible, lest we grow too fond of it."
Time is fun when you're having flies.
-Kermit the Frog
http://www.uwsg.iu.e du/hypermail/linux/kernel/0007.3/1305.html
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
From everything I hear MS puts a lot of emphasis on the software process. This doesn't prevent them from succumbing to the same failures. Complexity is the enemy of security, and paraphrasing Brook's law... The complexity of a piece of software goes up as the square of the number of modules (features?) involved. Examining a product like Netscape, or IE, even good engineering practice cannot prevent such an extremely complex systems from behaving chaotically at some point. Now add to this short deadlines, and insufficient knowledge: of programming, of the off-the-shelf modules being used; and of the design of the system by the programmers writing it and you have holes waiting to happen. It is a credit to the people writing the software that such holes are not discovered more often.
--locust
examples of a new type of security hole that results, not from bad coding practices, but from coders haphazardly interconnecting disparate components without considering how they'll work together.
If you don't consider how components will interact when used together, then that is bad coding practice. If it's easy to use a component incorrectly, to the point of causing security problems, then I would venture a guess that the component in question has a bad interface. When we write code at work, my co-workers and I strive to have classes which are pretty much impossible to use incorrectly. Contrast this with something poorly designed and implemented like MFC which, when functions aren't called in exactly the right order at exactly the right time, it ASSERTs. If anything, it just sounds like the developers should revisit the ways their classes interact with each other and tidy it up a bit.
It's all just bad coding practices as far as I can see...
Thankfully, IE 5 for the Macintosh spurned this 'innovation' and stuck with the hardened method of a config tree with sub-categories. I can install a fresh version of the browser and have it all configured in a few minutes. I still don't have the Windows version of IE configured the way I want it.
Another thing is that integration between the OS and the WWW is probably one of the creepiest, low-browed things I've heard of. There are just too many security problems associated with the internet to have a major part of your OS interface completely linked with it. This is ironically the problem they are noting with netscape.
I want to be able to browse in an encapsulated environment on a browser that 'utilizes' as few of the exploitable WWW technologies that exist. For this reason I use Lynx or w3m for 90% of my browsing. I fire up Mozilla for those inept pages who have no other way to use it except for javascript.
That right there is the largest concern I have with IE, the tight integration with the OS and filesystem. Not to mention mail, news, office documents, and the core scripting languages of the OS itself. Yes, you can turn a lot of that stuff off, but does it come that way by default?
V
The coders over at Netscape work hard, and they are only human. There's going to be bugs in everything. The discovery of these bugs enables us all to learn from these mistakes and not incorporate them in our own programs. Maybe instead of trashing Netscape, we should dedicated some time in helping.
--Dave
And what does it say for the kitchen-sink concept of software definition and development, in general.
To go one step further, what does it say for the concept of pay-for software?
Outside of games, developers of pay-for software generally keep buyers coming back year after year for upgrades by adding new features. Somehow it just doesn't cut it just fixing bugs. Those shouldn't have been there in the first place, and admitting that you're just fixing bugs means that you should be giving it away.
Now we're seeing a claim that in a rather fundamental fashion, feature accretion is not a good thing.
Now to take a 180, sometimes feature accretion just may be necessary. So how do we do it in a secure, reliable fashion? Is COM the answer? Does MS really have it licked? I say that with tongue in cheek, because I believe MS values speed to market and profits over ALL else. But maybe they have a kernel of a good idea. Of course, I was in the OpenDoc camp, in the old days.
The living have better things to do than to continue hating the dead.
What makes IE so insecure is it's application of this technology to equal what Java was touted to do:
While Mozilla contains a number of XPCOM components it is not possible for standard HTML to instantiate or exploit any of them. Standard HTML can only instantiate the standard set of Javascript objects and everything else is off-limits.
Only chrome can create arbitrary XPCOM objects and that's the implicitly trusted "application" that your Mozilla engine is running. AFAIK skins are treated as untrusted content.
Does that mean Mozilla doesn't contain bugs? Of course not, but it is designed to be safer than ActiveX controls in IE from the outset.
Doublespeak: Adding more programmers fragments the knowledge, but not if they're open source programmers, because they have the magic ability to "review each others' code", which is impossible if you have the wrong kind of license. And Brooks' Law doesn't hold because Eric Raymond said so. Better still, he quoted someone else saying so.
The initial premise is dodgy too; to support the thesis that the component model is to blame, he uses the example of Brown Orifice which comes about because of three things: Java, the Java Core and the Netscape JVM. That's one thing, in my book. Why stop at three? The Netscape JVM is coded in C, so that's a fourth "component". And the Brown Orifice hole serves your files via IP, so that's a fifth. Bollocks.
The outright lie; Mozilla has been coded "from the ground up". Like hell. If this is the case, why does it have anything to do with Netscape at all? Why, indeed, did the OPen Source Community need to wait for Netscape to open the code base, if there were all these people around who could code a browser "from the ground up". Mozilla has been coded, at best, from the scaffolding.
And then we get told that all problems will be sorted out in 6.0, for that is based on Open Source. Great. If, say, ZDnet put out an article on Microsoft security and concluded it with "But the next piece of vaporware coming out will surely solve all of these problems", they would be castigated to hell and rightly so.
A serious lack of critical judgement.
-- the most controversial site on the Web
Bus error
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I read the SecurityFocus article and was impressed by how the article pinpointed what I have begun to fear is a major blight on software development. More and more software is being developed haphazardly without a clear design, coherent engineering or a well defined development roadmap. This is will only get worse with the growing number of people who refuse to go to college and learn how to engineer software and instead believing hacking code is all there is to software development.
Unfortunately instead of the article to then discuss ways to attack the cause of the problem (badly engineered software), it describes ways to attack the symptoms (release the source so bugs can be found).
There is more to creating robust software than simply testing most the bugs out of a system. Proper engineering practices need to be set in place to allow the extensibility and modularity of the code. Releasing source code may catch buffer overflow exploits and the like but it doesn't solve problems like improper interfaces/protocols being chosen and several other bad design decisions.
Mozilla has already proved this with the fact that it is a complete rewrite of the original Netscape code. After a year wasted hacking at the code, the Mozilla developers realized that all the Open Source in the world could not change the fact that Netscape Navigator was badly engineered software. Mozilla is better than Netscape not simply because it is Open Source and all bugs are shallow but because it is being properly designed and engineered instead of being a series of unmaintainable hacks like Netscape's Navigator.
As the saying goes you cannot make a silk purse out of pig's ear.
1) Lack of multithreading/multiprocessing capability.
2) Memory allocation is very non-intuitive.
3) Exception handling is almost non-existant.
4) The blasted turtle never does what you want.
I would suggest (and I think my views are shared by a large percentage of the computer industry) that a better programming language for large-scale, team based software design must combine the data abstration of COBOL with the versatility of INTERCAL.
You want the truthiness? You can't handle the truthiness!
There have been several recent articles in some of the major software engineering journals, which question the feasibilty of using C or C++ for large projects. C/C++ have been demonstrated to be unsuitable for todays huge software projects, and all other software companies who persevere with C/C++ will eventually run into the same problems as Netscape.
So what is the solution? The academic community's research advocates the use of a new programming language, Logo, in order to solve the problem of scalability. The amazing levels of abstraction provided by Logo mean that Logo is certain to become the major programming language of the future.
I'm not saying that the article is wrong. In fact I agree with everything the author states. But I want to add the issue of "speed" to get the product out.
My experience at work also shows that tight schedules also cause problems. We all have access to the code of our peers but when we are forced to ship the product quicker than as-soon-as-possible we don't take into account what the other programmer is doing. There are those that design the tool that are supposed to prevent this, but if the requirements are lacking, then programmers will do things one way that will cause problems when integrating it to a tool another way.
Another problem comes when requirements change. Just recently I was on a program that changed a few requirements near the end, and this caused a major design change. With the tight schedule it was impossible to completely test the change to what it should be done. But management seems to think things are some when you change a "simple" requirement and doesn't give a proper budget.
The open source world doesn't worry too much about schedule. It is willing to produce something better than get the PR of a quick product. I believe open source produces code quicker, but for the quality it seems slow, where closed source can produce quicker than the open source because it hides the things that should have been fixed before the shipment. So this is only a perception that the closed source version was produced quicker.
Steven Rostedt
Steven Rostedt
-- Nevermind
"Oh my god it's falling apart at the seams"
"Only mozzila can save us now"
[Cue big green monster]