Address dependabot alerts #37

New Issue

2023-03-31T12:55:37Z

dboreham commented

2023-03-31 12:55:37 +00:00

Current alerts:

d3-color vulnerable to ReDoS (not at thing)
This is something about DoSing the browser process through specifying bad color space data. Doubtful that we are vulnerable since we do not allow color space data to be supplied externally. There is an update fix but dependabot doesn't know how to make the update due to transitive dependency issues. So a developer would need to figure that out. We may also no longer use the code path upon which this dependency arises.
Server-Side Request Forgery in Request (perhaps a thing, maybe)
This is about our use of the request http client library. The vulnerability is that if we use that library to perform an http get from some server controlled by an attacker, they can cause the library to transparently make a new http get request against some host like localhost, which might be a vulnerable server owned by us. Whether this is actually exploitable is not clear to me: I'm not sure if we make http requests to URLs supplied from outside. There is not currently a simple update fix. There's an unmerged fix, and used in as a patch in Metamask here.
Insufficient Granularity of Access Control in JSDom (not a thing)
This appears to be a bogus CVE in that the complaint is that JSDom (library that allows emulation of a browser's DOM processing in a Node.js process) will load the DOM data from a file on the local filesystem if you ask it to do that. This seems like a nothing burger because the code doing the asking could just as well go ahead and open the file, since Node.js allows that. JSDom maintainers closed the issue, disputing the validity of the CVE and citing documentation as adequate. Dependabot believes the problem is fixed in a newer version of JSDom, but again fails to provide an easy update fix. There is a comment on the issue suggesting that this conclusion by Dependabot is a false negative -- the problem was never addressed, although perhaps JSDom's interface was extended such that if the application wanted to filter resource load requests, it could filter out any local file loads. Since application code would need to be modified to enable this, simply updating the version wouldn't fix any vulnerability but it would shut up Dependabot.

Current alerts: * [d3-color vulnerable to ReDoS](https://github.com/cerc-io/laconic-console/security/dependabot/116) (not at thing) This is something about DoSing the browser process through specifying bad color space data. Doubtful that we are vulnerable since we do not allow color space data to be supplied externally. There is an update fix but dependabot doesn't know how to make the update due to transitive dependency issues. So a developer would need to figure that out. We may also no longer use the code path upon which this dependency arises. * [Server-Side Request Forgery in Request](https://github.com/cerc-io/laconic-console/security/dependabot/134) (perhaps a thing, maybe) This is about our use of the `request` http client library. The [vulnerability ](https://github.com/nodejs/undici/issues/2019)is that if we use that library to perform an http get from some server controlled by an attacker, they can cause the library to transparently make a new http get request against some host like `localhost`, which might be a vulnerable server owned by us. Whether this is actually exploitable is not clear to me: I'm not sure if we make http requests to URLs supplied from outside. There is not currently a simple update fix. There's an [unmerged fix](https://github.com/request/request/pull/3444), and used in as a patch in Metamask [here](https://github.com/MetaMask/metamask-extension/pull/18208). * [Insufficient Granularity of Access Control in JSDom](https://github.com/cerc-io/laconic-console/security/dependabot/101) (not a thing) This appears to be a bogus CVE in that the complaint is that JSDom (library that allows emulation of a browser's DOM processing in a Node.js process) will load the DOM data from a file on the local filesystem if you ask it to do that. This seems like a nothing burger because the code doing the asking could just as well go ahead and open the file, since Node.js allows that. JSDom maintainers [closed the issue](https://github.com/jsdom/jsdom/issues/3124#issuecomment-783502951), disputing the validity of the CVE and citing [documentation ](https://github.com/jsdom/jsdom#loading-subresources)as adequate. Dependabot believes the problem is fixed in a newer version of JSDom, but again fails to provide an easy update fix. There is a comment on the issue suggesting that this conclusion by Dependabot is a false negative -- the problem was never addressed, although perhaps JSDom's interface was extended such that if the application wanted to filter resource load requests, it could filter out any local file loads. Since application code would need to be modified to enable this, simply updating the version wouldn't fix any vulnerability but it would shut up Dependabot.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/laconic-console#37