Weekly Edition
Return to the Security page
| |||||||||||||
A critical security bug in tarsnap
The author of tarsnap ("online backups for the truly paranoid") has sent
out an
advisory describing a "critical" security bug in versions 1.0.22
through 1.0.27. "It may be possible for me, Amazon, or US government
agencies with access to Amazon's datacenters to decrypt data stored with
those versions of Tarsnap. This is an absolutely unacceptable compromise of
Tarsnap's security principles, and I sincerely apologize to everyone
affected." The posting describes how to respond to the problem and
is an interesting discussion of how easily things can go wrong in
security-related code.
(Log in to post comments)
A critical security bug in tarsnap Posted Jan 19, 2011 15:18 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
This is a brilliant description and one of the best explanations I have ever seen for a security errata. Kudos.
A critical security bug in tarsnap Posted Jan 19, 2011 16:59 UTC (Wed) by ledow (guest, #11753) [Link]
Someone please give this guy a "How to handle a security event" award. God, that's a wonderful page to read.
Basically:
Brilliantly written, and brutally honest. It made me look up this piece of software (which I'd never heard of) just to see if it was something I could give him money for.
A critical security bug in tarsnap Posted Jan 19, 2011 17:14 UTC (Wed) by patrick_g (subscriber, #44470) [Link]
Colin Percival was the "FreeBSD Security Officer" so he know how to deal with this sort of things.
That being said I agree that his page about the bug is brilliant.
A critical security bug in tarsnap Posted Jan 27, 2011 9:49 UTC (Thu) by trasz (guest, #45786) [Link]
Colin Percival _is_ the FreeBSD Security Officer.
A critical security bug in tarsnap Posted Jan 19, 2011 20:27 UTC (Wed) by branden (subscriber, #7029) [Link]
I hadn't even heard of tarsnap prior to this article.
And now in the very throes of an chagrin-inducing security problem, the author has me reading about his technology and stokes my interest in it.
I can't be the only one.
Congratulations to Colin Percival for turning a crisis into an opportunity.
A critical security bug in tarsnap Posted Jan 20, 2011 4:07 UTC (Thu) by branden (subscriber, #7029) [Link]
Oh, it's not Free Software. Never mind.
A critical security bug in tarsnap Posted Jan 20, 2011 6:14 UTC (Thu) by wahern (subscriber, #37304) [Link]
The author should be applauded for at least keeping the source code open. But I may have just violated the terms by inspecting the code without using the backup service.
"Redistribution and use in source and binary forms, without modification,
A critical security bug in tarsnap Posted Jan 20, 2011 9:27 UTC (Thu) by josh (subscriber, #17465) [Link]
Ick. I'd run across tarsnap before, and noticed that it had source code available; I never happened to come across the license, though. Thanks for pointing it out.
A critical security bug in tarsnap Posted Jan 19, 2011 21:41 UTC (Wed) by josh (subscriber, #17465) [Link]
The article, while extremely well handled, gets me wondering why tarsnap implemented its own cryptography in the first place rather than using one of the several well-known and well-tested cryptography libraries.
A critical security bug in tarsnap Posted Jan 19, 2011 22:41 UTC (Wed) by nedbass (guest, #70970) [Link]
Tarsnap actually does use OpenSSL. This bug is a good example of how easy it is to create insecure encryption constructions using secure crypto primitives.
A critical security bug in tarsnap Posted Jan 20, 2011 2:17 UTC (Thu) by wahern (subscriber, #37304) [Link]
It uses OpenSSL for some things, but the API shown in the article does not come from OpenSSL. Glancing at crypto_aesctr.c, it appears that he's rolled his own counter mode. It seems he's using OpenSSL's AES implementation for encrypting the nonce and then XORing the block stream into his bytestream himself. This is, IIRC, exactly how counter mode works.
The weird thing is, though, the nonce isn't incremented in his crypto_aesctr_stream() (i.e. after each block generation, which is the natural way to do it). So I suspect that he's concocted some sort of protocol atop AES-CTR, which would explain why he didn't just use OpenSSL's API. Alternatively, maybe he wrote the code before OpenSSL provided AES-CTR. But AES-CTR has been in OpenSSL for several years, and it doesn't explain why the nonce isn't incremented in the obvious place.
The author's description of the issue doesn't answer these questions.
A critical security bug in tarsnap Posted Jan 20, 2011 5:53 UTC (Thu) by wahern (subscriber, #37304) [Link]
*ugh*. This was bothering me so I investigated further. I see now what's happening. The code is indeed incrementing the counter in the lower half of the block. The nonce is for the upper half. tarsnap is using some sort of chunking scheme which resets the lower half of the counter between chunks. (It's not clear that such a scheme is necessary but I'll just presume it is.) The counter value is computed using the second approach specified by NIST recommendation SP800-38A Appendix B.2.
The code is indeed reimplementing OpenSSL's CTR support. There's no reason to do this unless it was implemented before OpenSSL exported that functionality. But regardless the bug isn't in the duplicated code; it's in code which would have been necessary whether using OpenSSL's CTR mode or not.
If there's a moral to this story, it's to properly comment code. All the existing comments just repeat in English _what_ the C code is doing (which is superfluous if you understand C well). None of the relevant comments explain _why_ the logic exists (i.e. explain the chunking scheme and the relation of the nonce to ensuring a unique counter). The why is the most important part, and had the why comment existed the bug might never had come about.
This incident is a classic lesson for how to properly comment code. Classic. They should use this as an example in classrooms.
|
|||||||||||||