The software does not properly restrict the size or amount of
resources that are requested or influenced by an actor, which can be used to
consume more resources than intended.
Extended Description
Limited resources include memory, file system storage, database connection
pool entries, or CPU. If an attacker can trigger the allocation of these
limited resources, but the number or size of the resources is not
controlled, then the attacker could cause a denial of service that consumes
all available resources. This would prevent valid users from accessing the
software, and it could potentially have an impact on the surrounding
environment. For example, a memory exhaustion attack against an application
could slow down the application as well as its host operating system.
Resource exhaustion problems have at least two common causes:
(1) Error conditions and other exceptional circumstances
(2) Confusion over which part of the program is responsible for
releasing the resource
Time of Introduction
Operation
Architecture and Design
Implementation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Availability
The most common result of resource exhaustion is denial of
service.
Access Control
In some cases it may be possible to force a system to "fail open" in
the event of resource exhaustion.
Likelihood of Exploit
Very High
Demonstrative Examples
Example 1
Java
class Worker implements Executor {
...
public void execute(Runnable r) {
try {
...
}
catch (InterruptedException ie) {
// postpone response
Thread.currentThread().interrupt();
}
}
public Worker(Channel ch, int nworkers) {
...
}
protected void activate() {
Runnable loop = new Runnable() {
public void run() {
try {
for (;;) {
Runnable r = ... r.run();
}
}
catch (InterruptedException ie) {
...
}
}
};
new Thread(loop).start();
}
C and C++
int main(int argc, char *argv[]) {
sock=socket(AF_INET, SOCK_STREAM, 0);
while (1) {
newsock=accept(sock, ...);
printf("A connection has been accepted\n");
pid = fork();
}
There are no limits to runnables/forks. Potentially an attacker could
cause resource problems very quickly.
Potential Mitigations
Phase
Description
Architecture and Design
Design throttling mechanisms into the system architecture. The best
protection is to limit the amount of resources that an unauthorized user
can cause to be expended. A strong authentication and access control
model will help prevent such attacks from occurring in the first place.
The login application should be protected against DoS attacks as much as
possible. Limiting the database access, perhaps by caching result sets,
can help minimize the resources expended. To further limit the potential
for a DoS attack, consider tracking the rate of requests received from
users and blocking requests that exceed a defined rate threshold.
Architecture and Design
Ensure that protocols have specific limits of scale placed on
them.
Implementation
Ensure that all failures in resource allocation place the system into
a safe posture.
Implementation
Fail safely when a resource exhaustion occurs.
Other Notes
Resource exhaustion issues are generally understood but are far more
difficult to successfully prevent. Taking advantage of various entry points,
an attacker could craft a wide variety of requests that would cause the site
to consume resources. Database queries that take a long time to process are
good DoS targets. An attacker would have to write a few lines of Perl code
to generate enough traffic to exceed the site's ability to keep up. This
would effectively prevent authorized users from using the site at all.
Resources can be exploited simply by ensuring that the target machine must
do much more work and consume more resources in order to service a request
than the attacker must do to initiate a request. Prevention of these attacks
requires either that the target system: - either recognizes the attack and
denies that user further access for a given amount of time; - or uniformly
throttles all requests in order to make it more difficult to consume
resources more quickly than they can again be freed. The first of these
solutions is an issue in itself though, since it may allow attackers to
prevent the use of the system by a particular valid user. If the attacker
impersonates the valid user, he may be able to prevent the user from
accessing the server in question. The second solution is simply difficult to
effectively institute -- and even when properly done, it does not provide a
full solution. It simply makes the attack require more resources on the part
of the attacker. The final concern that must be discussed about issues of
resource exhaustion is that of systems which "fail open." This means that in
the event of resource consumption, the system fails in such a way that the
state of the system -- and possibly the security functionality of the system
-- is compromised. A prime example of this can be found in old switches that
were vulnerable to "macof" attacks (so named for a tool developed by
Dugsong). These attacks flooded a switch with random IP and MAC address
combinations, therefore exhausting the switch's cache, which held the
information of which port corresponded to which MAC addresses. Once this
cache was exhausted, the switch would fail in an insecure way and would
begin to act simply as a hub, broadcasting all traffic on all ports and
allowing for basic sniffing attacks.
Description
