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 stems from the standard file descriptors (FDs) on a Unix system. Typically, when a process is started, FD 0, 1 and 2 are set to standard in, standard out, and standard error respectively. Subsequent uses of input and output functions--such as printf--will read or write from one of these three descriptors. Customarily, a program starts with its standard file descriptors opened to terminal devices. However, since the kernel does not enforce this convention, an attacker can force a standard file descriptor of a victim program to be opened to a sensitive file, so that he may discover confidential information from the sensitive file or modify the sensitive file. We present some examples of vulnerable programs in our paper "Model Checking An Entire Linux Distribution for Security Violations" which can be found at http://www.cs.berkeley.edu/~bschwarz/paper/mc-redhat.pdf. Section 3.2 is dedicated to this specific type of bug. Our suggestion for fixing these bugs is to have the program open 3 non-sensitive files, such as /dev/null, upon starting execution. This ensures that subsequent input and output operations will not take place on sensitive data. The maintainers of this package can find the interactive program traces at https://taverner.cs.berkeley.edu/traces/fd-write/ 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 when a file is opened onto a descriptor that may be 0, 1, or 2. We have manually audited this package to verify that subsequent write operations take place on this file. 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 [EMAIL PROTECTED] ---------------------------- URL with program traces for this package: https://taverner.cs.berkeley.edu/traces/fd-write/gnuchess-5.02-11/HTMLtrace/ Programs with bugs: gnuchess, book.c line 87 We don't believe this to be an exploitable bug, but it can cause data to be written to an unexpected file. _______________________________________________ Bug-gnu-chess mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnu-chess
