[HN Gopher] Zero-day flaws in authentication, identity, authoriz...
___________________________________________________________________
Zero-day flaws in authentication, identity, authorization in
HashiCorp Vault
Author : nihsy
Score : 226 points
Date : 2025-08-07 07:01 UTC (15 hours ago)
(HTM) web link (cyata.ai)
(TXT) w3m dump (cyata.ai)
| v5v3 wrote:
| Fantastic work guys. Thank you.
| maxall4 wrote:
| Mmm AI writing gotta love it... /s
| markasoftware wrote:
| it really does have that AI writing style, and these are the
| sorts of bugs I imagine an AI could have found...I wonder if
| that's what they did (though they claim it was all manual
| source code inspection).
| darkwater wrote:
| Having the blog post explaining the findings written - or
| aided - by an AI doesn't necessarily mean that the findings
| themselves were found using AI.
|
| Edit: even if the TLD they use is .ai and they heavily
| promote themselves as revolutionary AI security firm yadda
| yadda yadda
| neomantra wrote:
| From reading it and mostly from the introduction, it felt
| like they rolled up their sleeves and really dug into the
| code. This was refreshing versus the vibe-coding zeitgeist.
|
| I would be curious what AI tools assisted in this and also
| what tools/models could re-discover them on the unpatched
| code base now that we know they exist.
| Cthulhu_ wrote:
| I can imagine they could have used AI to analyze,
| describe and map out what exactly happens in the code.
| Then again, it's Go, following the flow of code and what
| exactly is being checked is pretty straightforward (see
| e.g. https://github.com/hashicorp/vault/blob/main/vault/r
| equest_h... which was mentioned in the article)
| benterix wrote:
| > .I wonder if that's what they did (though they claim it was
| all manual source code inspection).
|
| Give me one reason why they would do it by hand if they can
| automate is as much as possible. Vulnerability research is an
| area without any guarantees, you can spend months looking for
| bugs and find nothing. These guys are not stupid, they used
| LLMs trying to find whatever they could, they probably
| explored more blind alleys than we will know, and then got
| very good results. Many other companies are doing the same.
| klas_segeljakt wrote:
| https://youtu.be/SbeNRICgzTA?si=YdLrozOEtCBTclW2
| unwind wrote:
| This feels like a dupe of
| https://news.ycombinator.com/item?id=44821250.
|
| Edit: replaced link with link to HN post, not the article in that
| post.
| mdaniel wrote:
| There's no way a general security aggregator website qualifies
| as a better submission than the actual folks who actually
| discovered the vulns. They deserve all the recognition and to
| tell the story in their own words
| tiedemann wrote:
| TLDR: string parsing is hard and most of us are vulnerable to
| assumptions and/or never get around to do those fuzzy tests
| properly when checking that input is handled correctly.
| compressedgas wrote:
| I don't see any parsing going on here. They failed to normalize
| the input values the way that the LDAP server does before
| applying rate limiting resulting in an effectively higher than
| expected login attempt rate limit.
| procaryote wrote:
| A lot of these are on the pattern of normalising input as late
| as possible, which is an odd choice for a security product.
| LtWorf wrote:
| I mean... it's hashicorp... did you expect sanity?
|
| One of the vault backends has a size limit and so secret keys
| larger than 2048 bits would not fit. Amazing tool.
| Cthulhu_ wrote:
| I'd argue it's odd that they (or LDAP) normalise input in the
| first place. I can sort-of understand username normalization
| to avoid having both "admin" and "Admin" accounts, but that
| check only needs to be done when creating an account, when
| logging in it should not accept "Admin" as valid for account
| "admin".
|
| But I'm neither a security person nor have I done much with
| authentication since my 2000's PHP hobbying. I suspect an
| LDAP server has to deal with or try and manage a lot of
| garbage input because of the sheer number of integrations
| they often have.
| stackskipton wrote:
| It's enterprise product, a ton of money can be made by trying
| to parse complete garbage being tossed at you and delivering
| it.
| tptacek wrote:
| Security products are just products like everything else.
| They're not written differently than normal infrastructure
| products.
| edoceo wrote:
| But does it affect Bao? Could test there since they are so
| closely related.
| satoqz wrote:
| OpenBao maintainer here - The majority of these does affect us,
| more or less. Unfortunately it seems that we did not receive
| any prior outreach regarding these vulnerabilities before
| publication... make of that what you will. We've been hard at
| work the past days trying to get a security release out, which
| will likely land today.
| Scandiravian wrote:
| Thanks for the great work and swift communication
|
| I'm very disappointed to hear that the researchers did not
| disclose these findings to the OpenBao project before
| publishing them, so you now have to rush a release like this
|
| Will you reach out to the researchers for an explanation
| after you've fixed the issues?
| wafflemaker wrote:
| I can explain* researchers (and myself, though have nothing
| to do with it): We both learned about OpenBao today.
|
| explanation [?] excuse
| Scandiravian wrote:
| Thank you for the explanation. It's obviously not great
| that this was missed, but finger-pointing now doesn't
| really help anyone, so I'll focus on what seems to me
| like the root issue
|
| My impression is that there is an information gap about
| forked projects that lead to this issue
|
| I'm on vacation right now, but when I'm back I'll try to
| setup a small site that lists forks of popular projects
| and maybe some information on when in time the project
| was forked
|
| Hopefully something like that can make it more likely
| that these things are responsibly disclosed to all
| relevant projects
| Scandiravian wrote:
| It sounds like these issues are from before the fork, in which
| case they will be
|
| It also doesn't sound like the researchers made an effort to
| safely disclose these findings to the OpenBao project before
| publishing them, which I think would have been the right thing
| to do
| procaryote wrote:
| > This default is 30 seconds, matching the default TOTP period.
| But due to skew, passcodes may remain valid for up to 60 seconds
| ("daka" in Hebrew), spanning two time windows.
|
| Wait, why would I care this is "daka" in Hebrew? Is this a
| hallucination or did they edit poorly?
| neom wrote:
| Maybe just being cute. Author is Yarden Porat from Cyata, an
| Israeli cybersecurity company.
| onecommentman wrote:
| So perhaps using AI writing tools for English to polish his
| writing, since English may not be his first language and he
| doesn't want stumbling around English syntax to get in the
| way of his message.
|
| It may become an English writing style we all have to get
| used to from non-native English speakers and an actual valid
| use case for current AI. I know I'd use AI this way when
| writing something important in a language I'm semi-fluent in.
| I already use search engines to confirm the proper use and
| spelling of fashionably popular foreign phrases, instead of
| an online dictionary.
| andrewflnr wrote:
| What would including a reference to a Hebrew word in their
| English article have to do with polishing his writing? You
| seem to have gotten off the track of the original
| "evidence" while still fixating on the AI hypothesis.
|
| (Your comment is at least more charitable than the first
| couple in this thread, but still factually shaky at best.)
| tecleandor wrote:
| Also... what is "daka" ? 60 seconds? passcodes that remain
| valid for two time windows? I've been checking the dictionary
| and "daka" might mean "minute".
| n4bz0r wrote:
| https://s3.amazonaws.com/LCG/40kconquest/ffg_WHK03_34.jpg
| iddan wrote:
| Fun language fact: "daka" is hebrew for "minute" but it's
| literal meaning is "thin one" figurative being "the thin
| (shorter) time measure" in contradiction with an hour
| ("sha'aa")
| jimkleiber wrote:
| Fascinating, "dakika" is "minute" in Swahili...probably
| similar in Arabic as well...yup, Google AI says "daqiqa"
| for the Latin alphabet version of minute in Arabic.
| drivers99 wrote:
| "minute" is also "small"
|
| pars minuta prima (first small part) -> minute (1/60th of a
| circle, or of an hour)
|
| secunda minuta -> second (1/60 of a minute)
|
| minutus -> minute (adj), "very small in size or degree,
| diminutive or limited, petty"
|
| source: etymonline
| yardenporat wrote:
| Lolllllllll "Daka" is an Easter egg I added. Because I have a
| friend named Daniel. And this is an inside joke
| tptacek wrote:
| _Please don 't pick the most provocative thing in an article or
| post to complain about in the thread. Find something
| interesting to respond to instead._
|
| https://news.ycombinator.com/newsguidelines.html
| gtirloni wrote:
| Something feels odd reading the article. It's so verbose like
| it's trying to explain things like the reader is 5yo.
| plantain wrote:
| AI written, or edited.
| Cthulhu_ wrote:
| I'd say edited, I did wonder if they used AI to find the
| issues in the first place but they would brag about that
| front and center and pivot to an AI-first security company
| within seconds. Then again, maybe they used AI to help them
| map out what happens in the code, even though it's Go code
| and should be pretty readable / obvious what happens.
|
| That said, I think it's weird; the vulnerabilities seem to
| have been found by doing a thorough code review and
| comprehension, why then cut corners by passing the writeup
| through AI?
| benterix wrote:
| I don't think they would brag about it if they were found
| by AI, but based on their description I suspect most of
| this work was definitely done by LLMs, and then checked by
| humans.
| yardenporat wrote:
| I am not sure you are correct here :) As the one who
| found the 9 cves. I am pretty sure I a not an LLM. But
| these days, it is hard to know.
|
| (No llm were used for the research)
| dylan604 wrote:
| Why do you have that belief? If some researcher used AI,
| they'd be singing the praises of AI from the rooftops.
| There'd be Show HN on how cool AI is that it can find
| CVEs. VCs would be flooding the dev with offers, for what
| reason who knows, but that's VCs.
|
| Why would you think someone would hide the use of AI? I'm
| not familiar with a timeline with that behavior.
| benterix wrote:
| It was definitely edited by AI or written on the basis of
| initial information. Which is a pity because I'd love to see
| the original, it has more value for me.
| natebc wrote:
| This sentiment sums up why i dislike the broad use of LLMs
| and generative words/art/music. Genuine Human work has more
| value to me than anything generated by a computer.
|
| I like humans. I've even loved a few. I like what humans do;
| warts, typos and awkward phrasing included.
| neom wrote:
| The post covers 9 CVEs May-June 2025 (Full chain from default
| user > admin > root > RCE):
|
| CVE-2025-6010 - [REDACTED]
|
| CVE-2025-6004 - Lockout Bypass
| https://feedly.com/cve/CVE-2025-6004
|
| Via case permutation in userpass auth Via input normalization
| mismatch in LDAP auth
|
| CVE-2025-6011 - Timing-Based Username Enumeration
| https://feedly.com/cve/CVE-2025-6011
|
| Identify valid usernames
|
| CVE-2025-6003 - MFA Enforcement Bypass
| https://feedly.com/cve/CVE-2025-6003
|
| Via username_as_alias configuration in LDAP
|
| CVE-2025-6013 - Multiple EntityID Generation
| https://feedly.com/cve/CVE-2025-6013
|
| Allows LDAP users to generate multiple EntityIDs for the same
| identity
|
| CVE-2025-6016 - TOTP MFA Weaknesses
| https://feedly.com/cve/CVE-2025-6016
|
| Aggregated logic flaws in TOTP implementation
|
| CVE-2025-6037 - Certificate Entity Impersonation
| https://feedly.com/cve/CVE-2025-6037
|
| Existed for 8+ years in Vault
|
| CVE-2025-5999 - Root Privilege Escalation
| https://feedly.com/cve/CVE-2025-5999
|
| Admin to root escalation via policy normalization
|
| CVE-2025-6000 - Remote Code Execution
| https://feedly.com/cve/CVE-2025-6000
|
| First public RCE in Vault (existed for 9 years) Via plugin
| catalog abuse >
| https://discuss.hashicorp.com/t/hcsec-2025-14-privileged-vau...
| cipherboy wrote:
| For anyone interested in CVE-2025-6010:
| https://discuss.hashicorp.com/t/hcsec-2025-21-vault-user-enu...
| neuralkoi wrote:
| In non-CA mode, an attacker who has access to the private key of
| a pinned certificate can: Present a certificate
| with the correct public key Modify the CN in the
| client certificate to any arbitrary value Cause
| Vault to assign the resulting alias.Name to that CN
|
| I agree that this is an issue, but if an attacker has access to
| the private key of a pinned certificate, you might have some
| bigger issues...
| nailer wrote:
| when I first read your comment, I agreed, but it's actually a
| little bit deeper than that.
|
| You have access to the private key of the public key in a
| certificate. The certificate is making an attestation that the
| signer has verified that this canonical name belongs to this
| public key.
|
| You as the holder of the private key that matches the public
| key in the certificate should not allow you to change what the
| signer has attested about you.
| colechristensen wrote:
| You're not wrong that there is indeed a significant issue,
| but the parent isn't wrong either. If the attacker already
| has a private key you've probably already lost the war. Yes
| there's a real issue there but by the time an attacker
| reaches it they're already in the castle's keep.
| nailer wrote:
| > the parent isn't wrong either... if the attacker already
| has a private key you've probably already lost the war.
|
| When you lose your private key, you have lost the war to
| protect your identity - anyone else can now be you. But in
| a properly designed system, that should not also compromise
| the signer.
|
| If I steal your license I can pretend to be you, but I
| can't make the government say you are 7 feet tall.
|
| You may be making the point that a compromised keystore
| holding all users public keys may leak the signers private
| key at the same time it has leaked the victim's private
| key, but there are many ways the victim's private key can
| be leaked in most cryptosystems (eg, the victim's private
| key on their device may be stolen).
| tptacek wrote:
| This is authz bypass, not authn, right? You're an unprivileged
| user and can assume privileged roles.
| cipherboy wrote:
| 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.
| mike_hearn wrote:
| Impressive. It's worth reading despite the slight AI sheen to the
| writing, as it's unusually informative relative to most security
| articles. The primary takeaway from my POV is to watch out for
| "helpful" string normalization calls in security sensitive
| software. Strings should be bags of bytes as much as possible. A
| lot of the exploits boil down to trying to treat security
| identifiers as text instead of fixed numeric sequences. Also,
| even things that look trivial like file paths in error messages
| can be deadly.
| progbits wrote:
| My take on the normalization is that it happens in the wrong
| place - you should not do it adhoc.
|
| If your input from user is a string, define a newtype like
| UserName and do all validation and normalization once to
| convert it. All subsequent code should be using that type and
| not raw strings, so it will be consistent everywhere.
| Normal_gaussian wrote:
| Its ridiculous that we haven't been aggressively boxing login
| credentials for decades at this point. This kind of issue was
| well discussed when I did my degree well over a decade ago.
| ramenfunded wrote:
| It's the same discussion as "don't use floating point for
| money" and yet I've seen it done at every startup I've
| joined with all the same mistakes.
| jerf wrote:
| And if it turns out to be wrong for whatever reason, you can
| be confident your fixes will propagate anywhere the types are
| defined. If the situation is extremely bad, especially the
| sort of thing where all the users must still do something
| that you can't offload entirely on to the type (such as an
| entirely new set of methods and flow for correct usage), you
| can define a brand new type and the compiler will guide you
| as to how to force the entire system to be fixed as you push
| the new type in and remove the old one.
|
| I've done all these things in fairly high-security contexts
| where I had a very critical username normalization step. It's
| a very valuable tool.
| benterix wrote:
| Yeah, I tolerated the AI tint in this article only because it
| was very informative otherwise.
| shahartal wrote:
| Hey all -- authors of Vault Fault here (I'm Shahar, CEO at
| Cyata), really appreciate all the thoughtful comments.
|
| Just to clarify - all the vulnerabilities were found manually by
| a very real human, Yarden Porat.
|
| The writeup was mostly human-written as well, just aimed at a
| broader audience - which explains the verbosity. We did work with
| a content writer to help shape the structure and flow, and I
| totally get that some parts read a bit "sheeny." Feedback noted
| and appreciated - and yep, there's more coming :)
|
| btw likely missed with the direct link - we also found pre-auth
| RCE in CyberArk Conjur - cyata.ai/vault-fault
| yodon wrote:
| Your writeup was excellent. There's no more ubiquitous or lower
| signal comment here these days than "I think this was written
| by AI." There is no piece of English writing one can link to on
| HN without someone spamming us with a sentence or that form.
|
| Well written? AI. Poorly written? AI. Has a non-sequitor? AI.
| No non-sequitors? AI. Includes an em-dash (added automatically
| by Word for almost two decades)? AI. No em-dashes? AI.
|
| Eventually, hopefully, dang will declare "I think this was
| written by AI" to not be a productive topic for comments, just
| like commenters are already encouraged to engage with the
| strongest and best form of the ideas presented instead of
| attacking the most easily taken down strawman interpretation of
| them, but until then we all have to scroll through it on every
| post, no matter how well written it is, as yours is.
| oasisbob wrote:
| I disagree, the write up is overly verbose. If AI helped
| inflate it, that's worthy of conversation.
|
| Rhetorical faults are consistently discussed when security
| disclosures and notifications come up. How egotistical are
| the finders? Does it deserve a microsite? Does it deserve a
| logo? Similarly, why is the vendor response so vague? Why
| does it seem so weasel-like? Did they lie in this one
| place...?
|
| The problem with AI writing is that it doesn't have a voice,
| is not typically good, and interferes with the ethos and
| pathos the author is trying to develop. It's verbose, and
| typically telegraphs a lack of editing or real review.
|
| That humans still care about these things isn't a problem for
| dang to sort out. It's something that authors should continue
| to think about carefully before putting out automatically-
| generated content under their name.
| tptacek wrote:
| "Does it deserve a logo and a microsite" is one of those
| debates that happens on message boards that is otherwise
| pretty alien to the practice of vulnerability research.
| winwang wrote:
| If these are the problems (or, your problems), then it
| seems that it doesn't matter if AI wrote it or not -- just
| that the writing isn't "good".
| technion wrote:
| I generally dont like seeing these "blind username enumeration"
| type issues.
|
| Its nearly always possible to get usernames elsewhere, they are
| basically public and the private part is the key and any mfa
| token. Usernames can get locked out, but the workaround of having
| user enumeration sprays always burn CPU hashing time delaying
| passwords doesn't seem like a step forward.
| v5v3 wrote:
| Going by the naming, this was reported to Hashicorp prior to 10th
| June?
|
| And as it's now August, is it redacted as not fixed yet? Why not
|
| CVE-2025-6010 - [REDACTED]
| cipherboy wrote:
| 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.
| dylan604 wrote:
| > reasonably confident
|
| why does this phrase not fill me with confidence?
| cipherboy wrote:
| 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/calend
| ar/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.
| tptacek wrote:
| Why do you care? This is not a very meaningful
| vulnerability --- it's a side channel _user enumeration_.
| Even direct user enumeration is a sev:info finding.
| cipherboy wrote:
| 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!)
| booleanbetrayal wrote:
| As someone who is actively migrating from HCP Vault Dedicated
| to self-hosted OpenBao, thanks for this update. Any CVE issues
| worth tracking / linking here?
| cipherboy wrote:
| 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.
| tptacek wrote:
| Somebody has to say this so I guess I'll take the hit: part of
| the cost of an unsanctioned fork of a large project is that
| you're not going to be in the embargo list. Even with a large
| base of developers and users, the mechanics of a community-
| driven open source project can make people gun-shy about pre-
| disclosing.
|
| Over the long term, increasing prominence of your project will
| probably get you most disclosures directly, because
| vulnerability researchers are incentivized to confirm big
| targets for findings. But in the short term, I don't think this
| complaint about HashiCorp is based in any real norm of
| vulnerability disclosure.
| cipherboy wrote:
| 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.
| tptacek wrote:
| These are all points well taken. I'd just say, don't look
| for any kind of coherent fairness in vulnerability embargo
| lists. Certainly, if you're a fork that the upstream
| doesn't want to exist, I don't think there's any norm that
| you'll automatically be included. I'm irritated about a
| number of embargo lists myself, but if the vulnerability
| researchers wanted to include me, they could, regardless of
| what IBM thought.
| themk wrote:
| I've run Vault for a long time, and none of this surprises me.
| I've even reported some of these to Hashicorp in the past, along
| with other equally shocking bugs.
|
| The code base is an absolute mess.
|
| The number of bugs and weird edge cases I've found with my
| quickcheck property testing of their API is shocking, and makes
| me think their test suites are woefully inadequate.
| cipherboy wrote:
| 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. :-)
| fidotron wrote:
| > The code base is an absolute mess.
|
| This is an understatement, and honestly when I saw it the first
| time it was enough to make me wonder about all things
| Hashicorp.
| Hilift wrote:
| Where were all these people when Vault was released in 2015? I
| remember being told we were switching to Vault in 2018 and
| nada. It was like the economists before the 2008 mortgage
| salad. Did Vault not hire security people? This reminds me of
| when HeartBleed occurred in 2014. It was after that when
| someone looked at the code and bugs everywhere. The guy that
| created Heartbleed got a Phd and the guy that discovered it got
| a t-shirt. "And then it was acquired by IBM".
| tptacek wrote:
| I don't think the code is a mess (I've had to work with it
| before) and I don't think these vulnerabilities are shocking.
| This is an unusually thorough research project and if you look
| at any project you're going to find these kinds of logic
| vulnerabilities; the TOCTTOU parse differential thing is a
| classic insidious finding, because there's no pattern to match
| it to.
| chucky_z wrote:
| I'll +1 this. I've personally committed code to Vault and the
| OpenBao changes go hand-in-hand with the style of the Vault
| codebase. I enjoy both projects and appreciate that they both
| exist.
|
| It's all Go anyway, it all looks pretty similar. I think if
| anything it looks/feels this way because it's a security-
| first project. By that I mean the way the code is written
| tends to care more about security over anything else.
|
| Also the Hashicorp projects in general tend to use a lot of
| their own libraries/code so it's just a little different than
| other stuff. Code quality isn't too important so long as the
| code is maintainable (clearly it is, it's had a lot of
| versions) and works (again, clearly it does. a lot of folks
| use vault just fine, including me).
|
| All previous CVEs are handled in a very straightforward
| manner with reasonable notifications as well, just like this
| one. This just has a big fancy article attached to it because
| it's Blackhat week and folks want to get a big fancy release.
| If you need further proof of the Blackhat effect go look up
| the 'death of http/1.1' article.
| RankingMember wrote:
| > The code base is an absolute mess.
|
| As a bystander, can you give any examples? Is it just poorly
| structured, full of spaghetti, or something else?
| tptacek wrote:
| It's a good writeup, and I understand that it's Black Hat week
| and so the intensity meter is dialed up to 11 on these things.
| Some of these vulnerabilities are pretty clever. But these are
| mostly situational, things that would typically get sev:med or
| lower on an assessment.
|
| The RCE reported here is the product of an admin->root (Vault
| root, not Unix root) privilege escalation that already required a
| privileged account. It's a good bug! They got audit logs to get
| parsed as an executable plugin. The privilege escalation bug they
| used to allow admin accounts to set up plugins is also clever
| (they noticed that the sanity check for assuming the "root" token
| hardcoded "root", but the code that actually selected the token
| sanitized the token name, so you could use " ROOT").
| AgentMatrixAI wrote:
| Anybody else just wrapping SOPS in a rest api call and using
| that? Feel like that is just as good from my experience. While I
| think Vault is useful for large companies, I just need something
| to encrypt and decrypt and not rely on pgycrypto
___________________________________________________________________
(page generated 2025-08-07 23:01 UTC)