|
|
|
|
CWE-400 Individual Dictionary Definition (Draft 9)
Weakness ID
| Status: Incomplete 400 (Weakness Base) | | Description | Summary The application is susceptible to generating and/or accepting an excessive amount of
requests that could potentially exhaust limited resources, such as memory, file system storage,
database connection pool entries, or CPU. This can ultimately lead to a denial of service that
could prevent valid users from accessing the application. | | Likelihood of Exploit | Very high | | Common Consequences | 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. | | Potential Mitigations | 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. 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. | Demonstrative
Examples | Java Example: 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/C++ Example: 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. | | Context 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. | | Relationships | | | Source Taxonomies | CLASP - Resource exhaustion (file descriptor, disk space, sockets,
...) | | Applicable Platforms | All | | Related Attack Patterns | | CAPEC-ID | Attack Pattern Name |
|---|
| 82 | Violating Implicit Assumptions Regarding XML Content (aka XML Denial of Service (XDoS)) | | 2 | Inducing Account Lockout |
|
|
- Weakness
- Base
- Variant
- Class
- Chain
- Composite
- Category
- View
- Deprecated
