Zcash Ecosystem Security Lead

Community Grants Applications
63

Can someone overseeing this grant please provide clear clarification to why the milestone dates keep moving/being edited?

The original first milestone date put the work into conflict with Zcon, so I moved them back a month to the end of September. In September I mostly just did setup/exploratory work that I didn’t feel justified in billing for (like setting up a new laptop, getting various projects to build), so the ZCG committee and I agreed to shift all the deadlines back a month. The first milestone was completed in October. It has been invoiced for (which also included some days of work from September), and has been paid. The current milestone is due at the end of the month and includes an audit of zecwallet-lite-cli.

What tools were used on this report/audit?

The Ywallet audit was entirely manual source code review aside from using toolchain tools like cargo audit and dart pub outdated to help check for dependency updates and known vulnerabilities in dependencies. The details for this audit and future ones will all come out along with the report, so as to not prematurely disclose information about any bugs that are/were found.

4 Likes
65

Yes, that was my mistake, sorry. I should have forseen that problem and set the dates later from the start. (If I could do it over again with my retrospective knowledge, I’d put in the dates that are currently there.)

Each project is going to be on-boarded as they’re audited. The format of the support/outreach afterwards is whatever works best for the project. I’ll set up some general office hours too, that anyone can attend. (Everyone is free to email zecsec@defuse.ca for questions/support, you don’t have to wait for your audit to get help if you have a security question now!)

We follow the disclosure policy of the project under audit. This will work best if it’s a collaborative effort between me and other ecosystem projects. The only time an unmitigated issue would be disclosed without the consent of the project is if the project was acting negligently and putting users at risk, i.e. when the only way to protect users is to disclose the issue.

ZWL is the same approach. Thanks for the questions, I’m sure some others were wondering the same things.

2 Likes
68

I’m not certain I understand the “outreach” part of this proposal based on the descriptions above.

For transparency, In October, what this looked like specifically was:

  • (1 day of setup and catching up on the forums)
  • Reviewing all wallets for a potential mempool-related DoS bug suggested by @zancas (1 day)
  • Zwallet audit readout / remediation support (1 day)
  • Setting up zecsec.com (0.5 days)
  • Reviewing ZIP-317 for security and privacy (0.5 days)
  • 13 days of auditing Zwallet

In November so far, for the outreach component so far I’ve spent half a day researching and making suggestions on what to do long-term about the scanning issues and spent half a day getting the maintainer of the Arch Linux zcashd package to update it to 5.3.0 (it was previously on 5.0.0).

I’ll include a breakdown like this in my blog posts going forward.

Also, there is a bit of concern around the feedback loop where unless the audit is published as of date of completion, no one really knows the outcome and will assume worst case once the 90 days have passed.

There is no perfect way to do this. If the project I’m auditing is announced ahead of time and published immediately once bugs are fixed, then yes, some information about the existence of bugs can be gleaned from how long it’s taking the audit to be published. In my mind the most important thing is protecting users, which means helping to get any bugs fixed ASAP. There is no formal 90 day timeline for this project, that is just the industry standard for disclosing bugs without consent in case of negligent projects.

What is done during a manual source code review on the mobile audits? This process is not clear in the original proposal. Is this following the internal ECC mobile audit? Are there any runtime tests being conducted, or manual/compile analysis only?

Runtime tests are sometimes useful, e.g. to compare one implementation of some cryptography primitive with another, to use darksidewalletd to test reorg edge cases, and so on. I do that as-needed when it’s valuable to do so. The process for manual code review is, in brief (a) brainstorm everything that could go wrong in the target application (what are likely mistakes, what does an attacker want?), (b) create a basic threat model if one doesn’t already exist, (c) read the code and note any plausible bugs, (d) refine the list of plausible bugs into confirmed issues and write the report. It’s a creative process where you’re always trying to make the best use of time to find the worst kinds of bugs.

Who is we and where can the public view this policy?

We = me, usually projects will state their disclosure policy in their README or somewhere on their website (and if not that’s a recommendation I make). Sometimes I don’t and I just have to ask them what they are comfortable with.

From your recent audit was there anything noted in your report that would have helped speed up the process?

I won’t disclose recommendations from this audit yet but in general this is a kind of recommendation I make. For example, if a piece of code could be written differently to save auditing time in the future, I’ll make that recommendation. Anything that makes audits more efficient and more effective is a huge win.

Do we get to request feedback on the overall process of the audit party before the report is disclosed?

I’m not sure I understand what you mean by this. Feedback about what, from who?

2 Likes
71

If anyone would like to request a meeting to ask questions, get help with anything security-related, request an audit, or just chat, you can now schedule one through my calendly: Calendly - Taylor Hornby.

If you’re in a different timezone and there isn’t a time that works, just send me a message and I will make a time that works.

9 Likes
72

@earthrise
Cheers to a more secure Zcash eco-system :grin:

3 Likes
73

Is it possible to get an update on the November deliverable, or any prior audit that is available to view?

74

Hey m, I appreciate your concerns with the deliverables from Taylor, our Ecosystem Security Auditor. Given the sensitivity, technical review, communication loop and documentation work, the publishing of documents may take a couple months. Taylor just got started this September, and third-party auditors can take multiple quarters before releasing the reports to the public.

The ZCG committee has reviewed the ongoing efforts of the audits and is more than satisfied by the quality of work of Taylor. Watch out for updates in our bi-weekly meeting minutes. Cheers.

7 Likes
76

Quick update on the November deliverable: The main item was an audit of zecwallet-lite-cli and the modifications to lightwalletd in adityapk00/lightwalletd. In total I’m invoicing 9 days of auditing and 3.5 days of additional stuff including staying up to date with projects on the forum here, setting up calendly, writing up my review of scaling options, getting v5.3.0 to build on Arch and donating some money to the package maintainer to update the official package.

My current priority is getting the Ywallet audit report published so that everyone here can see exactly what comes out of the audit work.

10 Likes
77

I wrote a blog post about the process I use to audit projects for this grant: Security Audit Process | ZecSec: Zcash Ecosystem Security

I’m currently working on a 2023 roadmap and a “security auditor’s guide” to the Zcash ecosystem. I hope to have those published soon, too!

4 Likes
78

What’s holding you from publishing it?

1 Like
79

I think it’s pretty much good to go, but I still haven’t reviewed your fixes yet, so it’s blocking on me at the moment :slight_smile: My apologies for the delay!

1 Like
80

The Ywallet audit report has now been published. Feedback and questions are welcome!

I’ve also put together a tentative roadmap for this project in 2023 and a security auditor’s guide to the Zcash ecosystem which lists all the projects in the scope of this grant, plus a list of all historical audit reports, academic research, and notable bugs that I could find.

12 Likes
81

Reminder: anyone working in the Zcash ecosystem can now set up a private meeting with @earthrise using this Calendly link.

The kind of support projects can get this way includes:

  • Getting early security feedback on designs and code.
  • Help with responding to vulnerability reports.
  • Incident response for attacks on infrastructure.
  • Secure UX review of API designs and user interfaces.
  • Getting answers to technical questions about the Zcash protocol.
  • Anything else security- or -privacy-related, really!
10 Likes
82

I posted a transparency report, breaking down my invoices in Q4 2022: ZecSec's Q4 2022 Transparency Report | ZecSec: Zcash Ecosystem Security

11 Likes
83

January highlights: I did a full audit of ECC’s lightwalletd repo, did a super quick review of Zgo, and I got some office hour signups which is great to see. For February, I have a mini audit of free2z in progress, and I’m going taking a look at Zondax’s shielded hardware wallet.

15 Likes
84

February highlights:

I completed a short audit of free2z, I was really impressed by their proactive effort to secure the site using well-set-up CSP headers, HSTS, having a security.txt file, a bug bounty, etc.

My original intent was to finish an audit of Zondax, however I was put in touch with some folks proposing to use ORAM to speed up transaction retrieval for Zcash, and since the ORAM relies on SGX, I did some research to understand SGX’s and other enclaves’ vulnerabilities in detail in order to write up a risk assessment (that’ll be posted soon).

I came to the conclusion that we shouldn’t ask most users to trust their viewing keys to SGX, which gave me motivation to work out a more-scalable transaction detection design that’s pretty private on its own and is also compatible with ORAM/SGX for defense-in-depth.

In March I’m getting back into the Zondax audit and should deliver an assessment of the core hardware wallet code, with a stretch goal of auditing the integrations within various wallets as well.

10 Likes
85

Here’s that post: Risk Analysis of Intel's SGX and Other TEEs | ZecSec: Zcash Ecosystem Security

5 Likes
86

March highlights:

  • Completed a 12-day audit of Zondax’s Zcash shielded hardware wallet code.
  • Some research into identity-based encryption to see if it can be used to improve this scalability option.
  • Reviewed the ZSA ZIPs.
10 Likes
87

And here’s the quarterly transparency report summarizing the invoices for the past three months: ZecSec's Q1 2023 Transparency Report | ZecSec: Zcash Ecosystem Security

9 Likes
88

April highlights:

  • Completed a full 10-day audit of all of ZGo’s source code.
  • Prepared a talk for Zcon titled “Security Engineering: Learning from Safety-Critical Disciplines” with the intent that it’ll help teach engineers and leaders about how to reason about security and set up a good “security culture” within their organizations. (Talks haven’t been accepted yet so I’m not sure if it’ll actually be at Zcon—if not I’ll post it on some other medium.)
  • Audited @hanh’s early-stage Ledger hardware wallet code. I think he can write code faster than I can read it! :grin:
  • Reviewed the fixes to issues previously found in free2z.
  • Had a call w/ an organization interested in applying for the memo field enhancements RFP.

In May, my focus is on doing a complete audit @hanh’s Ledger code.

13 Likes