Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
Kees Cook <kees <at> debian.org> writes:
> On Sat, Sep 21, 2013 at 02:46:34PM +0200, Bas Wijnen wrote:
> > On Fri, Sep 20, 2013 at 10:12:16PM -0700, Kees Cook wrote:
> > > This is absolutely a bug in glibc. While the spec can say "undefined",
it
> > > is, in fact, not undefined. It worked in a very specific way for over
a
Right, “common law”. It predates the standard.
> > > decade, so that's pretty well defined. ;) The fortify function has no
need
> > > to change it.
> >
> > I strongly disagree. If I write a specification for something and an
> > implementation of it, then the specification is what defines the
behavior. If
But you don’t just write a C99 library! You write a libc for a Unix-ish
system, with POSIX coming into the mix… as well as lots of historic
practice! Using the standard not defining something as excuse to break
historic practice just makes you look bad.
> > Code that does undefined things is buggy, even if it works on some
> > implementation, and no matter how long it has worked.
I totally disagree. Yes, the C99 standard has a lot of Undefined
Behaviour, more than C89 anyway – but why?
> it's a bug to even allow undefined behavior.
I’m calling for a language that is enough like C for us to be able
to reuse existing code, but has no UB, defines signed overflow,
defines bit sizes (no more 36-bit ints), etc.
I think you’d like that too, from a security PoV.
The idea that there were conflicts in the standards committee is
not all that off, or maybe they just couldn’t decide or didn’t
want to or, like GCC developers (who said this publicly!) only
care about benchmark performance because relying on UB enables
some otherwise-unsafe optimisations. But it’s a nightmare and
prevents people from both writing reliable code now *and* using
old code (say, AT&T nroff, from decades back) with modern (other
than tcc and pcc) compilers.
> In a theoretical sense, sure. In this particular case, why bother breaking
> it when it's a trivial 1 line fix? My original approach was to fix it in
> libc and do a mass bug filing. Everyone wins. If we want to reject the
The glibc people decision to return NULL in crypt(3) has led to
several (plural) CVEs in other software, such as cyrus-sasl2 and
xlockmore, already and breaks the GNU CVS testsuite.
I’ve watched them (both upstream and Debian) not care.
(FWIW, musl never returns NULL, and MirBSD libc now also doesn’t,
even not in the very obscure cases where it was historically
acceptable, especially since even the “how to use crypt()” example
in POSIX itself happily dereferences the retval w/o NULL checks.)
I’m with you here, but I think you’re shouting at walls.
bye,
//mirabilos
Reply to: