[Top][All Lists]

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

Concerning a possible bug in the 'binutils' package

From: Ben Schwarz
Subject: Concerning a possible bug in the 'binutils' package
Date: Mon, 29 Aug 2005 14:43:48 -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 arises from misuse
of the library functions that create temporary files. These bugs
generally fall under one of two categories: 1) Use of unsafe
system calls--such as tempnam(), mktemp(), tmpfile(). These system
calls are inherently unsafe as they do not return a file descriptor.
Instead, they take a template as their argument, which is then
filled in with a random name. If the program re-uses this template,
there is a race condition on the name of the file. 2) Use of
a safe system call, mkstemp(), but re-use of its name template. For
the same reason as before, re-using the name template can lead
to race conditions. A safe program should only use the file
descriptor that is returned by mkstemp().

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.3 is dedicated to this specific type of bug.

Our suggestion for fixing these bugs is to make sure all code
uses mkstemp() instead of the other unsafe calls, and to
verify that it never re-uses the mkstemp() name template in other
system calls.

The maintainers of this package can find the interactive program
traces at https://taverner.cs.berkeley.edu/traces/tmpfile/
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.

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:
ar (bucomm.c lines 239 and 242)

We believe this program uses an unsafe system call to
create a temporary file, and the contents of the file
could be compromised by an attacker exploiting a race condition.

reply via email to

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