@@ -59,8 +59,8 @@ differently based on what arguments are provided:
5959 entire ` Buffer ` . While this behavior is * intentional* to improve performance,
6060 development experience has demonstrated that a more explicit distinction is
6161 required between creating a fast-but-uninitialized ` Buffer ` versus creating a
62- slower-but-safer ` Buffer ` . Starting in Node.js 8.0.0, ` Buffer(num) ` and
63- ` new Buffer(num)` will return a ` Buffer ` with initialized memory.
62+ slower-but-safer ` Buffer ` . Since Node.js 8.0.0, ` Buffer(num) ` and `new
63+ Buffer(num)` return a ` Buffer` with initialized memory.
6464* Passing a string, array, or ` Buffer ` as the first argument copies the
6565 passed object's data into the ` Buffer ` .
6666* Passing an [ ` ArrayBuffer ` ] [ ] or a [ ` SharedArrayBuffer ` ] [ ] returns a ` Buffer `
@@ -71,6 +71,19 @@ first argument, security and reliability issues can be inadvertently introduced
7171into applications when argument validation or ` Buffer ` initialization is not
7272performed.
7373
74+ For example, if an attacker can cause an application to receive a number where
75+ a string is expected, the application may call ` new Buffer(100) `
76+ instead of ` new Buffer("100") ` , it will allocate a 100 byte buffer instead
77+ of allocating a 3 byte buffer with content ` "100" ` . This is commonly possible
78+ using JSON API calls. Since JSON distinguishes between numeric and string types,
79+ it allows injection of numbers where a naive application might expect to always
80+ receive a string. Before Node.js 8.0.0, the 100 byte buffer might contain
81+ arbitrary pre-existing in-memory data, so may be used to expose in-memory
82+ secrets to a remote attacker. Since Node.js 8.0.0, exposure of memory cannot
83+ occur because the data is zero-filled. However, other attacks are still
84+ possible, such as causing very large buffers to be allocated by the server,
85+ leading to performance degradation or crashing on memory exhaustion.
86+
7487To make the creation of ` Buffer ` instances more reliable and less error-prone,
7588the various forms of the ` new Buffer() ` constructor have been ** deprecated**
7689and replaced by separate ` Buffer.from() ` , [ ` Buffer.alloc() ` ] [ ] , and
@@ -92,7 +105,7 @@ to one of these new APIs.*
92105 initialized ` Buffer ` of the specified size. This method is slower than
93106 [ ` Buffer.allocUnsafe(size) ` ] [ `Buffer.allocUnsafe()` ] but guarantees that newly
94107 created ` Buffer ` instances never contain old data that is potentially
95- sensitive.
108+ sensitive. A ` TypeError ` will be thrown if ` size ` is not a number.
96109* [ ` Buffer.allocUnsafe(size) ` ] [ `Buffer.allocUnsafe()` ] and
97110 [ ` Buffer.allocUnsafeSlow(size) ` ] [ `Buffer.allocUnsafeSlow()` ] each return a
98111 new uninitialized ` Buffer ` of the specified ` size ` . Because the ` Buffer ` is
@@ -111,7 +124,9 @@ added: v5.10.0
111124
112125Node.js can be started using the ` --zero-fill-buffers ` command line option to
113126cause all newly allocated ` Buffer ` instances to be zero-filled upon creation by
114- default, including buffers returned by ` new Buffer(size) ` ,
127+ default. Before Node.js 8.0.0, this included buffers allocated by `new
128+ Buffer(size)` . Since Node.js 8.0.0, buffers allocated with ` new` are always
129+ zero-filled, whether this option is used or not.
115130[ ` Buffer.allocUnsafe() ` ] [ ] , [ ` Buffer.allocUnsafeSlow() ` ] [ ] , and `new
116131SlowBuffer(size)`. Use of this flag can have a significant negative impact on
117132performance. Use of the ` --zero-fill-buffers ` option is recommended only when
0 commit comments