Re: Administrivia: List Announcement

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: tclahr@br.ibm.com
 * T/L: 6839-7091 .:. Phone: +55 19 3887-7091

Dave McKinney <dm@securityfocus.com>
13/05/03 13:25  

        To:     vuln-dev@securityfocus.com
        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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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 <aadams@securityfocus.com>

// Spot the error in this program.


#include 
#include 

#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