[Fwd: Re: New Mozilla vulnerabilities??]

[Christopher Aillon]

Stephen John Smoogen wrote:
> On 6/9/06, Josh Bressers <bressers at redhat.com> wrote:
>> >
>> > Matthew Miller wrote:
>> > > On Sat, Jun 03, 2006 at 02:36:13PM -0500, David Eisenstein wrote:
>> > >
>> > >>It mentions a bunch of vulnerabilities (all of which seem to affect
>> > >>Seamonkey, Thunderbird, and Firefox).  After looking at each VU#, 
>> it appears
>> > >>that none of the announcements mention the Mozilla suite.  Also, 
>> at least as
>> > >>of last night, none of them mention any CVE #'s.
>> > >
>> > >
>> > > No updates for Firefox for Fedora Core yet, either....
>> > >
>> > > <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194617>
>> > >
>> >
>> > I heard a rumor the other day that Red Hat Enterprise Linux may be 
>> planning
>> > to replace Mozilla with Seamonkey in their currently-maintained 
>> distros.  Am
>> > wondering if there is any truth to this rumor?  Also wondering if 
>> there is
>> > anything we in Fedora Legacy can do to help in this process of 
>> dealing with
>> > these critical Mozilla/Firefox/Seamonkey bugs?
>>
>> This is true.  We're going with seamonkey in RHEL.  I think this current
>> round of issues is proof as to why this has to happen.  Backporting 
>> to the
>> firefox 1.0 branch is nearly impossible given the drastic changes 
>> between
>> versions.
>>
>> Right now we're furiously working on backporting patches for the most
>> critical issues.  If you want to help mail Chris Aillon (caillon at redhat)
>> with your request.  He's currently heading up a small group of various
>> distributors trying to get all this work done.
>>
>
> I would say that it is not worth the effort to do that much
> backporting. I am having to deal with sites that just want to block
> old Firefox browser strings anyway at their firewalls. So my day job
> is basically going to be get 1.5.0.4{5,6,7} onto RHL-7.3 -> RHEL-4
> anyway.
>
> My {I am not much of a coder, but have to deal with the mess left over
> by them} possition would be that  getting a modularized javascript
> interpreter written, debugged, security minded than trying to back-fix
> things might be a better idea.
That would take years of effort to duplicate something that already 
exists.  SpiderMonkey (the mozilla.org JavaScript engine) is very 
security minded, and very modularized.  Download it from mozilla.org/js 
but not that while there are occasional issues in it, there aren't very 
many.  You are confusing JavaScript (the language) with DOM (an object 
model), which is where all the security holes are because it is designed 
to be a security hole if you think about it.  The point of the DOM is to 
give web sites access to things that HTML doesn't give them, and lets 
them control the browser in certain ways.  Just like you don't claim 
that C is insecure when there's a kernel vulnerability, you should be 
careful with claiming JavaScript is insecure when there is a DOM 
vulnerability.  JavaScript bindings are simply more readily available to 
websites than the native bindings, but those are also vulnerable if you 
ever install extensions which make use of them (such as enigmail).