Administrivia: List Announcement

[Dave McKinney <dm () securityfocus com>]

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 <aadams () securityfocus com>
// 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