On Mon, Dec 21, 2009 at 10:06 PM, Magnus Fromreide <[email protected]>wrote:
> On Mon, 2009-12-21 at 12:01 +0000, [email protected] wrote: > > Revision: 17926 > > > http://net-snmp.svn.sourceforge.net/net-snmp/?rev=17926&view=rev > > Author: bvassche > > Date: 2009-12-21 12:01:15 +0000 (Mon, 21 Dec 2009) > > > > Log Message: > > ----------- > > Applied patch #2912062: make sure that the string returned by > > read_config_read_octet_string() is properly terminated, such that the > > callers of this function do not trigger past-end-of-buffer reads. Found > > this issue via BoundsChecker. > > I think this patch is bogus as the result is a length + char-array, not > a zero terminated string. > > An octet string can quite legally contain embedded NUL characters and so > the bug that should be reported is that someone tries to operate on it > using a str* function. > > This is also the reason for the len argument to the function. > > I thus propose a reversal of this patch and a comment in the tracker > that explains the problem. > > To be honest I am considering a patch to never zero-terminate the result > of this function. > A difficulty with the function read_config_read_octet_string() is that it is being used for two different purposes: 1. For reading binary strings, e.g. an engine ID. This kind of data should be represented via a buffer pointer and buffer length, because it can contain binary zeroes. 2. For reading ASCII strings, e.g. usmUser::secName. This kind of data is most conveniently represented as a zero-terminated string. Should we really keep a single function read_config_read_octet_string() that is used for both reading binary data and reading ASCII strings ? Maybe it's better to have two functions, one for reading binary data and one for reading ASCII strings. Bart.
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
