disaster! glibc, gcc4, FORTIFY_SOURCE

[Cameron Simpson]

On 14Apr2005 02:54, Jakub Jelinek <jakub at redhat.com> wrote:
| On Thu, Apr 14, 2005 at 04:25:48PM +1000, Cameron Simpson wrote:
| > 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 [...]
| 
| 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.

I'll give this approach a spin, thanks.

| > 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 agree, being a purist myself, but often the obscure overflows let the
app continue apparently unharmed. When it's a core tool like /bin/sh
that can occasionally be desirable.

| > 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.

Ah, now there's the rub. Some naive people (like me) looked to
the rawhide/devel repository as a source of "more current" packages
i.e. closer to the packages author's live set with some desirable features
not in the QAed release package. A slightly different expectation than a
"testing arbitrary build features" variety of repository, which is what
fedora-devel is right now.

| 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).

Interesting. Even for core apps like /bin/sh? (Or course, one can
successfully argue that it's even more important to abort core apps
before really nasty stuff happens.) I'm not disagreeing with you, btw,
just interested in the thinking.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

EMACS: Escape Meta Alt Control Shift