Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing]

[Syzop <syz () dds nl>]

Hi,

auto12012 auto12012 wrote:

> I do not see, then, how vulnerabilities are linked to execution paths. An
> application does not become vulnerable simply because it took execution path
> A instead of path B. It was already vulnerable in first place because it
> based its decision on untrustworthy information.

What about something like free() bugs:
function A calls function b(buffer), function B detects invallid input does a
free(buffer) and returns 0. The return value of B is detected and function A
outputs some message to a logfile (ie: "invallid input detected") and free()'s
buffer <- double free:
-- non-usefull-code-but-demo --
static int somefunc(char *a)
{
        if (!strncmp(a, "test", 4)) {
                free(a);
                return 1;
        }
        return 0;
}

int main(int argc, char *argv[])
{
char *p;

        if (argc != 2)
                return 0;
        p = (char *)malloc(strlen(argv[1])+1);
        strcpy(p, argv[1]);
        if (somefunc(p)) {
                printf("Passed\n");
        }
        printf("You said: %s\n", p);
        free(p);
        return 1;
}
-- /non-usefull-code-but-demo --

Ofcourse the application isn't vulnerable _because_
of the different execution path taken, but it is
because that execution path _exists_.

In some mail later you said:
> If I do not believe vulnerability is related to execution
> path, it is not because I believe it is not dependent of anything, but
> simply because I believe it is dependent of something that is of much higher
> abstraction: logic.

When (manually) auditting code I'm thinking all the time about
all possible execution paths, what if A happends, then B combined with C...
Even automated programs exists which do this (www.splint.org).
So I don't know why you say it has nothing to do with vulnerabilities...

Unless you are talking about "vulnerabilities" and not about "detecting
vulnerabilities" but I thought the whole thread was about different methods
to analyze code / search for vulns.

    Bram Matthys.