On Fri, 3 May 2002, Shachar Shemesh wrote: > 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). Thisis > 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 areopionally > signed, but I don't think up2date can be configured to reject unsigned > RPMs. I don't even know whether it verifies the signature.
IIRC this is the default behaviour. > *Update mechanism reliability reputation*: Bad personal experience, but > not in a server. Anyone using it? > *Responsivness to problems*: ? > up2date requires registration (unlike redhat itself). Does this pose any technical problems? > > Debian: > > Debian's table seem to be version dependant. There are fluctuations > between sid, woody and potato. (or between stable, which only has bug fixes and security fixes, to 'testing/frozen' that has changes that are usually a bit tried-and-tested, to 'unstable' that is rumored to be stable enough?) > *Unattended update mechanism*: apt-get. It has the extra capability of > adding third parties to theupdate mechanism. They can also upgrade > major 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*: ? > Mandrake: Anybody got their urpmi working properly? Is there any way to use it for automatic periodical updates? I personally upgrade packages using rpm after I gave up on urpmi/rpmdrek/whatever . Has it improved in 8.2 ? Assuming it works properly: *Unattended update mechanism*: Probably not *Packages are protected against DNS poisening*: Yes, standard RPM signatures *Update mechanism reliability reputation*: Older versions occasionally don't get enough testing (e..g: apache/php packages for mandrake 7.2) *Responsivness to problems*: ? -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir ================================================================= 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]
