Tarsnap exploit bounty
daemonology.net
daemonology.net
Colin: if you post this bounty publicly anywhere, you have my permission to note also my commitment to match the bounty, which will remain ongoing until either (a) your bounty changes, or (b) I notify you otherwise (which is unlikely).
Good luck, everyone. I will be surprised and happy if this HN comment costs me anything. :)
you have my permission to note also my commitment to match the bounty
Thanks! I've updated the blog post with a link to this comment.
But if there was anyone whose code I would bet on, your name at the top of the list anyways!
But if there was anyone whose code I would bet on, your name at the top of the list anyways!
Well, we've already established that the code was wrong...
Hah, it's been a while since I read:
http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...
Makes me feel a little less bad for the Debian issue with (way!) too low entropy in key-generation.
Refactoring code using crypto dangerous :-/
Have you considered creating a 2.0 on top of NaCL? I could see that it would probably not be a good idea to actually throw out all the existing tarsnap-code etc -- I generally just mean if you'd want to move to a simple, yet "batteries-included"/shrink-wrapped crypto library?
I think if someone manages to exploit this bug, the details will be very interesting, and I think it's worth paying for "interesting".
Also an illustration of how unlikely it is that serious exploit developers are going to spend time writing a complicated Tarsnap exploit. :)
Fix bugs! Update your systems! If in doubt, assume that potential vulnerabilities are exploitable!
I’m a Tarsnap user from Iran. I’m not interested in these bounties anyways, but the phrase “problem countries” feels a little strange to me.
The reference to "other problem countries" is simply because I can't keep track of which countries are on the list right now... I'm pretty sure Iraq, Syria, and Libya have all gone onto Canada's list at some point recently but some or all of them may be back off the list. Sorry if it seemed a bit pithy; given how often I see no-sanctioned-countries clauses online I figured that residents of said countries would know if they were likely to be affected.
You're right. In hindsight I should have been clearer about the issue I was trying to address there. I am clearer in the bug bounty page on the tarsnap website, but my blog is written in less formal language, and I allowed myself to slip from informal into imprecise.
Anyway. Hope someone wins. A write-up would make interesting reading.
It's not the exclusion he has a problem with.
If you visit Iran, or meet any Iranians, you'll quickly realize the land and the people are not problems at all. They actually tend to go out of their way to be inclusive, because they know how brainwashed we are into thinking they are a "problem country", and they are eager to correct that.
What would you rather it be written in, a language that is itself written in C?
Using something like Java does cut out a whole class of memory exploits...
There have actually been quite a lot. But they're generally not things that could be exploited in a typical Java network/web application. They're mostly an issue for sandbox escapes; e.g. Java applets in the browser.
Now, will this happen for a given project? Different issue entirely which might justify using an inherently, safer language.
Besides, the problem is not that C is malware, it's that it's a bad language to write in. Once code exists in C, you can make it solid (https://sel4.systems is the logical extreme of that). So using a C-language compiler but doing actual development in not-C gives you way more defense-in-depth than doing day-to-day work in C.
Using C for a project makes sense for numerous reasons that plenty others have elaborated elsewhere. Very talented people such as Tarsnap team can even use it robustly. However, it's inferior to many other system languages in productivity, robustness, maintenance, or some combo of these. And you can build fast, reliable systems (even OS's) without it. Its widespread use is a legacy/network effect caused by targeting cheap hardware, UNIX using it, key FOSS using it, resulting labor, and resulting libraries/tools for it. So, use it or not, but let's be honest about what it is and the why.
Case in point -- how many web sites have been hacked that are written in PHP? or Wordpress? Avoiding C does not avoid bugs.
That's not a useful comparison, since you're distilling the question of how many bugs there are to whether there are bugs. If a language gets you two security-critical bugs in a 10-year-long project, that's not a reason to say "Eh, might as well have used C".
> Case in point -- how many web sites have been hacked that are written in PHP? or Wordpress? Avoiding C does not avoid bugs.
Sure, don't write security-critical software in PHP either. There are other languages in the world; some of them are specifically designed for writing security-critical software (e.g., Ada and Rust), some happen to be much better than C due to other parts of their design (e.g., Go, Haskell, idiomatic C++11, Vala), and some happen to be not significantly better than C (e.g., PHP, Python, Perl, bash, etc. etc.).
So instead of using C we should write our security-critical software in a language that was released 3 months ago and has no major deployments.
That said, if you have some sort of external constraint about using a language merely because other people are using it, there's Ada, which is over three decades old and has numerous major deployments.
If yes to 1, 2: Can you seriously defend the claim that C is not well to the "unsafe" end of the spectrum? And that, equivalently, there are a number of safer languages to write in?
If no to 1, 2: How can you actually justify that? Given the same programmer writing in Haskell and Assembler, with the same amount of effort, all code written by that programmer will have the same security level? Really?
It seems to me the only way to carry the argument that "It's not a problem to write security code in C" is to reduce all languages to "safe" and "unsafe", define "safe" somewhat absurdly as "impossible to write insecure code in", then claim that since all languages are in the "unsafe" column, it's just fine to use C.
The mere act of spelling that argument ought to nearly suffice to refute it.
The AdaCore book below illustrates nicely the different areas where defects are common and how they systematically eliminate them. The Wirth languages similarly added all kinds of protections in automatically while letting you disable safety where performance or low-level requirements demanded it. Still did interface protections for calls to that code. I think updating something like that with extra protections Ada community, etc have figured out would give lots of safety, performance, & without Ada's steep learning curve. What you think?
http://www.adacore.com/knowledge/technical-papers/safe-secur...
To the first point: Safety is good. Really. For security-critical software, safety is very, very, important. It's still not the only thing that's important. Familiarity to the developer still matters. Tool support still matters.
For example, I've got nearly 30 years of experience with C/C++. I can avoid (most of) the sharp edges. Could I write code that somebody could still pwn? Probably. Could a static analyzer, say, save me? Maybe. But let's say I wrote the same code in Haskell. Could I write at least something that could DOS the user's machine? Easily. Would I have any idea whether I was doing so? No. Could a static analyzer save me?
Second, I remember when Microsoft added the ability for Outlook to execute attachments. That was going to be a gaping security hole, no matter what language it was written in. The security hole was in the spec, not in implementing language. And if I understand derekp's point, you could have a safety hole in the library. For example, Java is safer than C at string handling... unless there was a flaw in Java's String library. Are you sure that there isn't one? How sure are you? Why are you that sure?
For that matter, did Haskell have an SSL package? Was that package anything besides a wrapper around a C library?
The higher level stuff you use, the more layers there are below you, and the greater the attack surface that you can't even see.
Now, you could argue that I'm more likely to write a security bug doing string handling by hand, than there is to be one in Java's String library. And I'd agree that it's probably so. But I need everything I use to be bulletproof, and an attacker only needs to find one flaw. The more I use, the less the odds are in my favor. (The more I write myself, also the less the odds are in my favor.) There is a place where writing it yourself, even in C, is the right answer, even for security critical code. But once you do, audit it heavily, analyze it with as many tools as you can, have whitehats take a serious run at it, and so on.
Fine, fine, it doesn't "refute" it, it "merely" makes it irrelevant to the real world.
I don't think the rest of your message is particularly relevant to mine. Having claimed that there are varying degrees of safety, I'm not sure how an extended discussion of the varying degrees of safety of various technologies counters anything I said.
(Also, as a pragmatic matter, I consider "C" and "C + Valgrind + Coverity + whatever else" to basically be different languages. However, don't talk to me about how wonderful the latter is if you're programming in the former! You have to actually use the tools, not just get a sense of comfort from the fact they exist.)
I'd say the biggest trap for young players is the C standard library, rather than anything about C the language. Null-terminated strings are very space efficient, but hard to work with. If you're willing to use something like bstrings, then you're setting yourself up for a higher likelihood of success. But most people choose what's built in, either for compatibility with other libraries, inertia, or not wanting yet another dependency, and then mess something up.
No, you have those problems in C too. Using another language gives you the problems you had before and takes away the memory safety problems.