• Static filters. The most popular static filters scan C/C++ code. One or two (discussed later) have emerged which target Java. The C checkers look for and flag uses of strcpy and other "suspect" library calls. In any case, the output of these programs is a set of cautions, questions, or--in a few cases--recommendations.
• Compiled-in and link-time checks. A different approach entirely is to compile the program as is, but insert "hooks" in the object code, called "catch basins", or "canaries", which can be used to diagnose (or even compensate for) memory-use problems.
• Fault injection/cascade. Another very promising approach which is gaining in popularity is "fault injection" testing. This entails bombarding a running program with input designed to bring faults to the surface.

• The best program in the "static checker" class is probably SLINT, from @Stake. But no one knows for sure, because, contrary to its initial published intent, @Stake has decided not to release or license SLINT, reserving use instead to its own consulting work. ITS4 from Cigital appears sound and useful, worth investigating: the most common criticism uncovered is that it returns many false positives. It has also been confirmed that many developers find LCLint (from the University of Virginia) useful. Its main drawback, judging from the opinions canvassed, is that specially formatted comments must be inserted in the source code in order to help guide the code-checking engine.
• Purify is an excellent example of the diagnostic class. LibSafe looks promising; now that it has moved from Bell Labs to Avaya research labs, it is expected that the commercial use of it to increase rapidly. StackGuard, which inserts a "canary" marker in the stack-handling object code, is quickly gaining recognition. But its popularity has resulted in a flurry of published methods aimed at circumventing it (which of course Immunix has replied to with patches and a new version). Immunix also has a new entry, FormatGuard, aimed at "format string overflow" bugs in C/C++ code.
• FIST (Fault Injection Software Tool) was the first widely available program to take its approach. But it seems to have been produced as a proof-of-concept project for DARPA, and, though it is prominently displayed on the Cigital home page, so far as can be determined it is not available commercially. AppScan and AppShield, from Sanctum, use the same basic approach in testing web-based application software. Each appears useful and popular. These tools warrant further review. The Hailstorm product, from Secure Labs, Inc., seems to aim at the same market but appears to be new and as yet weakly supported.

Table 2. Leaders in Secure Coding Tools.
(Asterisk* Denotes Tool is Part of a Commercial Suite)

Source code security analyzers are publicly available in the black hat community and are being used to scan for exploitable code. SLINT will help you render the PD wares obsolete.

SLINT is a core product to be sold into an existing GUI development package.

• Helps people be proactive while writing secure code by highlighting potentional hot spots of exploitable routines and poor memory allocations.
• Identifies suspect blocks of code.
• Makes the task of security review more palatable so you don't need a team of high-level experts to go through megabytes of code.
• Supplies solutions and/or alternatives to problem areas.
• Most security problems could have been fixed at the beginning of development. Secure applications must start with a secure base. The Best *BANG* for the buck is to be proactive at the start of program creation.
• Easy to implement into existing Y2K code review packages.

What will it examine and on what platforms?

• Unix/NT
• C, C++ (JAVA in the future)
• elf-32 binaries
• a.out files
• buffer overflows
• improper SetUID of files
• randomness code faults
• race conditions
• incorrect access of memory
• improper flags on critical system calls

L0phtwatch is a temporary file watcher for finding potential race conditions in applications.

Feszer 1.0... will log parameters to certain string operations exported from MSVCRT.dll, such as *printf(), strcat(), etc. It can help in detecting format string vulnerabilities and buffer overflows in a blind auditing environment.

We developed ITS4 to help automate source code review for security. ITS4 is a simple tool that statically scans C and C++ source code for potential security vulnerabilities. It is a command-line tool that works across Unix and Windows platforms.

ITS4 scans source code, looking for function calls that are potentially dangerous. For some calls, ITS4 tries to perform some code analysis to determine how risky the call is. In each case, ITS4 provides a problem report, including a short description of the potential problem and suggestions on how to fix the code.

ITS4 and its source code are provided [free] to the security community for any use that does not compete with Cigital's consulting practice.

Our approach employs white-box software analysis techniques that exercise target software, trip up the software as it runs using fault injection, and detect security problems with assertions. Faults that are injected identify potential vulnerabilities in the code. Our algorithm, called Adaptive Vulnerability Analysis (AVA), simulates anomalous and malicious uses of a software program to determine if the program can be exploited. AVA can be used to determine which inputs and flaws in a program can undermine the security of the system in which the program executes. AVA derives from models developed for assessing software fault tolerance; in particular, Extended Propagation Analysis (EPA), which has been employed to analyze safety-critical software. AVA does not provide an absolute security metric. However, it can be used to provide relative metrics of the frequency with which security of a system is violated.

LCLint is a tool for statically checking C programs. With minimal effort, LCLint can be used as a better lint. If additional effort is invested adding annotations to programs, LCLint can perform stronger checks than can be done by any standard lint.

Some problems detected by LCLint include:

• Violations of information hiding. A user-defined type can be declared as abstract, and a message is reported where code inappropriately depends on the representation of the type.
• Inconsistent modification of caller-visible state. Functions can be annotated with information on what caller-visible state may be modified by the function, and an error is reported if the modifications produced by the function contradict its declaration.
• Inconsistent use of global variables. Information on what global and file scope variables a function may use can be added to function declarations, and a message is reported if the implementation of the function uses other global variables or does not use every global variable listed in its declaration.
• Memory management errors. Instances where storage that has been deallocated is used, or where storage is not deallocated (memory leaks).
• Dangerous data sharing or unexpected aliasing. Parameters to a function share storage in a way that may lead to undefined or undesired behavior, or a reference to storage within the representation of an abstract type is created.
• Using possibly undefined storage or returning storage that is not completely defined (except as documented).
• Dereferencing a possibly null pointer.
• Dangerous macro implementations or invocations.
• Violations of customized naming conventions.
• Program behavior that is undefined because it depends on order of evaluation, likely infinite loops, fall-through cases, incomplete logic, statements with no effect, ignored return values, unused declarations, and exceeding certain standard limits.

LCLint checking can be customized to select what classes of errors are reported using command line flags and stylized comments in the code.

In contrast to previous work, our method does not require any modification to the operating system and works with existing binary programs. Our method does not require access to the source code of defective programs, nor does it require recompilation or off-line processing of binaries. Furthermore, it can be implemented on a system-wide basis transparently. Our solution is based on a middleware software layer that intercepts all function calls made to library functions that are known to be vulnerable. A substitute version of the corresponding function implements the original functionality, but in a manner that ensures that any buffer overflows are contained within the current stack frame, thus, preventing attackers from 'smashing' (overwriting) the return address and hijacking the control flow of a running program. We have implemented our solution on Linux as a dynamically loadable library called libsafe. Libsafe has demonstrated its ability to detect and prevent several known attacks, but its real benefit, we believe, is its ability to prevent yet unknown attacks. Experiments indicate that the performance overhead of libsafe is negligible.

It is generally accepted that the best solution to buffer overflow and format string attacks is to fix the defective programs. However, fixing defective programs requires knowing that a particular program is defective. The true benefit of using libsafe and other alternative security measures is protection against future attacks on programs that are not yet known to be vulnerable. That is why we made libsafe version 2.0 source code under the GNU Lesser General Public License.

In contrast to most other solutions, libsafe is extremely easy to install and use. No source code, recompilation, or special expertise is needed. And, the installation only takes a few minutes.

Libsafe does not support programs linked with libc5. If you find that a process protected by libsafe experienced a segmentation fault, use the ldd utility to determine if the process is linked with libc5. If that is the case, then you will either need to recompile/relink the application with libc6 (i.e., glibc) or to download a newer version that has been linked with libc6. From our experience, most applications are offered with a libc6 version.

Libsafe only protects a small set of known functions with obvious buffer overflow issues. [This] list is significantly shorter than the list of functions... known to have this problem. It also won't protect against code you write yourself (e.g., in a while loop) that causes buffer overflows.

Even if libsafe is installed in a distribution, the way it is installed impacts its use. The documentation recommends setting LD_PRELOAD to cause libsafe's protections to be enabled, but the problem is that users can unset this environment variable... causing the protection to be disabled for programs they execute!

Libsafe only protects against buffer overflows of the stack onto the return address; you can still overrun the heap or other variables in that procedure's frame.

Unless you can be assured that all deployed platforms will use libsafe (or something like it), you'll have to protect your program as though it wasn't there.

LibSafe seems to assume that saved frame pointers are at the beginning of each stack frame. This isn't always true. Compilers (such as gcc) can optimize away things, and in particular the option "-fomit-frame-pointer" removes the information that libsafe seems to need. Thus, libsafe may fail to work for some programs.

Rational Purify, Quantify and PureCoverage are a complete set of automated runtime analysis tools for improving application performance and quality for software developers who need to build and deploy resilient, reliable software applications in C/C++, Java and VB.

Purify, Quantify and PureCoverage provide Windows and UNIX developers with immediate productivity gains by easily integrating with existing processes. With no need for source code or lengthy recompilation, these tools help developers visualize the execution of their code, with comprehensive and repeatable information about ALL of the application, with or with out source -- including all third party components...

Rational Purify, Rational Quantify and Rational PureCoverage are ideal tools for testers to use early and frequently throughout development because they are easily incorporated into your existing processes such as nightly builds. These tools deliver a broad range of valuable diagnostic information. Rational Purify locates hard-to-find memory leaks and run-time errors that can cause program crashes. Rational Quantify pinpoints performance bottlenecks in your application. Rational PureCoverage identifies untested code and provides code-coverage analysis. All three tools incorporate Rational's patented Object Code Insertion technology so they can test any application or component even when the underlying source code is not available.

The Immunix tool set was originally developed as a DARPA-funded research project at the Oregon Graduate Institute of Science & Technology, and now is an on-going project at WireX Communications, Inc...

Immunix is a family of tools designed to enhance system integrity by hardening system components and platforms against security attacks. The Immunix OS is a [RedHat Linux 7.0] platform hardened with the Immunix tool set. Immunix works by hardening existing software components and platforms so that attempts to exploit security vulnerabilities will fail safe, i.e. the compromised process halts instead of giving control to the attacker, and then is restarted. The software components are effectively "laminated" with Immunix technologies to harden them against attack...

Immunix System 7 (Beta) is a server platform based on the distribution and optimized for server operations. System 7 comes with the newly released SubDomain and FormatGuard Immunix Tools.

SubDomain quarantines programs to protect the rest of the system from damage.

FormatGuard is the first general solution for format bugs. Format bugs a new class of vulnerability affecting all operating systems, which permit hacker attacks.

StackGuard 2.0 is a compiler that emits programs hardened against "stack smashing" attacks. Stack smashing attacks are the most common form of penetration attack. Programs compiled with StackGuard are largely immune to stack smashing attack... StackGuard is an extension to gcc that provides an integrity check for function call activation records, making programs largely immune to stack smashing attacks? [and] provides robust automatic protection against the all-too-common problem of stack smashing vulnerabilities. However, this protection is only provided for programs and libraries that are re-compiled with StackGuard.

Sanctum's AppScan is the first and only security software that automates the complex, manual task of auditing web applications. It enables developers and auditors of all levels to detect, assess, and fix application vulnerabilities and deliver cost-effective audits rapidly. AppScan simulates application attacks, points to potential security loopholes and provides guidance and advice on how to mend any bugs - before the hacker finds them!

Sanctum's AppShield stops application-level attacks. AppShield autonomously and intelligently identifies the legitimate requests made of an eBusiness site and permits only those actions to take place. AppShield secures your site by detecting, preventing, logging and alerting any type of application manipulation through the browser...

Sanctum's AppShield software secures your site by blocking any type of application manipulation through the web. It is an active system that monitors and responds to any unusual or unauthorized behavior anywhere within your site. When the system detects a potential act of Web Perversion against one of your applications, it:

• blocks the action and logs it
• alerts you to who, when and where and
• sends a warning to the possible perpetrator that the questionable behavior has been detected and recorded.

...Once a session is established, AppShield analyzes each HTML page that belongs to that session as it is being forwarded to the browser. The Policy Recognition Engine analyzes the page, looking for information such as CGI parameters, hidden field values, dropdown menu values, and maximum size of expected text fields. Based upon this run-time analysis, AppShield automatically determines the security policy of the application. Additional legal requests cause AppShield to adjust the security policy for the session.

Sanctum's AppAudit will help you find the holes in your Web site before somebody else does. AppAudit is a remote audit on your Web site conducted by Sanctum, to determine the general security of your site at the application level. AppAudit reveals Web application vulnerabilities, including:

• Hidden Manipulation
• Parameter Tampering
• Cookie Poisoning
• Stealth Commanding
• Forceful Browsing
• Backdoors and Debug options
• Configuration Subversion
• Buffer Overflow
• Vendor-assisted Hacking

Hailstorm is the next generation of security scanners, a proactive scanning device (PSS). Hailstorm eliminates the pain of bug-tracking and vulnerability databases. It allows the consumer to locate vulnerabilities that have never been publicly reported or discovered. Hailstorm puts the consumer in a position of power with regards to potential attackers or even IT vendors. Hailstorm does this by giving them the power to know where the vulnerability points are and from an IT vendor point of view, know where the weaknesses of a product are before purchasing. In addition, because our PSS technology does not rely on a vendor supplied bug database, customers cannot only test public software, but also proprietary and customized systems...

Up until now, security scanners have relied on very specific databases of known vulnerabilities. When new vulnerabilities are reported publicly, the scanner vendor must race to add new signatures to their bug database. This content must then be pushed out to the consumer so they can scan their networks for the new vulnerability. This model is fundamentally flawed. It puts the consumer 10 steps behind the attacker, and in a constant state of catch up.

Furthermore, security scanners often do not actually attempt to exploit a certain bug. Instead, they infer or deduct that a bug MAY BE PRESENT because a given file exists, or a particular service is running. The result is a haphazard report of "maybes" and "false-positives" which end up costing the IT staff tens of thousands of dollars in lost time...

Hailstorm performs a very methodical analysis of all on line software. Using its PSS technology, Hailstorm discovers bugs based upon their classification. Example classifications include buffer overflows, unfiltered file operations, parsing bugs, data leakage, and denial of service issues.

Using Hailstorm, the IT staff can discover new vulnerabilities and publish their own security advisories. This puts the power back into the hands of the people who are implementing the network and takes it away from the software vendors or hardware vendors who are releasing buggy and untested code. Software vendors can also use Hailstorm in house to help increase the code quality and product reliability.

Jtest is the world's most complete automatic class testing tool for Java. Its purpose is to help you increase your Java software's reliability while dramatically reducing the amount of time you spend testing. Jtest is designed to reduce the burden on Java developers as they write and test their programs from the class level at the earliest stages of development... Jtest automatically performs white-box testing, black-box testing, regression testing, and static analysis (coding standard enforcement) of Java code... Jtest enforces coding standards automatically with its static analysis feature. Jtest enforces a sophisticated set of Java coding standards as well as a set of Enterprise JavaBeans-specific coding standards.

During white-box testing, Jtest tests your code's internal structure at the class (or module) level and validates that the class, when passed unexpected input, will not cause the program to crash. Jtest uses ParaSoft's patented Test Generation System technology (patent #5,784,553 & 5,761,408) to automatically generate input test cases that expose uncaught, undocumented runtime exceptions...

To perform black-box testing, Jtest automatically provides a set of inputs based on sophisticated analysis and then executes the class with the inputs. You may also provide your own sets of inputs to be used by Jtest.

During regression testing, Jtest checks for errors introduced into previously correct software during modifications. Jtest remembers outcomes from previous runs, compares the outcomes every time the class is tested, and reports an error if an outcome changes.

Jtest performs static analysis by parsing the Java source and applying to it a set of coding standards. Jtest reports violations of these standards as errors. Java coding standards help you avoid errors as you write in the Java language and make your code easier to reuse, modify, and maintain.

BOWall is the program that implement protection against buffer overflow attacks for the binary executed Windows NT 4.0 files. The protection is given as two methods.

Vulnerable functions monitoring. The updating of set potentially vulnerable DLL functions is made. List of such functions concern strcpy, wstrcpy, strncpy, wstrncpy, strcat, wcscat, strncat, wstrncat, memcpy, memmove, sprintf, swprintf, scanf, wscanf., gets, getws, fgets, fgetws. The updating consists in addition of a integrity check code that checks local variable frame base pointer.

Obstacle to execution of dynamic libraries functions from data and stack memory. The essence of method consists in an obstacle to exploit functionality. It's produced at the expense of updating exported vulnerable DLL functions by addition of check code that checks the address of a call of the given functions. If the address of a call belongs to data or stack then program execution is blocked. Both methods are implemented to detect buffer overflow or exploit activity and terminate process by call of the privileged instruction at triggered state. The given protection methods only detect the fact of overflow, but not prevent overflow.

A buffer overflow is a really serious security problem and if one your servers has it, it could be exploited or be subjected to an attack that could lead to your box being comprimised. Buffer Syringe is a tool for checking servers/daemons (e.g. ftp) for buffer overflow(s) (holes) on given parameter(s).

Buffer Syringe has a configuration file where you place in the parameters needed to run the program.

Buffer Syringe 1.0
by: Digital Monkey (b0f)

>Connecting to [www.somehost.com] on port [21]...connected
220 ProFTPD 1.2.0pre9 Server (User FTP service) [www.somehost.com]
>LOGGING IN
>SENDING USERNAME...done
331 Password required for demo.
>SENDING PASSWORD...done
230 User demo logged in.
>SENDING PARAMETER #1 [1000 buffers]...done
550
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA: File name too long

>SENDING PARAMETER #2 [1000 buffers]...done
550
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBB: No such file or directory

Server terminated normally.
Press any key to exit...

Our technique provides full checking without changing the representation of pointers. We therefore avoid most of the problems... Some efficiency problems remain, but bounds checking need not be used in all of the files which make up a program, so trusted, performance-critical code can run at full speed.

The key idea is this:

• Every pointer expression derives a new pointer from a unique original pointer. For example, in "p+2*k+1" we derive a new pointer from "p." By contrast, in "p+q" or "p-q", we derive an integer from two pointers. The integer is nonsense as a pointer. We call this unique original pointer the expression's "base" pointer.
• Every pointer value is valid for just one allocated storage region. An allocated storage region may be a global, static, automatic or heap-allocated variable, structure or array.
• We can check whether a pointer arithmetic expression is valid by finding its base pointer's storage region, then checking that the expression's result points into the same storage region.
• If the base pointer appears not to refer to any valid region, then it must refer to a region originating in unchecked code. In this case we cannot check the result of the expression.
• If the base pointer's storage region is an array, say A[100], then (according to the ANSI standard) it is valid to calculate the address of the element after the last one valid (in this example, the address of A[100]). This is so that a pointer can be incremented and then tested for the loop exit condition. To prevent false alarms, we pad the storage layout of arrays to that A[100] is a valid pointer (we still check it when it is used).

We made some small modifications to the C front-end of gcc, the Gnu C compiler, to add code to check pointer arithmetic and use, and to maintain a table of known allocated storage regions. We went to some trouble to ensure that gcc's optimizer could handle the added code, and employed modest inlining for efficiency.

Performance notes:

• Nfib (dumb doubly-recursive Fibonacci): no slowdown.
  • Execution time: same.
  • Compile-time: slowdown of 3 (very small)
  • Executable size: much larger due to inclusion of library.
• Matrix multiply (ikj, using array subscripting):
  • Execution time: slowdown of around 30 compared to unoptimised.
  • Compile-time: slowdown of around 2.
  • Executable size: roughly the same.

The software is distributed free under GNU copyleft, in the form of a patch to the gcc source distribution.

What PScan does:

• Scans C source files for problematic uses of printf style functions. e.g.:

sprintf(buffer, variable): Bad! Possible security breach!
sprintf(buffer, "%s", variable): Ok

See the Format bugs post to BUGTRAQ for a good explanation of the security problems associated with sprintf(buffer, variable);. These security issues also currently involve being able to bypass stack protection mechanisms like StackGuard. I have submitted a paper to BUGTRAQ describing the issue.

All of these security problems can also occur with any printf-style function. It is simple to fall into the trap of misusing printf and friends, thus, the need for PScan.

What PScan does not do:

• Scan for traditional buffer over-flows. You should use a bounds-checking compiler for that.
• Scan for any other mis-use of function parameters.

The functionality given by PScan is limited. Yet it may be useful. I'm not going to claim it's the be-all and end-all of security scanners, but it does one thing, and it does it simply, and reasonable well.

Let's run PScan over everyone's favorite program: wu-ftpd. The text below is a sample of the output from PScan:

[aland@www pscan]$ ./pscan -p wu-ftpd.pscan ../wu-ftpd-2.6.1/src/*.c
../wu-ftpd-2.6.1/src/ftpd.c:2575 FUNC reply
../wu-ftpd-2.6.1/src/ftpd.c:6277 FUNC syslog
../wu-ftpd-2.6.1/src/ftpd.c:6292 FUNC syslog
../wu-ftpd-2.6.1/src/ftpd.c:6438 FUNC reply
[aland@www pscan]$

Last Stack Shield version: 0.7 beta 07 Jan 2000
Last site update: 08 Jan 2000

Stack Shield is a development tool that adds protection from "stack smashing" technique attacks to programs without any change in the code.

This technique consists in overflowing buffers by sending to the program an unexpected amount of input data, causing the overwrite of the function RET address that changed to anything the attacker wants (usually to an address of a location within the buffer overflowed). When a function returns it jumps to its RET address, executing the istruction put into the buffer. So the attacker gets the program executing any istruction he wants.

The Stack Shield protection system copy the RET address in an unoverflowable location (the beginning of the DATA segment) on function prologs (on function beginnings) and check if the two values are different on function epilogs (before the function returns). If the two values are different the RET address has been modified so Stack Shield terminates the program or try to let the program run ignoring the attack (risking at maximum a program crash).

Stack Shield implements also range checks on the RET address and the CALLs addresses. (It is able to stop frame pointer and function pointer overwrite attacks).

Stack Shield works as a assembler file processor and is supported by GCC/G++ front ends to automatize the compilation. No code change or other special operations are required (Only makefiles need minor changes, but a front end will be added in future versions to automatize this).

For more detailed info about Stack Shield please refer to the TECNICAL file included in the downloadable archives.