1. connect2id Avatar connect2id
  2. Crypto
  3. Nimbus-JOSE-JWT
  4. Issues

Security changelog

Issue #168 open
Vít Šesták created an issue

An unfortunate fact: Many libraries have some known vulnerabilities in their older versions. Nimbus-JOSE-JWT is not an exception. (See #23, #50 (?), #91, #107 and #122.)

Another unfortunate fact: Developers often don't upgrade the libraries, because:

  1. They don't know there is a reason for upgrade.
  2. They don't want to break the application by upgrading to a newer version.

As a result, there are many applications using libraries with outdated versions with known security issues. Please help resolving this issue for your library.

Is there any vulnerability info on our website?

I haven't found one. The tickets I've found were found by manual search of issues (except #107 – I found this one by manual code review a subsequent looking in commits). Such info could help with question like “Do I have to upgrade the library? Is the library version we are using still supported? Does upgrading to version X resolve the security issues?”

Are those known vulnerabilities pushed to a vulnerability database?

I've checked NVD (National Vulnerability Database) and haven't found any item for this library. An entry in NVD allows automated scanners like OWASP Dependency Check to inform developers that they are using a vulnerable library.

What are costs of an upgrade?

An actively developed library might sometimes introduce a BC-break. Can I upgrade from version X to version Y without worrying about breaking things?

Versioning scheme (like semantic versioning) might help. Some changelog with list of BC breaks might also help.

Responsible disclosure

That is the preferred way a vulnerability researcher can start a private discussion in a way that follows responsible disclosure? Is contacting support OK in this case? (This point seems to be probably rather OK, but a dedicated security contact might be better.)

Comments (11)

  1. Vladimir Dzhuvinov
    • changed status to open

    Hi Vit,

    You're the first person who has shown concern on those points, so that's welcome :)

    We use this place for tracking vulnerabilities. You're right that this info isn't exported to the online docs page. We've been thinking for about a month now how to feed selected bits of tracker info into the online docs (a site that runs on PHP / Statamic). I would very much like to automate this, as doing things manually is expensive and error prone. If you've got an example (links) how such a sec changelog ideally looks like, just let me know.

    The NVD has not been considered. I really wonder how many people actually use it, if not mandated by US gov legislation (our company is based in Bulgaria). Anyway, that's not a reason not to consider it.

    On BC upgrades I added this to the FAQ: http://connect2id.com/products/nimbus-jose-jwt/faq#bc-upgrades

    Basically, you're safe, as BC is never called directly, everything (as of v4) is routed via JCE.

    We also updated the lib page on responsible disclosure: http://connect2id.com/products/nimbus-jose-jwt/contribute#responsible-disclosure

    Cheers,

    Vladimir

  2. Vít Šesták reporter

    Hello, thank you for the fast response.

    The issue tracker is a reasonable place to track vulnerabilities, but it is hard to use right now. For example, I probably would not be able to find #107 if I did not discover the vulnerability independently. (This was actually the initial impulse for further investigation.) There is no general keyword like “vulnerability” or “attack” (and the related commit message contains a typo…) in the issue, so it is currently hard to make queries like “Do I have to upgrade the library? Is the library version we are using still supported? Does upgrading to version X resolve the security issues?”.

    An example of security changelog, including a dedicated mailinglist: https://www.playframework.com/security/vulnerability

    NVD is used both by publishers and subscribers. It is the largest vulnerability database I know. It is used it various tools like OWASP Dependency Check, Veracode Scanner or Nexus. (Nexus also uses OSVDB, but this one requires paid access for automated use.) The company I work at uses OWASP Dependency Check, so we are using NVD: https://www.ysofters.com/2015/12/01/owasp-dependency-check-at-ysoft/ (By the way, we are in Czech Republic, not in USA. And I have no idea if US companies are legally mandated.)

    There is a little confusion on “BC” – I mean “backward compatibility”, you probably mean “BouncyCastle”. I am sorry I did not realize the ambiguity.

    Thank you for adding the responsible disclosure note.

  3. Vít Šesták reporter

    Hello, what's the current status? Thank you for adding a note about responsible disclosure and considering a changelog, but the following three issues seem to be still not addressed:

    • Is there any vulnerability info on our website?
    • Are those known vulnerabilities pushed to a vulnerability database?
    • What are costs of an upgrade? (Backward compatibility…)
  4. Connect2id OSS

    We ask for patience, it will take us some time to set this up properly :)

    Thanks for the pointers!

  6. Daniel Marthaler

    I would also like to see NVD entries when critical bugs have been discovered. As we also use a OWASP dependency checker in our builds. This would help a lot.

  7. Vladimir Dzhuvinov

    At long last. Added security change log with those entries from the general change log which refer to vuln fixes: cddc85b

    Thanks to Quan Nguyen (Google sec) we now also have CVE's allocated for recent (2017) issues.

    Still to do: NVD

  10. Vladimir Dzhuvinov

    Got this response back:

    Thank you for your email and interest in contributing CPE content to the NIST CPE Dictionary.

    Approximately how many entries are you looking to send to NIST?

    The current process for adding new entries to the CPE Dictionary is to submit an XML formatted list of CPE entries to the cpe_dictionary@nist.gov mailing list. Each CPE name entry needs some sort of provenance data which can include simple HREF links to authoritative (preferably vendor) information, etc. that justify the instantiation of the name in the Dictionary (typically embedded within the file as an XML comment). The entries are then analyzed and normalized with existing CPE name entries in the Dictionary. If any CPE name entries in a submission are modified, a response is first sent to the submitter to verify that the changes are acceptable. Once an agreement is made the entries are added to the dictionary and will appear in the next nightly generation of the CPE feed. The process is currently conducted largely via email, but a new web/rest submission process is in the works as well.

    Specifics for the xml file and CPE names can be found in the CPE 2.3 specifications:

    And is summarized a little bit here:

    https://nvd.nist.gov/cpe.cfm

    Please let us know if you have any additional questions or comments and we look forward to assisting you in processing your name(s) submission.

    Thank you,

    Mase Izadjoo National Vulnerability Database National Institute of Standards and Technology nvd.nist.gov

  12. Log in to comment
Assignee
–
Type
bug
Priority
major
Status
open
Component
Documentation
Milestone
–
Votes
4
Watchers
7
Jira: the preferred issue tracker for Bitbucket. Join the team!