Fix a very stupid heap corruption bug: in ypproc_match_2_svc(), when we decide to do a DNS lookup, we NUL terminate the key string provided by the client before passing it into the DNS lookup module. This is actually wrong. Assume the key is 'foo.com'. In this case, key.keydat_val will be "foo.com" and key.keydat_len will be 7 (seven characters; the string is not NUL-terminated so it is not 8 as you might expect). The string "foo.com" is actually allocated by the XDR routines when the RPC request is decoded; exactly 7 bytes are allocated. By adding a NUL, the string becomes "foo.com\0", but the '\0' goes into an 8th byte which was never allocated for this string and which could be anywhere. The result is that while the initial request may succeed, we could trash other dynamically allocated structures (like, oh, I dunno, the circular map cache queue?) and SEGV later. This is in fact what happens.
Fix a very stupid heap corruption bug: in ypproc_match_2_svc(), when
we decide to do a DNS lookup, we NUL terminate the key string provided
by the client before passing it into the DNS lookup module. This is
actually wrong. Assume the key is 'foo.com'. In this case, key.keydat_val
will be "foo.com" and key.keydat_len will be 7 (seven characters; the
string is not NUL-terminated so it is not 8 as you might expect).
The string "foo.com" is actually allocated by the XDR routines when the
RPC request is decoded; exactly 7 bytes are allocated. By adding a NUL,
the string becomes "foo.com\0", but the '\0' goes into an 8th byte which
was never allocated for this string and which could be anywhere. The result
is that while the initial request may succeed, we could trash other
dynamically allocated structures (like, oh, I dunno, the circular map
cache queue?) and SEGV later. This is in fact what happens.

The fix is to copy the string into a larger local buffer and NUL-terminate
that buffer instead.

Crash first reported by: Ricky Chan <ricky@come.net.uk>
Bug finally located with: Electric Fence 2.0.5

jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase