full-disclosure - OpenSSL <=3D 0.9.6m vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

From: martin.pitt at canonical.com (Martin Pitt)
Subject: OpenSSL <=3D 0.9.6m vulnerability

Hi!

cyber_tal0n@...hmail.com [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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050303/9af83620/attachment.bin