[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Enabling compiler warning flags

From: Russ Allbery
Subject: Re: Enabling compiler warning flags
Date: Mon, 17 Dec 2012 22:29:58 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Jeffrey Walton <address@hidden> writes:

> Yeah, I think you are right about asprintf (though I have never used it).

> I can't count how many times I've seen silent truncation due to sprint.
> Most recently, I pointed it out on some SE Android patches (Android port
> of SE Linux) that passed by the NSA sponsored mailing list. They went
> unfixed. Amazing.

Silent truncation is the primary reason why strlcpy and strlcat aren't in
glibc.  Both functions are designed to silently truncate when the target
buffer isn't large enough, and few callers deal with that.  This
ironically can actually create other types of security vulnerabilities
(although it's probably less likely to do so than a stack overflow).

asprintf guarantees that you don't have silent truncation; either you run
out of memory and the operation fails, or you get the whole string.  The
cost, of course, is that you now have to do explicit memory management,
which is often what people were trying to avoid by using static buffers.
But it *is* C; if you're not going to embrace explicit memory management,
you may have picked the wrong programming language....  :)

strlcpy and strlcat have some benefit in situations where you're trying to
add some robustness (truncation instead of overflow) to code with
existing, broken APIs that you can't change, which I suspect was some of
the original motivation.  But if you can design the APIs from the start,
I'd always use strdup and asprintf (or something more sophisticated like
obstacks or APR pools) instead.

Russ Allbery (address@hidden)             <>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]