Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

mattermost.com

Post reply on HN
Print view View original

81–90 of 115 posts

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#81

Post by KajMagnus »

zwass wrote: post #57
russell_h wrote: post #56

I'm the maintainer of one of the affected SAML libraries. People need to stop using SAML. This needs to be a priority. A little background, for those who haven't had the displeasure of working with it: When a user wants to log into an application (the "Service Provider"), and is required to SSO against an "Identity Provider", the Identity Provider basically generates an XML document with information about the user, t…

As a service provider, are there viable alternatives to support SSO in an application?

OpenID Connect, like others mention, but there's more in life, than only SSO? Organizations also want to automatically deactivate of user accounts?

There's something called SCIM, "System for Cross-domain Identity Management", that does this, and which you can use together with OpenID Connect (OIDC).

SCIM can automatically deactivate a user account, if the person leaves the organization or moves to a different department. And can auto add and remove him/her to/from various user groups.

But with SAML, managers / admins still need to micro manage the user accounts, e.g. place the user in the correct group, if s/he gets a new job role. SAML only syncs user accounts upon login, from what I've understood. (So if the user stays logged in, then, with SAML, his/her account permissions can get out-of-date?)

SCIM: https://docs.microsoft.com/en-us/azure/active-directory/app-...

Azure AD uses this, and Okta, OneLogin, Github and some others too I suppose.

If anyone has tried SCIM it'd be interesting to hear what you think about it? (I've just read about it)

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#82

Post by KajMagnus »

ucarion wrote: post #60
zwass wrote: post #57

Earlier quoted context omitted.

As a service provider, are there viable alternatives to support SSO in an application?

Depending on who your customers are, you might get away with only supporting OIDC. But not supporting SAML is going to be a problem as you move into the big enterprises. Many big companies run on SAML, and expect to auth with vendors over SAML. That's why russell_h's comment is probably futile; it's the enterprises with the big SaaS budgets that keep SAML relevant, and they don't care if HN doesn't like it. Maybe in…

What about SCIM, "System for Cross-domain Identity Management", instead of SAML, if creating software for enterprises?

SCIM: https://docs.microsoft.com/en-us/azure/active-directory/app-...

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#83

Post by tptacek »

jupenur wrote: post #77
tptacek wrote: post #75

Earlier quoted context omitted.

I share your opinion of SAML, but I have to ask, as someone who has also implemented it in Golang: what gave you any confidence in an implementation backed by encoding/xml? It was to me immediately pretty obvious that DSIG and encoding/xml aren't a fit, if only because of encoding/xml's poor namespace support. There are other DSIG Golang libraries that use an etree-style interface for what I presume is the same reaso…

Blog author here; Russell's implementation is backed by github.com/beevik/etree, but like you said, it's just an interface. The tokenizer is still encoding/xml. Adding better support for namespaces and providing APIs compatible with dsig doesn't remove the underlying vulnerabilities.

Ugh. That's disappointing. I loathe SAML, but also think the right thing to do here is to make sure nobody uses encoding/xml as part of their SAML stack.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#84

Post by GauntletWizard »

I'd like to ask everyone here who's familiar with SAML to take a look at SPIFFE[1], which underlies Istio.

I'm biased in this regard, but I view SPIFFE's inclusion of JWT Tokens as an authentication method as fundamentally flawed - By allowing bearer tokens, you are no longer verifying identity, but passing identity around. JWT has also been susceptible in the past[2] to the same kinds of attacks here - Poorly defined verification semantics.

I suspect that buried in the semantics around SPIFFE's SPIRE Server and Agent are a number of vulnerabilities or other ways that trust doesn't mean quite what you think it means. I'd love for someone with interest to take a look. Besides the obvious downsides fundamental to Isitio's MITM Proxy architecture, I think there's more lurking on that edge.

[1] https://spiffe.io/ [2] https://auth0.com/blog/critical-vulnerabilities-in-json-web-...

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#85

Post by KajMagnus »

xyzzy_plugh wrote: post #38
tptacek wrote: post #10

Earlier quoted context omitted.

It's a little-loved library in the standard library that wasn't designed to support cryptographic security, but was by many projects repurposed as such to support SAML. It was a mistake for any SAML project to depend on encoding/xml.

I don't doubt it was a mistake, but I'm curious what the alternative is here? I'm looking to add SAML to my to project in the medium-term.

> I'm looking to add SAML to my to project in the medium-term

Did you hear about SCIM, "System for Cross-domain Identity Management"? If combining with OIDC, then, seems to me one gets a more modern alternative to SAML. I've read just a bit about SCIM though.

SCIM: https://docs.microsoft.com/en-us/azure/active-directory/app-...

I wrote more in this comment: https://news.ycombinator.com/item?id=25425665

(What's your project about?)

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#86

Post by nine_k »

russell_h wrote: post #56

I'm the maintainer of one of the affected SAML libraries. People need to stop using SAML. This needs to be a priority. A little background, for those who haven't had the displeasure of working with it: When a user wants to log into an application (the "Service Provider"), and is required to SSO against an "Identity Provider", the Identity Provider basically generates an XML document with information about the user, t…

I wonder how hard would it be to adopt some SAML 2.0 (or maybe just 1.x) with this, and maybe a few other problematic bits updated, but otherwise unchanged? Do you think the rest is worth keeping?

E.g. we did not stop using TLS when TLS 1.0 proved to have problems; we updated the cryptography and kept using the logic.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#87

Post by tedunangst »

userbinator wrote: post #76
tedunangst wrote: post #7

I've never liked (nor understood the popularity) of signature schemes that require parsing before verification. This has also led to problems with X.509. And DKIM. And plists. And package managers. And more. It's much simpler to sign the entire message, unparsed, and it's immune to these issues. We went through a decade of debate before deciding that "encrypt then mac" is the only right way to do things. That knowled…

This has also led to problems with X.509. Could you explain more about this? I thought the whole point of ASN.1 DER was to have only one canonical representation for a given structured value, and that the signing was done as-is on the sequence of bytes directly. It definitely doesn't have the same problems as XML and other text-based formats.

Overshoot on my part. I was thinking of problems like those in https://arxiv.org/abs/1812.04959, but that's a different problem.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#88

Post by ByteJockey »

nine_k wrote: post #86
russell_h wrote: post #56

I'm the maintainer of one of the affected SAML libraries. People need to stop using SAML. This needs to be a priority. A little background, for those who haven't had the displeasure of working with it: When a user wants to log into an application (the "Service Provider"), and is required to SSO against an "Identity Provider", the Identity Provider basically generates an XML document with information about the user, t…

I wonder how hard would it be to adopt some SAML 2.0 (or maybe just 1.x) with this, and maybe a few other problematic bits updated, but otherwise unchanged? Do you think the rest is worth keeping? E.g. we did not stop using TLS when TLS 1.0 proved to have problems; we updated the cryptography and kept using the logic.

But the problem here isn't he encryption. Well, for all I know, the encryption could be completely broken, I'm not a crypto-expert.

But the problem described in the post wasn't the encryption. It was the logic. Specifically the order that things are done in. Parsing something before verifying it can be dangerous.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#89

Post by pabs3 »

zwass wrote: post #57
russell_h wrote: post #56

I'm the maintainer of one of the affected SAML libraries. People need to stop using SAML. This needs to be a priority. A little background, for those who haven't had the displeasure of working with it: When a user wants to log into an application (the "Service Provider"), and is required to SSO against an "Identity Provider", the Identity Provider basically generates an XML document with information about the user, t…

As a service provider, are there viable alternatives to support SSO in an application?

If the user interface for TLS client certificates were not so consistently terrible across all browsers on all platforms, I would suggest them.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#90

Post by koolba »

hnarn wrote: post #47
dboreham wrote: post #39

Earlier quoted context omitted.

I believe the problem being addressed is where the payload may be transcoded in flight or otherwise not delivered in exactly the same form. Put another way: the signature validates the payload, however it may end up being represented to the validator on delivery. It isn't simply a transport integrity measure.

I might be missing the point here, but isn't the whole idea of signing a message that it should not be possible to "transcode the message in flight"? If you even allow the message to be "not delivered in exactly the same form" in the first place, you're introducing an attack vector completely without reason, because what you instead could do is let the payload be strongly signed and unchanged, and then have differing…

Yep and it’s even worse because the signing and encryption involves XML transforms to canonicalize the source prior to verifying them. So you force the recipient to not only validate a potentially transformed message, but they have to transform it again too!

It’s the perfect intersection of precarious and deranged.

Post reply on HN