Sarah Jamie Lewis announces her candidacy for the Major Grants Review Committee

I am sorry you feel that way. I am trying to make things very clear so CAP members who do not understand the nuance of disclosure can get a bit more insight.

I really didn’t think this would be that difficult of a question.

Does this mean you do not think the MGRC should write down a set of ethical standards and have the community hold them to those standards? The community just needs to trust the MGRC? Where is the verify?

I outlined my views on this 3 months ago in the Code of Ethics thread. And at several points in the main MGRC thread.

RE: Accountability. The community will hold members to whatever standard the community collectively enforces through the ZIP and elections procedures. The MGRC will hold each other accountable through whatever processes it puts in place to ensure accountability. If the community doesn’t like the behavior of a particular candidate or an elected member then they are free to vote against that member, or appeal to the committee to adopt a process around that behavior if it is within the MGRCs remit.

As I have stated multiple times, if elected I will vote for proposals that demand transparency and enforce strict procedures regarding MGRC members actual or perceived conflicts of interest.

Should any other candidates wish to outline what policies they would like the MGRC to adopt I will happily consider them and document my reasons for voting for or against them, but I’m not going to comment on hypothetical/unwritten/unseen/latent codes of ethics.

1 Like

I’d like to state for the record that when @sarahjamielewis discovered the Zecwallet Security issues, she DID NOT notify me or even let me know that she had discovered the issue. She did not notify me before tweeting out the bug, and did not notify me after either.

[Moderation edit for factual accuracy by @daira: it is clear that Sarah Jamie Lewis did in fact notify Aditya, approximately 4 minutes after the tweet, via GitHub.]

Some alert Zecwallet users noticed the tweets and let me know, after which I fixed the issues, each within 24 hours of me being notified.

I consider that a serious breach of personal and professional ethics on part of @sarahjamielewis. I fail to see how tweeting out security bugs without notifying the developer of them helps Zecwallet users.

It’s hard enough to build software in this space, and this kind of unethical behaviour by someone calling themselves a security researcher makes things harder still.

12 Likes

This is demonstrably false. The github issue I opened synchronously with the tweet is right here: CRITICAL: This release has a MITM Vulnerability that allows anyone to intercept requests · Issue #40 · adityapk00/zecwallet-lite · GitHub

Your response was, as can be seen from the issue, “Ooh, oops.”

5 Likes

The tweet did not tag Zecwallet did not reply cc Zecwallet or even DM Zecwallet. No email either. It “quote tweeted” the Zecwallet account, which intentionally does not notify the account.

By the time the issue was filed, someone else had already reported the tweet to me, the issue had been identified and a fix was on the way.

That was the most irresponsible way to disclose a security issue, and this thread’s attempt to reframe that irresponsible disclosure as somehow ethical is beyond comprehension.

6 Likes

Kudos for getting so much done in the 2-3 minutes between when I clicked “Tweet” and submitted the issue (which I will note you acknowledged, seconds later - as can be sen from the github link).

I will kindly ask you to remove the inaccuracies in your previous tweet. You are entitled to you opinion on security disclosure, but you explicitly stated that I did not contact you at all - which is a lie, as I have demonstrated.

Also, I will note that I reported several other security issues in the full node version of Zecwallet prior to this incident via github issues - i.e a public disclosure process - at no time was I told to report these via different mechanisms.

But let’s set aside, those quibbles and allow me to make a broader point.

I tweeted to warn people that you had released a new version of the software with a critical MITM vulnerability. The bug was so severe and so blatant the only action users could take to stay safe is to not use zecwallet. The software had been plugged by high profile accounts earlier in the day and so both the chance of compromise and the number of users likely to be impacted were high.

There has been no public postmortem detailing how software with such a critical, trivially exploitable issue was released to users, and as far as I can tell there have been few changes to prevent such mistakes from happening again. I would still recommend people not use zecwallet unless they understand those risks.

Further, and more generally, the Zecwallet lite website advertises it as “fully private” despite that being impossible right now. There is also no indication of previous security issues listed on there to inform users.

Whatever you may think about the way I disclosed the MITM vuln, the way zecwallet lite was rushed out with that critical vulnerability was, and many of the continued practices in promoting the wallet are, irresponsible.

For the record, there are a lot of vendors who dislike my approach to life, who dislike me informing people who use their systems about the risks they are subjecting those people to. I don’t lose sleep over it.

3 Likes

You are misrepresenting what several of us have expressed concerns about. No one said anything about your ‘approach to life’ or not wanting users to be aware of risks.

This is about you publicly tweeting out details of a vulnerability (this is the key point, we are talking about details, not the mere existence of a bug) before giving the dev a chance to release a patch. This put users at risk no matter how you try to spin it.

If you had contacted the dev about the details privately and let him release a patch (which he was able to do very quickly), and then tweeted about your concerns, I do not think there would be any controversy here. Zec wallet users like me would be grateful to you in this alternative scenario.

Your behavior in this instance, and your refusal to simply say ‘I made a mistake and would not do something like this again in the future’, makes me question your ability to be a team player if your were on the MGRC. If you were elected, would you put the privacy and security concerns of Zcash users first?

6 Likes

In my opinion, you are just wrong, for example, how many people are at risk at the time of the release of the patch -100%, provided that someone will use this error, and the time for developing the patch is not known, so hushing up the problem is the wrong way out, stopping the use was goal, provided that 99.9 users cannot use the vulnerability to hack the wallet, and those who may not get access to some of the warned users.
When there is a threat to the finances or health of people, you will prefer to give time to specialists to fix the situation or give people the opportunity to save themselves (for example, get out of the bomb zone, or not use contaminated money). What does the team play have to do with it?
Only now I realized which team you are talking about, and which team are you in, in the zec user team who risk their money or in the development team who risk their reputation and funding?

1 Like

No one suggested ‘hushing up the problem’. A general warning like ‘there is a bug please don’t use the latest version of zec wallet until it’s patched’, would have been ok. A public discussion of the bug and how to assure it doesn’t happen in the future would then be appropriate, after user’s have been warned, and after the bug had been patched.

What Sarah’s tweets did was give specific details to attackers about how to attack zec wallet users.

I really don’t like how you phrased this like there are two opposing teams: Zcash users versus Zcash developers. I’m not a Zcash developer btw, I am a zec wallet user.

Zcash users, developers, and security researchers need to all be on the same team. I brought up being a team player because Sarah’s tweet made me feel, as a Zcash user, like she, a security researcher, was not on the same team as me.

5 Likes

Yes, there are different teams, it is naive to think that all altruists. Users are warned for their safety, not for fame, I remind you that saying not to use the wallet in this case is better than trying to fix the problem without publicity, because at the time of fixing an attack can be made. If you think that the behavior was not ethical, then according to which point of ethics. Attacking and blaming is also not ethical, and there are no conditions under which it was impossible to do this.

I agree with you on the point of disclosing the conditions of the attack, it was possible not to indicate in detail, but I do not think that this would change anything, few people can organize an attack, the probability is close to 0.

1 Like

(Speaking for myself. And specifically, not speaking for ECC because I know several people there disagree with me about this.)

Anyone can see from the timestamps on the tweet and the GitHub issue that the issue was opened only 4 minutes after the tweet. GitHub would have provided sufficient notification. There is objectively no basis on which to argue that Sarah didn’t notify Aditya about this vuln.

FWIW, I don’t believe software devs have any right to expect so-called “responsible disclosure”. We may ask for it, but that’s a different thing, and honestly it is mainly just to make our lives easier. (You can argue that perhaps it allows more thorough fixes under less time pressure, but even that’s debatable and only applies to some vulns, probably not including the one at issue here.)

4 Likes

I like that Sarah has not softened her position at all despite being criticized & pressured, says much about what she would bring to MGRC.

3 Likes

Interesting take, I disagree. responsible disclosure is something a researcher commits to, not a vendor.

I would argue that quote tweeting first then filling out the github is a clear violation of ISO 30111.

At the end of the day, full disclosure is a mechanism for getting vendors to adopt and adhere to ISO 30111 - responsible disclosure is the enforcement mechanism.

I can find other ISO’s this would violate.

It is worth noting that the git hub was submitted after the initial public disclosure that did not include the vendor. This might seem like splitting hairs but it is actually important.

every vendor I work with would blacklist you for that - The time difference you could explain as lag, but Sarah admits that she sent the tweet before the vendor report. If it wasn’t a quote tweet, it is still a dick move but it is a lot more dubious if it violates 30111 or not and you wouldnt get blacklisted.

30111 is the framework which disclosure ethics are built upon.

I do not understand how anyone could have managed to get a security contract, post 2013, without providing a written copy of their ethics, specifically ISO 30111:2013

You must include ISO 30111 or you fail due diligence. - go check an old NCC contract, it will either reference 30111 or their own more restrictive version, which will be written down.

If you are a contractor, you sign ISO 30111 in your contract. If you are an employee you sign the companies ethics statement in your employee contract. (which will be more constraining than 30111)

3 Likes

This has been a very interesting and important discussion. My two cents:

If it is possible to publicly disclose a vulnerability in a way that reduces the likelihood of it being exploited before a fix is deployed, that should be the preferred option. This position is based on common sense (I have no special expertise in this area), but I’d be very surprised if there are security/disclosure standards that argue the opposite.

4 Likes

(Speaking very much for myself.)

I wouldn’t allow any ISO/IEC (or other) standard to take precedence over my personal ethics, and I wouldn’t expect anyone else to.

As it happens, ECC’s vuln disclosure procedure is here, and if it has any similarity to that standard then it’s pure coincidence. It’s obviously fine for people to voluntarily sign up to particular policies, but if they’re independent researchers, as Sarah is, it is also fine for them not to. In particular, please note that the Zcash Code of Conduct does not place any requirements on modes of vulnerability disclosure, and that’s intentional.

6 Likes

Your position is I violated a proprietary ISO standard, the remit of which explicitly applies to “vendors involved in handling vulnerabilities.” - A standard that you can’t even show everyone because it is paywalled?

Just so I’m clear, that is where you are drawing your ethical line?

If so I’m truly sorry to the ISO and they should revoke my membership ASAP.

More seriously,

I do! It is because your experience is, much like disclosure ethics are, not universal.

Thankfully my ethics are not bound to what vendors think of me. I am free to follow my own sense of right and wrong.

I believe strongly in the peoples right to know what risks they are being subjected to. I’ve already explained why find the modern “responsible” disclosure trend abhorrent, so I’m not going to repeat myself.

If you wish to continue to lament that people like me shouldn’t be security researchers then you are of course free to do so. Lobby for a licensing regime maybe?

4 Likes

Sarah, in retrospect, do you agree that opening a github issue or notifying the developer directly before tweeting out details about vulnerability is the right thing to do?

1 Like

As I’ve stated numerous times in this thread, this was a trivially exploitable 10 hour-old MITM exploit in a cryptocurrency project - I believed then, and I believe now, that warning users about the risk was more crucial than getting the actual issue fixed.

In an ideal world, the presence of such an issue should be enough to call into question the entire risk assessment of the project. We still don’t have a root cause analysis behind why such a version of the wallet with such a critical issue was released (or any idea of the actual vulnerability window i.e. downloads of the vulnerable version v.s. the update). If we want to talk about actual risks to Zcash users then we need to look there.

To use an imperfect analogy: If I found a fire in a building, my first action would be pull the alarm and get everyone out of the building, to safety, not to call the building owner.

9 Likes

There is a certain action aimed at warning users, we will take for the fact that there is an error and its detection, who told you that only one person found the error, while you are releasing the update, users are under threat, right, and if you spent weeks on elimination, the network cannot be stopped , then you need to stop using at least a problem wallet. As for me, this is a correct and ethical act.
Based on the facts, what do you think is the chance that an attacker seeing this problem was able to gain access to users’ wallets based solely on the information disclosed on Twitter?

(Speaking for myself.)

Look, it’s clear that the approach to vulnerability disclosure is a highly contentious aspect of the infosec field. It has been contentious for over 30 years, and will continue to be, because there isn’t a right answer. It simply isn’t the case that there’s an “accepted behaviour” on how to disclose vulns and that people who don’t follow it are wrong.

There are plenty of toxic people in the cryptocurrency community, but people who accurately report vulns in a good-faith attempt to protect potential users (regardless of whether you agree with how they do it) are not that.

11 Likes