Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing]
From: Syzop (syz@dds.nl)Date: 03/28/02
- Previous message: Crispin Cowan: "Re: A buffer overflow study - generic protections"
- In reply to: auto12012 auto12012: "Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing]"
- Next in thread: auto12012 auto12012: "Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 28 Mar 2002 23:44:51 +0100 From: Syzop <syz@dds.nl> To: auto12012 auto12012 <auto12012@hotmail.com>, vuln-dev@securityfocus.com
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.
- Previous message: Crispin Cowan: "Re: A buffer overflow study - generic protections"
- In reply to: auto12012 auto12012: "Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing]"
- Next in thread: auto12012 auto12012: "Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]