I have read and tested this program, and what I have gathered, buf1 and buf2 will be diferent whether you type the same string: for example: changing the SIZE to 5: # ./vulndev-1 1234567890 1234567890 buf1: 123456 buf2: 12345 because strncpy copies only 5 bytes (0 to 4) and for loop copies 6 bytes (0 to 5) Is it the problem? Obrigado / Regards /* * Thiago Canozzo Lahr .:. IT Security Brazil * IBM Global Services .:. Email: tclahrat_private * T/L: 6839-7091 .:. Phone: +55 19 3887-7091 */ Dave McKinney <dmat_private> 13/05/03 13:25 To: vuln-devat_private cc: Subject: Administrivia: List Announcement Aaron Adams and myself would like to announce our plans to take vuln-dev in a new direction, which we think will improve the overall value of the list. We've enlisted another Symantec employee, Anthony Roe, who'll be helping us with some of the workload entailed to see this idea through. One of the purposes of the list is to provide a learning facility for people interested in the process of vulnerability research. Two important steps in this process are identifying potential vulnerabilities (through whatever means available) and then proving that the condition does exist and will impact various security properties. Discussion on this list often focuses on specific real world issues, while sometimes neglecting the broader theoretical aspects of the vulnerabilities. These theoretical aspects include why something is an issue, how to spot similar issues, discussion of general classes of vulnerabilities, how realistic it is to reproduce issues across platforms and architectures, and attack scenarios/methods of exploitation. We have brainstormed on ways to stimulate this type of discussion and turn vuln-dev into a richer learning resource for those who read the list. The idea we settled on was to present the list with theoretical problems and then host a discussion of what makes the issue a security problem and how it could be exploited by a malicious attacker. Part of our inspiration for this idea was various challenges that others have hosted such as gera's Insecure Programming by Example web page[1] or King of the Stack. The basic idea is that people are presented with a fabricated program that may have an exploitable security issue and then as a group, we can discuss where the problem exists and what the nature of the problem is, possibly even developing a proof-of-concept to establish whether or not the issue is exploitable. From this point we would encourage people to develop and post different proof-of-concepts to illustrate various techniques of proving the issue to be exploitable as well as consequences of exploitation. The goal is to help people to improve their vulnerability research skills (such as code auditing). We encourage people of various skill levels to participate or observe and will try to keep the problems difficult and interesting for all who are interested. We also hope that other people will contribute interesting problems for discussion. There won't be any incentive for participating in these challenges other than a potential learning experience, but I think that should be enough motivation for most people. I should be careful to state that none of this is intended to affect or detract from what is normally discussed on vuln-dev and we'll only continue doing it as long as there is an interest. We only wish to take a more active role in making the list a better learning resource. Depending on how well-received this idea is, we may also be making changes to the FAQ to reflect this new direction. [1] http://community.core-sdi.com/~gera/InsecureProgramming/ --- We'll kick this off with the first challenge, which was devised by Aaron Adams: // vulndev-1.c // vuln-dev mailing list security challenge #1 // by Aaron Adams <aadamsat_private> // Spot the error in this program. #include <stdio.h> #include <stdlib.h> #define SIZE 252 int main(int argc, char *argv[]) { int i; char *p1, *p2; char *buf1 = malloc(SIZE); char *buf2 = malloc(SIZE); if (argc != 3) exit(1); p1 = argv[1], p2 = argv[2]; strncpy(buf2, p2, SIZE); for (i = 0; i <= SIZE && p1[i] != '\0'; i++) buf1[i] = p1[i]; free(buf1); free(buf2); return 0; } Dave McKinney Symantec keyID: BF919DD7 key fingerprint = 494D 6B7D 4611 7A7A 5DBB 3B29 4D89 3A70 BF91 9DD7
This archive was generated by hypermail 2b30 : Tue May 13 2003 - 15:24:59 PDT