disaster! glibc, gcc4, FORTIFY_SOURCE

[Jakub Jelinek]

On Thu, Apr 14, 2005 at 04:25:48PM +1000, Cameron Simpson wrote:
> At the risk of looking like a complete idiot, I'd like to report an
> apparently serious problem with the recent glibc etc stuff in (I think)
> Fedora-Development.
> 
> In an excess of zeal yesterday I upgraded some packages from the
> development set and now various programs report "buffer overflow detected"
> and like messages, and abort. These programs include bash and my usual
> mail reader. I've reverted my glibc to 2.3.4 from fedora-updates and
> things are a bit better but not totally fixed, so I figure I've still
> got some more packages to locate and revert:-(

No, reversion is not the right first step here. 
Whenever you see such messages, you should see how is it possible
to reproduce it, ideally install the corresponding *debuginfo*.rpm package,
get a backtrace from where the buffer overflow happened and report
it into bugzilla.  Rawhide glibc even prints some limited backtrace
by default when the overflow happens.

There are no known bugs in the -D_FORTIFY_SOURCE=2 patches and all
buffer overflows it detected (several dozens) turned up to be real
bugs in the programs, sometimes very severe.

> If confirmed, is there a URL that documents the effects of this?
> Is there a runtime way to turn these from "abort" into "warn but proceed"?

There is no way to turn it off.  If you overflow an buffer, all bets are
off what the program is actually doing.

> I'd like to suggest that this kind of build not be done for any release
> versions; while all the crashing programs are almost certainly buggy,
> unless the user can switch the behaviour _off_ they will be very very
> unhappy.

In development versions, the intent is obviously that as many such problems
are detected and fixed.  For released versions it must stay too, because
although all/most problems in the usual usage of the programs will be fixed,
when you start doing something exceptional/hostile to the programs, such as
trying to give it unusually big inputs or exploit in some other way,
the aborts are going to turn the vulnerability into a DoS (and show where
the problem was, so that it also can be fixed soon if reported).

	Jakub