High Severity Security Vulnerability - Access Restriction Bypass
Opened this issue · 20 comments
Snyk is logging a high severity security vulnerability with this repo here. I believe this is called out in Issue #442 and a fix was implemented in #426 but the PR was closed. Would it be possible to address this? A high severity vulnerability, in a library of this nature, means it is currently unsuitable for enterprise projects. Thanks.
this is already covered on this issue #422
and there's an open pr from March 3rd here: #385 that would fix this.
I closed my PR because I forgot I had used the same branch when adding fixes for our company OSS fork where we will be patching and releasing form3tech-oss#2 and by branch included some changes required for our CI
we have published our fix here: https://github.com/form3tech-oss/jwt-go/releases/tag/v3.2.1 FYI
Has anyone requested a CVE for this issue? If not I'm happy to.
This is what iv been working from https://snyk.io/vuln/SNYK-GOLANG-GITHUBCOMDGRIJALVAJWTGO-596515
maybe time to create a dedicated org for this project and for it there? So the only place with the fix isnt related to some company but rather a independent group those interested in this project can look after it?
maybe time to create a dedicated org for this project and for it there? So the only place with the fix isnt related to some company but rather a independent group those interested in this project can look after it?
+1 to this. I'm currently implementing some security packages and while I'm heavily reviewing all the available options this repo has a lot of traction and an API I really like, albeit in an abandoned state (i.e: no go modules definition yet). If the maintenance goes back on track I can see myself using this and contributing back to
Also as a side note, this repo is the first golang option on jwt.io, so the extra exposure should warrant more care on the maintenance status
CVE-2020-26160 has been assigned to this issue.
So there seems to be a lot interest in creating a sperate organisation for this repo. I don't know how we'd go about doing this or how such a thing would be structured, does anyone have thoughts about steps to doing this?
I am especially interested in thoughts from @dgrijalva to see if this would carry his consent
@ripienaar The maintainer hasn't replied to this bug since it was first filed in July. I've switched over to the form3 fork, but I've been unable to persuade my project's dependencies to switch. Some projects want to switch to https://github.com/square/go-jose instead
I know he hasnt responded, but we wouldnt want to do essentially a hostile takeover without reaching out, so in the absense of that, I think we need to discuss how to make a org and who would be willing to work on it.
I understand, but I've reached out to him on email and twitter a few weeks ago.
I'll ask my work if we could maintain a fork. I notice that Google, Apache and Microsoft are on the list of who imports this, I wonder if they'd be interested in maintaining this.
You're well within your rights (under the terms of the license) to fork the code into a project with a new name (as not to infringe on the trademark) and to maintain/merge fixes there.
It will become a new project, and perhaps if @dgrijalva picks up the project again, he may consider merging the improvements back in.
There's plenty of interest in setting up a forked version of this project, there isn't an obvious deadlock here that would prevent that. I am consuming this library in a number of places and will switch over to the Form3 form in the interim period.
Andy Randall from Kinvolk suggested contacting Dave via LinkedIn. He also has an email address on his profile.
Has anyone done this yet? If not, would one person be open to contacting him for response?
You're well within your rights (under the terms of the license) to fork the code into a project with a new name (as not to infringe on the trademark) and to maintain/merge fixes there.
@alexellis as you mention, there is already a fork in place by form3, which can be used as a temporary workaround. The Issue is, this 'module' (in the broad sense, because there isn't even a go.mod file yet in here) is the main one and fragmentation can be a PITA from a process viewpoint with security packages, because this one may be already audited and being used at companies following PCI DSS standards (just to name an example) and I'm not certain forks are freely allowed without a full re-audit
In my case, as fortunately the design allows it, I can still use this main module with the forked and fixed Claims implementation, but the ideal scenario would be for Dave to create an organization and concede control of the repo if he is no longer able or interested on maintaining it so the aforementioned issues can be subverted and development continue
The fix appears to be provided and ready to be merged per the fix mentioned by @brianmay above. This issue is a security issue for us downstream. Is there any update on whether it will ever be merged?
To solve this (and bunch of other problems) I've created another JWT lib. Feel free to check it https://github.com/cristalhq/jwt
Hello! For the snyk issue @camin-mccluskey mentioned, is 4.0.0-preview1 the latest fixed version? Will there be a fixed latest version outside of preview?
Thanks