sponsored by
OSdata.com: security 

OSdata.com

Security: race condition attacks

Google


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


geek humor


OSdata.com is used in more than 300 colleges and universities around the world

Read details here.


    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.


previous page next page
previous page next page

home page

two levels up

holistic issues

one level up

peer level


Made with Macintosh

    This web site handcrafted on Macintosh computers using Tom Bender’s Tex-Edit Plus and served using FreeBSD .

Viewable With Any Browser


    Names and logos of various OSs are trademarks of their respective owners.

    Copyright © 2005 Milo

    Last Updated: May 9, 2005

    Created: May 9, 2005

previous page next page
previous page next page