‼️ SAML Privilege Escalation via PySAML2 ‼️

[arikfr]

Thanks to responsible disclosure from @yabeow and @aphtrinh from Calif, we became aware of a critical security vulnerability for Redash deployments that have SAML enabled.

If you have SAML enabled, it is essential that you follow the proposed mitigation steps as soon as possible.

For more information, please see the Security Advisory.

[majormoses]

I want to say that I am glad that this is finally being addressed. However I am dismayed that this is not the first time this was actually reported as claimed, this was properly disclosed years ago with a submitted patch to update the dependency. The maintainers chose not to patch the known CVEs at the time, with no indication as to why.

Defects are to be expected. It is how we choose to handle the defects that establishes and loses trust/credibility. My org has made the decision that this is not something we are willing to further gamble on. I highly recommend other organizations abandon this project until it finds new leadership who can reestablish trust that they address security issues as a priority. I do not yet see any accountability or game plan on how things will be different this time.

[arikfr]

I believe I close multiple Dependabot PRs on that day because I didn’t have the resources to check the implications of those updates. This one was unfortunate because of the severity of the issue vs. ease of fix, but hindsight is always 2020. If the report wasn’t automated, it would’ve been considered more seriously, as we done with the most recent report.

As for game plan on how things will be different, this is the purpose of the other announcement (#5962). The plan is to update the CI and update all dependencies so we can start from a clean slate. If those who use the project don’t step up to maintain it, this kind of issues will keep happening. So you can either abandon the project, or you can actually help it.

[majormoses]

👍 for trying to get the community to help out 👎 for not taking accountability and making excuses. We have noticed the decline in quality over the years and this was simply the straw that broke the camels back in our case. In a sense we are grateful it was neglected to this extent, as it gave us the justification to entirely replace it. This is not isolated, there still are multiple open CVE's that have been reported and closed "because too busy". Even weeks after being being disclosed again there is still not a released version with a fix, forget making CI work. Get a release built locally if you have to, protecting your users should be your number one priority! CI is the next step once you have remediated the immediate concerns.

[wlach]

This feels pretty uncalled for. Redash has been an amazing gift to the world, and I'm grateful for it. @arikfr and others have been generous enough to continue to try to maintain redash, even though it's obviously not their primary gig anymore. With something as complex as this, issues like this are pretty much bound to come up: I don't think anyone could have done any better. I guess you could argue that there should be more of a warning on the tin that this software isn't under active development, but I think that's pretty obvious to anyone paying attention to the release history.

P.S. I opened a few PRs which I think/hope might be enough to get CI working again. It would be great if we could spin a new release with this fix + whatever else has landed since the last one (or at least update the preview images on https://hub.docker.com/u/redash, which my company uses):

#6037
#6038