From what I understood about this bug, it was irrelevant for Mozilla
RC-1 because the exploited feature was not working at all there (i.e. -
the bug was there, but another bug prevented exploiting the first one).
I am using debian sid, and they carry nightly mozilla builds (mine is
from 20020502, as can be seen from the "user-agent" string in this email).
As far as I understood from the bugtraq posting, they tried to contact
someone at mozilla (rather than submit the bug to bugzilla). This is
standard responsible full disclosure procedure, which mozilla was
probably not set up to follow (the procedure was built with commercial
companies in mind, not open transparent development processes and bug
systems).
As a side note - I am begining to lose hope with securing a platform. I
used to be able to say certain distributions make frequent security
updates, and that this is the only real protection. However, I since
amended this saying to add "and you need to support their automatic
update to not halt your services". This new addition automatically
disqualifies Microsoft (they have, on several occasions, posted updates
that broke functionality, and they also posted updates that were not
included in the automatic update mechanism). I have also had an occasion
in the past where RedHat's up2date mechanism completely broke
functionality of a desktop machine, so I am a bit hesitant to trust
RedHat on this (anyone can give counter experience?).
I am coming more and more to the conclusion that the only way is to
forego functionality, and even that doesn't always save you (what good
is saying "don't use telnet, use SSH" if ssh has had exploitable bufer
overruns itself?).
I'll start a comparison table, and I'm asking the list to help me fill
it in:
Microsoft (W2K and Win XP server):
*Unattended update mechanism*: I don't know (is "Windows Update"
scriptable?)
*Packages are protected against DNS poisening*: Yes
*Update mechanism reliability reputation*: Very bad - patches take time
to be included even after they are released. Machines regularily stop
working after updates.
*Responsivness to problems*: Mediocre
Please note that responsivness and reliability are a tradeoff, but MS is
doing poorly on both.
*OpenBSD*:
*Unattended update mechanism*: I don't know for sure, but I think not.
*Packages are protected against DNS poisening*: As far as I know updates
are distributed source only, so the answer is probably not.
*Update mechanism reliability reputation*: Very good, but I don't have
many sources on this.
*Responsivness to problems*: Usually high
RedHat:
*Unattended update mechanism*: up2date
*Packages are protected against DNS poisening*: RPMs are opionally
signed, but I don't think up2date can be configured to reject unsigned
RPMs. I don't even know whether it verifies the signature.
*Update mechanism reliability reputation*: Bad personal experience, but
not in a server. Anyone using it?
*Responsivness to problems*: ?
Debian:
Debian's table seem to be version dependant. There are fluctuations
between sid, woody and potato.
*Unattended update mechanism*: apt-get. It has the extra capability of
adding third parties to the update mechanism. They can also upgrade
majour versions (i.e. - from potato to woody). On the down side, the
output from the upgrade scripts is not easy to automatically script
(though possible).
*Packages are protected against DNS poisening*: debs are signed using
gpg. There is a package containing the signatures of all debian
developers. However, apt does not have an option to verify the
signatures. A script workaround may be possible, but the default answer
is "no".
*Update mechanism reliability reputation*: Very high. Debian maintainers
on the stable release are extremely careful not to break anything. Apt
on stable will not upgrade you to a new version if security problems
have been discovered in the old one, but will rather install a patched
older version that is not vulnerable. This causes false positives when
scanning for vulnerabilities, but means your server doesn't break
functionality or upgrades unexpectably.
*Responsivness to problems*: Usually high, with at least one recorded
glitch.
Sun:
*Unattended update mechanism*: Not that I'm aware of.
*Packages are protected against DNS poisening*: No. Regular HTTP download
*Update mechanism reliability reputation*: Never heard of problems.
*Responsivness to problems*: ?
Ok, if you can give me your input (anyone using Mandrake or Suse as
servers here?).
Tzafrir Cohen wrote:
>Hi
>
>It seems that recently a meduim security hole was exposed in mozilla:
>allows a server to read local files.
>
>See the origianl advisory:
>
> http://sec.greymagic.com/adv/gm001-ns/
>
>as well as lwn.net's short summary:
>
> http://lwn.net/2002/0502/security.php3
>
>Anybody here happens to know more about the ways in which GreyMagic tried
>to inform Netscape of this flaw (according to ther advisory)? The bugs in
>the bugzilla were only opened (immediatly) after the annoncement of this
>advisory.
>
>Regarding a promptly fix: A fix to the nightly build was ready almost
>immedietly. But what about existing versions?
>
>I stil see no relation to that in nither netscape's site nor in
>mozilla.org. From what I understand from mozilla it will be fixed in the
>next release candidate (or will it be 1.0?). Of course, mozilla is at a
>beta phase, and any release is a bugfix release.
>
>What distros come with volnurable versions of mozilla that should be
>updated ASAP?
>
>
>
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
