B. Miller, D. Koski, C. P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz revisited: A re-examination of the reliability of UNIX utilities and services. Technical report, University of Wisconsin - Madison, 1995.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....errors are a common source of software defects and lead to many security vulnerabilities. CERT advisories report security holes resulting from bu er over ow, i.e. updates beyond the bounds of a bu er [29] Furthermore, 60 of the UNIX failures reported in the 1995 FUZZ study [23] are due to runtime string manipulation errors, such as bu er over ow, access beyond the bounds of a string and misuse of the null termination byte. Our goal is to perform static analysis that detects all string runtime errors with just a few false alarms. A false alarm is a reported error that ....

B. Miller, D. Koski, C. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz revisited: A re-examination of the reliability of Unix utilities and services, 1995. Available at http://www.cs.wisc.edu/bart/fuzz/fuzz.html.

....standard UNIX utilities by giving them input consisting of large, random streams of characters[28] They found that 25 33 crashed or hung. The dominant causes were problems with pointers and array dereferencing. Similar experiments with X Window and MS Windows programs produced similar results[29, 16]. This is relevant to security because a program that misbehaves when given random input will likely misbehave when given malicious input. 2.1.4 Purify A tool called Purify, presented by Hastings and Joyce [22] can be used to detect many kinds of memory errors. This includes accessing a bu er ....

B. P. Miller, D. Koski, C. P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services. Technical report, Computer Science Department, University of Wisconsin, November 1995.

....one update to one of three counters, is considered one instrumentation site. We transform the instrumentation to be sampled rather than unconditional using the framework described in Section 2. In lieu of a large user community, we generate many runs artificially in the spirit of the Fuzz project [20]. Each run uses a randomly selected set of present or absent files, randomized command line flags, and randomized responses to ccrypt prompts including the occasional EOF. We have collected 2990 trial runs at a sampling rate of 1000; 88 of these end in a crash. Applying each elimination ....

B. Miller, D. Koski, C. P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz revisited: A re-examination of the reliability of UNIX utilities and services. Technical report, Computer Science Department, University of Wisconsin, Madison, WI, 1995.

....Bugzilla database provided that the bug reports can be reproduced automatically. All one needs is an HTML input, a sequence of user actions, an observable failure and a little time to let the computer simplify the failure inducing input. C. Minimizing Fuzz In a classical experiment [6] [7], Bart Miller and his team examined the robustness of UNIX utilities and services by sending them fuzz input a large number of random characters. The studies showed that, in the worst case, 40 of the basic programs crashed or went into infinite loops when being fed with fuzz input. We wanted ....

Barton P. Miller, David Koski, Cjin Pheow Lee, Vivekananda Maganty, Ravi Murthy, Ajitkumar Natarajan, and Jeff Steidl, "Fuzz revisited: A reexamination of the reliability of UNIX utilities and services," Tech. Rep., University of Wisconsin, Computer Science Department, Nov. 1995.

....and is therfore the most common. In the following, it is assumed that an instrumentor is available. Noise makers A noise maker [12] 32] belongs to the class of testing tools that make tests more likely to fail and thus increase the efficiency of testing. In the sequential domain, such tools [25] [33] usually work by denying the application some services, for example returning that no more memory is available to a memory allocation request. In the sequential domain, this technique is very useful but is limited to verifying that, on the bad path of the test, the program fails gracefully. ....

B. Miller, D. Koski, C. P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz revisited: A re-examination of the reliability of UNIX utilities and services. Technical report, University of Wisconsin, Madison, 1995. 7

....precision they provide, formal methods suffer from the inherent difficulty in specifying the requirements, the system, and then applying the process of checking the requirements specification against system specification. Recently, several specific security testing techniques have been developed [4, 7, 18, 23, 21, 28]. As discussed in section 5, these techniques are either restricted to some specific security flaws or limited by the underlying testing techniques. Another alternative for security testing is to use general testing techniques, such as path testing, data flow testing, domain testing, and syntax ....

....requests its environment for an input. The input that the environment provides to the application will most likely affect the application s behavior. A secure application should tolerate an unexpected anomaly in the environment input. One way to perturb the input is to use random input as in Fuzz [8, 23]. However, this approach dramatically increases the testing space, which and calls for a significantly large amount of testing effort. The Fuzz approach does not exploit the semantics of each input. Our vulnerability analysis, however, has shown that inputs most likely to cause security violations ....

[Article contains additional citation context not shown here]

B. Miller, D. Koski, C. Lee, V. Maganty, R. Murthy, A. Natarajan and J. Steidl. Fuzz revisited: A re-examination of the reliability of unix utilities and services. Technical report, Computer Sciences Department, University of Wisconsin, 1995.

....the precision they provide, formal methods suffer from the inherent diculty in specifying the requirements, the system, and then applying the process of checking the requirements specification against system specification. Recently, several specific security testing techniques have been developed [4, 8, 19, 24, 22, 29]. Adaptive Vulnerability Analysis (AVA) is designed by Ghosh et al. to quantitatively assess information system security and survivability. This approach exercises software in source code form by simulating incoming mali cious and non malicious attacks that fall under various threat classes [22, ....

....Analysis (AVA) is designed by Ghosh et al. to quantitatively assess information system security and survivability. This approach exercises software in source code form by simulating incoming mali cious and non malicious attacks that fall under various threat classes [22, 23, 28, 29] Fuzz [9, 24] is a black box testing method designed by Miller et al., which feeds randomly generated input stream to system utilities in order to test how reliable they are. Bishop and Dilger studied one class of the time of check to time of use (TOCTTOU) flaws [4] and investigated using static analysis ....

[Article contains additional citation context not shown here]

B. Miller, D. Koski, C. Lee, V. Maganty, R. Murthy, A. Natarajan and J. Steidl. Fuzz revisited: A re-examination of the reliability of unix utilities and services. Technical report, Computer Sciences Department, University of Wisconsin, 1995.

....This puts the client in a position of dumb processing all event messages being sent. Event messages can come at any time, in any order and they can even be generated by the clients themselves, for the purposes of interprocess communication. 3. RELATED WORK In [Forrester and Miller, 2000, Miller et al. 1995] it is shown that when event driven applications are fed with random sequences of events, they tend to malfunction. In fact, all the applications tested in [Forrester and Miller, 2000] were found to be vulnerable to random event messages. Among the applications tested, they managed to find code ....

....pointers which is a very dangerous security practice. In another situation, the identification of an application that was received in a message was trusted to the degree that it was used directly without verifying the correctness of the value. The difference between [Forrester and Miller, 2000, Miller et al. 1995] and this paper is that the former examine mainly the problems in event driven systems as a software reliability issue. In this paper we examine them in the security perspective. In [Ghosh and Voas, 1999, pages 38 44] the problem of software reliability with regards to commercial off the shell ....

[Article contains additional citation context not shown here]

Miller, B. P., Lee, C. P., Maganty, V., Murthy, R., Natarajan, A., and Steidl, J. (1995). Fuzz revisited: A re-examination of the reliability of unix utilities and services. Technical report, Computer Sciences Department, University of Wisconsin.

.... Koopman describes benchmarks to test OS robustness by feeding corrupt data to system calls [29] similarly, Miller et al. and Forrester describe the Fuzz tests, robustness tests based on feeding random data or messages ( fuzz ) into key input points in operating systems and applications [17] 32] [33]. The major difference between these benchmarks and the ones we propose is in their goals and the knowledge they assume. Tsai s and Siewiorek s benchmarks are primarily designed to test particular known fault tolerance mechanisms deployed in fault tolerant hardware and software systems; to this ....

B. Miller, D. Koski, et al. Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services. Technical Report CS-TR-95-1268, University of Wisconsin, Madison, 1995.

....capabilities of standard type systems, and different languages deal with such run time errors in different ways. Unsafe languages like C [31] ignore the problem and leave it to the programmer to insert checks where appropriate. As a result C programs are notoriously prone to inexplicable crashes [33], or, worse, inexplicable, correct looking results. In contrast, safe languages such as SML [34] Scheme [5] and Java [22] equip program operations with appropriate run time checks where necessary. These checks guarantee that a misapplied program operation immediately raises an error signal, ....

Miller, B., Koski, D., Lee, C. P., Maganty, V., Murthy, P., Natarajan, A., and Steidl, J. Fuzz revisited: A re-examination of the reliability of unix utilities and services. Computer Science Department, University of Wisconsin, 1995.

....examples of automated robustness testing. Crashme works by writing random data values to memory and then attempts to execute them as code by spawning a large number of concurrent processes [Carette96] The Fuzz project injects random noise (or fuzz ) into specific elements of an OS interface [Miller98] Both methods find robustness problems in operating systems, although they are not specifically designed for a high degree of repeatability, and Crashme in particular is not generally applicable for testing software other than operating systems. While robustness under stressful environmental ....

Miller, B., Koski, D., Lee, C., Magnanty, V., Murthy, R., Natarajan, A. & Steidl, J., Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services, Computer Science Technical Report 1268, Univ. of Wisconsin-Madison, May 1998.

....capabilities of standard type systems, and different languages deal with such run time errors in different ways. Unsafe languages like C [31] ignore the problem and leave it to the programmer to insert checks where appropriate. As a result C programs are notoriously prone to inexplicable crashes [33], or, worse, inexplicable, correct looking results. In contrast, safe languages such as SML [34] Scheme [5] and Java [22] equip program operations with appropriate run time checks where necessary. These checks guarantee that a misapplied program operation immediately raises an error signal, ....

Miller, B., Koski, D., Lee, C. P., Maganty, V., Murthy, P., Natarajan, A., and Steidl, J. Fuzz revisited: A re-examination of the reliability of unix utilities and services. Computer Science Department, University of Wisconsin, 1995.

....the architectures of these tools do not preclude such an implementation. Rather, interest in Windows NT and its reliability have recently begun to increase. Also, many of these tools focus on the reliability of the operating system or the platform rather than the reliability of applications. Fuzz [11] is one fault injection tool that tested the reliability of Unix utilities, applications, and services. The basic DTS architecture is not dependent on a particular fault injection mechanism. However, the initial DTS tool implementation is based on the interception of library calls and corruption ....

B. P. Miller, D. Koski, C. P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz revisited: A re-examination of the reliability of UNIX utilities and services. Technical Report CS-TR-

....contains only clean expressions. Thus, the behaviour of a clean C program is always predictable and does not depend on the environment. String manipulation cleanness violations lead to many nasty bugs. For example, we have found that 60 of the UNIX failures reported in the 1995 FUZZ study [13] are due to string manipulation cleanness violations. In Nov. 1988, the Internet worm incident used a bu er over ow in fingerd to attack 60,000 computers [16] Furthermore, CERT advisories indicate that bu er over ows account for up to 50 of today s software vulnerabilities [18] 1.1 Main ....

B. Miller, D. Koski, C. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz revisited: A re-examination of the reliability of Unix utilities and services, 1995. Available at http://www.cs.wisc.edu/bart/fuzz/fuzz.html.

....or survives [6] These focus mostly on robustness in the face of arti cial errors, whereas we are interested more in the features of actual errors. Another approach is explicit testing, such as the fuzz studies that compare how a set of systems utilities behaved in the face of random inputs [17, 18]. In terms of examining bugs found with automatic techniques, the closest work compared to us is a study by Koopman et al. that used randomized testing to measure the e ectiveness of error handling code on 13 di erent POSIX implementations [13] They measured both the types of errors that ....

B.P. Miller, D. Koski, C.P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz Revisited: A Reexamination of the Reliability of UNIX Utilities and Services. Technical Report CS-TR-

....or survives [6] These focus mostly on robustness in the face of artificial errors, whereas we are interested more in the features of actual errors. Another approach is explicit testing, such as the fuzz studies that compare how a set of systems utilities behaved in the face of random inputs [17, 18]. In terms of examining bugs found with automatic techniques, the closest work compared to us is a study by Koopman et al. that used randomized testing to measure the e#ectiveness of error handling code on 13 di#erent POSIX implementations [13] They measured both the types of errors that ....

B.P. Miller, D. Koski, C.P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz Revisited: A Reexamination of the Reliability of UNIX Utilities and Services. Technical Report CS-TR-1995-1268, University of Wisconsin, 1995.

....or survives [6] These focus mostly on robustness in the face of artificial errors, whereas we are interested more in the features of actual errors. Another approach is explicit testing, such as the fuzz studies that compare how a set of systems utilities behaved in the face of random inputs [17, 18]. In terms of examining bugs found with automatic techniques, the closest work compared to us is a study by Koopman et al. that used randomized testing to measure the effectiveness of error handling code on 13 different POSIX implementations [13] They measured both the types of errors that ....

B.P. Miller, D. Koski, C.P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz Revisited: A Reexamination of the Reliability of UNIX Utilities and Services. Technical Report CS-TR-1995-1268, University of Wisconsin, 1995.

No context found.

B. Miller, D. Koski, C. P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz revisited: A re-examination of the reliability of UNIX utilities and services. Technical report, University of Wisconsin - Madison, 1995.

No context found.

B. Miller et al., "Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services," Tech. Report, University of Wisconsin, 1995.

No context found.

Barton P. Miller, Cjin Pheow Lee, Vivekananda Maganty, Ravi Murthy, Ajitkumar Natarajan, and Je# Steidl. Fuzz revisited: A re-examination of the reliability of unix utilities and services. Technical report, Computer Sciences Department, University of Wisconsin, 1995.

No context found.

B. Miller, D. Koski, C. P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz revisited: A re-examination of the reliability of UNIX utilities and services. Technical report, Computer Science Department, University of Wisconsin, Madison, WI, 1995.

No context found.

Barton P. Miller, Cjin Pheow Lee, Vivekananda Maganty, Ravi Murthy, Ajitkumar Natarajan, and Je# Steidl. Fuzz revisited: A re-examination of the reliability of unix utilities and services. Technical report, Computer Sciences Department, University of Wisconsin, 1995.

No context found.

Miller, B., Koski, D., Lee, C., Maganty, V., Murthy, R., Natarajan, A. & Steidl, J., "Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services," Computer Science Technical Report 1268, Univ. of Wisconsin-Madison, May 1998

No context found.

B.P. Miller, D. Koski, C.P. Lee, V. Maganty, R. Murphy, A. Natarajan, and J. Steidl. Fuzz revisited: a re-examination of the reliability of Unix utilities and services. Technical Report Tech. report CS-TR-95-1268, U. Wisconsin, April 1995.

No context found.

B. P. Miller, D. Koski, C. P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl. Fuzz revisited: A re-examination of the reliability of UNIX utilities and services. Technical report, University of Wisconsin, Computer Science Department, Nov. 1995.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC