Tarsnap exploit bounty(daemonology.net)
daemonology.net
Tarsnap exploit bounty
http://www.daemonology.net/blog/2015-08-21-tarsnap-1000-exploit-bounty.html
7 comments
Funny, I was just about to send you an email asking if you wanted to try your hand at this, given that you're much better at this sort of thing than I am. :-)
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.
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.
Just to be candid: putting an extra $1000 into the pot is way less costly than me spending the time trying (and almost certainly failing) to get a heap overflow in Tarsnap working (even if were an easy one). Also: it's an easy bet for me to make, because at the figures we're talking about, I think we might be unlikely to attract the right talent. :P
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!
To be equally candid: I didn't think you would want the $1000, but I thought you might enjoy the challenge. Similarly, I think the people who are most likely to win this are going to be more interested by the puzzle than by the money. The $1000 is there mainly as linkbait to increase the odds that the right people hear about this.
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...
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...
> 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?
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?
That's part of why I have code in libcperciva which is shared with other projects -- the new AESNI code in tarsnap was all tested via its inclusion in spiped and scrypt before it came into this tarsnap release.
Just to be 200% clear: cperciva is offering $1000 for an exploit of a bug in Tarsnap 1.0.35 that he already fixed in the current 1.0.36 version?!
Yes. Or more precisely, for a demonstration of how the bug can be exploited -- I'm not looking for something "weaponized".
I think if someone manages to exploit this bug, the details will be very interesting, and I think it's worth paying for "interesting".
I think if someone manages to exploit this bug, the details will be very interesting, and I think it's worth paying for "interesting".
I also like the very public illustration of how not all memory corruption bugs are easily exploitable (or, occasionally, meaningfully exploitable at all).
Also an illustration of how unlikely it is that serious exploit developers are going to spend time writing a complicated Tarsnap exploit. :)
Also an illustration of how unlikely it is that serious exploit developers are going to spend time writing a complicated Tarsnap exploit. :)
You may be right, but I hope people won't take away the message that bugs like this don't matter.
Fix bugs! Update your systems! If in doubt, assume that potential vulnerabilities are exploitable!
Fix bugs! Update your systems! If in doubt, assume that potential vulnerabilities are exploitable!
My takeaway has always been "It's easier to fix a memory corruption bug than it is to determine if the bug is exploitable"
[deleted]
Yep.
> No bounty if you're in Iran, North Korea, or some other problem countries.
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.
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.
As elahd hypothesized, this is the trade-sanctions thing -- if someone from Iran would win and there's some way I can legally pay out the bounty, I'll do it, but I don't want to be in the position of owing someone a bounty but having geopolitics prevent me from paying it.
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.
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.
Just change the wording. They aren't problem countries. Our governments don't get along, is all.
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.
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.
I found the wording a bit strange too. Perhaps mention why and that you can choose a charity to donate it to even if you were from those countries?
Anyway. Hope someone wins. A write-up would make interesting reading.
Anyway. Hope someone wins. A write-up would make interesting reading.
I'm not from any of those countries, but the wording struck me as really unfortunate. People from those countries could likely take it as a slight upon themselves. I think it is fair that people, who are not causing these "problems" themselves, identify themselves with their country because of its history and culture, even though they possibly do not agree with their government's policies. They already have to suffer enough because of the policy of many Western countries towards their country.
the wording struck me as really unfortunate
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.
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.
I think you are reading into it too much. Those countries are "problem countries" because citizens of many countries cannot legally transfer funds due to sanctions... It has nothing to do with a value judgement on the countries or the culture by the author of this post.
Not that long since a sitting US President referred to Iran (and others) as the "Axis of Evil", I think some sensitivity is to be expected.
He's probably referring to the problem of sending money to those countries from Canada, where he lives.
[deleted]
Can't transfert money to some countries from banks that also do business in the US...
Original reporter here. I was starting to worry when this will ever get fixed. I am not skilled in exploit development and I basically just found the bug by accident so I won't take the challenge.
Props to Tarsnap team for doing stuff like this. They set quite a good example for others in design, implementation, and combating exploits. Always liked their work. Especially the hilarious and overly-generous pricing scheme. Truly original. ;)
You're going to be even more impressed when you realize that "they" should be "he." :)
Colin actually commented a couple days ago that he finally hired a minion.
Oh, cool. Thanks for letting me know.
Oh heck, it was just one guy. You were right: I'm very impressed.
ISTM this could cost you more than $1000? Wouldn't Ariel Ben Yehuda deserve a bonus over the $100 if the reported bug could be exploited?
Yes, I might reassess that bounty.
I don't understand why people still consider it acceptable to write security critical software in languages like C.
I see this opinion expressed quite frequently. Avoiding C avoids only a limited number of potential bugs, and bugs can occur no matter what language you use. Also, when programming in a higher level language, chances are that if you need to do anything interesting, you are more likely to be using someone else's library module which in turn is written in C. Also, the higher level you go, the more framework is sitting underneath your code -- framework that you must understand 100% in order to avoid misusing it (not to mention flaws in that framework).
Case in point -- how many web sites have been hacked that are written in PHP? or Wordpress? Avoiding C does not avoid bugs.
Case in point -- how many web sites have been hacked that are written in PHP? or Wordpress? Avoiding C does not avoid bugs.
1: Do you agree that languages can be safer or less safe to write code in?
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.
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.
It's kind of a false debate. There were a number of empirical studies in the 90's that compared many 3GL languages, esp to Ada as it was being assessed. The results were that C programmers produced the highest number of defects (esp severe ones), C++ improved on that, and Ada's safety features cut that way down except one time. Outlier might have meant anything. However, almost everything ever published showed C/C++ were less productive, harder to maintain, harder to integrate, and had more bugs/vulnerabilities. So, burden of proof is actually on other side to justify C particularly as a wise choice in building robust software.
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...
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...
That's not enough to refute derekp's point, though. Let's admit that C is unsafe, and that some (not all) other languages are safer. But, first, safety is not the only virtue. And second, you don't get safety just by using a safe language.
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.
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.
"That's not enough to refute derekp's point, though."
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.)
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 see this opinion expressed quite frequently. Avoiding C avoids only a limited number of potential bugs, and bugs can occur no matter what language you use.
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.).
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.).
> Rust
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.
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.
Yes, agreed. We should choose languages based on their suitability for the job, not how long they've been free to ruin the world.
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.
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.
But it avoids a huge class of really really bad bugs.
If you remove manual memory management and mutable stare you can go pretty far in terms of security even in a dynamically typed system. See clojure as an example.
Security problems aren't just buffer overflows. Using another language gives you another set of problems. And of course, the underlying problem is the computation model employed by all modern computers, so using a higher-level language doesn't necessarily protect you from buffer overflows.
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.
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.
> Using another language gives you another set of problems
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.
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.
Control over memory layout and timing. [1]
[1] https://cryptocoding.net/index.php/Coding_rules
[1] https://cryptocoding.net/index.php/Coding_rules
> I don't understand why people still consider it acceptable to write security critical software in languages like C.
What would you rather it be written in, a language that is itself written in C?
What would you rather it be written in, a language that is itself written in C?
Most languages I can think of that would be better than C have solid non-C implementations. Ada has GNAT, a free software compiler that is itself written in Ada. Rust's compiler is in Rust (and, years ago, OCaml), though it uses LLVM, which is C++, for code generation. Go's reference implementation is I believe fully Go, although parts are mechanically translated from C. OCaml is mostly written in OCaml. etc.
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.
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.
As much as I love Rust, I think it's a bit early to be using it in heavy production.
PL/0 (MULTICS), PL/S (z/OS), ALGOL (MCP), LISP/Scheme (dozens), Fortran (PRIMOS), Pascal (UCSD p-system), BASIC (Apple II), Modula2/Oberon (Lilith & Oberon systems), and Ada (Army ASOS, i432 mainframe) are/were written in C? Actually, the answer is no and they implemented these OS's/runtimes without it. They vary in pro's and con's [with Fortran OS hilarious] but not being C-like was a good quality they share in common. Actually, MULTICS team specifically chose PL/0 over C's predecessor because they thought PL/0's design choices would lead to less security problems. They were right [1].
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.
[1] https://www.acsac.org/2002/papers/classic-multics.pdf
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.
[1] https://www.acsac.org/2002/papers/classic-multics.pdf
How many memory corruption / buffer overflow exploits have there been say in the JVM?
Using something like Java does cut out a whole class of memory exploits...
Using something like Java does cut out a whole class of memory exploits...
>How many memory corruption / buffer overflow exploits have there been say in the JVM?
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.
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.
The good thing about something like this (in the abstract) is that you've potentially got many users hammering the facilities in many ways, and it becomes battle-hardened as a result. To this end, Colin hisself is sort of doing this w/ libcperciva[0] to a degree. One library of common code shared among many projects.
[0] https://news.ycombinator.com/item?id=10099294
[0] https://news.ycombinator.com/item?id=10099294
That's a true benefit of using C. The more people know the language, the more people who can comprehend and improve the software. Goes for more than just security in terms of what's improved.
Now, will this happen for a given project? Different issue entirely which might justify using an inherently, safer language.
Now, will this happen for a given project? Different issue entirely which might justify using an inherently, safer language.
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. :)