Pre-Proposal: Dash Bug Bounty Program by BugCrowd

[Tallyho]

Proposal Evaluation Committee​

We have revised our report in accordance with the new information. It is with deep regret that we feel it necessary to flag up certain issues on what is clearly a popular proposal, but since the mission of PEC is primarily to protect Dash we feel it is necessary to remind MNOs that they are not in possession of all the details pertinent to this proposal.

Edit: since posting this report, Jim has offered to share the numbers privately with anyone who asks, which is commendable. I would be interested to know from those people whether they share our concerns or feel the total amount of this proposal vs. bounty pool is actually reasonable.

Our main concern is what proportion of the proposal funds MNOs think will actually go to the bounty pool and how little they would consider reasonable. For example, would MNOs still support a proposal like this that pledged to use less than 13% of the total for the actual bounty??

 

[jimbursch]

This is unfortunate.

I shared with @Tallyho a copy of the quote that was provided to me by BugCrowd, upon which I based my estimates for the budget proposal. The content of that quote is subject to a non-disclosure agreement that BugCrowd required me to sign. This is not unusual or nefarious. It is a standard business practice to enable parties to engage in negotiation involving sensitive information such as pricing and discounts.

I believe @Tallyho's main concern is the trade-offs that have to be made between defining the scope of the program and the size of the bounty pool.

Here is what I wrote to @Tallyho, with figures redacted because they are covered under the non-disclosure agreement with BugCrowd:

"When I started working on this project I envisioned a $100,000 bug bounty fund that would be trumpeted from the mountaintops. After researching top tier bug bounty programs, I quickly learned that the amount of the bounty fund is the least important factor. What's important is a relationship with thousands of hackers, hundreds of fully vetted expert researchers, a tested methodology for assigning priority and value to vulnerabilities, and systems in place to accomplish all of that efficiently, securely, and safely. I would be glad to put you in touch directly with the BugCrowd rep to explain in detail what their system entails.

"To be clear, <redacted> is what BugCrowd stated in their quote and is NOT what I have allocated for the bounty pool. As I have stated repeatedly, all these amounts are subject to negotiation, wherein I will be working to get the best deal for Dash.

"Perhaps it would help if I gave you some scenarios with specific numbers. For these scenarios I will not set aside a reserve to deal with USD/Dash price fluctuation. Instead, those funds will be included in the bounty fund and any price fluctuation will be absorbed there."

I then presented figures for 4 scenarios of exactly how the funding could be allocated, which included a scenario in which over $100,000 is allocated for the bounty fund, but only one application could be included in the scope of the program.

I concluded my email with @Tallyho with the following:

"I am of the opinion that it is better for Dash to cover as many important applications as possible in the program and keep the bounty pool to a viable minimum. I also think it is unnecessary to ask the MNOs for more funding to increase the amount of the bounty pool.

"My negotiating position with BugCrowd is that we should receive substantial discounts because we are paying in cash up front for a 12-month program, and those discounts will be applied for additional applications to be included in the program".

If anyone would like to see the numbers, I will be happy to share them privately and confidentially, subject to the terms of the non-disclosure agreement that I am bound to uphold.

 

[Tallyho]

Thank you for making that offer Jim, that's a good idea.

I believe @Tallyho's main concern is the trade-offs that have to be made between defining the scope of the program and the size of the bounty pool.

My apologies, I thought I had made it clear that we recognise we don't have the knowledge to assess the costs for the Bugcrowd program. You have also said you are still negotiating these, which is understood.

Our concerns relate more specifically to the size of the bounty pool vs. the total amount requested, and the portion of the total funds that don't appear in the quote. I have edited my post above to better explain.

 

[jjk]

we feel it is necessary to remind MNOs that they are not in possession of all the details pertinent to this proposal

Why do you feel it is necessary to remind us that?
You are NOT here to think for MNOs - the only way to provide any value by your effort is to provide justified beliefs, arguments in order to get as close to facts and truth as possible.

While we cannot provide the details, we are deeply concerned ...

is the least justified argument possible, and using such against something or even someone is what trolls do.

Also please call yourself something else but "committee" - "group" or "gang" for instance, because "committee" is misleading since you were not appointed or elected by the community.


Three days ago, based on other reports before this one I wrote you:

"I appreciate the rigour of your PEC reports as well as the effort you put in it. Information it contains is sometimes very interesting.
However the form, the tone, and especially the extort of authority with which you present it is harmful for the ambience of dash network community, and for me personally hard to digest.

If you had the actual mandate to designate the metrics for sake of correlating proposal's acceptance / rejection, which essentially means having a voting power sufficient to decide about the acceptance / rejection (which I hope you do not have), ...
even then I would prefer that your actual, individual arguments would be possible to comment on the same way as we are used to on this forum or on the Dash Central's discussion."

You replied that you had noted it, but it feels more like the opposite.

 

[jimbursch]

Under the 4 scenarios that I gave to @Tallyho, the portions of the bounty pool are:

70% -- only 1 application included in the program
46% -- 4 applications included in the program
38% -- 5 applications included in the program
22% -- 7 applications included in the program

Under no scenario that I have presented does the bounty pool drop to 13% as @Tallyho claims. I believe she is misrepresenting the information that I have shared with her. If anyone would like to check my math, I am happy to share the numbers privately and confidentially as is required by the non-disclosure agreement.

I would also like to point out that I am making every effort to be as transparent and responsive as possible. To be accused of being disingenuous and deceptive is rather insulting.

 

[jjk]

To be accused of being disingenuous and deceptive is rather insulting.

Yes, it was insulting. Just ignore them.

And hey, your proposal is doing quite well so cheers up

 

[jimbursch]

THANK YOU! to the MNOs who supported this project. We won't let you down.

and THANK YOU! to the DashIncubator (formerly DashBudgetWatch) backers who supported this project. We couldn't have done it without you!

 

[demo]

Under no scenario that I have presented does the bounty pool drop to 13% as @Tallyho claims.

Who is she @Tallyho? Here she is.

She introduced herself as a person who asks stupid questions, and now she changed her attitude and she gives stupid answers and stupid evaluations.

Who evaluated her to become an evaluator? Stupidity has it limits. Naming yourself an official evaluator and start judging people, this exceeds the limits of stupidity. For in the same way you judge others, you will be judged.

 

[demo]

The proposal seems to pass so I want to submit the below bug in order to be evaluated. It is mainly a design bug, but on what it concerns randomness in mn payee section it is also an ordinary bug.

We are talking about money, so safety is the number one priority. Dash developers dont seem to care about language safety, they even use pure interpreted languages (like perl) . Perl is unsafe as long as it is not a compiled language, which means that an agent can change the libraries of the language (with the help of automatic updates e.t.c.) and thus change the behavior of the code in the runtime. And he can do this selectively, by targeting specific IPs. Everything depends on the trust you have in the core developers of the interpreted language, and this is also a blind trust as long as you are unable to prove to the others that your IP has been targeted by them, neither you can discover whether they have targeted another IP or not. Some of my questions regarding these and some relevant issues still remain unanswered by the core team.

And here is another question:

Who is about to judge whether something is a bug or not? I personally trust @UdjinM6 to become a bug evaluator (but he has to stop being a Dash developper of course, because bug evaluator and developer roles contradict eachother). Is he an evaluator or not?

Who else is candidate to become a bug evaluator? Who is "Philip Da Silva" from BugCrowd and how comes he evaluates as a bug evaluator?

Being a bug evaluator is a personal quality, not a company quality. Especially as long as we dont know the names of the persons who are hiding behind the company, this turns the evaluation of the company questionable and even suspicious.

Bugcrowd has a lot of evaluators, so it is very important to know the (nick)names of the persons who are about to become Dash's Bug evaluators.

 

[jimbursch]

Last week I signed the customer agreement with BugCrowd and this week they are working on opening an exchange account so that they can accept payment in Dash. Once we have made the first payment, we will be set up on the BugCrowd platform and we will be writing a bounty brief that defines the scope of the program and the parameters of bounty payouts, along the lines of their taxonomy of vulnerability rating:

https://www.dash.org/forum/attachments/bugcrowd-vulnerability-rating-taxonomy-pdf.4215/

The program will be initially launched privately to an invitation-only group of BugCrowd's best, fully vetted researchers, and then opened to the public after the private trial run. When bugs/vulnerabilities are reported through the platform, the BugCrowd engineering team assesses the report to make sure it falls within the bounty brief and evaluates the priority level, which determines the amount of the bounty.

Throughout this process I will be consulting/coordinating with @flare on the Core Team. I would also love to get developers like @UdjinM6 involved with the program.

 

[demo]

Last week I signed the customer agreement with BugCrowd and this week they are working on opening an exchange account so that they can accept payment in Dash. Once we have made the first payment, we will be set up on the BugCrowd platform and we will be writing a bounty brief that defines the scope of the program and the parameters of bounty payouts, along the lines of their taxonomy of vulnerability rating:

https://www.dash.org/forum/attachments/bugcrowd-vulnerability-rating-taxonomy-pdf.4215/

The taxonomy of bugcrowd is not applicable to the Dash purposes. The bugs of Dash should be discovered in the stable version of code that resides into github. They are logical bugs and design bugs, not server configuration bugs. ( I have already point to several logical and design bugs, for example the design choice to use an interpreted language in sentinel is a serious design bug).

Do not accept paying bugcrowd for "Server Security Misconfiguration" e.t.c.. Tell them that only if they discover bugs in the stable version that resides into github, this is acceptable. Whoever claims to be a Dash bug evaluator, should start by compiling the source code of Dash, then discover bugs related to the code.

The real testers are people who read the code and discover bugs that way, not the ones who perform a million automatic tests and discover bugs based in pure chance. Whoever is unable to read the code, cannot be named a real tester. Instead of paying the stupid test monkeys better buy the automatic test software they are using. Please pay only the real testers. I hope that @flare and @UdjinM6 agree with that.

 

[jimbursch]

Thanks @demo -- I'll make sure your points are included in the bounty brief.

The first application that will be included in the program is the "protocol" as defined here:
https://github.com/dashpay/dash

The next application will probably be the Copay wallet when it is released. We can add several more applications, as the budget allows.

 

[alex9]

Hello @jimbursch

I just wanted to say thank you for taking up this idea and working in this direction. I believe that this is one of the important points for the full-fledged growth of the project. Good luck to you and everyone who is involved and leads Dash to success.

 

[demo]

Thanks @demo -- I'll make sure your points are included in the bounty brief.

The first application that will be included in the program is the "protocol" as defined here:
https://github.com/dashpay/dash

Ok.
When bugs are discovered by BugCrowd, and before pay them, post the bug (timestamped and signed by Bugcrowd's digital signature) here in this forum thread and in github's issues page.

This is because some serious (mostly design and protocol) bugs and deficiencies (for example: the veritas team, separate the vote layer, randomness in mn payee e.t.c.) are already reported in the forum and in github issues, so it is not appopriate to pay people for known bugs and deficiencies.
Only in case there is no one which can prove that the BugCrowd discovered bug is not an original one, you should pay BugCrowd.
I hope that @flare and @UdjinM6 agree with that.

 

[Dashmaximalist]

Ok.
When bugs are discovered by BugCrowd, and before pay them, post the bug (timestamped and signed by Bugcrowd's digital signature) here in this forum thread and in github's issues page.

This is because some serious (mostly design and protocol) bugs and deficiencies (for example: the veritas team, separate the vote layer, randomness in mn payee e.t.c.) are already reported in the forum and in github issues, so it is not appopriate to pay people for known bugs and deficiencies.
Only in case there is no one which can prove that the BugCrowd discovered bug is not an original one, you should pay BugCrowd.
I hope that @flare and @UdjinM6 agree with that.

we can even put the copy of know bugs on dash blockchain so that there is no confusion absolutely

 

[demo]

we can even put the copy of know bugs on dash blockchain so that there is no confusion absolutely

Not all the reported bugs are considered as bugs by the core team.

For example the randomness in mn payee selection is not considered by the core team as a known bug. Let the Bugcrowd company investigate freely and without any hints, and if they come here with a bug related to mn payee selection caused by a hacked /dev/random device, then it will be hard for the core team to deny the bug, once again.

We trust nobody. This is the motto, isnt it?

Dont trust the core team to give a list of known bugs to the bugcrowd company. They may add or delete some bugs from the list, they may also generalize some known bugs, for their own benefit (which is, a small amount of bugs to be discovered).

Let bugcrowd to investigate with a clear and objective mind, without hints or tips. And if they discover a bug already reported in the forum or in github which the core team denied its existence, then this will be a minus point for the core team.

I hope that @flare and @UdjinM6 agree with that.

 

[demo]

I just wanted to say thank you for taking up this idea and working in this direction.

Or maybe @jimbursch took up the below idea (which is similar but older than yours), and worked in the same direction.

Those executables may (or may not) are infected with PWS trojans, but the trolls never ask an independent tester to check them, neither they want a relevant testing proposal to pass from the budget system. They prefer to pay the marketeers to fill the internet with garbage-info about how great dash is, so that the dash deficiencies to never being heard by the masses.

But this is not the correct way for a digital cash that wants to survive in the future to evolve. The correct way is to pay an anti-core team, a team that will have the mission to attack the core team and reveal all their wrongs and errors.

Me too, I want to say thank you to @jimbursch, for convincing the stupid MNOs towards the necessity of an independent tester.

 

[UdjinM6]

Not all the reported bugs are considered as bugs by the core team.

For example the randomness in mn payee selection is not considered by the core team as a known bug.
...

There is no such bug or vulnerability in mn payee selection you are trying to push because it does not use randomness in the way you think it does. I already answered this concern in the thread you linked to but you fail to listen and/or read the actual code. For whatever reason you are still looking for an answer where you expect it to be and not where it actually is and where I pointed you to. And as a result, you are making wrong assumptions, basically.

I do agree that we should not pay for "discovery" of known issues/bugs (unless it also comes with a great solution for such a problem).

 

[demo]

it does not use randomness in the way you think it does.

So If I compile and install a masternode in my own machine, the dash code does not use the /dev/random device for the masternodes payee selection? Then what kind of randomness does it uses? Is it a network randomness? Do all the masternodes decide together what truly random is? And where is the appropriate code for it?

You are not obliged to answer of course. If you do not answer, but you insist in your position, it is maybe something I dont understand. I advice the ignorants not to trust me, but rather trust @UdjinM6. He is probably right. But I will insist in my position, until I understand my error.

@dark_wanderer If it was 10 days already then dashd (12.0) could see it as "never paid" even if it was before but that's ok, it means that you are in top 10% from which MNs are picked randomly so just keep your mn online do NOT restart it via masternode start-* commands and it should be paid eventually. If you restart, it will be brought to the end of the queue and you'll have to wait 7+ days to get into that top 10% again.

Where is this randomness in the code, if not into the FindRandomNotInVec ?

https://github.com/dashpay/dash/blo...f3034197e94f1a18ff/src/masternodeman.cpp#L550
https://github.com/dashpay/dash/blob/master/src/masternodeman.cpp#L632

   InsecureRand insecureRand;
    // shuffle pointers
    std::random_shuffle(vpMasternodesShuffled.begin(), vpMasternodesShuffled.end(), insecureRand);
bool fExclude;

Isnt std::random_shuffle a call to my local machine?
What if I compile std::random_shuffle (or its dependencies and its dynamically linked libraries) in a way it does not behave as random as you expect it does? How the rest masternodes discover a masternode which hacked his own local randomness?

 

[UdjinM6]

So If I compile and install a masternode in my own machine, the dash code does not use the /dev/random device for the masternodes payee selection? Then what kind of randomness does it uses? Is it a network randomness? Do all the masternodes decide together what truly random is? And where is the appropriate code for it?

You are not obliged to answer of course. If you do not answer, but you insist in your position, it is maybe something I dont understand. I advice the ignorants not to trust me, but rather trust @UdjinM6. He is probably right. But I will insist in my position, until I understand my error.


https://github.com/dashpay/dash/blo...f3034197e94f1a18ff/src/masternodeman.cpp#L550
https://github.com/dashpay/dash/blob/master/src/masternodeman.cpp#L632

   InsecureRand insecureRand;
    // shuffle pointers
    std::random_shuffle(vpMasternodesShuffled.begin(), vpMasternodesShuffled.end(), insecureRand);
bool fExclude;

Isnt std::random_shuffle a call to my local machine?
What if I compile std::random_shuffle in a way it does not behave as random as you expect it does?

Once again: https://www.dash.org/forum/threads/...masternode-monitoring.2722/page-6#post-109861
The code: https://github.com/dashpay/dash/blob/master/src/masternodeman.cpp#L550-L612
tl;dr version: it doesn't use any system random functions, instead it uses hashing of some data which is known by everyone (the data is a block hash, which is random-ish and can't be gamed, and mn outpoint) to produce deterministic output ("score") and to select next payee based on that.

 

[demo]

tl;dr version: it doesn't use any system random functions, instead it uses hashing of some data which is known by everyone (the data is a block hash, which is random-ish and can't be gamed, and mn outpoint) to produce deterministic output ("score") and to select next payee based on that.

I am trying to understand what you said, and how this is translated into the code. If it doesnt use any system random functions, then it is ok and you are right.

I will investigate whatever system random functions you may use into the code (if any), and how these functions (if hacked in the system) can affect code's behavior. Thanks for the hints and for the clarifications you gave to me . I always appreciate a code related talk with you.

 

[demo]

the data is a block's hash, which is random-ish and can't be gamed.

I think I understood the theory.
Thanks for helping me understand what's going on.

 

[jimbursch]

Bugcrowd has received payment so we are now proceeding with the initial setup of the program. For the first month or so the program will be private, open only to Bugcrowd's best vetted researchers. This will give us a chance to work out any bugs with the bug program ahead of going public. I will, however, keep the community informed as we go along.

If you would like to get an idea of what the program will look like, you can see other Bugcrowd programs here:
https://bugcrowd.com/programs

These are the most relevant to Dash:

https://bugcrowd.com/mastercard
https://bugcrowd.com/circle
https://bugcrowd.com/westernunion
https://bugcrowd.com/simple
https://bugcrowd.com/card

 

[ampp]

In light of the ethereum bug i think some sort of bounty program has to be very significant. The reward for a wallet draining bug is millions, although "illegal" and you have to cover your tracks. Too significant and you end up making the coin worthless. A bounty of a million for a qualified unexploited repair might gather true attention. I think the same bug bounty program could be used as a insurance of last resort as if the exploit is preferred over the bounty then that money is now fairly useless. Obviously the rules for payout have to be very well laid out and all precautions taken.

It will be interesting to see what happens with the ethereum ico's. If anyone will bother to save them.

 

[CaptAhab]

Great work @jimbursch

 

[Matt Robertson]

are the bugcrowd bounties active yet?

 

[jimbursch]

are the bugcrowd bounties active yet?

The program is initially launching privately to selected BugCrowd researchers, and then will be opened to the public in late August or early September.

 

[jimbursch]

If anyone would like to see a preview of what the private Dash Bug Bounty program will look like, PM me and I will send you a link.

If anyone has any questions, please don't hesitate to ask here.

 

[jimbursch]

Yesterday a press release went out announcing the Dash Bug Bounty Program. Here are some places where it has been picked up:

https://www.crowdfundinsider.com/2017/08/120205-dash-teams-bugcrowd-cybersecurity-services/
https://paymentweek.com/2017-8-3-dash-employs-elite-cybersecurity-service-bugcrowd-hack-blockchain/
http://www.econotimes.com/Dash-empl...to-identify-blockchain-vulnerabilities-838227
https://cointelegraph.com/news/dash-employs-white-hat-hackers-to-hack-its-own-blockchain
http://www.banklesstimes.com/2017/08/03/dash-invites-crowd-to-hack-its-blockchain/

 

[jimbursch]

I have created a new thread for Dash Bug Bounty Program updates under the Dev Tech Discussion: Projects forum located here:
https://www.dash.org/forum/threads/dash-bug-bounty-program.16100/

Go there for the latest updates and information.