CVE in ag-auth dependency

[inaz0]

Hi,

I'll seen you are using the ag-auth package in your code but recently an Security Vulenrabilities was found in jsonwebtoken used by ag-auth.

But ag-auth was not upgrade since 4 years...

Did you plan to remove ag-auth and replace it by non obsolete package ?

Detail of CVE : https://thehackernews.com/2023/01/critical-security-flaw-found-in.html

[MegaGM]

TL;DR As long as you use standard AuthEngine, which is shipped with socketcluster by default, your application is not affected by CVE-2022-23529

1. First I've tried to reproduce the CVE-2022-23529 with minimal requirements.
   Indeed it is reproducible with currently used jsonwebtoken@8.5.1 and is not reproducible with jsonwebtoken@9.0.0

npm i jsonwebtoken@^8.3.0
touch index.js

const jwt = require('jsonwebtoken')
const token = jwt.sign({ username: 'Alice' }, 'qwerty')
const maliciousArgument = {
  toString: () => {
    console.error('CVE-2022-23529 is reproducible')
  },
}
jwt.verify(token, maliciousArgument)

2. Then I've inspected jsonwebtoken.verify method and it seems CVE-2022-23529 is possible to exploit only by using the specific function signature, when you substitute the second argument secretOrPublicKey with an entity containing toString method.

jwt.verify(token, maliciousArgumentInsteadOfSecretOrPublicKey[, options, callback])

It's possible because toString is casually called within jsonwebtoken.verify

options.algorithms = ~secretOrPublicKey.toString().indexOf('BEGIN CERTIFICATE')

3. Then I've (re)inspected closely the usage of jsonwebtoken by maintained versions of socketcluster

• socketcluster-server@14.7.2
  uses AuthEngine.verifyToken of sc-auth@5.0.2 in SCServer._processAuthToken

• socketcluster-server@17.1.0 uses AuthEngine.verifyToken of ag-auth@1.0.1 in AGServerSocket._validateAuthToken

Neither sc-auth nor ag-auth allow usage of the vulnerable signature of jsonwebtoken.verify function, which is required to exploit the CVE-2022-23529.

4. To be double sure I've tried various ways to forge a malicious token, then to feed it to jsonwebtoken, as well as to its underlying jws library.
   It turns out to be possible to feed a malicious Buffer instead of legitimate token to jws.verify
   Because jws.verify uses toString in multiple places within its flow.

const maliciousBuffer = Buffer.from('abc')
maliciousBuffer.toString = () => {
  console.error('CVE-2023-????? is reproducible')
  return 'xyz'
}
jws.verify(maliciousBuffer)

This could have been avoided if jws wouldn't use toString directly.

const unsafe = maliciousBuffer.toString()
const safe = Buffer.prototype.toString.call(maliciousBuffer)
console.info('unsafe', unsafe) // xyz
console.info('safe', safe) // abc

Fortunately, type checks in jsonwebtoken.verify prevent such kind of tampering with the token argument before it reaches underlying jws library.
It seems very improbable to exploit the vulnerability by forging JSON Web Token itself.

5. I've thought hard of any possible ways to exploit the CVE-2022-23529 against socketcluster@14 or socketcluster@17 applications.
   The only scenario I came up with is when you create a custom-build AuthEngine, deliberately use vulnerable jsonwebtoken.verify function signature, and feed it untrusted arguments.
   Honestly, who in the world would do that? 🔥 👀

@SocketCluster/core IMO CVE-2022-23529 seems too far-fetched. However, since jsonwebtoken@9.0.0, apart from CVE-2022-23529, also fixes CVE-2022-23539, CVE-2022-23540, CVE-2022-23541, I guess we still should consider bumping its version in the near future. Maybe after it'll become v9.0.1 or so.

@inaz0 Fortunately, socketcluster is not affected. Nevertheless, thank you very much for taking your time and reaching us out!

[jondubois]

@MegaGM Thanks for posting this detailed analysis. I'll try to bump up the jsonwebtoken version number anyway to make the warnings go away.

[MegaGM]

Sure. I'll make issues in the respective repos as a reminder