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.

....is sent, and can be intercepted by an interactive debugger like GDB[6] The user is then able to examine memory locations, including the mirror, and make use of GDB s features to better track down the cause of an error. 4 Experiments To test the e#ectiveness of our debugging tool, we used Fuzz[7] to find Solaris utilities that crash on some inputs, and instrumented five such programs for testing (nroff, plot, ul, units, col) We also tracked down bugs that appear in two programs from the Olden benchmark suite (health, voronoi) A summary of what our tool revealed about these runs is given ....

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.

....algorithm for solving the integer constraints. Finally, security knowledge is used to formulate heuristics that capture the class of security relevant bugs that tend to occur in real programs. Others have applied runtime code testing techniques to the problem, using, e.g. black box testing [41, 42] or software fault injection [21] to find buffer overruns in real world applications. However, runtime testing seems likely to miss many vulnerabilities. Consider the following example: if (strlen(src) sizeof dst) break; strcpy(dst, src) Note that off by one errors in buffer management, ....

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

....capabilities of standard type systems, and di#erent languages deal with such run time errors in di#erent ways. Unsafe languages like C [18] 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 [20]. In contrast, safe languages such as Lisp, Scheme, ML, and Java check primitive program operations. The latter two use a mixture of compile time type checking and insertion of run time checks. The first two give the programmer even more power and exclusively rely on run time checks. 1 These ....

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.

....For library functions that a#ect type flow, we are in the process of building up a collection of instrumented versions. These are wrappers of the original functions, hand written to capture their type behavior. 4 4 Initial Experiments To test the e#ectiveness of our debugging tool, we used Fuzz[6] to find Solaris utilities that crash on some inputs, and instrumented five such programs for testing (nroff, plot, ul, units, col) A summary of what our tool revealed about each of the crashing runs is given below. nro#: An array of pointers is accessed with a negative index, and the retrieved ....

B. Miller, D. Koski, C.P. Lee, V. Maganty, R. Murthy, A. Natarajan, J. Steidl. Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services. University of WisconsinMadison, 1995. ftp://grilled.cs.wisc.edu/technical papers/fuzz-revisited.ps

....1. 5 (tmp1 = tmp2 = x, x) tmp3 = verifyTag( p, pointer type) p) verifyPtr(tmp3, int type) tmp3) copyTag(tmp2, tmp3, int type) tmp1) Figure 1: Output of instr(x = p, false) 4 Experiments 4. 1 Identifying Bugs To test the e#ectiveness of our debugging tool, we used Fuzz[12] to find Solaris utilities that crash on some inputs, and instrumented five such programs for testing (nroff, plot, ul, units, col) We also tracked down bugs that appear in two programs from the Olden benchmark suite (health, voronoi) A summary of what our tool revealed about these runs is ....

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.

....Nonetheless, their results found many Abort type failures in Windows NT, and a few Catastrophic failures that were caused by very complex execution sequences that could not be isolated for bug reporting purposes. Other recent related work is the Fuzz project at the University of Wisconsin [12] [13], which has concentrated on Unix systems. There does not appear to be any previously published work that performs testing oriented dependability comparisons of multiple Windows versions, nor comparisons of Windows to Unix robustness. 3. Implementation The existing Ballista testing system ran ....

Miller, B.P., D. Koski, C. Pheow Lee, V. Maganty, R. Murthy, A. Natarajan & J. Steidl, Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services, University of Wisconsin, CS-TR-95-1268, April 1995.

....have other motives (e.g. higher reliability) or simply wish to appear less strident. Those interested in reading advocacy pieces for open source software and free software should see http: www.opensource.org and http: www.fsf.org. There are other papers which examine such software, for example, Miller [1995] found that the open source software were noticeably more reliable than proprietary software (using their measurement technique, which measured resistance to crashing due to random input) 2.1.5. Comparing Linux and Unix This paper uses the term Unix like to describe systems intentionally like ....

Miller, Barton P., David Koski, Cjin Pheow Lee, Vivekananda Maganty, Ravi Murthy, Ajitkumar Natarajan, and Jeff Steidl. 1995. Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services. ftp://grilled.cs.wisc.edu/technical_papers/fuzz-revisited.pdf.

....code (which may not be available for a COTS component) and are in general more suitable for test set coverage analysis than robustness testing. 5 Two portable software approaches are targeted specifically at testing the robustness of software components. The University of Wisconsin Fuzz approach [7] tests user programs (e.g. UNIX command line utilities) with both random and crafted input streams, looking for program crashes and system hangs. Its goal is to quantify and describe the robustness of UNIX systems from the typical interactive user s point of view. The Carnegie Mellon University ....

Miller, B., 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, Computer Sciences Technical Report 1268, University of Wisconsin--Madison, 1995.

....technique that performs fault injection on source code, but is in general more suitable for test set coverage analysis than robustness testing. Two portable SWIFI approaches are specifically targeted at testing the robustness of software components. The University of Wisconsin Fuzz approach [10] generates a random input stream to various Unix programs and detects crashes and hangs. The Carnegie Mellon robustness benchmarking approach [11] 12] tests individual system calls with specific input values to detect crashes and hangs. Both techniques focus on robustness problems that can ....

Miller, B., et al., Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services, Computer Science Technical Report 1268, Univ. of Wisconsin-Madison, 1995.

....the Fuzz project at the University of Wisconsin used random noise (or fuzz ) injection to discover robustness problems in operating systems. That work documented the source of several problems, and then discovered that the problems were still present in operating systems several years later [Miller98][Miller89] The Fuzz approach tested specific OS elements and interfaces (compared to the completely random approach of Crashme) although it still relied on random data injection. Other work in the fault injection area has also tested limited aspects of robustness. The FIAT system [Segall90] ....

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.

....algorithm for solving the integer constraints. Finally, security knowledge is used to formulate heuristics that capture the class of security relevant bugs that tend to occur in real programs. Others have applied runtime code testing techniques to the problem, using, e.g. black box testing [41, 42] or software fault injection [21] to find buffer overruns in real world applications. However, runtime testing seems likely to miss many vulnerabilities. Consider the following example: if (strlen(src) sizeof dst) break; strcpy(dst, src) Note that off by one errors in buffer management, ....

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

.... here, and is described at length elsewhere [15, 17, 21] Many C programs have buffer overflow vulnerabilities, both because the C language lacks array bounds checking, and because the culture of C programmers encourages a performance oriented style that avoids error checking where possible [14, 13]. For instance, many of the standard C library functions such as gets and strcpy do not do bounds checking by default. The common form of buffer overflow exploitation is to attack buffers allocated on the stack. Stack smashing attacks strive to achieve two mutually dependent goals, illustrated in ....

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. Report, University of Wisconsin, 1995.

....the adoption of Cluster Computing technology because of the large amount of data to be processed and or because of their long computation times. Good OS and system software choices may reduce the risk but avoiding it altogether is beyond current technology. For instance, a study conducted in 1995 [45] showed that basic Unix application abort or hang up when subject to random input due to software bugs in the range of 18 to 23 for major commercial distributions (with the best robustness shown by GNU Linux applications, in the range of 7 to 9 ) Substantial scientific and technological ....

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-95-1268, Computer Science Department, University of Wisconsin, April 1995.

....capabilities of standard type systems, and different languages deal with such run time errors in different ways. Unsafe languages like C [17] 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 [20]. In contrast, safe languages The authors are supported in part by NSF grants CCR 91 22518 and CDA 9414170. such as SML [21] and Scheme [3] equip all program operations with appropriate run time checks. These checks guarantee that misapplications of program operations immediately raise an ....

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.

....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, 19, 23, 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.

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.

No context found.

Barton Miller, David Koski, 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. ftp://grilled.cs.wisc.edu/technical papers/fuzz-revisited.pdf, February 1998.

No context found.

Barton P. Miller, David Koski, Cjin Pheow Lee, Vivekananda Maganty, Ravi Murthy, Akitkumar Natarajan, and Jeff Steidl. Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services. Technical report, Computer Science Department, University of Wisconsin, November 1995.

No context found.

Barton P. Miller, David Koski, Cjin Pheow Lee, Vivekananda Maganty, Ravi Murthy, Akitkumar Natarajan, and Jeff Steidl. Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services. Technical report, Computer Science Department, University of Wisconsin, November 1995.

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