lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <404F7F85.8030200@jmu.edu>
From: flynngn at jmu.edu (Gary Flynn)
Subject: Browser security was Re: MDKSA-2004:021 - Updated
 mozilla packages fix multiple vulnerabilities

Florian Weimer wrote:

> Mandrake Linux Security Team wrote:
> 
> 
>> A number of vulnerabilities were discovered in Mozilla 1.4:
> 
> 
> Wow.  A GNU/Linux distributor who finally releases a security update for
> Mozilla.  Isn't this a first?
> 
> There is a list of published issues at:

I'm glad you said "published" instead of "known". :)

> <http://www.mozilla.org/projects/security/known-vulnerabilities.html>
> 
> Now compare this to what some distributions are shipping (most of them
> are at 1.4, AFAIK).
> 
> Apparently, browser (and mail client) security isn't something at which
> you can beat the market leader easily, despite its sorry performance in
> this regard.  8-/

Amen.

Looking at the workarounds on the "known vulnerability" page, it
appears the old saw about "disable javascript, java, etc." should
apply to all browsers visiting untrusted sites.

What I'd like to see personally is a right-click "temporarily
disable/enable risky functionality for this site" option so this
functionality can be turned on and off easily for those users
willing to put up with the discomfort of day to day web "browsing"
without scripts but not willing to put up with having to go
through three or more configuration screens for a temporary site
visit. Yeah, I know, make it too easy and you get the email attachment
syndrome but I think the feature would overall encourage more people
to try browing in a safer default configuration than today's
mechanism. You fight human nature and you lose. It could always be
disabled by a master switch in an organizational policy. Shoot,
even security vendors make use of script on their web pages
and I think most of us would have to admit having to go to a site
requiring script and forgetting to turn it back off at least
once. :)

-- 
Gary Flynn
Security Engineer - Technical Services
James Madison University


Powered by blists - more mailing lists