@@ -59,8 +59,8 @@ differently based on what arguments are provided:
59
59
entire ` Buffer ` . While this behavior is * intentional* to improve performance,
60
60
development experience has demonstrated that a more explicit distinction is
61
61
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.
64
64
* Passing a string, array, or ` Buffer ` as the first argument copies the
65
65
passed object's data into the ` Buffer ` .
66
66
* Passing an [ ` ArrayBuffer ` ] [ ] or a [ ` SharedArrayBuffer ` ] [ ] returns a ` Buffer `
@@ -71,6 +71,19 @@ first argument, security and reliability issues can be inadvertently introduced
71
71
into applications when argument validation or ` Buffer ` initialization is not
72
72
performed.
73
73
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
+
74
87
To make the creation of ` Buffer ` instances more reliable and less error-prone,
75
88
the various forms of the ` new Buffer() ` constructor have been ** deprecated**
76
89
and replaced by separate ` Buffer.from() ` , [ ` Buffer.alloc() ` ] [ ] , and
@@ -92,7 +105,7 @@ to one of these new APIs.*
92
105
initialized ` Buffer ` of the specified size. This method is slower than
93
106
[ ` Buffer.allocUnsafe(size) ` ] [ `Buffer.allocUnsafe()` ] but guarantees that newly
94
107
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.
96
109
* [ ` Buffer.allocUnsafe(size) ` ] [ `Buffer.allocUnsafe()` ] and
97
110
[ ` Buffer.allocUnsafeSlow(size) ` ] [ `Buffer.allocUnsafeSlow()` ] each return a
98
111
new uninitialized ` Buffer ` of the specified ` size ` . Because the ` Buffer ` is
@@ -111,7 +124,9 @@ added: v5.10.0
111
124
112
125
Node.js can be started using the ` --zero-fill-buffers ` command line option to
113
126
cause 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.
115
130
[ ` Buffer.allocUnsafe() ` ] [ ] , [ ` Buffer.allocUnsafeSlow() ` ] [ ] , and `new
116
131
SlowBuffer(size)`. Use of this flag can have a significant negative impact on
117
132
performance. Use of the ` --zero-fill-buffers ` option is recommended only when
0 commit comments