cipherboy

Joined 11 years ago

Karma
700
Submissions
203
Member since
Sep 28
Head of OpenBao Development @ ControlPlane.

The BUSL-1.1 is not OSS.

My views are my own, not that of any past, present, or future employer.

https://cipherboy.com

https://github.com/cipherboy

[email protected]

View on Hacker News

Recent submissions

Comment · 3 months ago
Vault has had PKI since pre-v1; ACME was introduced in 2022 to modernize its APIs.
Comment · 1 year ago
I'll bite ;-) Appreciate your replies as always tptacek!

It is a fair criticism. But I think two things give us an advantage here:

1. IBM started this fork and later bought HashiCorp, with the acquisition having fully completed. I've broached the subject with both sides post-acquisition but got only a negative response from the HashiCorp side and no response from IBM. We are very much a known entity to the teams that matter inside IBM. And I'd posit within HashiCorp as well given I came out of their Vault Crypto team. ;-)

Whether IBM wishes to cooperate is a different matter. Mentioning again, publicly, doesn't hurt and hopefully raises awareness to researchers (such as yourself!).

2. The Linux Foundation's OpenSSF (our umbrella foundation) has a reputation which we try our best to uphold. Obviously they'd be rightfully upset if we shared pre-disclosure vulnerabilities widely. So we won't and don't. Certainly the broader Linux distribution security list is a positive model in this regard.

If this were J. Doe's pet fork of $CRITICAL_SOFTWARE, 100% agree. But the fork is neither new nor lacking in reputation of its component/parent entities, so I'd hope researchers give us the same consideration they would any other of LF's forks (Valkey, OpenSearch, OpenTofu, ...).

But that said, I've personally disclosed vulnerabilities post-fork to HashiCorp and have mentioned to them that I have stopped future disclosures without a further agreement. This just leads to a two-party zero-day vulnerability race, which is not in anyone's best interest.

Comment · 1 year ago
Yes and https://discuss.hashicorp.com/t/hcsec-2024-05-vault-cert-aut... was an earlier authN+authZ bypass in the same code block.

So maybe one step down in severity, though I do not know the details of what HCSEC-2024-05 was fixed with as that was after the fork point. OpenBao moved to full cert pinning (constant-time cert.Raw comparisons) when remediating that one, which meant we were not affected by this variant.

Comment · 1 year ago
Since HashiCorp and OP did not opt to disclose to OpenBao, the most authoritative source right now is HashiCorp's security tracker, linked down-thread: https://news.ycombinator.com/item?id=44821779

https://discuss.hashicorp.com/tag/security-vault is the aggregate link, with HCSEC-2025-[13..22] being the relevant topics.

I will be working shortly to acquire additional CVE numbers for OpenBao for the 8 affected issues.

HCSEC-2025-18 / CVE-2025-6037 (core user confusion bug) does not affect OpenBao.

In general, our release notes detail fixed security issues: https://openbao.org/docs/release-notes/2-3-0/ per policy https://github.com/openbao/.github/blob/main/SECURITY.md. This also has contact information if anyone wishes to discuss additional new security issues.

Comment · 1 year ago
To quote a movie, only a Sith deals in absolutes ;-)

The OpenBao community call is in 10 minutes if you want to talk more about it live: https://calendar.google.com/calendar/embed?src=s63voefhp5i9p... (OpenSSF community calendar link).

But, the short answer why I say _reasonably_ sure is because HashiCorp and the OP haven't released a lot of details about exactly what case(s) are affected, so there's only so much we can do except look at our own code and infer what we can and make an educated guess.

So, barring some structural problem I'm not immediately aware of, I have reasonably high confidence based on discussions amongst the community members.

Comment · 1 year ago
OpenBao, under the Linux Foundation's OpenSSF, is making meaningful improvements to the code. I'd love to have high-quality reports, if you're willing to re-visit these. :-)
Comment · 1 year ago
I do not speak for HashiCorp, but they have published information on this CVE here: https://discuss.hashicorp.com/t/hcsec-2025-21-vault-user-enu...

OpenBao is reasonably confident in our fix: https://github.com/openbao/openbao/pull/1628

We had earlier pulled support for pre-Vault-1.0 userpass pre-bcrypt hashing (so there's no longer a timing difference there that could be used for enumeration) and using cache busting on lookup should also ensure consistency across storage layers. Plus, normalizing the remaining error messages through when the user's credential is fully validated as correct.

Comment · 1 year ago
Comment · 1 year ago
On behalf of the OpenBao project, I welcome collaboration with future researchers. We were not informed of these vulnerabilities before HashiCorp posted their usual CVE bulletins, which is disappointing. (Especially as HashiCorp's Vault no longer has an Open Source edition ;-)

We've triaged as being affected by 8 of the 9 CVEs (in fixing an earlier Cert Auth vulnerability, we correctly remediated this one) and have merged patches for most of them.

Happily, the community has done some great work on remediating these and I'm very appreciative of them.

I'm most excited about the audit changes: this was the impetus needed to make them be configuration driven in the next release series. Leaving audit device (which, as a reminder, have a socket mode which can make arbitrary TCP calls!) open to API callers is rather unsafe, even with prefix being limited.

(Edit: And of course it goes without saying, but we're more than happy to accept contributions to the community -- code, docs, technical, or otherwise!)

Comment · 1 year ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton