Buffer Overflow Attacks

Buffer Overflow Attacks

Buffer Overflow Attacks

Buffer Overflows:
The Essentials
3
Solutions in this Chapter:
■ The Challenge of Software Security
■ The Increase of Buffer Overflows
■ Exploits vs. Buffer Overflows
■ Definitions
Introduction
Buffer overflows. In most information technology circles these days, the term
buffer overflows has become synonymous with vulnerabilities or in some cases,
exploits. It is not only a scary word that can keep you up at night wondering if
you purchased the best firewalls, configured your new host-based intrusion prevention
system correctly, and have patched your entire environment, but can
enter the security water-cooler discussions faster than McAfee’s new wicked
anti-virus software or Symantec’s latest acquisition. Buffer overflows are proof
that the computer science, or software programming, community still does not
have an understanding (or, more importantly, firm knowledge) of how to design,
create, and implement secure code.
Like it or not, all buffer overflows are a product of poorly constructed software
programs.These programs may have multiple deficiencies such as stack
overflows, heap corruption, format string bugs, and race conditions—the first
three commonly being referred to as simply buffer overflows. Buffer overflows
can be as small as one misplaced character in a million-line program or as complex
as multiple character arrays that are inappropriately handled. Some buffer
overflows can be found in local programs such as calendar applications, calculators,
games, and Microsoft Office applications, whereas others could be resident
in remote software such as e-mail servers, FTP, DNS, and the ever-popular
Internet Web servers.
Building on the idea that hackers will tackle the link with the least amount
of resistance, it is not unheard of to think that the most popular sets of software
will garner the most identified vulnerabilities. While there is a chance that the
popular software is indeed the most buggy, another angle would be to state that
the most popular software has more prying eyes on it.
If your goal is modest and you wish to simply “talk the talk,” then reading
this first chapter should accomplish that task for you; however, if you are the
ambitious and eager type, looking ahead to the next big challenge, then we welcome
and invite you to read this chapter in the frame of mind that it written to
prepare you for a long journey.To manage expectations, we do not believe you
will be an uber-hacker or exploit writer after reading this, but you will have the
tools and knowledge afterward to read, analyze, modify, and write custom buffer
overflows with little or no assistance.
The Challenge of
Software Security
Software engineering is an extremely difficult task and of all software creationrelated
professions, software architects have quite possibly the most difficult task.
Initially, software architects were only responsible for the high-level design of
the products. More often than not this included protocol selection, third-party
component evaluation and selection, and communication medium selection.We
make no argument here that these are all valuable and necessary objectives for
any architect, but today the job is much more difficult. It requires an intimate
knowledge of operating systems, software languages, and their inherent advantages
and disadvantages in regards to different platforms. Additionally, software
architects face increasing pressure to design flexible software that is impenetrable
to wily hackers. A near impossible feat in itself.
Gartner Research has stated in multiple circumstances that software and
application-layer vulnerabilities, intrusions, and intrusion attempts are on the
rise. However, this statement and its accompanying statistics are hard to actualize
due to the small number of accurate, automated application vulnerability scanners
and intrusion detection systems. Software-based vulnerabilities, especially
those that occur over the Web are extremely difficult to identify and detect.
SQL attacks, authentication brute-forcing techniques, directory traversals, cookie
poisoning, cross-site scripting, and mere logic bug attacks when analyzed via
attack packets and system responses are shockingly similar to those of normal or
non-malicious HTTP requests.
Today, over 70 percent of attacks against a company’s
network come at the “Application layer,” not the
Network or System layer.—The Gartner Group
4 Chapter 1 • Buffer Overflows: The Essentials
Buffer Overflows: The Essentials • Chapter 1 5
As shown in Table 1.1, non-server application vulnerabilities have been on
the rise for quite some time.This table was created using data provided to us by
government-funded Mitre. Mitre has been the world leader for over five years
now in documenting and cataloging vulnerability information. SecurityFocus
(acquired by Symantec) is Mitre’s only arguable competitor in terms of housing
and cataloging vulnerability information. Each have thousands of vulnerabilities
documented and indexed. Albeit, SecurityFocus’ vulnerability documentation is
significantly better than Mitre’s.
Table 1.1 Vulnerability Metrics
Exposed
Component 2004 2003 2002 2001
Operating System 124 (15%) 163 (16%) 213 (16%) 248 (16%)
Network Protocol 6 (1%) 6 (1%) 18 (1%) 8 (1%)
Stack
Non-Server 364 (45%) 384 (38%) 267 (20%) 309 (21%)
Application
Server Application 324 (40%) 440 (44%) 771 (59%) 886 (59%)
Hardware 14 (2%) 27 (3%) 54 (4%) 43 (3%)
Communication 28 (3%) 22 (2%) 2 (0%) 9 (1%)
Protocol
Encryption Module 4 (0%) 5 (0%) 0 (0%) 6 (0%)
Other 5 (1%) 16 (2%) 27 (2%) 5 (0%)
Non-server applications include Web applications, third-party components,
client applications (such as FTP and Web clients), and all local applications that
include media players and console games. One wonders how many of these vulnerabilities
are spawned from poor architecture, design versus, or implementation.
Oracle’s Larry Ellison has made numerous statements about Oracle’s
demigod-like security features and risk-free posture, and in each case he has been
proven wrong.This was particularly true in his reference to the “vulnerabilityfree”
aspects of Oracle 8.x software which was later found to have multiple buffer
overflows, SQL injection attacks, and numerous interface security issues.The point
of the story: complete security should not be a sought-after goal.
More appropriately, we recommend taking a phased approach with several
small and achievable security-specific milestones when developing, designing,
and implementing software. It is unrealistic to say we hope that only four vulnerabilities
are found in the production-release version of the product. I would
fire any product or development manager that had set this as a team goal.The
following are more realistic and simply “better” goals.
■ To create software with no user-provided input vulnerabilities
■ To create software with no authentication bypassing vulnerabilities
■ To have the first beta release version be free of all URI-based vulnerabilities
■ To create software with no security-dependant vulnerabilities garnered
from third-party applications (part of the architect’s job is to evaluate
the security and plan for third-party components to be insecure)
Microsoft Software Is Not Bug Free
Surprise, surprise. Another Microsoft Software application has been identified
with another software vulnerability. Okay, I’m not on the “bash Microsoft”
bandwagon. All things considered, I’d say they have a grasp on security vulnerabilities
and have done an excellent job at remedying vulnerabilities before production
release. As a deep vulnerability and security researcher that has been in
the field for quite some time, I can say that it is the most –sought-after type of
vulnerability. Name recognition comes with finding Microsoft vulnerabilities for
the simple fact that numerous Microsoft products are market leading and have a
tremendous user base. Finding a vulnerability in Mike Spice CGI (yes, this is
real) that may have 100 implementations is peanuts compared to finding a hole
in Windows XP, given it has tens of millions of users.The target base has been
increased by magnitudes.
Go with the Flow…
Vulnerabilities and Remote Code Execution
The easiest way to be security famous is to find a Microsoft-critical
vulnerability that results in remote code execution. This, complemented
by a highly detailed vulnerability advisory posted to a
dozen security mailing lists, and BAM!, you’re known. The hard part
is making your name stick. Expanding on your name’s brand can be
accomplished through publications, by writing open source tools,
speaking at conferences, or just following up the information with
new critical vulnerabilities. If you find and release ten major vulnerabilities
in one year, you’ll be well on your way to becoming
famous—or should we say: infamous.
Even though it may seem that a new buffer overflow is identified and
released by Microsoft every day, this identification and release process has significantly
improved. Microsoft releases vulnerabilities once a month to ease the pain
on patching corporate America. Even with all of the new technologies that help
6 Chapter 1 • Buffer Overflows: The Essentials
automate and simplify the patching problem, it still remains a problem. Citadel’s
Hercules, Patchlink, Shavlik, or even Microsoft’s Patching Server are designed at
the push of a button to remediate vulnerabilities.
Figure 1.1 displays a typical Microsoft security bulletin that has been created
for a critical vulnerability, allowing for remote code execution. Don’t forget,
nine times out of ten, a Microsoft remote code execution vulnerability is
nothing more than a vulnerability. Later in the book, we’ll teach you not only
how to exploit buffer overflow vulnerabilities, we’ll also teach you how to find
them, thus empowering you with an extremely monetarily tied information
security skill.
Remote code execution vulnerabilities can quickly morph into automated
threats such as network-borne viruses or the better known Internet worms.The
Sasser worm, and its worm variants, turned out to be one of the most devastating
and costly worms ever released in the networked world. It proliferated via
Buffer Overflows: The Essentials • Chapter 1 7
Figure 1.1 A Typical Microsoft Security Advisor
a critical buffer overflow found in multiple Microsoft operating systems.Worms
and worm-variants are some of the most interesting code released in common
times.
Internet worms are comprised of four main components:
■ Vulnerability Scanning
■ Exploitation
■ Proliferation
■ Copying
Vulnerability scanning is utilized to find new targets (unpatched vulnerable
targets). Once a new system is correctly identified, the exploitation begins.A
remotely exploitable buffer overflow allows attackers to find and inject the
exploit code on the remote targets. Afterward, that code copies itself locally and
proliferates to new targets using the same scanning and exploitation techniques.
It’s no coincidence that once a good exploit is identified, a worm is created.
Additionally, given today’s security community, there’s a high likelihood that an
Internet worm will start proliferating immediately. Microsoft’s LSASS vulnerability
turned into one of the Internet’s most deadly, costly, and quickly proliferating
network-based automated threats in history.To make things worse,
multiple variants were created and released within days.
The following lists Sasser variants as categorized by Symantec:
■ W32.Sasser.Worm
■ W32.Sasser.B.Worm
■ W32.Sasser.C.Worm
■ W32.Sasser.D
■ W32.Sasser.E.Worm
■ W32.Sasser.G
The Increase in Buffer Overflows
Contrary to popular belief, it is nearly impossible to determine if vulnerabilities
are being identified and released at an increasing or decreasing rate. One factor
may be that it is increasingly difficult to define and document vulnerabilities.
Mitre’s CVE project lapsed in categorizing vulnerabilities for over a nine-month
stretch between the years 2003 and 2004.With this said, if you were to look at
the sample statistics provided by Mitre on the number of vulnerabilities released,
it would lead you to believe that vulnerabilities are actually decreasing. As seen
by the data in Table 1.2, it appears that the number of vulnerabilities is
decreasing by a couple hundred entries per year. Note that the Total
8 Chapter 1 • Buffer Overflows: The Essentials
Vulnerability Count is for “CVE-rated” vulnerabilities only and does not
include Mitre candidates or CANs.
Table 1.2 Mitre Categorized Vulnerabilities
2004 2003 2002 2001
Vulnerability Count 812 1007 1307 1506
Table 1.3 would lead you to believe that the total number of identified vulnerabilities,
candidates, and validated vulnerabilities is decreasing in number.The
problem with these statistics is that the data is only pulled from one governing
organization. Securityfocus.com has a different set of vulnerabilities that it has
cataloged, and it has more numbers than Mitre due to the different types (or less
enterprise class) of vulnerabilities. Additionally, it’s hard to believe that more
than 75 percent of all vulnerabilities are located in the remotely exploitable portions
of server applications. Our theory is that most attackers search for remotely

exploitable vulnerabilities that could lead to arbitrary code execution

download