Systematic generation of "all possible inputs" is needed for and only for
security guys. The attacker side of the world only care about the impact
and not about the reasons leading to the impact. Since they have all the
time in the world, they can flood with random stutff and wait for whatever
time for thiings to happen. To counter these types of attacks, the
security side of the world a) does not have enough time b) they need to
check for reasons of the impact in order to do something to mitigate it c)
They certainly need to *systematically* check for each and every input
(which is hard if you go into complex protocols, or atleast have the code
only allow good inputs).

On Fri, 29 Mar 2002, Lincoln Yeoh wrote:

> Going through all the input and possible states and all that can be
> impossible, but when so many programs are so fragile you don't have to -
> they blow up at the first bend.
>
> Thing is C is such an unfriendly environment we can say an automated
> program can practically spot 95% of the bugs because 95% of the bugs could
> have been automatically avoided in the first place - either by some special
> program, or by using a different language.
>
> Don't have to exploit those 5% high level bugs when you can be root with
> the 95% right?
>
> That said, many of the web sites out there have the "pass raw cgi
> parameters to the db" problem. Give a programmer a low level tool and
> blahblahblah, give a programmer a high level tool and blahblahblah :).
>
> Cheerio,
> Link.
>
> At 11:42 AM 28-03-2002 -0500, Michal Zalewski wrote:
>
> >To tell how the process is to behave in certain conditions, you have to be
> >able to predict this behavior, or actually run / go thru the program and
> >see what happens. And you have to know it for all possible input
> >perameters. Both approaches, without making significant sacrifices, are
> >not very feasible for a typical real-life project (say, Sendmail), where
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]