Date: Sat, 13 Feb 2016 19:51:04 +0300 From: Alexander Cherepanov <ch3root@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: snprintf return value misuse in a lot of projects On 2016-02-13 17:11, Yuriy M. Kaminskiy wrote: > I noticed dangerous pattern in a lot of projects, where snprintf(3) > return value is used without checking, with potentially disasterous > consequences: It's kinda a known. E.g., some such patterns are listed in https://sourceware.org/ml/libc-alpha/2013-10/msg00686.html . The same problem is with strlcpy. > And there are yet another very common pattern: > > p += snprintf(p, end-p,[....]); > p += snprintf(p, end-p,[....]); > p += snprintf(p, end-p,[....]); > ... > > which may be 'barely safe' by posix (if you'd read `man 3posix snprintf`, > you'd expect 2nd line is [somewhat] safe (end-p is negative, then > casted to size_t and produce value larger than (size_t)INT_MAX, that > should result in error EOVERFLOW), and third and following will dance > around last byte, likely remaining safe), but it is TOTALLY > broken on glibc, as glibc's snprintf DOES NOT follow posix, and accepts > *any* size. For a glibc discussion please see https://sourceware.org/bugzilla/show_bug.cgi?id=14771 . As for POSIX, the requirement of EOVERFLOW for a big second parameter is a (rejected) bug in POSIX -- http://austingroupbugs.net/view.php?id=761 . A closely related bug -- http://austingroupbugs.net/view.php?id=1020 . ISO C describes the size parameter of snprintf as a limit to the number of output characters written, without any connections to the size of the buffer. Thus, the following examples are valid in ISO C: char s; snprintf(s, 20, "abc"); snprintf(s, SIZE_MAX, "%s", "abc"); OTOH POSIX describes the size parameter as the actual size of the buffer (bug 1020) and requires to reject buffers of size larger than INT_MAX (bug 761). Even though POSIX contradicts ISO C in this question (while formally deferring to ISO C) there is a sentiment that the POSIX approach is better for safety/security. (E.g., it was expressed during the recent discussion about strlcpy/strlcat in the glibc mailing list.) As it turned out, the same problem affects the fread function, with the Linux kernel instead of POSIX contradicting ISO C. See https://sourceware.org/bugzilla/show_bug.cgi?id=19165 and https://sourceware.org/ml/libc-alpha/2016-02/msg00274.html . Perhaps this is a topic that will benefit from input from a wider community. -- Alexander Cherepanov
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.