IBC Security Advisory Huckleberry
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: v7.0.1 v6.1.1 v5.3.1 v5.2.1 v4.4.1 v4.3.1 v4.2.2 v4.1.3 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…
Excerpt (1199 of 1289 characters). Read the whole post on the forum ↗
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.
Thanks for your reply, @jacobgadikian!
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.
The amounts don’t bother me.
I just want to know:
- Who is responsible for checking h1
- How often it is checked
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.
Really each chain should contribute to these bounties. Need a way to get them all signed up.
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.
thec00n: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 believe that the bounty amounts are being looked at, theres interest in increasing them.
Thank you @CarlosRodriguez
Will IBC-go v3.3 be patched as well ?
No, I am sorry, but the v3 release line reached already end of life, so we are not supporting it anymore. We encourage you to upgrade to v4 at least.
thanks so much for your work on this @CarlosRodriguez
Please do not use v4.1.2 and v4.2.2 thanks Carlos and Jacob - came to ask same Q. Who is checking Hermes?
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.
Jure:In paricular, what would turn this from “low severity / low impact” into “high severity / critical”?
I believe that theft risk.
hen: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.
Hey that’s actually really useful information, I hate h1 personally.