Netherlands = pwnt

I’m proud of the Porguese team in the world cup. Not just because they won but because of the way they played the game. The Netherlands team should be ashamed of the way they played. Sure anyhing goes to win but man was that ugly. From the start of the game their tactic seemed to be to simply injure the portuguese players. They did manage to upset some of portuguese players (which is normal) but overall it didn’t work very well. And even though for most of the second half Portugal had 1 less player, the team managed to remain calm and outplay the Netherlands. The referee was bad but at least he didn’t show 3 yellow cards to a single player… anyway he won’t be refereeing any important matches anytime in the near future.

I remember the silly dutch going like “pffft Portugal is just a bunch of star players, they can’t play as a team”. Forced to swallow their own words again… sucks to be dutch today .

Konichiwa England

Made Me Laugh, Made Me Cry, Made Me Ramble

I broke into uncontrollable laugher after I read this post (via Halvar Flake). I was like “ROTFLOL! DUMBASS!”. Than after I finally stopped laughing I realized that the guy that made the post is not only an experienced programmer but also apparently a researcher? How can anyone be a C programmer for years (hell, even for months) and not know this? This left me wondering if this guy is the rule (average joe programmer) instead of the exception (dumb harry programmer). That made me sad.

While on the subject of programming and security I have to say I really like microsoft’s work on Spec# (and its derivative Sing#). Which is not surprising considering I’m a C# fan. I also liked the little I’ve read about Singularity so far but that’s subject for another post.

The fact of the matter is that while integer overflows like the one in the one in that google research blog post are trivial and easy to spot, others aren’t. Often functions can get passed values which they shouldn’t be able to get. This happens either because of some weird error in the program or because someone found a way to manipulate the values that get passed to that function. A simple example is when a programmer takes a “length” value written into a network packet by the client software and uses it to allocate memory on the server without making any checks.

Doesn’t take a genius to figure out that this isn’t a good idea. However as software complexity increases, situations like this can become harder to detect when the function that, keeping with the example, allocates the memory is thousands of code lines away from the function that processed the input in a different source file, written by other programmers, maybe years apart. Not to mention that if programmers are being told to work 12 hour days, 6 days per week to meet impossible deadlines set by incompetent people in management, the likelihood of something like this happening increases even if the programmers in questions would normally be very careful about flaws like these. When you’re exhausted and being pressured by your boss to code faster you tend not to care about “little things” nearly as much (and also make more mistakes, which leads to more frustration which leads to more “not caring”). Overworking programmers IS NOT A GOOD IDEA! Writing good code can be a very demanding task (especially in error-prone languages like C). And off course all programmers re-use code (functions, objects,…). A particular piece of code that used to be in a situation where it’s arguments were safe may find it’s way into a program where its arguments are unchecked user input (or something equally as bad).

Even if without any malicious intent, untested boundary cases, such as a function getting passed “buf_size” when it should be “buf_size-1″ can easily lead to crashes, data corruption or both.

As a programmer I’ve had to deal with these problems. Here’s how I write a function (pseudo c-code):

/* func
* Does [whatever was specified]
* Arguments:
* – unsigned int length – size of the thing. Must be at least MIN_LENGTH; Must be at most MAX_LENGTH.
* – Thing *th – pointer to the Thing.
* Returns: 0, ERR_OUT_OF_BOUNDS, ERR_INVALID_PTR, ERR_PRINTER_ON_FIRE.
*/
int func(unsigned int length, Thing *th) {
Thing tmp;
/* other variable declarations */

if ((length = MAX_LENGTH))
return ERR_OUT_OF_BOUNDS;

/* more code goes here */

/* This isn’t actual C code but you get the point */
if (tmp.values != values_that_make_sense)
return ERR_PRINTER_ON_FIRE; /* I don’t actually use this one and I always try to avoid generic error messages */

*th = tmp;

return 0; /* Everything went right as far as we know */
}

Then I call the function like this for example:

err = func(length, &th);
if (err != 0) {
check_for_every_possible_error_and_do_what_needs_to_be_done;
}

Basically my function checks a precondition and a postcondition. I could check the postcondition after the function but I believe a function should be as “self-sufficient” (and if possible, just depend on its arguments) as possible to ensure portability and prevent slipups. That way I can just copy the function, set the constants it uses and make sure I handle every error. Both the constants and the possible errors are listed in the initial comment which makes it easy to re-implement the function in another program.

Sure this is a poor man’s basic implementation of design by contract. If you’re interested in doing it in C you should probably look here. Personally I hope I’m done with C (and C++ and if it’s not too much to ask – it probably is – Java… I hate Java so very much). Regardless of what someone might tell you, creating reliable, secure code in C is a pita. Pointers and manual memory manual memory management are things of the past. The future belongs to managed code, garbage collectors, design by contract and generally speaking, higher abstraction.