Here’s October’s monthly update:
The ZWL cli is neat, I’ve used it a few times
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.
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 firstname.lastname@example.org 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.
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?
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.
Cheers to a more secure Zcash eco-system
Is it possible to get an update on the November deliverable, or any prior audit that is available to view?
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.
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.
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!
What’s holding you from publishing it?
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 My apologies for the delay!
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.
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!
I posted a transparency report, breaking down my invoices in Q4 2022: ZecSec's Q4 2022 Transparency Report | ZecSec: Zcash Ecosystem Security
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.
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.
- 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.