[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Concerning a possible race condition in the 'make' package

From: Ben Schwarz
Subject: Concerning a possible race condition in the 'make' package
Date: Wed, 31 Aug 2005 09:49:01 -0700 (PDT)

This email concerns a bug or security vulnerability that members of
the MOPS project (http://www.cs.berkeley.edu/~daw/mops/) have found
during a recent audit of all programs packaged with the Redhat 9 Linux
distribution. We believe that one or more of the packages maintained
by recipients of this email contain bugs that may be exploitable
(although sometimes they are just bugs that may result in unexpected
program behavior).

The specific type of bug which we have found is a time-of-check to
time-of-use vulnerability. These often occur when two system calls
are performed that re-use the same literal pathname. For instance,
an example of a vulnerability would be a setuid program that checks
if a user has access to view a file (e.g., through the access()
system call), and then opens the file (e.g., with open() ) if the
user was deemed privileged. The problem is that this sequence of
operations is not atomic, and access privileges could be changed
between the two system calls.

We present some examples of vulnerable programs in our paper
"Model Checking An Entire Linux Distribution for Security Violations"
which can be found at
Section 3.1 is dedicated to this specific type of bug.

Our suggestion for fixing these bugs is to not use fixed pathnames
when accessing the file system, but rather file descriptors.
File descriptors cannot be changed behind-the-scenes, so there cannot
be race conditions.

The maintainers of this package can find the interactive program
traces at https://taverner.cs.berkeley.edu/traces/race/
A program trace consists of a series statements that caused the program
to reach a state where we believe malicious behavior can occur. One can
navigate the program code by clicking on transitions (two program states
separated by a '->') in the leftmost pane to see the program behavior
that caused our modelchecker to reach its final state.
For this specific bug, transitions to the final "bug" state will occur
after two system calls have been performed on a filename. We have
manually audited these traces to verify that there are race conditions

At this end of this email is a more detailed description of where the bug
can be found. Any questions about this specific bug can be directed to


URL with program traces for this package:

Programs with bugs:
make (commands.c line 504)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]