|
From: Danett s. <dan...@ya...> - 2007-10-27 22:33:22
|
Hi,
How are you?
That's my first post at mail-list, first of all,
congratulations for the good project. :)
I downloaded the last version of valgrind and compiled
it without problems.
I also created a small program to test valgrind, the
code is below:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]){
int t;
int *x;
int *y;
char destino[10];
char zf[15]="\0";
memset(zf, '\0', sizeof(zf));
x = (int *)malloc(sizeof(int));
y = (int *)malloc(sizeof(int));
if (argc == 1){
printf("\nYou MUST provide at last one
argument.\n");
exit(1);
}
strcpy(destino, argv[1]);
printf("\n\ntest\n");
for (t=0; t <= 16; t++){
zf[t] = 'A';
}
printf("\n\n zf is %s\n", zf);
free(x);
*x = 5;
return(0);
}
I compiled it using:
# gcc -o hacked hacked.c -g -O0
I used valgrind like this:
# valgrind --leak-check=full --track-fds=yes ./hacked
blen
==26956== Memcheck, a memory error detector.
==26956== Copyright (C) 2002-2007, and GNU GPL'd, by
Julian Seward et al.
==26956== Using LibVEX rev 1732, a library for dynamic
binary translation.
==26956== Copyright (C) 2004-2007, and GNU GPL'd, by
OpenWorks LLP.
==26956== Using valgrind-3.2.3, a dynamic binary
instrumentation framework.
==26956== Copyright (C) 2000-2007, and GNU GPL'd, by
Julian Seward et al.
==26956== For more details, rerun with: -v
==26956==
--26956-- DWARF2 CFI reader: unhandled CFI instruction
0:50
--26956-- DWARF2 CFI reader: unhandled CFI instruction
0:50
test
==26956== Invalid write of size 4
==26956== at 0x80484E5: main (hacked.c:34)
==26956== Address 0x415A028 is 0 bytes inside a block
of size 4 free'd
==26956== at 0x401C2CE: free
(vg_replace_malloc.c:233)
==26956== by 0x80484E1: main (hacked.c:32)
==26956==
==26956== FILE DESCRIPTORS: 3 open at exit.
==26956== Open file descriptor 2: /dev/pts/1
==26956== <inherited from parent>
==26956==
==26956== Open file descriptor 1: /dev/pts/1
==26956== <inherited from parent>
==26956==
==26956== Open file descriptor 0: /dev/pts/1
==26956== <inherited from parent>
==26956==
==26956==
==26956== ERROR SUMMARY: 1 errors from 1 contexts
(suppressed: 11 from 1)
==26956== malloc/free: in use at exit: 4 bytes in 1
blocks.
==26956== malloc/free: 2 allocs, 1 frees, 8 bytes
allocated.
==26956== For counts of detected errors, rerun with:
-v
==26956== searching for pointers to 1 not-freed
blocks.
==26956== checked 54,228 bytes.
==26956==
==26956==
==26956== 4 bytes in 1 blocks are definitely lost in
loss record 1 of 1
==26956== at 0x401B637: malloc
(vg_replace_malloc.c:149)
==26956== by 0x804846E: main (hacked.c:13)
==26956==
==26956== LEAK SUMMARY:
==26956== definitely lost: 4 bytes in 1 blocks.
==26956== possibly lost: 0 bytes in 0 blocks.
==26956== still reachable: 0 bytes in 0 blocks.
==26956== suppressed: 0 bytes in 0 blocks.
We can se it were able to detect 2 bugs:
1) The acess to freed pointer (pointer NULL
reference):
==27191== Invalid write of size 4
==27191== at 0x8048567: main (hacked.c:38)
==27191== Address 0x415A028 is 0 bytes inside a block
of size 4 free'd
==27191== at 0x401C2CE: free
(vg_replace_malloc.c:233)
==27191== by 0x8048563: main (hacked.c:36)
2) The pointer (y) allocated and not free'd.
==27191== 4 bytes in 1 blocks are definitely lost in
loss record 1 of 1
==27191== at 0x401B637: malloc
(vg_replace_malloc.c:149)
==27191== by 0x80484E2: main (hacked.c:15)
However it missed 2 bugs (50%) of the flaws, the other
too are:
3)A stack overflow using strcpy() at Line 24 -
strcpy(destino, argv[1]);
4) A off by 1 using a loop to fill the array at line
28-32.
I seen that Valgrind can detect the overflow 3
(strcpy) if I call hacked with a so big argument,
like:
# valgrind --leak-check=full --track-fds=yes ./hacked
blenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblenblen
==26996== Invalid free() / delete / delete[]
==26996== at 0x401C2CE: free
(vg_replace_malloc.c:233)
==26996== by 0x80484E1: main (hacked.c:32)
==26996== Address 0x6E656C62 is not stack'd, malloc'd
or (recently) free'd
==26996==
==26996== Invalid write of size 4
==26996== at 0x80484E5: main (hacked.c:34)
==26996== Address 0x6E656C62 is not stack'd, malloc'd
or (recently) free'd
==26996==
==26996== Process terminating with default action of
signal 11 (SIGSEGV)
==26996== Access not within mapped region at address
0x6E656C62
==26996== at 0x80484E5: main (hacked.c:34)
However in this way my program segfault, so I should
not need valgrind since I must generate the overflow
to it detect (and SIGSEGV is a good sign of it too).
The same happen if I increase some bytes (4,5,6,..) in
the loop in the for(), however the program will crash
(sigsegv).
My question is, I'm missing something in the use of
valgrind? Is possible to use valgrind to detect this 2
kind of flaws that valgrind missed in my code?
Off-Topic: Do you costume to use other tools to caught
this kind of flaws? What program? I'm always looking
for static analisys tool, runtime tools, gcc patchs,
etc that can detect security flaws and have a low
number os false positives. If some of you have some
indication it's very appreciated. :)
Backing to valgrind...
Q1) There is a way to use valgrind in a already
running process? For example, attach to a running
process?
Q2) I had developed a small module for apache, how is
the best way to test it with valgrind? I can't call it
directly since it's a dso module. Apache2 is
multi-thread and have a lot of code and modules, there
is a specific way where I can call valgrind and filter
only possible problems of my code? (Hard task ahn?
hehe)
All replys are welcome.
Sorry for so big e-mail and a lot of questions, hope
this can be useful to others too.
Cheers
Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/
|
|
From: Brad H. <br...@fr...> - 2007-10-28 00:27:20
|
On Sunday 28 October 2007 09:33:12 am Danett song wrote: > 3)A stack overflow using strcpy() at Line 24 - > strcpy(destino, argv[1]); That necessarily isn't an error. If argv[1] can fit into destino, then there is no bug. Valgrind can't tell you about an error that might occur with different input. Possibly a static analysis tool can warn you that strcpy is a bad idea. In this case, something like flawfinder is probably about the right level. See: http://www.dwheeler.com/flawfinder/ > 4) A off by 1 using a loop to fill the array at line > 28-32. I don't know about this one. As a guess, this might not be showing up on your architecture because the array doesn't have anything after it. Try re-ordering the variable declaration or adding something at the end. Brad |