6 ms·
Sign in as anyone: Bypassing SAML SSO authentication with parser differentials
- oncallthrow 2y agoXML is to authentication bypasses what C is to buffer overflow attacks
- deleted 2y ago[deleted]
- dietr1ch 2y agoSad that XML has too many features for an otherwise somewhat nice, but verbose markup language.
- treve 2y agoFeature are kind of a negative for security. Imagine if yaml was used!
- alexchamberlain 2y agoI think there is a "safe" subset of both XML and YAML that 80% of people actually use.
- bawolff 2y agoFrom a security perspective that's kind of useless, as your concern is not what the "good" people do, it's what the "bad" people do.
- alexchamberlain 2y agoWell, you can define such a subset and write or configure parsers to only use that; I've seen both XML and YAML libraries do just that, by disabling remote file loading or arbitrary code execution for example.
- bawolff 2y agoDisabling xml remote entities and billion laughs is a given. In the context of saml that's hardly the least of it. Lots of the problems are things like allowing comments to sort of change the meaning of the document, allowing signatures to sign only part of the document. Allowing multiple signatures to sign different parts of the document, etc.
- Muromec 2y agowhich is exactly the problem. if you have two parsers of the same format in a security context that show slightly different behavior (maybe in the rest 20% or maybe not) it's often enough.
- bawolff 2y agoSome of it isn't explicitly XML's fault (although it doesn't help). SAML and especially XMLSignature are terrible standards even in ways that dont involve xml.
- pvg 2y agoYou're selling XML short here, it had its own share of straight up RCEs too.
- thayne 2y agoXML could really benefit from a standardized subset that cuts out all the unnecessary features and security footguns.
- Nextgrid 2y agoI find that the "unnecessary features" and footguns are what makes XML, well, XML. I guess there must be some legitimate usage of those, or at least was back in the day. If you strip them out, you'd end up with a JSON-like (so you may as well use JSON).
- dralley 2y agoOr something like RON https://github.com/ron-rs/ron https://github.com/ron-rs/ron
- thayne 2y agoNo, you would have an extensible markup language. And json is not a good fit for markup. Now, xml has also been used for a lot of things where a hierarchical format like json would have worked better than a markup format, of which SAML would be a good example. But there are also cases where a markup format makes more sense, like svg or docbook, or odf.
- thayne 2y agoGMarkup[1] is pretty close to what I had in mind. If only it was more prevalent and had an agreed upon standard. [1]: https://docs.gtk.org/glib/markup.html https://docs.gtk.org/glib/markup.html
- derektank 2y ago>We discovered an exploitable instance of this vulnerability in GitLab, and have notified their security team GitLab has released a fix on their end for anyone else wondering https://about.gitlab.com/releases/2025/03/12/patch-release-gitlab-17-9-2-released/ https://about.gitlab.com/releases/2025/03/12/patch-release-g...
- bawolff 2y agoIts kind of annoying to explain the vulnerability in a blog post and then omit the parser differential in question. It is like writing the introduction to a story and omitting the climax.
- mdaniel 2y agoThe sibling comment's blog post <https://news.ycombinator.com/item?id=43374972 https://news.ycombinator.com/item?id=43374972> included the relevant detail: they were just doing (...//ds:DigestValue).firstChild.nodeValue without checking that .firstChild was a Node (in the offending case, it was a Comment). Thus, the non-canonical one saw the "masked" signature, the corrected one which tossed out comments saw a Node and when two implementations differ about a signed document hilarity will ensue
- bawolff 2y agoAre you sure that is the one for this blog post? i got the impression that was a different vuln for a different saml implementation. Also using comments to bypass saml is very old news. https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations https://duo.com/blog/duo-finds-saml-vulnerabilities-affectin... is a post from 2018 about it.
- mdaniel 2y agoEvidently it's not the same, sorry; it seems that I lept to conclusions with the two signature mismatch vulns by ahacker1 showing up so close to one another but opening the very tiny, very dark, code picture shows this seems to be xpath-centric, not nodeType as the workos link discussed
- blincoln 2y agoI'm guessing they didn't want to be directly responsible for dropping a zero-day that allows authorization bypass in countless systems across the planet before the parties responsible for those systems have a chance to fix them. I'm sure the specifics will come out sooner or later.
- noleary 2y agoThis is a great write-up. He's mentioned in the article, but a major shout-out is warranted for ahacker1. He's doing really sophisticated and valuable work to secure SAML implementations. We at SSOReady are really appreciative of his work. Earlier this week, WorkOS put together a nice write-up on their own collaboration with ahacker1: https://workos.com/blog/samlstorm https://workos.com/blog/samlstorm
- Diggsey 2y agoI recently had to implement SAML and this headline does not surprise me in the slightest. The SAML spec itself is fairly reasonable, but is built upon XML signatures (and in turn, XML canonicalization) which are truly insane standards, if they can even be called such. Only a committee could produce such a twisted and depraved specification, no single mind would be capable of holding and combining such contradictory ideas. It would be so simple to just transmit signatures out-of-band and SAML would be a pleasure to implement.
- jiggawatts 2y agoIt’s much worse than you’re making it sound: XML is literally an eXtensible Markup Language, so… of course the SAML standardisation committee invented their own extension mechanism language on top of it. Coming up with your own protocol on top of a protocol for a tiny amount of data amounting to not much more than what’s in an authentication cookie is the special kind of stupid that only the largest and most bureaucratic committees can produce.
- whizzter 2y agoThe SAML people aren't the most crazy ones though, the entire XML signature stuff is the insane part (You find it in other places such as xADES,SOAP,etc as well). In some misguided effort to avoid a inner-platform effect they made the decision to embed the signature in the structure itself being signed and thus enable these scenarios (needing canonical XML to verify things). For any hate JWT gets, JSON-inside-JSON,etc, at least it architecturally avoids these kinds of security issues since you verify once and only read data from what has been verified and nothing else, instead of having to re-create data and hope that the loose structure doesn't mess things up.
- deleted 2y ago[deleted]
- TZubiri 2y agoIs SSO salvageable at all? It seems like the idea of just logging into different accounts is fine. Also just the idea of connecting your accounts together such that you can get megacompromised is foundationally riskier
- wcoenen 2y agoIsn't the simpler conclusion here that one should look for the signature where it is supposed to be? Instead of using an excessively general XPath like "//ds:Signature" that might find any signature in any unexpected location...
- Muromec 2y agoHot take, but for me the conclusion always was -- get a big stick and use it to prevent web developers from touching anything near your security sensitive code. Starting from design, protocols and data formats of it. The set of habits and design considerations simply doesn't match day to day practice of the usual web development. It's often the opposite of what you need to write normal code.
- TZubiri 2y agoI don't think it's fair to blame the skill of web developers (although if they use javascript and leftpaddings they have it coming). The nature of web software is 100 times riskier than anything else because of the risk profiles and 100% connectivity
- chairmansteve 2y agoAnyone who thinks a publically accessible web site is secure is insane.
- TZubiri 2y agoI feel most responses to vulnerabilities are so lenient, you have to throw out some baby with the bathwater, you can't surgically remove the dangerous component, you gotta chop and throw chemotherapy en masse. If you are an IT admin with any pride, SAML is out of any future plans. The idea of SSO is suspect as a whole. Xml parsing has been hit twice in a week, avoid it in the future, anything wrong with a policy that replaces xml with json?
- tptacek 2y ago
- _cenw 2y agoGitHub's SAML implementation is useless. The idea is that you can bring your own account into an enterprise, and that sort of works on the site itself, but it does not prevent apps where you log in with GitHub from reading your organization membership once you have authorized an app on the organization level (and if you didn't, it hides the membership from oauth tokens, so it has this capability!). A SAML session is only required if said app fetches data via a token obtained from that user - and in my glance around, this was almost never the case - SAST tools almost always use app instance tokens and are happy to show anyone with a GitHub account in your organization your code. Tailscale fixed this when I pointed it out, Sonarcloud told me to please don't tell anyone and GitHub took a few weeks to say this is totally expected behavior - when no vendor I told did, and their docs contradicted them. I swear, reporting security bugs is a thankless endeavor, even if you just randomly stumble over them. I couldn't imagine doing this as a job.
- weard_beard 2y agoThis is the operating procedure at every conceivable level. You would not believe how difficult it is to convince young developers raised on Javascript that client side validation is not enough, much less the business owners setting out functional requirements and budgets.
- dboreham 2y ago[flagged]
- weard_beard 2y agoThey'd be fired if they spent a penny more fixing it.
- UltraSane 2y agoMusk should be fired. He has irreversibly destroyed the Tesla brand.
- 2y ago
- tptacek 2y agoSAML (more broadly XML-DSIG) is literally the worst security protocol in common use. I think you should generally be taking whatever hits you need to take to transition from it to OAuth. Certainly, I would refuse to bring a new product to market that relied on it. It's incredibly dangerous. Unless there's some breakthrough in practical formal verification, I can't imagine that this will be the last or the worst DSIG vulnerability.
- shellcromancer 2y agoSecurity Cryptography Whatever’s take on this week SAML non-sense will be fun.
- tptacek 2y agoHonestly, hadn't thought of it, but of course we should do that. Thanks!
- janderson215 2y agoI’d sub to infosec rant podcasts. $5/mo Patreon sub for a non-vtuber version.
- nimish 2y agoOne day I will write an essay on all of the incredibly stupid things XML DSig does, and that's not even touching the cryptography. It's peak enterprise software brain. Someone should go deep on the mailing list and standards body horrors of WS-* and OASIS/XACML and all that crap
- pushkar2911 2y agoPlease write about this. I would love to read it.
- akdor1154 2y agoMy (possibly misunderstood to the point of misphrasing) understanding, is that SAML still has the point-of-difference that your sso provider can cancel a session. Is that right?
- kayodelycaon 2y agoUgh. No one should use REXML unless they have no other choice. It will happily parse invalid xml, which causes an infinite number of problems downstream. It’s quite literally parsing xml using regular expressions. It’s an excellent case study for why you shouldn’t do that. Projects didn’t start using Nokogiri for performance. They used it because it’s correct.
- mtkd 2y agoOne of risks of AI code assistance is that they are not necessarily looking at the wider picture when it comes to libraries used on a large code base I was testing o3 recently and it kept changing the library used by a block of code every time it tried to fix an issue in the block that was unrelated to the library used (haven't seen that happen with Sonnet) Easy to see how issues could creep in because a modification is made that switches to an inferior library/gem that exists in the code base or standard library so still passes tests etc. but doesn't need a Gemfile change
- LtWorf 2y ago> It’s quite literally parsing xml using regular expressions. It’s an excellent case study for why you shouldn’t do that. It's like a textbook example no? Don't parse non-regular languages with regular expressions.
- wavemode 2y agoI would go further: don't parse with regular expressions. At all. They should be used for search (does this text contain something I'm looking for) not parsing (creating a syntax tree from unstructured input).
- kinow 2y agoBlueSky post with a video showing the vulnerability:https://bsky.app/profile/ulldma.bsky.social/post/3lkbi6rasl22a https://bsky.app/profile/ulldma.bsky.social/post/3lkbi6rasl2...
- GauntletWizard 2y agoSaml is insecure by design. Others have said it better before me, such as https://joonas.fi/2021/08/saml-is-insecure-by-design/ https://joonas.fi/2021/08/saml-is-insecure-by-design/, but the quote I got from an old thread here was "Sign Bytes, not meanings". Parser differentials are expected and even necessary. What you intend to get from a signed response is very meaningful. A dilemma in modern TLS is that sometimes you want to trust one internal CA; That's the easy path. Sometimes you want to accept a certificate from a partner's CA, and you've got multiple partners - and you can no longer examine just the end certificate, but the root of that chain is equally important in your decisions. This is also why I recommend whenever possible against AWS Sig algorithms; V4 is theoretically secure, but they screwed it up twice - SigV1 and SigV3 were insecure by design, and yet somehow made it past design review and into the public.
- malkia 2y agoMaybe asking stupid question, but would older versions of puppet be affected (like 6?). Also is there a site to check deps down to what maybe affected?
- TZubiri 2y agoTry dependabot? But it's a tool by github, maybe better not to depend on a self reporylt
- robmccoll 2y agoDon't use SAML, mostly because it uses XMLDSig. Don't use XMLDSig because it's hard to get usefully right and easy to get dangerously wrong.
- layer8 2y agoThis is an example of a parser mismatch vulnerability. Related submission a year ago: https://news.ycombinator.com/item?id=38743029 https://news.ycombinator.com/item?id=38743029
- fsfsd43535 2y agoInteresting vulnerability! It's a classic example of how seemingly small differences in implementation (REXML vs Nokogiri) can lead to significant security holes. Kudos to Peter Stöckli and ahacker1 for finding it! I wonder how many other libraries are vulnerable to similar parser differential attacks. It's a good reminder to be extremely careful when dealing with XML and SAML, which are complex beasts at the best of times. As asmor pointed out, Github's SAML implementation has other issues too. It seems like SAML is just inherently difficult to get right. Also, to the person who suggested not mixing personal and professional stuff in the same Github account: wise words! I've seen that cause headaches more than once.
- RainyDayTmrw 2y agoRelated: Latacora's (2019) article, How (not) to sign a JSON object[1]. In short, nesting trees and signing them is difficult and prone to pitfalls. It's easier if the envelope holds the message as a raw string, and the signing is performed on the raw string. [1]: https://www.latacora.com/blog/2019/07/24/how-not-to/ https://www.latacora.com/blog/2019/07/24/how-not-to/
- oefrha 2y agoI’m aware of the reputation of XML signatures, but it’s the first time I read about technical details, and they make my head spin. Q: Is there any non-legacy reason to use SAML instead of libsodium’s public key authenticated encryption (crypto_box)? Another Q: Is there any non-theoretical risk of parser differential when using libsodium’s cyrpto_box on one end and Golang’s x/crypto/nacl/box on the other end?
- blincoln 2y agoWouldn't using crypto_box mean the developer would have to implement their own custom authorization mechanism from scratch? i.e. it looks like a reasonably good way of exchanging encrypted messages, but I don't see anything in the docs indicating that it would provide the equivalent of group membership/roles/permissions. Building something like that as custom code is a huge commitment, and could easily result in severe vulnerabilities specific to that system.
- oefrha 2y agoI was thinking you can strip out the retarded signature protocol in SAML (replace that with libsodium) and leave the actual payload intact, or even switch from XML to a simpler wire format like JSON for the payload. But maybe even the payload part of the standard isn't worth saving, I can't tell after reading a single article about it.
- pas 2y agoOf course, but then you run into the ipv6 problem. How do you upgrade every fucking end-and-middlebox out there? The WAFs the legacy-legacy-sure-we'll-upgrade-this-quarter-oops-next-decade-again boxes that got migrated to the clouuuud (to a private cloud as a Windows Server 2003 VM of course) ... Hence the whole "enterprise" IT.
- dudeinjapan 2y agoI'm working on refactoring RubySaml right now so that it uses pure Nokogiri XML parser, which would have avoided at least one of these CVEs. It's really a mess because the current way things work RubySaml is subclassing REXML::Document, which you can't do in Nokogiri, and in the process I have found 15 year old bugs in JRuby Nokogiri, which the maintainer @flavorjones was very responsive and merged my patch. Anyway, fun times.