Live data from Hacker News

Zcoin implementation bug enabled attacker to create over 500K Zcoins

makebitcoingreatagain.wordpress.com

181–190 of 223 posts

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#181
post #138

Earlier quoted context omitted.

What language can be better peer-reviewed?

A purely functional statically typed one, like OCaml or Haskell, because there would be so much less to review, and an insane amount of the reviewing work is automatic. Zero bugs around state, zero bugs around memory mgmt, zero bugs about error conditions not being handled, zero bugs due to some data being expected but not being written, etc.

Well, a couple months back I attended a talk on a Haskell implementation of the Noise protocol.

The programmer admitted that he was a cryptography novice, and in fact a Haskell novice.

As a result the code he wrote is needlessly abstract - for one thing the guy uses Free monads and in turn ropes in template Haskell as part of his state model. I really have no idea what code he's generating.

The code has other features that make review challenging - for instance he doesn't qualify any of his imports so it's hard to tell where to look for the functions he's implementing.

Maybe you are better at auditing Haskell than I am. As DJ Bernstein writes in various places, one common exploit is to construct an elliptic curve Diffie Helman shared secret with input that isn't a curve point. I really can't tell if the guy is mitigating against this attack or not, but here you can have a look:

https://github.com/centromere/cacophony

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#182
post #176

Earlier quoted context omitted.

This wasn't an exploit of that type though. I assume Rust allows for the same type of error? Not familiar with Rust, but does the following work?: let mut x = 0; if x = 1 { println!("oops, meant =="); }

Actually the type system catches that particular mistake: error[E0308]: mismatched types --> src/main.rs:5:6 | 5 | if x = 1 { | ^^^^^ expected bool, found () | = note: expected type `bool` = note: found type `()` error: aborting due to previous error error: Could not compile `playground`. To learn more, run the command again with --verbose.

Interesting. Is there any plausible way that Rust can fall into the == vs = trap?

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#183

The error is here: https://github.com/zcoinofficial/zcoin/blob/81a667867b5d8489... and the line of code: zccoinSpend.denomination == libzerocoin::ZQ_LOVELACE; In other words, a statement with no effect. In D, such a line gives an error, not a warning: Error: == has no effect in expression You can force the statement to be accepted by casting it to void. It's really past time for languages to not accept such code any…

The D forums seem to suggest this is only true for primitive types, is that correct?

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#184
post #182

Earlier quoted context omitted.

Actually the type system catches that particular mistake: error[E0308]: mismatched types --> src/main.rs:5:6 | 5 | if x = 1 { | ^^^^^ expected bool, found () | = note: expected type `bool` = note: found type `()` error: aborting due to previous error error: Could not compile `playground`. To learn more, run the command again with --verbose.

Interesting. Is there any plausible way that Rust can fall into the == vs = trap?

I haven't yet reached the level of Rust mastery where I'm confident in this answer, but as far as I can tell it's very hard to make that kind of mistake. I'd be very interested to hear what others have to say on it though.

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#185
post #172

Earlier quoted context omitted.

Yep. I'd add that if it's a warning you're absolutely certain of, use the warning control pragmas to suppress them, and document why the warning's suppressed. Keep the compiler output clean so you can see where you need to examine.

Yup. I'm a big fan of -Wall -Wextra -Werror If these options are set before you write any code, then these problems don't arise.

Worth noting you should probably disable -Werror for distribution if you expect users to compile your code. They aren't going to fix your error for you and you can't know what warnings will be added to future compilers, nor what previous compiler versions marked as errors. Among many other people saying the same thing see [0] if you don't trust me.

Also IMO you often want to explicitly disable a few of those from -Wall and -Wextra -- Looking at the last c++ project I wrote, I turned off a few things like `-Wno-unused-parameter` for example.

[0]: http://blog.schmorp.de/2016-02-27-tidbits-for-the-love-of-go...

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#186

Earlier quoted context omitted.

Didn't try, but I could imagine that running -Wall over that codebase produces huge amounts of noise rendering it practically useless, until somebody gets to fix all warnings which are not bugs.

Running static analyzers (PVS-Studio, for example) and splitting up functions to simple things should at least make it easier to detect errors.

For splitting, there's a balance you need to strike. Split things up too far and the errors are definitely harder to detect.

IMO rote splitting usually doesn't simplify, it just hides the complexity.

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#187
post #165
post #123

Earlier quoted context omitted.

> -Wall over that codebase produces huge amounts of noise rendering it practically useless As a c++ developer I would nope the hell out of there or spend a month fixing the warnings - depending on pay. No way would I work with something in that state long term. > until somebody gets to fix all warnings which are not bugs. Code that is filled with ignored warnings generally gets worse, not better. Having little to no…

Especially a security critical program, you really need to be using bug discovery tools as much as possible. You might even find some zero days just by addressing all the warnings.

I think that's kind of OP's point... Use a more modern language that actually treats these kind of bugs (and many many others) as errors rather than as optional warnings.

There's a reason practically no one uses a memory-safe C++ implementation.

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#188
post #114

Earlier quoted context omitted.

Yeah, let's compare with a stricter language: In Rust, x = y evaluates to (), not any of the values in x or y. In Rust, numbers are not implicitly usable as booleans in conditionals.

Indeed, just as in every other ML-family language since 1973. (I'm glad these things are finally getting mainstream attention, but I'm not sure why people get so excited about "Rust features" that are almost all taken straight from Ocaml)

Hey, I'm just glad to see 1970's PL research finally making it to the mainstream(ish), regardless of which language gets the marketing credit for it.

I think the main advantage Rust has over OCaml is that it is syntactically more like C. But, hey, if it's what gets HM-style type inference to the masses, I'll take it.

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#189
post #100

Earlier quoted context omitted.

You are looking at a 1k LOC function in a 7k LOC file with a bug that can be easily spotted by -Wall and you think it's the fault of the programming language? The only thing irresponsible is putting your hard-earned money into the 100th Bitcoin fork maintained by some guy with an Anime avatar. Once you stop trusting the developers it essentially becomes an underhanded ... contest and no language wins.

Didn't try, but I could imagine that running -Wall over that codebase produces huge amounts of noise rendering it practically useless, until somebody gets to fix all warnings which are not bugs.

Thats what I did when I joined an OSS C++ project. It's a great task for someone that wants to learn disparate parts of the code base.

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#190
post #163
post #80

Earlier quoted context omitted.

The difference is not negligible: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Sure, it's silly benchmarks, so I wouldn't take the results as gospel. But the fact is, nobody who writes C# managed to produce a benchmark yet that beats a C++ program. Fast languages like Rust have managed to at least match the performance of C in some benchmarks (and even beat it in others).

> nobody who writes C# managed to produce a benchmark yet that beats a C++ program No, but I've seen Haskell programs that were much faster than the C++ program they replaced, which is what matters in the real world. Microbenchmarks measure what happens if you have the time to polish every single line to perfection. If you have infinite developer time then C++ will be faster than most languages. But infinite develope…

Did the Haskell programs implement the same algorithm?
Post reply on HN