[Bug c++/46513] New: Request: Warning for use of unsafe string handling functions

[Bug c++/46513] New: Request: Warning for use of unsafe string handling functions

[noloader at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513

           Summary: Request: Warning for use of unsafe string handling
                    functions
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: noloader@gmail.com


Hi All,

The security minded folks of Linux [1,2], Apple [3], Microsoft [4], and
C/C++[5] agree that the original string handling functions are lacking or
deficient (i.e., "unsafe). Most surprising is that a diverse and disparate
group can unanimously agree on anything.

I often review internal code, GNU/FSF code, and open source code which
regularly uses unsafe functions. As one commenter stated on
{BugTraq|FunSec|FullDisclosure} (can't find the reference at the moment).
"there is no reason to be using strcpy in 2010".

The comment on the mailing list might indicate a larger problem: some folks are
not aware that some of these functions are unsafe and/or dangerous, and should
not be used. Consider: how many times have you seen copy/paste code that uses
an unsafe function *AND* offers a security statement or warning about it use?

A warning switch - perhaps part of "-Wextra" - would be very useful for the
following functions (with the Linux/Unix suggested replacement) since
replacements are readily available on all platforms.

strcat -> strlcat
strcpy -> strlcpy
strncat -> strlcat
strncpy -> strlcpy
sprintf -> snprintf
vsprintf -> vsnprint

Jeffrey Walton
Baltimore, MD, US

[1] Graff and van Wyk. Secure Coding: Principles & Practices,
http://www.securecoding.org/
[2] Wheeler. Secure Programming for Linux and Unix HOWTO - Creating Secure
Software, http://www.dwheeler.com/secure-programs/
[3] Apple, Inc. Secure Coding Guide,
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/SecureCodingGuide/Introduction.html
[4] Howard and LeBlanc. Writing Secure Code,
http://www.microsoft.com/learning/en/us/book.aspx?ID=5957
[5] Seacord. Secure Coding in C and C++,
http://www.cert.org/books/secure-coding/

[Bug c++/46513] Request: Warning for use of unsafe string handling functions

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-11-17 00:53:47 UTC ---
The maintainers of GNU libc, the C and C++ committees and the POSIX working
group have not seen fit to include those functions, and they're not available
on my GNU/Linux box.

[Bug c++/46513] Request: Warning for use of unsafe string handling functions

[noloader at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513

--- Comment #2 from Jeffrey Walton <noloader at gmail dot com> 2010-11-17 01:08:22 UTC ---
Hi Jonathan,

(In reply to comment #1)
> The maintainers of GNU libc, the C and C++ committees and the POSIX working
> group have not seen fit to include those functions, and they're not available
> on my GNU/Linux box.
Interesting. In 2010, I was hoping the strl* functions would side step the
political mess of TR24731-1 on *nix. For those resisting, TR24731-1 is now a
normative part of the C1x draft (as Annex K), so its coming whether they want
it or not :/

Never the less, a warning would still be useful since lots of code still
employs the unsafe functions. For those who are inclined - such as myself and
others who perform security related audits - a compiler warning would be a
welcome addition, even if there is no standard replacement. I'll tackle "what
to replace it with" in-turn on the specific platform.

Jeff

[Bug c++/46513] Request: Warning for use of unsafe string handling functions

[noloader at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513

--- Comment #3 from Jeffrey Walton <noloader at gmail dot com> 2010-11-17 02:04:14 UTC ---
(In reply to comment #1)
> The maintainers of GNU libc, the C and C++ committees and the POSIX working
> group have not seen fit to include those functions, and they're not available
> on my GNU/Linux box.

Indeed. Below is from "Secure Portability" by Damien Miller
(http://www.openbsd.org/papers/portability.pdf).

I know "finding the replacement" is not a GCC issue, but perhaps folks who need
to the *nix safe string gear can use TR24731-2 (not TR24731-1), which is POSIX
and includes strl* and friends.

And to reiterate: the warning would be useful. Miller states [in 1995] over 100
projects are *NOT* using strcpy and friends. So there are at least 100 projects
(plus me) who would likely use the switch ;). The number would only grow as
other security minded folks became aware of the GCC functionality.

Jeff

The strlcpy and strlcat API properly check the target buffer’s bounds,
nul-terminate in all cases and return the length of the source string, allowing
detection of truncation. This API has been adopted by most modern operating
systems and many standalone software packages, including OpenBSD (where it
originated), Sun Solaris, FreeBSD, NetBSD, the Linux kernel, rsync and the
GNOME project. The notable exception is the GNU standard C library, glibc [12],
whose maintainer steadfastly refuses to include these improved APIs, labelling
them “horribly inefficient BSD crap” [4], despite prior evidence that they are
faster is most cases than the APIs they replace [13]. As a result, over 100 of
the software packages present in the OpenBSD ports tree maintain their own
strlcpy and/or strlcat replacements or equivalent APIs - not an ideal state of
affairs.

[Bug c++/46513] Request: Warning for use of unsafe string handling functions

[noloader at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513

--- Comment #4 from Jeffrey Walton <noloader at gmail dot com> 2010-11-17 03:49:44 UTC ---
(In reply to comment #2)
> Hi Jonathan,
> 
> (In reply to comment #1)
> > The maintainers of GNU libc, the C and C++ committees and the POSIX working
> > group have not seen fit to include those functions, and they're not available
> > on my GNU/Linux box.
> Interesting. In 2010, I was hoping the strl* functions would side step the
> political mess of TR24731-1 on *nix. For those resisting, TR24731-1 is now a
> normative part of the C1x draft (as Annex K), so its coming whether they want
> it or not :/
I stand corrected: C1X draft dated 2010-10-04 now includes the bounds checking
interfaces. See "C1X Draft",
http://www.open-std.org/Jtc1/sc22/wg14/www/docs/n1516.pdf at
http://www.open-std.org/Jtc1/sc22/wg14/www/projects.

So in addition to [nearly ubiquitous] support for strlcpy and friends, we will
have strcpy_s and friends.

Jeff

[Bug c++/46513] Request: Warning for use of unsafe string handling functions

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-11-17 10:43:51 UTC ---
(In reply to comment #3)
> I know "finding the replacement" is not a GCC issue, but perhaps folks who need
> to the *nix safe string gear can use TR24731-2 (not TR24731-1), which is POSIX
> and includes strl* and friends.

TR24731-2 does include functions from POSIX, but the only string handling ones
in n1337 are strdup and strndup, not strl* - and I might be wrong but I don't
know of any plans to add strl* to POSIX.

Besides, anything in C1x will not make it into a C++ standard for many years,
we're still trying to get C++0x finished and new features won't be added now. 
Maybe this request should be for the C front end?
Otherwise you're requesting warnings in C++ code about functions for which
there are no portable, standardised alternative available.

[Bug c++/46513] Request: Warning for use of unsafe string handling functions

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-11-17 11:50:16 UTC ---
On Wed, 17 Nov 2010, noloader at gmail dot com wrote:

> I stand corrected: C1X draft dated 2010-10-04 now includes the bounds checking
> interfaces. See "C1X Draft",
> http://www.open-std.org/Jtc1/sc22/wg14/www/docs/n1516.pdf at
> http://www.open-std.org/Jtc1/sc22/wg14/www/projects.
> 
> So in addition to [nearly ubiquitous] support for strlcpy and friends, we will
> have strcpy_s and friends.

I can't imagine glibc will want to have that set of functions in libc - I 
expect it will simply omit that optional set of interfaces and not define 
__STDC_LIB_EXT1__.  Maybe someone will write a glibc add-on putting them 
in a separate library that a handful of people might then use.

*Some* of the functions there are useful, but the notion that tmpfile (for 
example) has security issues requiring tmpfile_s is nonsense.  And the 
main utility of most of those functions is to retrofit security 
improvements to old code without understanding it.  glibc has its own 
means for such retrofitting (in particular _FORTIFY_SOURCE).  In both 
cases they are really a matter of reducing the risk from certain kinds of 
bugs rather than fixing them; to fix them, you need actually to understand 
the code and determine when you should avoid arbitrary limits and allocate 
as much memory as needed (taking care about overflow when calculating 
allocation sizes) and when you should impose limits and how you should 
handle overflow of them (quietly truncating is not generally a good 
approach); safer interfaces and _FORTIFY_SOURCE should then be used *on 
top of* proper design and calculation of allocations, to reduce the risk 
of any remaining bugs, rather than as a substitute for avoiding the 
possibility of overflow or truncation in the first place.

If you wish to enforce a coding standard disallowing certain functions in 
a particular code base, you are free to use existing GCC features such as 
"#pragma GCC poison" and the "deprecated" attribute.  That seems better to 
me than GCC embedding particular assumptions about a particular set of 
functions, when everyone will have their own preferences about what 
functions should be used and whether functions are safe in a given code 
base depends on how it uses them.

[Bug c++/46513] Request: Warning for use of unsafe string handling functions

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
Resolved as Won't Fix per comment #1 and others.