Bug 57421 - Newer ucd-snmp libraries cause Ethereal to segfault
Summary: Newer ucd-snmp libraries cause Ethereal to segfault
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ucd-snmp   
(Show other bugs)
Version: 7.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-12-12 02:28 UTC by Gerald Combs
Modified: 2015-03-05 01:09 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-05 04:50:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch for struct sbuf support in perl module source (2.39 KB, patch)
2002-01-02 22:09 UTC, Hrunting Johnson
no flags Details | Diff

Description Gerald Combs 2001-12-12 02:28:39 UTC
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(char *buf,
+sprint_value(struct sbuf *buf,
             oid *objid,
             size_t objidlen,
             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):

How reproducible:

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 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.

Additional info:

This is related to bug #55303.  Dunno if the problem is exploitable.

Comment 1 Guy Harris 2001-12-12 07:35:05 UTC
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.

Comment 2 Gerald Combs 2001-12-12 18:08:12 UTC
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");

  echo $sd;

Comment 3 Hrunting Johnson 2002-01-02 22:09:30 UTC
Created attachment 41652 [details]
Patch for struct sbuf support in perl module source

Comment 4 Phil Knirsch 2002-01-29 14:59:44 UTC
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

Note You need to log in before you can comment on or make changes to this bug.