[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.BSI.4.58.0410290928400.24294@malasada.lava.net>
Date: Fri, 29 Oct 2004 09:30:54 -1000 (HST)
From: Tim Newsham <newsham@...a.net>
To: David Brodbeck <DavidB@...l.interclean.com>
Cc: Michael Wojcik <Michael.Wojcik@...rofocus.com>,
Valdis.Kletnieks@...edu, bugtraq@...urityfocus.com
Subject: RE: Update: Web browsers - a mini-farce (MSIE gives in)
> > From: Tim Newsham [mailto:newsham@...a.net]
>
> > But lets assume that a good programmer is writing software and
> > it comes to his attention that there is a buffer overflow, or
> > that user input is not being filtered, or that user input is being
> > passed to a printf type function. What happens next? Well, it
> > depends on how many bugs there are, how much other work needs
> > to be done, and very importantly, what the perceived impact of
> > that bug is. You cannot imagine how many times a bug is pointed
> > out and the author of the software says "ok, that bug can only
> > happen if the user does something stupid, and it is not exploitable.
> > Lets defer that one."
>
> This suggests that it's reasonable for a program to segfault because the
> user made a mistake, instead of having some non-fatal form of error
> handling. I don't think that should be acceptable at all, though I agree
> it's very common. If I had a dollar for every time I've lost work because a
> segfault or GPF happened before I saved my document...
A "defer" means "we'll fix it, but we have more important things to
do first." I wouldn't say its an acceptance that its "reasonable"
behavior.
Tim N.
Powered by blists - more mailing lists