Hi!
[EMAIL PROTECTED] [2005-03-02 5:58 -0800]:
> The vulnerability specifically exists due inproper use of then
> strncpy function.
> The vulnerable code is shown below:
>
> -- snip --
> char name[128];
> -- snip --
> if (ghbn_cache[i].order > 0)
> {
> if (strncmp(name,ghbn_cache[i].name,128) == 0)
> break;
> }
>
> Due to a routine security audit of the strncpy man file, we at
> tal0n security now know that the result of strncpy will not be null
> terminated !!!!!!
The code you cited uses strncmp(), not strncpy(), and since
ghbn_cache[i].name really is 128 bytes, I cannot see anyting wrong
with the strncmp().
In apps/s_socket.c, copying into this string is well-checked with
if(strlen(name) < sizeof ghbn_cache[0].name)
{
strcpy(ghbn_cache[lowi].name,name);
In crypto/bio/b_sock.c, this is done more sloppily with
strncpy(ghbn_cache[lowi].name,name,128);
It is clear that the resulting string might not be null-terminated any
more; agreed, this is really bad practice. However, since strnmcp() is
used with limiting to 128 bytes this is still safe (although fragile).
However, I just checked 0.9.7e, is there an additional vulnerability
in 0.9.6 which was fixed in the meantime? Or am I missing something?
Have a nice day,
Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian GNU/Linux Developer http://www.debian.org
signature.asc
Description: Digital signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
