Red Hat Bugzilla – Bug 57421
Newer ucd-snmp libraries cause Ethereal to segfault
Last modified: 2015-03-04 20:09:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
Description of problem:
Recent versions of the ucd-snmp packages have a patch named
"ucd-snmp-4.2.1-security2.patch" applied. This patch redefines two
functions, sprint_objid and sprint_value:
-char * sprint_objid(char *buf, oid *objid, size_t objidlen)
+char * sprint_objid(struct sbuf *buf, oid *objid, size_t objidlen)
+sprint_value(struct sbuf *buf,
struct variable_list *variable)
Ethereal passes a char * to both functions no matter what. As a result,
all ethereal or tethereal application compiled and linked against the
updated ucd-snmp packages segfault when they encounter an SNMP packet.
This includes the Ethereal packages that ship with Red Hat Linux 7.2.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run 'ethereal' and start a capture, updating in real time or run
'tethereal -V port 161'.
2. From another terminal window on the same machine, run an snmpget query,
e.g. 'snmpget 18.104.22.168 system.sysDescr.0 public'.
3. Thrill at the sigt of a core dump.
Actual Results: Ethereal segfaults.
Expected Results: Ethereal displays a properly dissected SNMP packet.
This is related to bug #55303. Dunno if the problem is exploitable.
The change in question not only changes the source-level API of the library, it
also changes the ABI of the library; therefore, *any* application that calls the
"sprint_XXX()" routines and that is linked with the old version of the library
will fail to work correctly if the new version of the library is installed with
the same shared library version number.
Shared library version numbers were introduced (in SunOS 4.0, the shared library
mechanism of which was the model for the SVR4 mechanism, which is the one
subsequently adopted by glibc on Linux 2.x, and by and the ELF-based BSDs, in
their independently-implemented mechanisms) to solve this problem - if a library
is changed in such a way that programs built against the old library will not
necessarily work with the new library, due to an ABI change, the major version
number of the library should change, so that programs built against the old
library will not bind to the new library.
If the old "sprint_XXX()" APIs are considered fatally insecure, so that no
application using them can be trusted, but you don't want to break applications
linked against the old library and that *don't* use those APIs, you should have
1) a shared library with the old version number, but with those APIs
*not* exported (made static if they're not used by other object files in
the library, given new names such as "XXX_UNSAFE_sprint_XXX()" if they are
used by other object files in the library), for use by applications linked
against the old library that don't use those APIs;
2) a shared library with the new version number, with the fixed versions
of those APIs exported.
A compile-time workaround has been committed to the Ethereal source tree, and
will be in the next release.
I have also verified that this bug affects PHP (if it's built with SNMP support
- the default Red Hat packages evidently aren't). The following script dumps core:
$sd = snmpwalk("<SNMP-enabled device address>", "public", ".iso");
Created attachment 41652 [details]
Patch for struct sbuf support in perl module source
The latest version (4.2.3) is available via rawhide now. This should fix this
problem. It does not contain the big security2 patch anymore as the buffer
overflow have been fixed correctly upstream.
Read ya, Phil