On Fri, 2002-12-13 at 16:11, [EMAIL PROTECTED] wrote: ... > well.... I guess this is a little confusing too. The redhat download centers > show for RH 7.3 the file: > > openssh-3.1p1-3.i386.rpm 213 KB 04/17/2002 12:00:00 AM > > and for RH 8.0 the file: > > openssh-3.4p1-2.i386.rpm 213 KB 09/03/2002 09:33:00 PM > > Looking at the date stamp in the RH 7.3 centers I'd say there's little chance > that this isn't vulnerable to the bug found this summer unless RH also back > dating the fixes?
The latest 7.3 openssh package is 3.1p1-6 make sure the redhat mirror you are using has the latest. The 3.1p1-x, the 'X' part is the epoch number which according to redhat outweighs the version number of the package. So it could be possible for RedHat to release a package versioned 2.2-1, then release an errata package 2.3-2, and then have a superceding errata release that is 2.2-3.... I guess that could be confusing, but I can't think of a better way to do it. I remember being worried about the openSSH versions too. There were a few of them in a short period of time, if I remember correctly, I read the description of the vulnerability at the openSSH website and they said that if you had disabled the S-key (or something like that) that you weren't vulnerable. When I then went and checked the RedHat package I had installed it didn't have S-Key Auth enabled anyway. So I waited for the RPM rather than jumping on the 3.4 tarball. > Is it fair to say, then, that the errata page is THE source of information as > to whether or not a particular program is up-to-date, security wise? Has any > thought been given, to the best of your knowledge, to show that a piece of > software has been modified to provide a security fix when the user does a The source packages have the change logs and notes in them, and I could swear I remember reading an RPM command option somewhere that would give that info too??? THE source of information is the source itself.... RedHat always has source RPMS available for the Open Source licensed programs that they distribute, but in this case it wasn't necessary, because the Errata Notes at RHN (e.g. https://rhn.redhat.com/network/errata/errata_details.pxt?eid=1047 ) Referenced the actual Vulnerability name: The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0083 to this issue. The Errata Notes for Security problems almost always do refer to the CERT or the CVE announcement. Heck a lot of times CERT even tells you what package and FTP url to get the RedHat patch. If I remember correctly there is a very VALID reason to back-port the security fix to 3.1p1 rather than just distribute 3.4 The reason I think I remember is that version 3.4 required a newer version of openssl, that new version of openssl that might have required a change of lots of other programs like mod_ssl, stunnel, links, w3m, fetchmail, etc.... At the very least all those programs would have to have been tested. I'm really glad that RedHat backports the fixes, cause I would be caught between a rock and a hard place if I had to make a choice between changing the openssl lib version on a production server or having a known hole in my SSHd. I feel confident knowing that any potential bug I am introducing is limited to the program that would be vulnerable without the fix, rather than making a sweeping change that could introduce *new* bugs to all kinds of other apps I have on my box. -Ben. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
