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: Always 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 1.1.1.1 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.
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"); echo $sd; ?>
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. Thanks, Read ya, Phil