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. "

Comments

Agreement from Alan Cox

[The Pim]

Alan Cox noted this aptly a few months ago:

The evidence from the MS world is that buffer overflows are the _least_ of your worries in a component based environment. Complete inability to build a coherent security model combined with people who wave their arms around when asked hard questions about it are most of the problem.

Nobody in the windows world is much into buffer overflows right now, you dont need them to tear apart a windows system. There's a lesson there for gnome.

http://www.uwsg.iu.e du/hypermail/linux/kernel/0007.3/1305.html

Re:Correct Observation, Wrong Solution

[locust]

More and more software is being developed haphazardly without a clear design, coherent engineering or a well defined development roadmap.

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

XPCOM/COM doesn't equal security holes

[DrXym]

XPCOM/COM is just an object technology and in itself doesn't make a product any more or less secure than if it were written with Corba or with plain-old DLL exported methods.

What makes IE so insecure is it's application of this technology to equal what Java was touted to do:

1. It allows 3rd party COM objects to install and run with complete abandon on your PC. Once installed, that control owns your ass.
2. It's security model is hopeless - any object marked safe for scripting can be created by any HTML. Even if the control isn't malicious it can be made to do malicious things when you visit a website.

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.

Pretty mindless advocacy

[streetlawyer]

It always makes you think when you see the words "ego-free" and "Eric Raymond" in consecutive paragraphs. And indeed, this article is a complete piece of boosterism, thin on facts and think on rhetoric.

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.

Who cares if it's secure...

[Wakko Warner]

I just want netscape to go an hour without crashi

Bus error
--

"One World, one Web, one Program" - Microsoft promotional ad

Correct Observation, Wrong Solution

[Carnage4Life]

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.

That's not the problem

[Anonymous Coward]

Netscape's problems with maintaining a stable and secure codebase are not to do with a haphazard software design methodology. Their problems are more fundamental than that. In my opinion, Netscape's problems stem from the fact that they coded Navigator/Communicator in the wrong language.

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.

Speed is also an issue.

[nevets]

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

Sounds a bit like a dodgy B film

[grahamsz]

"Oh my god it's falling apart at the seams"

"Only mozzila can save us now"

[Cue big green monster]