Re: Administrivia: List Announcement

From: Brian Hatch (vuln-dev_at_ifokr.org)
Date: 05/13/03

  • Next message: Bennett Todd: "vulndev-1.c challenge (was Re: Administrivia: List Announcement)" 
    Date: Tue, 13 May 2003 10:45:21 -0700
To: vuln-dev@securityfocus.com

    > #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);

    Fail to verify buf1 and buf2 != NULL after malloc.
    (and why not just use 'char buf1[SIZE]; and char buf2[SIZE];' ??

    And for goodness sake, let's cast things properly if you're going
    to malloc, and for good form include the size of the element, even
    when it's a char:

            char *buf1 = (char*)malloc( SIZE * sizeof(char) );

    > p1 = argv[1], p2 = argv[2];
    > strncpy(buf2, p2, SIZE);

    strncpy doesn't null terminate if strlen(p2) > SIZE.
    (Not necessarily an issue for this dinky program.)

    > for (i = 0; i <= SIZE && p1[i] != '\0'; i++)
    > buf1[i] = p1[i];

    Why not NULL terminate buf1?
    (Again, we're not using it here anyway, but it seems silly not to.)

    > free(buf1);
    > free(buf2);

    Assume the user makes the malloc fail by setting nasty process limits.
    Thus buf1 and buf2 don't have SIZE bytes at all, yet we copy into
    the locations they would be. Voila - overflow.

    Or, since we're free'ing a memory location that was never malloc'd,
    it's kind of like a double free bug (though since it was never malloc'd
    properly in the first place, perhaps it needs a better name.) 

    --
Brian Hatch                  Time exists solely
   Systems and                for the purpose of
   Security Engineer          preventing everything
www.hackinglinuxexposed.com   from happening at once.
Every message PGP signed

  • Next message: Bennett Todd: "vulndev-1.c challenge (was Re: Administrivia: List Announcement)"

    Relevant Pages

    • Re: problem with memcpy and pointers/arrays confusion - again
      ... this second method is known as an explicit conversion, or cast. ... The cast, in effect, tells the compiler: ... the malloc function. ... function taking a size_t as a parameter and returning a void pointer (i.e. ...
      (comp.lang.c)
    • Re: why is casting malloc a bad thing?
      ... In the compilers we used in the 1980s (including VAX ... compilers for IBM PCs), malloc() had type: ... Without the cast, you got ... and adds HUGE amounts of risk. ...
      (comp.lang.c)
    • Re: Casting the return value of malloc()...
      ... The major reason for not using superfluous casts, of which malloc() ... programmer's ability to treat a cast as a warning sign. ... then the compiler can catch type errors. ... The sizeof operator should never be followed immediately by '(' ...
      (comp.lang.c)
    • Re: Casting the return value of malloc()...
      ... The major reason for not using superfluous casts, of which malloc() ... programmer's ability to treat a cast as a warning sign. ... then the compiler can catch type errors. ... The sizeof operator should never be followed immediately by '(' because it is not a function. ...
      (comp.lang.c)
    • Re: Casting the return value of malloc()...
      ... The major reason for not using superfluous casts, of which malloc() ... programmer's ability to treat a cast as a warning sign. ... then the compiler can catch type errors. ... might be allocated with malloc must be declared with a typedef. ...
      (comp.lang.c)