Security: Race Condition Attacks (original) (raw)
sponsored by
| 
| | OSdata.com |
| ------------------------------------------------------------------------------------ | | ---------- |
OSdata.com is used in more than 300 colleges and universities around the world
Find out how to get similar high web traffic and search engine placement.
race condition attacks
Processors work in terms of one discrete step at a time. Modern operating systems give the appearance of multi-tasking by quickly swapping between processes, completing each over one or more time slices. Additionally there are hardware and software interrupts (such as for handling disk I/O) that can preempt other running processes.
A race condition is any case where the results can be different depending on the order that processes arrive or are scheduled or depending on the order that specific competing instructions are executed.
A classic example of a race condition attack is the old UNIX login attack. When a new login process was created, there was a brief moment when the new process was running at priority (kernel or root) mode and hadn’t yet been switched to normal user mode. If the human user repeatedly poked at the escape key while logging in, there was a small possibility that the change from root to user could be prevented, allowing the human complete access to the entire system. This depended on whether the escape key processing occurred before or after the switch to normal user mode.
Another example involves the checking and running of a shell or batch file. In some systems, the operating system does some kind of initial checking to make sure that the shell or batch file is “safe” or otherwise correct. Once confirmed, the file is turned over to another process to be run. In some systems, there may be a brief window of opportunity during which a human or a program could substitute a different file for the one that has been validated, allowing free execution of commands that should be prevented from running.
Typical places for race condition attacks involve opening a file, validating a file, running a subprogram, checking a password, or verifying a username.
defense
The first line of defense is better software writing. Be aware of what are atomic ((indivisible) and non-atomic (divisible) operations in shell scripts, application program macros, and user-written or local-written programs. If you are uncertain as to whether or not an operation is atomic, assume that it is non-atomic.
System administrators and other end users will want to keep alert for security updates to software (especially system software and operating systems) that patch race condition security holes.
common attacks
- man in the middle
- race condition
geek humor
OSdata.com is used in more than 300 colleges and universities around the world
A web site on dozens of operating systems simply can’t be maintained by one person. This is a cooperative effort. If you spot an error in fact, grammar, syntax, or spelling, or a broken link, or have additional information, commentary, or constructive criticism, please e-mail Milo. If you have any extra copies of docs, manuals, or other materials that can assist in accuracy and completeness, please send them to Milo, PO Box 1361, Tustin, CA, USA, 92781.
Click here for our privacy policy.
home page
two levels up
one level up
- Cost
- Hardware Supported
- Hardware-Software Integration
- Installation and Set-up
- Utilization of Resources
- Scalability
- Connectivity
- Reliability
- Security
- Failure Handling and Failure Recovery
- Speed
- Sophistication
- Ease of Use
- Maintenance and Administration
- Disabled Access
- Release Dates
- Development and APIs
peer level
This web site handcrafted on Macintosh computers using Tom Bender’s Tex-Edit Plus 
and served using FreeBSD 
.
Names and logos of various OSs are trademarks of their respective owners.
Copyright © 2005 Milo
Last Updated: May 9, 2005
Created: May 9, 2005