Re: Administrivia: List Announcement

> #include <stdio.h>

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 doesn't null terminate if strlen(p2) > SIZE. (Not necessarily an issue for this dinky program.)

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

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

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

> free(buf1);

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