On Saturday 14 May 2005 20:29, Jaqui Greenlees wrote: > Ian G wrote: > true enough. but if the user has to choose to install an extention > instead of the browser going after it. ( automatic plugin finder [ more > in netscape than mozilla tools, but it happens with mozilla's browsers > also ] ) then it is definately end user's choice to breach security.
Right. The user has opened pandora's box. But in a sense, the browser encourages her to do that by providing for plugins anyway. And, if there isn't enough flexibility, she'll switch to something else, and all the good works are for nought. Security isn't measured by whether we can create the most secure tool, by our own measures. It is measured by how many people we can deliver how much adequate security to. If we can provide 99% protection to a million, then that's better than 99.5% protection to half a million users. (Well, in the absence of other numbers - of course we'd like to do both.) > > About the best you can do is set an API and > > close down anything that doesn't conform to it. > > close down how? my draconian answer: refuse to run anything that is not > 100% api compliant. > not even 99% allowed. Well, right, where you detect that, shut it down. But that doesn't come anywhere near a level of security that's worth much: API compliance is not an exact science, as you never know when the plugin is going to go haywire or decide to start phoning home with the passwords. A breach of its address space for reading purpose may not be detected, but it sure as hell is something we want to avoid. > > And, as it is the host that is vulnerable, the > > host is also responsible; if MF wanted to avoid > > buffer overflows, it could have written the > > code to be invulnerable to them (using java, > > or insisting that all plugins be written in java > > for example, or inventing your own "java", or > > putting each plugin in a separate process, or > > ...) > > so this means.. mozilla's developers chose to ignore good coding practices? No, they made some compromises forced on them by the marketplace. The market for browsers is pretty much limited to C/C++, so they have to make that compromise from the start, and accept buffer overflows in any code they choose to let loose within the address space. (By way of comparison, in the same time frame, my company chose Java for desktop clients for security reasons, and even though our result is much more secure and robust, we can't get people to install Java without violence or blackmail, so much so that Java on the desktop is pretty much a failure for commercial purposes.) (And even if Mozilla had picked Java, they'd still run into flack from the capabilities crowd, who'd point out how much of a mess Java is ... :) there's no easy answer here.) > they decided to use m$'s drag and drop rad style coding rather than do > any real coding? > most common cause of buffer overflow errors is from bloated code, caused > by using a drag and drop interface designer, linking to prebuilt > libraries. this is what causes a continuation of buffer overflows, > reusing libs with bloated interface design elements. OK, but practically, I don't see what can be done about it. Buffer overflows are very hard to detect, outside and before the case. About the only thing I can think of is to run every plugin in a separate process, but I know too little about Microsoft arch to know whether that makes sense. > yup, trade the absolute security of your system to be online. > trade the security of your browser for features that don't add anything > but bells and whistles. > > I test my browser for vulnerabilities, never have any because of never > having any extentions or clientside scripting enabled. Right. For you that's grand. Trying to get the rest of the browsing community to do that is a non-starter. Question is, what is there that you do that could be used to help the average user? iang -- http://iang.org/ _______________________________________________ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
