mirror of
https://github.com/github/codeql.git
synced 2025-12-16 16:53:25 +01:00
114 lines
2.3 KiB
XML
114 lines
2.3 KiB
XML
<!DOCTYPE qhelp PUBLIC
|
|
"-//Semmle//qhelp//EN"
|
|
"qhelp.dtd">
|
|
<qhelp>
|
|
|
|
<overview>
|
|
|
|
<p>
|
|
|
|
Applications are constrained by how many resources they can make use
|
|
of. Failing to respect these constraints may cause the application to
|
|
be unresponsive or crash. It is therefore problematic if attackers
|
|
can control the sizes or lifetimes of allocated objects.
|
|
|
|
</p>
|
|
|
|
</overview>
|
|
|
|
<recommendation>
|
|
|
|
<p>
|
|
|
|
Ensure that attackers can not control object sizes and their
|
|
lifetimes. If object sizes and lifetimes must be controlled by
|
|
external parties, ensure you restrict the object sizes and lifetimes so that
|
|
they are within acceptable ranges.
|
|
|
|
</p>
|
|
|
|
</recommendation>
|
|
|
|
<example>
|
|
|
|
<p>
|
|
|
|
The following example allocates a buffer with a user-controlled
|
|
size.
|
|
|
|
</p>
|
|
|
|
<sample src="examples/ResourceExhaustion_buffer.js" />
|
|
|
|
<p>
|
|
|
|
This is problematic since an attacker can choose a size
|
|
that makes the application run out of memory. Even worse, in older
|
|
versions of Node.js, this could leak confidential memory.
|
|
|
|
To prevent such attacks, limit the buffer size:
|
|
|
|
</p>
|
|
|
|
<sample src="examples/ResourceExhaustion_buffer_fixed.js" />
|
|
|
|
</example>
|
|
|
|
<example>
|
|
|
|
<p>
|
|
|
|
As another example, consider an application that allocates an
|
|
array with a user-controlled size, and then fills it with values:
|
|
|
|
</p>
|
|
|
|
<sample src="examples/ResourceExhaustion_array.js" />
|
|
|
|
<p>
|
|
The allocation of the array itself is not problematic since arrays are
|
|
allocated sparsely, but the subsequent filling of the array will take
|
|
a long time, causing the application to be unresponsive, or even run
|
|
out of memory.
|
|
|
|
Again, a limit on the size will prevent the attack:
|
|
|
|
</p>
|
|
|
|
<sample src="examples/ResourceExhaustion_array_fixed.js" />
|
|
|
|
</example>
|
|
|
|
<example>
|
|
|
|
<p>
|
|
|
|
Finally, the following example lets a user choose a delay after
|
|
which a function is executed:
|
|
|
|
</p>
|
|
|
|
<sample src="examples/ResourceExhaustion_timeout.js" />
|
|
|
|
<p>
|
|
|
|
This is problematic because a large delay essentially makes the
|
|
application wait indefinitely before executing the function. Repeated
|
|
registrations of such delays will therefore use up all of the memory
|
|
in the application.
|
|
|
|
Again, a limit on the delay will prevent the attack:
|
|
|
|
</p>
|
|
|
|
<sample src="examples/ResourceExhaustion_timeout_fixed.js" />
|
|
|
|
|
|
</example>
|
|
|
|
<references>
|
|
|
|
</references>
|
|
|
|
</qhelp>
|