isaacs / minipass

A stream implementation that does more by doing less

Home Page:https://twitter.com/izs/status/1174465160737509376

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Security risk

KennyGoi opened this issue · comments

Affected files:
minipass/index.js
303: [FLUSHCHUNK] (chunk) {

minipass/index.js
304: return chunk ? (this.emit('data', chunk), this.flowing) : false

minipass/index.js
366: emit (ev, data) {

minipass/index.js
368: if (ev !== 'error' && ev !== 'close' && ev !== DESTROYED && this[DESTROYED])

minipass/index.js
410: for (let i = 2; i < arguments.length; i++) {

minipass/index.js
203: [READ] (n, chunk) {

minipass/index.js
208: chunk = chunk.slice(0, n)

minipass/index.js
212: this.emit('data', chunk)

minipass/index.js
366: emit (ev, data) {

minipass/index.js
368: if (ev !== 'error' && ev !== 'close' && ev !== DESTROYED && this[DESTROYED])

minipass/index.js
410: for (let i = 2; i < arguments.length; i++) {

Risks:
An attacker could provide a very high loop iteration count, causing the loop to go on for prolonged periods of time, potentially causing the application to stop responding. Additionally, if the operation inside the loop is tied to some exhaustible functionality, it may cause bloat elsewhere; For example - if file writes occur inside the loop, then an attacker can cause that file to bloat by simply engaging this file writing capability a very high amount of times.

The application relied on a user-provided value to determine the number of iterations performed by a loop, without enforcing a limited range for this value.

Do you have a POC that demonstrates how an attacker might abuse this? I'm having a hard time seeing how this could occur without the developer doing it to themselves.

No POC provided, this is a self-pwn issue. Closing.