[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: PROPOSAL: Cluster 17 - MULT2 (14 candidates)
All:
I expected to see a number of RECAST votes in the MULT2 cluster based
on the Same Codebase content decision. One specific example is:
>Candidate: CAN-1999-0113
>Announced: 19990714
>Assigned: 19990607
>Category: SF
>
>Some implementations of rlogin would allow root access if given a
>-froot parameter.
which was on AIX and Linux. This bug was reported in 1994, although a
Bugtraq posting says "This rlogind bug has been around for a long
time." The rlogin TERM bug was in 1997.
Applying Spaf's logic for the rlogin TERM buffer overflow, this is
probably the same codebase, so should stay a single entry. However,
given that Linux rlogin was fixed due to early security screening that
prevented the rlogin TERM bug, the question becomes whether the Linux
team fixed rlogin *before* the -froot bug was discovered. We have a 3
year time window that to me may make the difference between whether
this candidate is accepted or split.
In general, if nobody has any clear reason to believe that these two
are different codebases, then which way should we go - split by OS, or
keep them merged together?
Another example is:
| =================================
| Candidate: CAN-1999-0048
| Announced: 19990714
| Assigned: 19990607
| Category: SF
| Reference: CERT:CA-97.04.talkd
| Reference: FreeBSD:FreeBSD-SA-96:21
| Reference: AUSCERT:AA-97.01
| Reference: SUN:00147
| Reference: XF:talkd-bo
|
| Talkd, when given corrupt DNS information, can be used to execute
| arbitrary commands with root privileges.
|
which appears at least on FreeBSD, AIX, and SunOS/Solaris. Is this
another case like expreserve, where the program was written by a
single person, in which case these are probably the same codebase?
Also, if anybody has a good "history of Unix" reference, I would
appreciate it. It's clear that history will need to be consulted
heavily for these types of problems. I'd like to prevent inaccuracies
as much as possible.
Thanks,
- Steve