OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Syzop (syzdds.nl)
Date: Thu Mar 28 2002 - 16:44:51 CST

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

    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.