Slashdot Mirror
A Source Code Typo Allowed An Attacker To Steal $592,000 In Cryptocurrency (bleepingcomputer.com)
An anonymous reader writes: "A typo in the Zerocoin source code allowed an attacker to steal 370,000 Zerocoin, which is about $592,000 at today's price," reports BleepingComputer. According to the Zcoin team, one extra character left inside Zerocoin's source code was the cause of the bug. The hacker exploited the bugs for weeks, by initiating a transaction and receiving the money many times over.
"According to the Zcoin team, the attacker (or attackers) was very sophisticated and took great care to hide his tracks," reports the site. "They say the attacker created numerous accounts at Zerocoin exchanges and spread transactions across several weeks so that traders wouldn't notice the uneven transactions volume... The Zcoin team says they worked with various exchanges to attempt and identify the attacker but to no avail. Out of the 370,000 Zerocoin he stole, the attacker has already sold 350,000. The Zcoin team estimates the attacker made a net profit of 410 Bitcoin ($437,000)."
"According to the Zcoin team, the attacker (or attackers) was very sophisticated and took great care to hide his tracks," reports the site. "They say the attacker created numerous accounts at Zerocoin exchanges and spread transactions across several weeks so that traders wouldn't notice the uneven transactions volume... The Zcoin team says they worked with various exchanges to attempt and identify the attacker but to no avail. Out of the 370,000 Zerocoin he stole, the attacker has already sold 350,000. The Zcoin team estimates the attacker made a net profit of 410 Bitcoin ($437,000)."
I don't think steal is the right word in this context. The article doesn't state that anyone else lost their coins. More accurately would be "created", "unauthorized-mining", or perhaps most accurately "counterfeited"
One char can make big different in performance and correctness. The greatest one character code change I made and got stunning performance improvement was adding an &. It took significant effort to find it, because instrumenting the entire executable for profilers was just out of the question. But once found it was trivial. The caller was passing a std::map by value. The answers were correct and the scaling effects were not visible till the map grew to big sizes. I expected to something along these lines.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Seems like he collected an ~500k$ bug bounty. The interesting part is "Zero Coin is a project to fix a major weakness in Bitcoin: the lack of privacy guarantees we take for granted in using credit cards and cash. Our goal is to build a cryptocurrency where your neighbors, friends and enemies can’t see what you bought or for how much" per Zero Coin. It seems they succeeded in their goal and were hoist by their own petard. Of course, had they recovered the funds then ZeroCoin would have failed at its purpose. I wonder who took the loss.
I'm a consultant - I convert gibberish into cash-flow.
That is absolutely correct, and there was a very good article in The Economist relating to the removal of $55 million from 'The Dao' which made the same legal argument that exploiting poor programming in a Smart Contract was not theft but simply following the rules of a system, even if those rules did not do what the creators intended.
In addition The Economist argued that that whereas the heist was not a crime, altering digital ledgers to retrieve the lost ether was affront to the whole project.
the attacker has already sold 350,000
By which we mean he has already moved it into other accounts that he likely controls.
I'm an American. I love this country and the freedoms that we used to have.
> A one character bug? Really?
Sure, I've seen many single-character bugs, and created a few. I imagine MOST experienced programmers have done this at least once:
if (a = b) {
When they meant:
if (a == b) {
Every language I can think of has a common single-character bug. Many Microsoft SQL users routinely leave off the semicolon which terminates a statement. Sometimes that results in buggy behavior right away, sometimes not until two years later when a change is made to the *proceeding* statement.
> What about the tests?
This is crypto-currency, the hot new thing tests are for old fogeys who still use dollars. Get with the times, young programmers are Agile, they don't plan and test their work, they release early and often. They release the Minimum Viable Product (minimum piece of shit they can get away with for a moment), it's illegal now to even think about corner cases and make code robust.
The story says " allowed an attacker to steal 370,000 Zerocoin, which is about $592,000 at today's price". I seriously doubt 370,000 Zerocoins is worth anywhere near $592k now that the news is out and trading has been suspended. If you can't spend it, it's worth is zero, which kind of makes sense for something named Zerocoin. The name should have been warning enough.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
An obscure, second-rate digital coin can be worth that much money? There is a bubble in the cryptocoin market. I wonder what happened to Dogecoin.
"First they came for the slanderers and i said nothing."
The bug has been found with a modern diagnostic tool, such as clang-5.0 with all the warnings and sanity checks enabled. Anyway, this is really cool story.
Your last two examples actually aren't stealing. Don't believe me? Ask a judge.
I mean the following statement. This works okay:
SELECT 1
SELECT 2;
This doesn't:
SELECT 1
THROW
The latter is equivalent to:
SELECT 1 AS THROW
I had originally written "the preceding or proceeding statement". That's reasonably clear, I think, though it stretches the definition of "proceeding". Then I realized that changes to the PRECEDING statement won't affect anything, so long as if that preceding statement is properly terminated with a semicolon. So I ended up with "the proceeding statement", which is poor wording.
Wow. I'm surprised the total value of all Zerocoin is worth that much in $USD
No, we just need IDE's and complilers for current ones that enforce certain constraints.
If that is the right repository, then this is the relevant pull request: https://github.com/zcoinoffici...
It is a one line change from two days ago. Apparently the typo was initializing a variable to 1 instead of 0.
My (mod funny) comment was a bit of a caricature of Agile, of course. Still, I'm surprised you said what you did, rather than chuckling. I thought you'd been doing professional development for a number of years. Perhaps I'm remembering wrong.
Agile emphasizes *automating* testing. Automated testing is a good thing. It sometimes catches regressions and fatal errors that completely break the build entirely. That saves your alpha and beta testers from dealing with some of the easy, dumb mistakes.
Scrum by the book says sprints should be 1 week preferably, up to 2 weeks, and you should have a release (or a minimum a releasable product at the end of each sprint (each week). If you're going to plan it and build it in a week, that doesn't leave more than a few hours for QA. Traditionally high quality software spends a few weeks in alpha testing and a few weeks in beta testing before it moves to limited release. If you follow Scrum as originally written, release comes at the sprint - alpha testing is done after release, by customers in production. That's advantageous in that customers get the cutting edge new features right away, and it also means they are getting alpha-grade software. Much like the difference between Fedora and Red Hat Enterprise Linux. Many people like Fedora, which is cutting edge, on their desktops. Virtually nobody wants that on their production servers, they want the reliability of Red Hat or CentOS Enterprise, which has been tested for at least 18 months. Fedora is basically the beta test for RHEL, and that beta test takes 18 months, not 18 hours.
I would also think you'd know that an essential, fundamental concept behind Agile is that we don't know what the future holds, requirements change -- so long-term planning is basically pointless. That makes perfect sense - to everybody who hasn't yet been taught how to determine what the *real* requirements actually are. Certainly sitting in a meeting the users' boss's boss doesn't tell you what the users' actual needs are, but there are methods to determine the real needs, and plan for them even years in advance. Agile rejects that notion, though for those who have been shown how to do it, it's a proven fact that you *can* learn the requirements, and the likely future requirements. You just have to be taught how to do so.
Who is the victim? Surely the crime, if any, is that Zcoins were forged by exploiting this bug...
> If you're finding things wrong during QA at the end of an agile sprint, there's something seriously wrong
Suppose QA is blended into your four and a half days of planning, research, development, and testing. Somehow (magic?) you're testing the changes you've not yet finished against everyone else's unfinished changes. Obviously you're not testing how your changes work with the other guy's changes before you've decided how to write either change. So that gives you max maybe 7 hours integration testing and validation, spread throughout the last two days of the week. Do you *really* think a a couple hours of each (at the most) can replace several weeks of each? Really? If so, maybe you're the reason we catalog 100 vulnerabilities in other people's software *per day*.
With Scrum and Agile generally you have two options:
A) Knowingly trade faster development at the cost of quality assurance.
B) Unknowingly trade faster development at the cost of quality assurance.
Those are the choices. Do you have any idea what "release early" means? It means release before it's thoroughly tested, in the case of Scrum specifically, it generally means nobody has ever tested it at all - nobody other than (maybe) the developer has tried out the feature to see if it works correctly, and integrates correctly with everything else. Paying customers do alpha testing. (And no, automated unit tests (while useful) in no way replace beta testing, alpha testing, and validation. So you get speedy development but at a cost. Again your two choices are:
A) Knowingly trade faster development at the cost of quality assurance.
B) Unknowingly trade faster development at the cost of quality assurance.
You can either know what you're giving up, or not know. But nothing is free, there is a definite cost. If you think thorough testing is for chumps, perhaps you're the guy who wrote "goto fail".
I call publicity stunt
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
A one character bug? Really?
"one character typo" can cover a wide range of things. Using = instead of == is probablly the most famous but also generally one of the easiest to spot (modern compilers usually have a warning for it). Using the wrong variable is a big one (not helped by the fact that mathematicians love one-character variable names). Using the wrong logical or comparision operator can be another.
Unfortunately TFA doesn't say what the "one character typo" was and looking at their github I don't see any one character typos being fixed recently. I do however see a "two character" typo being fixed though ("||" vs "&&"). I also see some == being change to >= but I *think* that is just a case of making a test more paranoid.
https://github.com/zcoinoffici...
What about the tests?
It takes extreme discipline to carefully create test cases that cover every failure case. All too often people only test that the normal case works as it should and fail to test the error handling.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
If we're feeling obtuse: that kinda is yet another new programming langauge... it's just one which happens to be a strict subset of an existing one.
Does this prove that programming language design has no impact on software quality? No? Then I don't care.
Of course there will always be some non-zero number of bugs in mainstream software. That doesn't mean we can't improve things.
Some developers say that typos are not dangerous and PVS-Studio is not needed. This great tool for typos search: https://www.viva64.com/en/exam... Now I have the argument. :)
This doesn't look like a typo. And without digging deeper, even the variable name doesn't look like it would be unclear to what it should be initialized. Maybe somebody from the team was involved ...