[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-security
Subject:    Re: Handling Mozilla security bugs, draft 8 ("release candidate")
From:       Ben Bucksch <ben.bucksch.news () beonex ! com>
Date:       2001-10-26 6:56:42
[Download RAW message or body]

Frank Hecker wrote:

> The changes in this draft include: 

The changes you made look fine. More important are the changes you did 
*not* make.

All: I discussed a bit more with each of Mitch and Frank privately some 
time ago. Unfortunately, both discussions stopped at some point. I hope, 
they don't disagree with me discussing the 2 most important points here.


  1. Vendor warnings wording/content

Frank suggested the following wording wrt. vulnerability warnings:

"Mozilla distributors who wish to inform their users of the existence of 
a vulnerability may redistribute these [official] security warnings 
verbatim or use them as a basis for warnings to their own users. However 
Mozilla distributors and others should not publish information that 
could be used to create exploits for the bug."

That (which is different from the wording in the latest draft) would 
work for me, with one exception discussed next.


  2. No warning at all

Mitch told me that he in fact sees cases where a severe exploit would 
not be warned about at all. He mentioned the case, where the only 
workaround would be to stop using the product.
I do think that it is important to warn users even in those cases. If 
Netscape doesn't want to issue a warning to its users, that's Netscape's 
choice, but I would surely want to warn Beonex users. Under the current 
policy, I would not be allowed to.

Even if the strategy Mitch proposed might sound reasonable /from a 
certain point of view/, it is very problematic in practice. When exactly 
is there "no workaround"? For example,

    * does disabling JavaScript count as workaround? I would surely say
      yes, and it would probably be the most common workaround, but
      somebody could argue that many websites are not usable at all
      without JavaScript. If we follow that argumentation, we wouldn't
      warn about the majority of severe bugs.
    * If there is a buffer overflow bug in the image lib, does it count
      as workaround to disable images?
    * If there is a overflow in HTTP, HTML or (mail-)MIME code, does it
      count as workaround to use a filtering proxy? Many companies force
      the use of a proxy anyway and could, maybe even without too much
      hassle, install a proxy [rule], which protects against the
      exploit. So, I would say that there is a workaround. Netscape OTOH
      might argue that most of its users are individuals which are
      connected directly to the internet and that it is (in fact)
      unreasonable to ask them to install a proxy.


I stick to my point that it is necessary to warn users about every 
severe bug. Every policy which disallows that does IMO put users 
unnecessarily at risk.

[prev in list] [next in list] [prev in thread] [next in thread]