This site graciously hosted
by our friends at
7. Survey and Analysis of Available Tools
Table of Contents |
Previous Section |
7.1 The Status Quo
There are many tools available today which claim to help a
programmer detect security problems. Unfortunately, only a few are
of professional quality and commercial grade, and most of these are
either limited in scope, hard to use, or not actually available. In
this section the best of the breed are reviewed.
Due to the scope of this survey we have not formally evaluated any
of these tools. We have, however, quickly examined the source code
of some, where it was available, and also canvassed the security
community for reports of experience with the tools. Several of them,
such as FormatGuard, are in fact are quite new.
In order to provide a single reference description of several of the
products, excerpted from each company?s own marketing materials, are
7.2 Approaches used by the tools
Several different approaches are possible to the problem of checking
or compensating for bugs that cause security holes. Three dominate
7.3 Leaders in the field
- 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
- 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)
- 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 top three tools in each of the approaches are reviewed as well
as a tenth product: Jtest, which does not specifically target
security bugs, but appears very useful for this purpose.
Table 2. Leaders in Secure Coding Tools.
- 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
(Asterisk* Denotes Tool is Part of a Commercial Suite)
7.4 Product summaries from leading vendors
AtStake (also "@stake") provides security consulting services. Its
technical team is headed by "Mudge", a founder of the so-called
"L0pht" and the author of the security scanner SLINT. He was
consulted in detail about SLINT for the purposes of this survey.
(Despite what the website says, SLINT is not currently available
for licensing. Its reputation, however, warrants keeping on eye out
for it to become available.)
The text which follows describes @stake's: SLINT, L0phtwatch, and
Feszer 1.0. All material is quoted verbatim, with minor formatting
changes, from http://www.atstake.com/.
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.
7.4.2 Cigital Security
SLINT is a core product to be sold into an existing GUI
What will it examine and on what platforms?
- 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.
L0phtwatch is a temporary file watcher for finding potential
race conditions in applications.
- 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
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.
Cigital Security advertises that their Software Security Group
"designs, analyzes and tests security-critical software." The
following information is quoted from their web site at
Cigital's lead product is ITS4.
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.
Cigital was formerly known as Reliable Software Technologies. FIST
(Fault Injection Security Tool) was developed at Reliable Software
Technologies under a DARPA/ITO grant. It does not appear to be
available commercially, but more investigation is probably
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
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
7.4.3 University of Virginia
David Evans of the University of Virginia wrote and (with a small
staff) supports LCLint. The following material is quoted verbatim
from the "LCLint User's Guide", found at
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
7.4.4 Avaya Labs Research
Some problems detected by LCLint include:
LCLint checking can be customized to select what classes of
errors are reported using command line flags and stylized
comments in the code.
- 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
- 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
- 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
LibSafe was developed at Bell Labs. It is now marketed by Avaya
Labs Research. All material is quoted verbatim from
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.
Concerning LibSafe, David Wheeler makes several good points [Wheeler
2001] about its limitations.
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
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
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
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.
7.4.5 Rational Software
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
Rational Software bills itself as "the E-Development company." It
offers a suite of relevant tools. The following descriptions are
taken verbatim from http://www.rationalsoftware.com/.
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 Quantify and
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.
StackGuard is part of a suite of tools, called "Immunix", offered by
Wirex. The following descriptive material is excerpted verbatim from
The Immunix tool set was originally developed as a
research project at the
Oregon Graduate Institute of
Science & Technology, and now is an on-going project
at WireX Communications,
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
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
Sanctum was founded by a group of technical experts with experience
in Israeli intelligence and cyber-security. They offer a suite of
products aimed at the security of web-based applications. The
material below is quoted verbatim from
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
7.4.8 Secure Labs, Inc.
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,
...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.
- 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.
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 tests web-based application software, primarily with fault
injection techniques. The following description is taken verbatim
from the Secure Labs website at
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
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.
Parasoft, Inc. markets Jtest, a unit testing tool for Java classes.
While it is not specifically a security tool, the descriptions at
http://www.parasoft.com/ do appear promising for this
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.
7.5 Less popular, independent, and unsupported software
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
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.
In addition to the market leaders listed above, several other
packages exist today which may be of use in developing or testing
secure software. Here is a representative sampling.
BOWall is independently marketed by Andrey Kolishak. It aims to
protect binaries executing on Windows NT from buffer overflows. It
is sometimes described as a "Windows NT StackGuard." The following
is text taken verbatim from
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
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
As an example of the sort of tools one can easily find on the
Internet after just a little looking, we include here the freely
available bsyrin1. The code is credited to "Digital Monkey"
(email@example.com), and is archived at
http://b0f.freebsd.lublin.pl/, whence we take its
description and the accompanying sample run.
Since bsyrin1 is an independent, unsupported effort, and source code
is not (to our knowledge) available, we cannot recommend its use.
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 ...connected
220 ProFTPD 1.2.0pre9 Server (User FTP service)
331 Password required for demo.
230 User demo logged in.
>SENDING PARAMETER #1 [1000 buffers]...done
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA: File name too long
>SENDING PARAMETER #2 [1000 buffers]...done
BBBBBBBBBBBBBBBBBBB: No such file or directory
Server terminated normally.
Press any key to exit...
"Buffy the Buffer Overflow Slayer" is an independent effort by
Michael Howard, supplied in his recent book [Howard 2001]. It is a
modest program, but well written, and makes an excellent example of
a simple filter. Contacting the author, we obtained an updated
version of buffy and his permission to include it in this study.
The program is included herein its
Michael Howard is an employee of Microsoft, in a senior technical
position. But the software was written and supplied by Mr. Howard as
an individual and not in his capacity as an employee. It is
completely unsupported software, written (and included here) only as
7.5.4 GCC bounds-checking patch
Richard Jones and Paul Kelly of Imperial College developed a
bounds-checking patch for the gcc compiler in 1995 [Jones 1995]. The
software is currently being maintained by Haj Ten, of the
Netherlands. See http://web.inter.nl.net/hcc/Haj.Ten.Brugge/for
current status and availability.
The consensus evaluation of the pacth is that the bounds checking
works well. However, an occasionally significant impact on
performance--and the sheer size of the executables produced--offer a
significant barrier to general adoption of this method.
The following notes are quoted verbatim from the website created by
Jones and Kelly, http://www.doc.ic.ac.uk/~phjk/BoundsChecking.html.
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:
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.
- 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
- 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
- If the base pointer's storage region is an array, say
A, 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). 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 is a valid pointer
(we still check it when it is used).
The software is distributed free under GNU copyleft, in the
form of a patch to the gcc source distribution.
- 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
- Matrix multiply (ikj, using array subscripting):
- Execution time: slowdown of around 30 compared to
- Compile-time: slowdown of around 2.
- Executable size: roughly the same.
"Are you tired of yet more externally exploitable buffer overflows
in C programs? Do you want to audit your source for common mistakes?
If so, PScan is for you!"
So begins the enthusiastic description by the author of Pscan, a
"limited problem scanner for C source files." The text below is also
quoted from http://www.striker.ottawa.on.ca/~aland/pscan/.
What PScan does:
The program is distributed as Open Source, but under the GNU
copyleft, so we are not able to show the source code here.
- Scans C source files for problematic uses of printf style
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.
sprintf(buffer, variable): Bad! Possible security
sprintf(buffer, "%s", variable): Ok
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:
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.
- Scan for traditional buffer over-flows. You should use a
bounds-checking compiler for that.
- Scan for any other mis-use of function parameters.
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/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
In surveying the field of secure code analysis one finds a
surprising number of references to StackShield. Here is a run-down.
By: "Vindicator." Source: http://www.angelfire.com/sk/stackshield/index.html.
The following text is rendered verbatim (indeed, letter by letter).
Last Stack Shield version: 0.7 beta 07 Jan 2000
Table of Contents |
Previous Section |
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
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.