Problem - Kevin Tafuro

ability to run. The default limits are usually set much higher than they need to be,
which ends up allowing any given application to use up far more resources than it
ordinarily should.
Windows 2000 and newer versions provide a mechanism by which applications can
self-impose restrictive limits on the resources that it uses. It’s a good idea for the programmer
to lower the limits to a point where the application can run comfortably,
but if something unexpected happens (such as a memory leak or, more to the point,
a denial of service attack), the limits cause the application to terminate without
bringing down the rest of the system with it.
Discussion
Operating system resources are difficult for an application to control; the pooling
approach used in threads and sockets is difficult to implement when the application
does not explicitly allocate and destroy its own resources. System resources, such as
memory and CPU time, are best managed using system quotas. The programmer can
never be sure that system quotas are enabled when the application is running; therefore,
it pays to be defensive and write code that is reasonably aware of system
resource management.
The most basic advice will be long familiar from lectures on good programming practice:
• Avoid the use of system calls when possible.
• Minimize the number of filesystem reads and writes.
• Steer away from CPU-intensive or “tight” loops.
• Avoid allocating large buffers on the stack.
The ambitious programmer may wish to replace library and operating system
resource management subsystems, by such means as writing a memory allocator that
enforces a maximum memory usage per thread, or writing a scheduler tied to the system
clock which pauses or stops threads and processes after a specified period of
time. While these are viable solutions and should be considered for any large-scale
project, they greatly increase development time and will likely introduce new bugs
into the system.
Instead, you may wish to voluntarily submit to the resource limits enforced by system
quotas, thereby in effect “enabling” quotas for the application. This can be done
on Windows using job objects. Job objects are created to hold and control processes,
imposing limits on them that do not exist on processes outside of the job object. Various
restrictions may be imposed upon processes running within a job object, including
limiting CPU time, memory usage, and access to the user interface. Here, we are
only interested in restricting resource utilization of processes within a job, which will
Guarding Against Resource Starvation Attacks on Windows | 731
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.