flak rss random

finding bugs in tarsnap

Some people were hanging around Michael Lucas’s table at BSDCan, and the topic of conversation turned to Tarsnap. (Lucas has a book about it.) Each person went round the circle and said they were happy to pay Colin for his service, but when it was finally my turn I was forced to admit that while I would pay for Tarsnap, I found a bug and so, thanks to the bounty, it may be more accurate to say I get paid to use it.

Neither of these bugs is especially exciting, but they’re a little outside the norm. The most interesting part of the story is probably that in each case, prior to reviewing the code in question, I had recently been thinking about the same class of bug in other circumstances.

Around the same time I was working on signal safe strcpy I wondered if anyone had managed to get the POSIX signal rules right. I knew Colin was a pretty fastidious developer, and in particular he cares about what the standard says you can do, not just what it seems likely you can get away with in practice. So even if I found minor pedantic bug, it would be worth reporting. I did, and it was. tarsnap had a signal handler that was reading from a constant array. So what, how could this matter? The standard says thou shalt not. Gotcha! In reality, it’s entirely harmless and the average unix program does far more terrible things in signal handlers, but having convinced myself that such a silly bug was sure to exist, it was easy to find.

If you look at a list of contributing factors that explain how Heartbleed leaked private keys, somewhere far down near the bottom you’ll find “used BN_free and not BN_clear_free”. In LibreSSL, we went big hammer and clear all the bignums, regardless of sensitivity. And so it was that when I bumped into Colin at BSDCan 2014 two weeks later, failure to clear secret bignums from memory was fresh in my mind. Reviewing the spiped code, I came across some DH code that used the OpenSSL BN code, but didn’t call BN_clear_free. Gotcha! Of course, Colin has his own thoughts on the futility of memory clearing, but if a library provides an API to do something, one should probably use it. Again, a mostly harmless bug and pretty far down the list of mistakes people make when implementing DH, but knowing that such a bug was probably there made it possible to find.

I doubt I would have found either bug if I hadn’t been specifically looking for them. It’s worth remembering that beyond the short list of bugs that everybody knows about and looks for, there’s a long tail of bugs that get overlooked. While my two examples aren’t serious, some bugs in this category can be. A good strategy for finding such bugs is to identify one example, then search for more in other people’s code.

Posted 02 Jul 2015 13:09 by tedu Updated: 02 Jul 2015 13:09
Tagged: c programming