On 14Apr2005 02:54, Jakub Jelinek <jakub@xxxxxxxxxx> 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@xxxxxxxxxx> DoD#743 http://www.cskk.ezoshosting.com/cs/ EMACS: Escape Meta Alt Control Shift
