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