Recently, the ibc-go team received a report via Hacker One of a potential security vulnerability impacting IBC connected full nodes. This issue is low-severity in general, and it has a low impact and likelihood of exploitation. Depending on how a full node is architected, this issue could potentially yield a high or critical severity vulnerability.
ALL versions of ibc-go are affected. A patch to remediate this issue will be released on May 25th at 15:00 CET in the following versions:
Note that the patch is NOT state-machine breaking. The patch can be deployed individually by validators and full nodes without a chain-halt upgrade and should be applied as soon as possible. Though many potentially impacted parties have mitigations in place to prevent the issue from introducing vulnerability into their architectures, we highly recommend that full node operators, oracle networks, and bridges prepare to patch their implementations as quickly as possible once the release is available to fully remediate this issue.
This notice has been posted in accordance with the ibc-go’s vulnerability disclosure policy. If you find a vulnerability, please disclose it responsibly via our bug bounty program on HackerOne.
Is H1 being checked, by who, and at what interval?
I have used it in the past. 18 days response time isn’t good enough so I don’t use it anymore or even consider it a viable option for reporting issues.
Yes, we do check H1 and that is our main entry point for security reports. I am sorry to hear that your experience with our response times has not been good, but we are trying to improve.
oh hey, quick question – in this case, “we” is the ibc-go team?
I am just trying to understand the flow. Currently I have in fact recommended against using H1 at all especially if an item is important.
It’s no reflection on the ibc-go team, by the way-- I believe that the issue has been (and maybe still is?) the org controlling the H1 parent account. IBC-GO crew definitely cannot be blamed for not getting to a report on an issue in Tendermint that happened >18 months ago. Just, since then, I’ve let people know that maybe H1 isn’t the best path, especially for items that carry critical importance.
Thank you for the patch, and for your work in general.
The bounty rewards for Cosmos are absolutely pathetic. cosmos-sdk or ibc-go are used by chains that have a combined TVL of billions of dollars and the reward of finding a critical bug that compromises these billions of dollars is 5k? You should seriously take a look at immunefi to get a sense what protocols pay out in web3 these days.
I’ve made reports there. I’ve seen them go to naught with no response for 18days.
That’s dangerous and I’m just trying to get a clear understanding of the flow and process, so I can assess whether or not it is correct to continue advising people who are reporting issues, that at most, they should be doing H1 plus contacting the relevant team lead.
I really don’t know who is involved in that flow and I know it’s been really bad in the past. The money is kind of whatever, compared to the value of these reports.
Hacker One is the best way to disclose potential vulnerabilities. We monitor it closely for any incoming reports and try to react promptly. Apologies again for poor experience in the past, though. Informal Systems has recently taken a lead on setting up better processes and improve response times, so hopefully you will notice things getting better.
We will also re-evaluate the value of the bounties. Bumping the bounties was on the table a few months ago, but the conversation died a bit, so we will try to pick it up again.
For validators and nodes already in any of the supported v4.x, v5.x, v6.x or v7.x release lines, the upgrade to this new patch versions does not need to be coordinated.
Is there a CVE for this advisory? It would be helpful to have a better understanding of the severity, mechanisms and risks. In paricular, what would turn this from “low severity / low impact” into “high severity / critical”?
Any thoughts on posting the bounties on Immunefi as well? They have a massive community of hackers. Curious about the reason behind H1 and not Immunefi.
Personally I think that’s just inertia. I know that @Jessysaurusrex will likely be changing some stuff, what are the differences between H1 and immunefi?
Ah I see, makes sense. From what I understand and my prior experience, H1 is more focused on traditional SAAS yet Immunefi was solely founded to focus on web3 bug bounty hunting.
I don’t think the topic is a matter of H1 vs. Immunefi but rather a question of why host on H1 but not on Immunefi. After all, it doesn’t hurt to cover your bases and have more of the community and eyes on your bug bounty programs. Just my two cents and curious to hear what the team is thinking as Immunefi has a lot of notable clients on their roster.
Please do not use v4.1.2 and v4.2.2