Logan Buesching

Without a doubt, reading Secure Coding in C and C++ made me quite scared of coding securely.  In particular, all the ways you can mess up integer security.  Ever since I had read that book, it has given me a whole new perspective on things to look out for and security problems that can arise.  Lets take a look at what’s going to be a future interview question I’m going to ask people.

// Returns true if set, false if not set
bool ToDecimal(char* string, unsigned long* pdw)
{
    char* end = NULL;
    unsigned long dw = strtol(string, &end, 10);
    if ( dw == LONG_MAX || dw == LONG_MIN
     || (dw == 0 && wzEnd=string) )
    {
        return false;
    }
    *pdw = dw;
    return true;
}

Find the bug!

So what’s wrong with this code? Hint: many things are wrong (which is why I like it), but I’m speaking of what’s relevant to my post. Well, strtol happens to return a signed integer, not an unsigned integer.  What happens if –1 is passed in?  Well, strtol will return –1 (and on most machines it’s represented as 0xffffffff).  The compiler will then stick it into the unsigned long and away they go!

int main()
{
    //Sploits!
    unsigned long age = 25;
    unsigned long brosAge = 0;
    char* theInput = "-1000" //Nasty input
    if (ToDecimal(theInput, &brosAge))
    {
        printf("My age + my brothers age = %d",
		(age+brosAge)); //4294966320
    }
}

In my theoretical program, it’s hardly a problem, but what happens if I reserved a buffer, was doing pointer arithmetic, or something else that could cause serious damage?  This could have just become an entry point into a security hole.  So please, check your signs!