full-disclosure - Re: new class of printf issue: int overflow

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <200701110955.30235.tom@electric-sheep.org>
Date: Thu, 11 Jan 2007 09:55:29 +0100
From: Thomas <tom@...ctric-sheep.org>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: new class of printf issue: int overflow

Hello Felix.

Am Donnerstag, 11. Januar 2007 02:00 schrieb Felix von Leitner:
> This is about two issues.  First: abs within vasprintf.
> 
> I just read some gnupg source code and stumbled upon their
> vasprintf implementation.

Did you told them about it?

> Second issue: int overflow in *printf:
> 
> But that got me thinking.  *printf return an int, and it's supposed to
> be the number of chars written.  So a typical idiom is
> 
>   size_t memory_needed=snprintf(NULL,0,format_string,...);
>   char* ptr=malloc(memory_needed+1);
>   sprintf(ptr,format_string,...);

This is nothing new.
It is documented in the man-page and in the libc sources.

By coincidence I found such a bug while doing a code review
a few weeks ago. But in this case the return value was used
in calculating an pointer offset and using this pointer again
in sprintf(). At the end the result was an overflow. :-)

Bye
Thomas

-- 
Tom <tom@...ctric-sheep.org>
fingerprint = F055 43E5 1F3C 4F4F 9182  CD59 DBC6 111A 8516 8DBF

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/