Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Denial of Service #3955

Open
zebambam opened this issue Apr 16, 2019 · 14 comments

Comments

Projects
None yet
7 participants
@zebambam
Copy link
Contributor

commented Apr 16, 2019

Scaling discussions don’t make sense unless the ultimate goal is to reduce the likelihood that users will not be able to use Zcash because of a lack of service.

There are lots of ways to fill up our service currently.

When we spot them, we should link them to this epic.

  • A small number of shielded transaction of massive size.
  • A small number of or many transactions with many empty outputs.
  • Many small transactions filling the mempool currently crash the nodes that receive them. It’s possible to knock nodes offline. Transaction expiry helps reduce the cost for an attacker.

Additionally, the failure mode is currently catastrophic.

  • Filling the mempool currently results in a node crash.

With such an attack, someone might be able to knock over mining pool operators, and thus significantly drop the hashpower of the network, facilitating a 51% attack.

Suggested course of action:

Set limits on the mempool size, and reject further transactions.
Other steps that result in the reduction of the likelihood of a successful DoS attack.

@leto

This comment has been minimized.

Copy link
Contributor

commented Apr 20, 2019

@zebambam Are there any bounties for this? It's pretty trivial to DoS the entire Zcash network and prevent any real transaction from occurring, for a few dollars a day. One attack which I have discovered, in the process of designing defenses, is called the "Sapling Wood-Chipper", but without financial incentive from ECC, such as a real bug bounty program, the tool will remain private.

fargo-foot_0

@zebambam

This comment has been minimized.

Copy link
Contributor Author

commented Apr 22, 2019

Hi @leto there's currently no bounty for bugs on ECC, partly because (if you click the label "denial of service", you'll see for yourself) we already have quite a few filed. This ticket is just to coordinate and track them through our prioritization process.

@zebambam

This comment has been minimized.

Copy link
Contributor Author

commented Apr 22, 2019

Also I love that movie, thanks for the reference!

@leto

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2019

@zebambam Just to clarify: Currently it would cost 1/20th a ZEC (about $4) to fill all transactions of all blocks per day, on the Zcash mainnet via the Sapling Woodchipper. Looking at all the bugs filed with "Denial of service", I don't see anything similar. Do you want a dedicated Github Issue for this network-wide transaction Denial-of-Service ? This is a severe attack and again, it's very worrisome that there is no Zcash bug bounty program.

@zebambam

This comment has been minimized.

Copy link
Contributor Author

commented Apr 23, 2019

Not all of the DoS bugs that we are aware of are filed as bugs currently, for what are probably obvious reasons. Far more worrisome to me than our lack of bug bounty program is our inability to resolve bugs for the amount of time that some of these have filed. It's something that I'm doing my best to work on, hence this ticket. Once our problem shifts from "we can't fix bugs in a timely fashion" to "we don't know about enough bugs" then the time would be right to start a bug bounty program.

@tearodactyl

This comment has been minimized.

Copy link

commented Apr 24, 2019

@zebambam, thanks for noting that over three dozen DoS Issues could use some attention. And so so sorry to hear that it looks like a bit of work. Hopefully they are mostly minor, compared with what @leto is describing. Then again, 20% of $412M could buy some engineering time, even in Silly Valley, to secure the network and plug the holes in this rather porous implementation. Your position to close out already filed Issues before there is value in looking at new ones assumes that you can close them faster than new ones can be found.

ECC management may entertain a remote possibility that there exist expert developers who have not been employed by ECC, but have several years of experience digging through and plugging holes in numerous versions of the Zcash codebase. Possibly these are not the typical bug bounty jocks, looking for quick hits by scoping out some peripheral bugs. Maybe such serious blockchain developers have already identified mitigations and actually tested the solutions. I'm sure you'd understand that with a mortgage due, they cannot set aside paying gigs, in order to walk salaried ECC staff through the intricacies of the discoveries and details of the fixes. As long-term participants in the ZK ecosystem, they may even consider being compensated in ZEC for their time.

@zebambam

This comment has been minimized.

Copy link
Contributor Author

commented Apr 24, 2019

@tearodactyl I think it's possible that in your analysis of the situation you've committed the sin of singularity - in fact there's a plurality of activity at ECC and fixing security bugs is only a component of that, with investment proportioned accordingly. The majority of the funds go to developing code from which other neighboring projects can benefit for free. I'd be delighted to be able to pay for more help fixing issues, but not at the expense of ECC fixing bugs in the code that we write. I expect that supplanting internal quality processes with external help would align incentives incorrectly and result in further degraded performance on ECC's part. At least as a primary strategy. I'm not opposed to that strategy to supplement some internal future effort to remediate serious DoS issues like the ones of the magnitude that Leto has been describing.

@leto

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2019

@mineZcash if ECC does not want to run a real bug bounty program like Monero (https://hackerone.com/monero) or Horizen (they run their own, and actually value bug reports), I guess ECC does not really care about the security of the Zcash network very much.

No reason to bring in paperwork-fetishizing bureaucrats to this technical discussion. It seems the decision to ignore the severeness of this network-wide Denial-of-Service has already been made.

@zebambam

This comment has been minimized.

Copy link
Contributor Author

commented Apr 25, 2019

Hey.. everyone calm down. This ticket was raised precisely so that we can get these issues into a higher priority spot in the backlog. The decision about the priority of these issues is far from over, I raised this ticket precisely so that we can have a better internal conversation about it.

@nathan-at-least

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2019

Just to clarify nowhere in this ticket has any ECC representative said that we do not want to run a bug bounty program. We do not currently have a bug bounty program.

@daira

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2019

It's a good job this is the issue for the general DoS "epic" rather than something more specific, otherwise I would be ruthlessly deleting off-topic comments by this point :-/

@mineZcash

This comment has been minimized.

@zebambam

This comment has been minimized.

Copy link
Contributor Author

commented May 13, 2019

Duke @leto filed this issue as CVE-2019-11636 here: https://www.cvedetails.com/cve/CVE-2019-11636/

We are still working on scheduling fixes.

@campassi

This comment has been minimized.

Copy link

commented May 24, 2019

"Availability Impact: Partial" in the CVE detailed markup seems far off target. @leto do you have any suggestions available which may swiftly patch this issue?

Surprising that a knowledgeable onlooker has not yet shorted the market while simultaneously launching an attack.

With such an attack having the distinct capacity to cripple ECC's regular income stream, should this vuln not be bumped to highest priority?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.