On Thu, Mar 07, 2002 at 02:14:46PM +0000, Gordon McKinney wrote:
> I will happily compile up some new ucd-snmp win32 lib files.
>
> Which version would be acceptable for Ethereal?
4.2.4.
Unfortunately, it's not out yet. All previous versions have a
vulnerability to an internal buffer overflow that cannot be worked
around.
Note also that the 4.2.4.pre2 version *also* has that vulnerability -
the fix was checked in after the 4.2.4.pre2 tarball was made. There are
no tarballs available from the SourceForge site that include the fix;
the fix is only in CVS.
In addition, note that Ethereal *also* needs to be changed to use
different UCD SNMP APIs, in order to avoid *other* buffer overflows.
I have a version on which I've been working that does so; *if* compiled
with a version of 4.2[.x] with the fix, it doesn't crash on any of the
PROTOS capture files that Gerald put on the Ethereal site, but it *will*
crash if compiled with any version that doesn't have the fix.
It's not finished, however; it currently will not compile with CMU SNMP,
or with versions of UCD SNMP prior to 4.2.2 (the first version that
introduced the new APIs). We could either
1) ship that version, which is a bit cleaner (fewer #ifdefs and
fewer workarounds - it needs neither the 4.1.2
binary-incompatibility workaround nor the Red Hat
source-incompatibility-workaround), and might also force RPMs
to be built with a newer version of the library which *might*
get rid of the dependency problems people have had with the
UCD SNMP library and RPM binary packages of Ethereal (that's
purely a guess; I have no evidence to indicate whether it
would or wouldn't) but would leave people with CMU SNMP, or
older versions of UCD SNMP, in the cold
or
2) ship a version that uses the new API if available in the
library with which it's built and falls back on the older
UCD SNMP, or CMU SNMP, APIs, with a *much* larger buffer, if
the new API isn't available - it would let those users have a
version of Ethereal that's *less* vulnerable, but it still
would be vulnerable (to the internal-to-the-library overflow,
and to overflows of the bigger buffer), and if people build
binary packages on systems with libraries without the new
API, those binaries will be vulnerable (although less
vulnerable) even on systems with UCD SNMP 4.2.4 (when it
comes out).
I'm inclined to do 1), as it's simpler (even simpler than the *current*
code, as it lacks the workarounds for the aforementioned other problems)
and removes the buffer-overflow vulnerabilities, even if it leaves users
who have older versions of the library installed in the cold.