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 read a bit of the code.
And I believe I've found a vulnerability:
For example consider this:
const { StaticPool } = require("node-worker-threads-pool");
const staticPool = new StaticPool({
size: 1,
task: (n) => {while(n){console.log("a");}
return n;
},
timeout:10
});
staticPool.exec(0).then((result) => {
console.log("result from thread pool:", result); // result will be 0.
});
staticPool.exec(1).then((result) => {
console.log("result from thread pool:", result); //will never return
});
staticPool.exec(0).then((result) => {
console.log("result from thread pool:", result); // will never be executed
});
The worker thread is now will be hijacked till node restart in the malicious task which never ends.
Moreover the library never says to the user that something went wrong.
The process will keep running, with the exhausted poll (the attacker only need to make sure that he sends as much tasks as available workers).
In dynamic pool, attacker might cause a server CPU runout.
For summary:
The user which tries to protect its process from an expensive task taking down its service, might be tricked to use timeout feature, which supposedly guarantees that this never happens.
The attacker only need to find a case where task is expensive to compute (for example an edge case of regex).
The threads are hijacked to the expensive case, leading to a potential DDOS.
The user is never informed that something went wrong, while the pool never executes following tasks.
The text was updated successfully, but these errors were encountered:
@exx8 Hi, thank you for commenting. There is no timeout setting on the options of StaticPool, user should use the createExecutor api to set timeout for each task. code below works:
const{ StaticPool }=require("node-worker-threads-pool");conststaticPool=newStaticPool({size: 1,task: (n)=>{while(n){console.log("a");}returnn;}});staticPool.exec(0).then((result)=>{console.log("result from thread pool:",result);});staticPool.createExecutor().setTimeout(10).exec(1).then((result)=>{console.log("result from thread pool:",result);}).catch(()=>console.error('timeout'));staticPool.exec(0).then((result)=>{console.log("result from thread pool:",result);});
I've read a bit of the code.
And I believe I've found a vulnerability:
For example consider this:
The worker thread is now will be hijacked till node restart in the malicious task which never ends.
Moreover the library never says to the user that something went wrong.
The process will keep running, with the exhausted poll (the attacker only need to make sure that he sends as much tasks as available workers).
In dynamic pool, attacker might cause a server CPU runout.
For summary:
The user which tries to protect its process from an expensive task taking down its service, might be tricked to use timeout feature, which supposedly guarantees that this never happens.
The attacker only need to find a case where task is expensive to compute (for example an edge case of regex).
The threads are hijacked to the expensive case, leading to a potential DDOS.
The user is never informed that something went wrong, while the pool never executes following tasks.
The text was updated successfully, but these errors were encountered: