Related topics

Today's bugs have BRANDS? Be still my bleeding heart [logo]

Code-slinger Verity reviews the rash of groovy-named open-source security vulns

Bug #2: GnuTLS

From Apple's woes to old Gnus. Again, you will find an excellent analysis of the GnuTLS bug here; but for those of you who can't be bothered to click through, here again is the mystery voice with a summary of the C code in question:

/* Original code comment: this function returns a boolean */
/* VS meta-comment: oh yeah? */
int check_if_ca (/*loadsa params*/)
{
    int result;
    /* Bit of initialisation, then we get to business: */
    result = _gnuls_x509_underscores_are_us(params);
    if (result < 0) {
        /* left out the assert() here */
        goto cleanup;
    }
    result = _bit_twiddling_bogeyman_baffling(more);
    if (result < 0) {
        goto cleanup;
    }
    result = _zippity_doo_da(yet_more);
    if (result < 0) {
        goto cleanup;
    }
    /* ... */
    /* After dozens more lines in this style, we come to: */
    result = 0; /* ie false - VS */
cleanup:

    /* Call _gnutls_free_datum() a few times */
    /* Nice use of the singular 'datum' by the way */
    return result;      
}

You will have spotted that this code uses the same inky-dinky-goto-vous pattern as the previous sample. In mitigation, the author at least names his label "cleanup" and not "fail" - he has a sunnier perspective on life. Also, because of the extra curly brackets, this sample is not so vulnerable to an accidentally repeated goto line rendering swathes of logic unreachable.

He has, however, fallen foul of a very C-ish problem. As you know, C functions - especially library functions - very often return an integer error code. Because there are typically many different ways to get it wrong and only one to get it right, and because one can conveniently test for zero using the ! logical not operator, a much-used API convention is to return 0 if all went well and an error code otherwise.

So you end up writing code like this:

if (!conquer_earth()) {
  /* go hollow out the Earth's core */

where the logic appears to read face-after-fundament:

if the Earth is NOT conquered then
    Hollow out its core. HoldOnAMinuteWtf?

The fix is to have your function instead return boolean true on success and false on failure. This is what Matey has done here, or rather what he says he has done in his comment. Unfortunately, the comment is as far as he got before falling asleep. He didn't even bother to change the return type of his function to bool... oh wait, he's writing in C, so he couldn't. Bummer.

Now, had he been writing in C++, I claim he would have started by fixing his return type. Had he once again fallen prematurely into the arms of Morpheus, on his next compile, he would have got a message like

warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)

(OK, that is the Microsoft C++ compiler's opinion, but it is what I have to hand, ok?)

This message amounts to a polite cough in a situation that calls for a yell of "What gives, moron?" - but for that sort of thing we'd to need to rewrite in something like Pascal, which I recognise is an event comfortably beyond the infinite improbability horizon. But the act of writing a little logic to suppress that tiny squeak of C++ protest would surely have awakened our dreamy programmer from his slumber at the wheel.

Bonus observation: you can go inspect the now-repaired code here. You'll see that the chosen solution is to add another label called (can you guess?) fail.

fail:
result = 0; /* Means boolean false */
cleanup:
// Do datum clean up stuff...

This change guarantees that all the intertwined code paths through this function perform at least one goto. Well done. With this touch, the fixer has performed an act of alchemy: he has turned rubbish into spaghetti.

Sponsored: 10 ways wire data helps conquer IT complexity

Next page: Bug #3: Heartbleed