Node crashes when a big sparse array is given to console.log (might cause DoS)

[mik01aj]

var a=[] 
a[1000000000]=1 
console.log(a) 

This ends up with a FATAL ERROR: process out of memory. Wouldn't expect this...

Note that many applications use console.log for logging their stuff, and this can lead to a DoS attack: for example, when an user-specified JSON {"1000000000":"a"} is merged with some pre-existing array and then printed on console. Having an upper bound on printed Array items in console.log seems like an easy fix for this.

I originally reported this to security@nodejs.org, but I got this response:

I don't think we consider this a security issue (it's known and documented) but it's arguably a quality-of-implementation issue. If you'd like to pursue this further, can you file an issue (...)?

So I'm opening an issue 😃

Btw, I can't see this documented anywhere in the console docs, but maybe I'm missing something?

[ChALkeR]

@mik01aj Am I correct that when speaking about DoS, you have console.log(util._extend([],{"1000000000":"a"})) or console.log(Object.assign([],{"1000000000":"a"})) in mind, and this in fact requires someone to use Object.assign or util._extend on an Array?

If so, Object.assign([],{"length":1000000000}) (or util._extend([],{"length":1000000000})) will chew all your memory even without console.log, so you can't blame Node.js here. Edit: I was mistaken here, see below.

[mik01aj]

Yes. I think it can be pretty common in PATCH endpoints, or in deserialization libraries, or Redux reducers. I didn't check for real-world examples, but I believe that console.log should never ever crash the process, regardless of what was passed in.

Note that Object.assign([],{"length":1000000000}) or similar examples create just objects, and this doesn't make Node crash - it's console.log that does (note that Node uses console.log internally in REPL too).

[vkurchatkin]

If so, Object.assign([],{"length":1000000000}) (or util._extend([],{"length":1000000000})) will chew all your memory

How so?

[ChALkeR]

@vkurchatkin My bad, it seems that I was incorrect, sorry.

I was testing this in repl, and it consumed the memory not on that operation, but when trying to print the result.

I will edit my comments above, thanks!

[ChALkeR]

As a possible fix, we could limit the maximum length of an array being printed in util.inspect and replace it with an [Object] (or [Array]), if it's too long — pretty much the same way like it is done when nesting level is too deep.

[mik01aj]

Yes, that's what I meant. 👍

As for DoS risk, I don't have time to think about a good full blown code example, sorry. Maybe later... Or maybe this could convince you that it's certainly possible to make such an array accidentally: lodash/lodash#1685.

[vkurchatkin]

As a possible fix, we could limit the maximum length of an array being printed in util.inspect

+1.

[ChALkeR]

@mscdex This is related to util.format/util.inspect, not to console.

[bnoordhuis]

console.log() and friends call util.format() and util.inspect(), though.

[ChALkeR]

@bnoordhuis This is what I meant, and is exactly why this issue belongs to util, not to console =).

[rvagg]

Seems like the same issue as I was pinged about on Twitter recently

It'd be nice to not have unexpected and non-obvious behaviour like this if we can help it. Fair enough if you're actually using up memory but when you know you're not but it still dies, that's not so great.

/cc @trevnorris