denial of service and may lead to remote code execution vulnerability about cache-base HOT 18 CLOSED

Hi Brian (@doowb) after our additional discussions and review regarding this issue, we have agreed that there is no vulnerability here, and that you are indeed sanitizing the key value correctly within set-value package dependency.

Thanks for your assistance in resolving this, it is much appreciated!

from cache-base.

@snipem our comments crossed paths. There is a vulnerability remaining in this library although it's possible the existing CVE will be rejected and a new one issued for get-value instead. And yes, @danielelkabes is a security researcher at WhiteSource

from cache-base.

Hi Brian (@doowb) after our additional discussions and review regarding this issue, we have agreed that there is no vulnerability here, and that you are indeed sanitizing the key value correctly within set-value package dependency.

Thanks for your assistance in resolving this, it is much appreciated!

@danielelkabes Are you with Whitesource? Can we expect that you revoke the CVE and will not alert any further findings with Whitesource code checks?

from cache-base.

Thank you @danielelkabes for looking into this further.
Thank you @sokra for the additional PoC when getting a value.
@rarkins I agree that this is something different, should be discussed separately, and patching any issues in dependencies is a better approach.

I'm going to close this issue and we can discuss get-value there.

from cache-base.

@rarkins Wow that was quick. Our on-premise installation removed the vulnerability just minutes after our discussion. Thanks.

from cache-base.

Please provide some code to demonstrate/reproduce the issue you're having.
The links that you provided either don't contain any information or require signing into another service.

from cache-base.

I think like others we only get the notification that there is a problem with this line 71 described in mdeknowis post.
The cve link works.

Whitesource: https://www.whitesourcesoftware.com/vulnerability-database/
there you can search for cve-2020-28275

But there are no more informations :(

from cache-base.

Thanks @BLoeT.
When searching whitesource, I found the cve and they have a section with "PoC Code", however, that code does not demonstrate a security issue (the underlying library that handles "set" takes into account keys with __proto__, so the Object prototype is not modified).

Since the PoC Code doesn't actually show checking another object to see if the prototype has been modified, this shouldn't be a valid issue:

const Cache = require('cache-base');
const cache = new Cache();
const anotherObject = {};

cache.set('__proto__.polluted', 'true');
console.log(anotherObject.polluted);
// undefined

If this was a valid security issue, then anotherObject.polluted would be 'true'.

//cc @whitesource @rarkins how do we get this addressed in the whitesource database?

from cache-base.

Hi Brian (@doowb) we are trying to reach you and your team for the past two months, please check your mail and spam, there you can find a detail report, we can discuss this issue and figure out together what should be our next steps.

@BLoeT at this time you can see the details about this vulnerability here - https://www.whitesourcesoftware.com/vulnerability-database/CVE-2020-28275 . and here https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28275

Thanks,

from cache-base.

@danielelkabes please see the comment above. The underlying set-value package does proto checking: https://github.com/jonschlinkert/set-value/blob/master/index.js

from cache-base.

@danielelkabes I found your email from today and responded.

I never received the original email with a report, so I'm not able to speak to anything other than what's in the linked CVE. If there is more, I'm happy to have a discussion so we can create a reproducible test case and provide a fix.

@rarkins thank you for pointing to set-value (I just realized I didn't actually link to it 😄 )

from cache-base.

It'd be great if a potential patch could be backported to older versions, including v1. Our project refers to [email protected] via chokidar v3, which is in turm coming from pretty recent babel and watchpack versions. 🙏

from cache-base.

Here is a repro which allows to pollute the prototype:

const Cache = require("cache-base");
const c = new Cache("cache");

const key = "__proto__"; // <- This need to be user controlled
const entry = c.get(key);
entry.hello = "polluted";

console.log({}.hello);

from cache-base.

@sokra that prototype pollution appears to come from get-value. Repro: https://runkit.com/embed/ndj8wjcvv55q

Both v3 and v4 of cache-base depend on get-value@^3.0.1 so any fix published there (e.g. [email protected]) would then make this library non-vulnerable.

@danielelkabes will assess whether to update the description of the existing CVE or if it's more appropriate to issue a new one

from cache-base.

Note there are a few more related (security) issues:

• new Cache("__proto__") sets the prototype of the instance, which removes all methods and set/get etc throw errors.
• similar problems with new Cache("constructor") or new Cache("set"), etc.
• c.get("hasOwnProperty") should probably not return the function on Object.prototype
• c.has("hasOwnProperty") should probably not return true for the function on Object.prototype
• some older cache-base versions allow to omit prop and set all entries directly on the Cache instance, which allows to c.del("__proto__.set"), c.del("constructor.prototype.set") to break all cache classes.
• c.set("xxx", {}); c.set("xxx", { __proto__: ... }) allows to modify the prototype of the object, which could break stuff
• c.set("hasOwnProperty", 1) and c.set("__proto__", 1) crashes. see this line (id can be a bad value)

from cache-base.

@sokra I agree with you that there are some other bugs/issues. I don't believe all of those are necessarily security related due to the difference in developer/implementor vs user supplied inputs.

Also, PRs are welcome with fixes for these bugs ;)

from cache-base.

any update on resolving this? still being reported via npm

from cache-base.

I'm not sure which DB npm uses but the CVE has been rejected officially: https://nvd.nist.gov/vuln/detail/CVE-2020-28275

I also don't see it here: https://www.npmjs.com/advisories

from cache-base.