Regarding the security advisory: GHSA-62q6-v997-f7v9

[manugarg]

Hello @thomas-chauchefoin-sonarsource,

Thanks for reporting GHSA-62q6-v997-f7v9. I had a question for you. You mentioned in the advisory:

Attackers could execute arbitrary JavaScript code in the context of the software in which pacparser is embedded.

The impact would vary greatly depending on its use, but persistent instances of pacparser (e.g. without calls to pacparser_cleanup() between two proxy resolutions) could be forced to return arbitrary values for proxies by overriding the implementation of functions like findProxyForURL().

pacparser creates its JS context which has nothing to do with the application context that's running it. I guess at the max it can cause the proxy resolution to fail or result in wrong proxy being used. It cannot go outside of its own context. What am I missing?

[manugarg]

Also, you mention this:

The JavaScript engine currently used by pacparser is an old and unsupported version of Spidermonkey, 1.7. Vulnerabilities in this engine could allow the execution of arbitrary code on the host on which pacparser is running. We are aware of enterprise security products embedding pacparser and running as root, in which case attackers could elevate their privileges. We are aware of several memory corruption vulnerabilities in this version of the software, but we didn't (yet) leverage them to obtain arbitrary code execution.

Are you aware of memory corruption vulnerabilities in Javascript engine or pacparser?

[thomas-chauchefoin-sonarsource]

Hey! Thank you for your work on this issue.

pacparser creates its JS context which has nothing to do with the application context that's running it. I guess at the max it can cause the proxy resolution to fail or result in wrong proxy being used. It cannot go outside of its own context. What am I missing?

By "context", I mean that if someone executes arbitrary code by first injecting JavaScript and then exploits a vulnerability in SpiderMoney, they can compromise the application that uses pacparser as a library. I'll be happy to update the advisory if somneeds to be clarifiedunclear.

Are you aware of memory corruption vulnerabilities in Javascript engine or pacparser?

SpiderMonkey. Now that the JavaScript injection is fixed, it's much less of a problem–the PAC file is likely always trusted.

I feel like we should use the GitHub Advisory to request a CVE, pacparser is a dependency of many projects and they should be made aware of the new security release?

[manugarg]

By "context", I mean that if someone executes arbitrary code by first injecting JavaScript and then exploits a vulnerability in SpiderMoney, they can compromise the application that uses pacparser as a library. I'll be happy to update the advisory if somneeds to be clarifiedunclear.

This is what I am confused about. JS Context that pacparser creates is not exposed to the caller program -- since its unexposed, this context cannot have any other user data (only any injected data, pacfile, url, host). Whatever arbitrary code someone manages to run, will run in the same unexposed context. At the most someone can cause denial of service by making the context/script take forever, thus impacting the "availability". I think "confidentiality" and "integrity" impact should not be there. Does that make sense?

[thomas-chauchefoin-sonarsource]

Whatever arbitrary code someone manages to run, will run in the same unexposed context.

By running JavaScript code with the injection bug (in the context of SpiderMonkey), it can exploit memory corruptions in SpiderMonkey to break out of the engine and execute "native" code instead (in the context of the program).

[thomas-chauchefoin-sonarsource]

I updated the advisory to clarify what we discussed in this thread.

I feel like we should use the GitHub Advisory to request a CVE, pacparser is a dependency of many projects and they should be made aware of the new security release?

I still think that a CVE should be requested, what's your opinion on this point?

[thomas-chauchefoin-sonarsource]

For the record, MITRE assigned CVE-2023-37360 to this bug.