Vulnerability in v8

[nirapx]

Description

It seems that in v9 you fixed the vulnerability: CVE-2022-23529 Arbitrary File Write via verify function.
I'm using jsonwebtoken v8 on Node v8 (legacy system) and I can't upgrade it.
Is there a patch for this vulnerability in v8?

Environment

• Version of this library used: 8
• Version of the platform or framework used, if applicable: Node 8

[aegilops]

To trigger this "vulnerability" you would need to deserialize untrusted input and pass it straight to the verify function without validating it.

Not only that, you'd need to use a library that can deserialize functions as members of objects, which is very unusual, and it would need to preserve the case of the object property.

As long as you don't do that in your app, you cannot trigger this bug.

More details on my LinkedIn post

You do need to take more care with 8.5.1, since 9.0.0 is secure by design, but if you validate the inputs to verify and test your app then you can have some confidence - not every app built with 8.5.1 is automatically broken!

P.S. I work for GitHub, but not for the Advisory team and this is written in a personal capacity

[Uzlopak]

If you use node v8, than you have bigger security issues than what the CVE claims ;).

[TinkCai]

We're using a serverless service and the cloud provider only provides Nodejs8.9 and Nodejs10.15, so we can't upgrade it to a higher Nodejs version.
It's Nodejs10.15 with jsonwebtoken@9.0.0, when jwt.sign is called, an exception will happen.

errMsg: TypeError: Right-hand side of 'instanceof' is not an object
at Object.module.exports [as sign] (:34560/var/user/node_modules/jsonwebtoken/sign.js:108)

I'm wondering if 9.x.x can support this case.

[Uzlopak]

This is because KeyObject is added and exported in node version 11.

You could theoretically use a library like proxyquire. So e.g. in your code you do

const jwt = require('jsonwebtoken')

Instead you do

const jwt = proxyquire('jsonwebtoken', { crypto: { KeyObject: Object } })

proxyquire will manipulate the require call to crypto in jsonwebtoken and because we defined KeyObject as Object, it will return that. So the instanceof check will be not against undefined but Object.

This would also mean. that the proposed security vulnerability bugfix is basically patched out ;).

Check the performance.

[arovetto]

I agree with @nirapx, I also need the patch for CVE-2022-23529 on branch 8 without the breaking changes on v9.
Thanks

[aegilops]

You don't need such a patch though, I don't think. I agree a point release would have been sensible, even though I think it's unlikely to be necessary.

The likelihood of an app deserializing a function and passing it straight to the secret used to validate JWT is tiny - it would be a huge design flaw and entirely break the authentication model of the app.

Most JSON libraries can't even deserialize a function, and the one that can needs a non-standard config to trigger the bug.

There may be other ways to deserialize data into objects that does this, yes, but it is still very unlikely that any app would accept untrusted data as secrets with no validation.

[BrianCraig]

This vulnerability decision looks extremely arbitrary, if the parameter passed is supposedly from user input, how does it even gets evaluated? Almost every library would have the same "exploit".
This doesn't make any sense, not using eval on user input is a must in js development

[arovetto]

I agree with you all. Applications consuming the library hardly are affected by the vulnerability. However, it's hard to explain and justify with stakeholders that the software is not affected when reports assert the opposite, and also my build pipeline perform a npm audit to check for any high and critical vulnerable libraries to be updated, that now it fails.
So unless the vulnerability will be de-classed, I would appreciate a lot if you could backport to patch also on v8.
Thanks

[Uzlopak]

Good news everyone: CVE-2022-23529 got withdrawn. So need to upgrade to v9.

github/advisory-database#1595 (comment)