Tìm hiểu tấn công tràn bộ đệm (Buffer Overflows)

Chapter 1
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 pre-vention 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 soft-ware 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 com-plex as multiple character arrays that are inappropriately handled. Some buffer
overflows can be found in local programs such as calendar applications, calcula-tors, 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 wel-come 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 creation-related 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 advan-tages 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 scan-ners 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 vul-nerabilities 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 “vulnerability-free” 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 vul-nerabilities 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 vulnera-bilities
■ 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 vulnera-bilities and have done an excellent job at remedying vulnerabilities before pro-duction 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.

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, comple-mented 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 vulner-abilities in one year, you’ll be well on your way to becoming
famous—or should we say: infamous.