Download Hacking The Art of Exploitation 1st Edition Jon Erickson ebook All Chapters PDF

Download as pdf or txt
Download as pdf or txt
You are on page 1of 39

Download the full version of the ebook at

https://ebookgate.com

Hacking The Art of Exploitation 1st Edition


Jon Erickson

https://ebookgate.com/product/hacking-the-art-of-
exploitation-1st-edition-jon-erickson/

Explore and download more ebook at https://ebookgate.com


Hacking: The Art of Exploitation
by Jon Erickson ISBN:1593270070
No Starch Press © 2003 (241 pages)

This text introduces the spirit and theory of hacking as


well as the science behind it all; it also provides some
core techniques and tricks of hacking so you can think
like a hacker, write your own hacks or thwart potential
system attacks.

Table of Contents
Hacking—The Art of Exploitation
Preface
Ch
apt
- 0x100—Introduction
er
1
Ch
apt
- 0x200—Programming
er
2
Ch
apt
- 0x300—NETWORKING
er
3
Ch
apt
- 0x400—Cryptology
er
4
Ch
apt
- 0x500—Conclusion
er
5
Index
Back Cover

Hacking is the art of creating problem solving, whether used to find an unconventional solution to a difficult problem
or to exploit holes in sloppy programming. Many people call themselves hackers, but few have the strong technical
foundation that a hacker needs to be successful. Hacking: The Art of Exploitation explains things that every real
hacker should know.

While many hacking books show you how to run other people’s exploits without really explaining the technical
details, Hacking: The Art of Exploitation introduces you to the spirit and theory of hacking as well as the science
behind it all. By learning some of the core techniques and clever tricks of hacking, you will begin to understand the
hacker mindset. Once you learn to think like a hacker, you can write your own hacks and innovate new techniques,
or you can thwart potential attacks on your system.

In Hacking: The Art of Exploitation you will learn how to:


 Exploit programs using buffer overflows and format strings
 Write your own printable ASCII polymorphic shellcode
 Defeat non-executable stacks by returning into libc
 Redirect network traffic, conceal open ports, and hijack TCP connections
 Crack encrypted 802.11b wireless traffic using the FMS attack

If you’re serious about hacking, this book is for you, no matter which side of the fence you’re on.

About the Author

Jon Erickson has a formal education in computer science and speaks frequently at computer security conferences
around the world. He currently works as a cryptologist and security specialist in Northern California.
Hacking—The Art of Exploitation
Jon Erickson

NO STARCH PRESS

San Francisco

HACKING.

Copyright © 2003 Jon Erickson.

All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic
or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior
written permission of the copyright owner and the publisher.

1 2 3 4 5 6 7 8 9 10 – 06 05 04 03

No Starch Press and the No Starch Press logo are registered trademarks of No Starch Press, Inc. Other product
and company names mentioned herein may be the trademarks of their respective owners. Rather than use a
trademark symbol with every occurrence of a trademarked name, we are using the names only in an editorial fashion
and to the benefit of the trademark owner, with no intention of infringement of the trademark.

Publisher: William Pollock


Managing Editor: Karol Jurado
Cover and Interior Design: Octopod Studios
Technical Reviewer: Aaron I. Adams
Copyeditor: Kenyon Brown
Compositor: Wedobooks
Proofreaders: Stephanie Provines, Seth Benson
Indexer: Kevin Broccoli

For information on translations or book distributors, please contact No Starch Press, Inc. directly:

No Starch Press, Inc.


555 De Haro Street, Suite 250, San Francisco, CA 94107
phone: 415-863-9900; fax: 415-863-9950; [email protected]; http://www.nostarch.com

The information in this book is distributed on an "As Is" basis, without warranty. While every precaution has been
taken in the preparation of this work, neither the author nor No Starch Press, Inc. shall have any liability to any person
or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information
contained in it.

Library of Congress Cataloguing-in-Publication Data

Erickson, Jon (Jon Mark), 1977-


Hacking : the art of exploitation / Jon Erickson.
p. cm.
1-59327-007-0

1. Computer security. 2. Computer hackers. 3. Computer networks–Security measures. I. Title.


QA76.9.A25E72 2003
005.8–dc22

2003017498

ACKNOWLEDGMENTS

I would like to thank Bill Pollock, Karol Jurado, Andy Carroll, Leigh Sacks, and everyone else at No Starch Press
for making this book a possibility and allowing me so much creative control of the process. Also, I would like to thank
my friends Seth Benson and Aaron Adams for proofreading and editing, Jack Matheson for helping me with
assembly, Dr. Seidel for keeping me interested in the science of computer science, my parents for buying that first
Commodore Vic-20, and the hacker community for their innovation and creativity that produced the techniques
explained in this book.
Preface
This book explains the details of various hacking techniques, many of which get very technical. While the fundamental
programming concepts that these hacking techniques build from are introduced in the book, general programming
knowledge will certainly aid the reader in understanding these concepts. The code examples in this book were done
on an x86-based computer running Linux. Having a similarly set-up computer to follow along is encouraged; this will
let you see the results for yourself and allow you to experiment and try new things. This is what hacking is all about.

Gentoo Linux was the distribution that was used in this book, and is available at http://www.gentoo.org.
Chapter 1: 0x100—Introduction
The idea of hacking may conjure up stylized images of electronic vandalism, espionage, dyed hair, and body piercings.
Most people associate hacking with breaking the law, therefore dubbing all those who engage in hacking activities to
be criminals. Granted, there are people out there who use hacking techniques to break the law, but hacking isn't really
about that. In fact, hacking is more about following the law than breaking it.

The essence of hacking is finding unintended or overlooked uses for the laws and properties of a given situation and
then applying them in new and inventive ways to solve a problem. The problem could be the lack of access to a
computer system or figuring out a way to make old phone equipment control a model railroad system. Usually, the
hacked solutions solve these problems in unique ways, unimaginable by those confined to conventional methodology.

In the late 1950s, the MIT model railroad club was given a donation of parts, most of which were old telephone
equipment. The members used this equipment to rig up a complex system that allowed multiple operators to control
different parts of the track by dialing into the appropriate section. They called this new and inventive use of equipment
"hacking", and many consider this group to be the original hackers. They moved on to programming on punchcards
and ticker tape for early computers like the IBM 704 and the TX-0. While others were content with just writing
programs that solved problems, the early hackers were obsessed with writing programs that solved problems well. A
program that could achieve the same result using fewer punchcards was considered better, even though it did the
same thing. The key difference was how the program achieved its results—elegance.

Being able to reduce the number of punchcards needed for a program showed an artistic mastery over the computer,
which was admired and appreciated by those who understood it. Analogously, a block of wood might solve the
problem of supporting a vase, but a nicely crafted table built using refined techniques sure looks a lot better. The early
hackers were transforming programming from an engineering task into an art form, which, like many forms of art,
could only be appreciated by those who got it and would be misunderstood by those who didn't.

This approach to programming created an informal subculture, separating those who appreciated the beauty of
hacking from those who were oblivious to it. This subculture was intensely focused on learning more and gaining yet
higher levels of mastery over their art. They believed that information should be free, and anything that stood in the
way of that freedom should be circumvented. Such obstructions included authority figures, the bureaucracy of college
classes, and discrimination. In a sea of graduation-driven students, this unofficial group of hackers defied the
conventional goals of getting good grades, instead pursuing knowledge itself. This drive to continuously learn and
explore transcended even the conventional boundaries drawn by discrimination, evident in the group's acceptance of
12-year-old Peter Deutsch when he demonstrated his knowledge of the TX-0 and his desire to learn. Age, race,
gender, appearance, academic degrees, and social status were not primary criteria for judging another's worth—this
was not because of a desire for equality, but because of a desire to advance the emerging art of hacking.

The hackers found splendor and elegance in the conventionally dry sciences of math and electronics. They saw
programming as a form of artistic expression, and the computer was the instrument of their art. Their desire to dissect
and understand wasn't intended to demystify artistic endeavors, but was simply a way to achieve a greater
appreciation of them. These knowledge-driven values would eventually be called the Hacker Ethic: the appreciation of
logic as an art form, and the promotion of the free flow of information, surmounting conventional boundaries and
restrictions, for the simple goal of better understanding the world. This is not new; the Pythagoreans in ancient Greece
had a similar ethic and subculture, despite the lack of computers. They saw beauty in mathematics and discovered
many core concepts in geometry. That thirst for knowledge and its beneficial by-products would continue on through
history, from the Pythagoreans to Ada Lovelace to Alan Turing to the hackers of the MIT model railroad club. The
progression of computational science would continue even further, through to Richard Stallman and Steve Wozniak.
These hackers have brought us modern operating systems, programming languages, personal computers, and many
other technological advances that are used every day.
So how does one distinguish between the good hackers who bring us the wonders of technological advancement and
the evil hackers who steal our credit card numbers? Once, the term cracker was coined to refer to the evil hackers
and distinguish them from the good ones. The journalists were told that crackers were supposed to be the bad guys,
while hackers were the good guys. The hackers stayed true to the Hacker Ethic, while crackers were only interested
in breaking the law. Crackers were considered to be much less talented than the elite hackers, simply making use of
hacker-written tools and scripts without understanding how they worked. Cracker was meant to be the catch-all label
for anyone doing anything unscrupulous with a computer — pirating software, defacing websites, and worst of all, not
understanding what they were doing. But very few people use this term today.

The term's lack of popularity might be due to a collision of definitions — the term cracker was originally used to
describe those who crack software copyrights and reverse engineer copy protection schemes. Or it might simply be
due to its new definition, which refers both to a group of people that engage in illegal activity with computers and to
people who are relatively unskilled hackers. Few journalists feel compelled to write about an unskilled group using a
term (crackers) that most people are unfamiliar with. In contrast, most people are aware of the mystery and skill
associated with the term hackers. For a journalist, the decision to use the term crackers or hackers seems easy.
Similarly, the term script kiddie is sometimes used to refer to crackers, but it just doesn't have the same sensational
journalistic zing of the shadowy hacker. There are some who will still argue that there is a distinct line between
hackers and crackers, but I believe that anyone who has the hacker spirit is a hacker, despite what laws he or she
may break.

This unclear hacker versus cracker line is even further blurred by the modern laws restricting cryptography and
cryptographic research. In 2001, Professor Edward Felten and his research team from Princeton University were
about to publish the results of their research — a paper that discussed the weaknesses of various digital watermarking
schemes. This paper was in response to a challenge issued by the Secure Digital Music Initiative (SDMI) in the SDMI
Public Challenge, which encouraged the public to attempt to break these watermarking schemes. Before they could
publish the paper, though, they were threatened by both the SDMI Foundation and the Recording Industry
Association of America (RIAA). Apparently the Digital Millennium Copyright Act (DMCA) of 1998 makes it illegal
to discuss or provide technology that might be used to bypass industry consumer controls. This same law was used
against Dmitry Sklyarov, a Russian computer programmer and hacker. He had written software to circumvent overly
simplistic encryption in Adobe software and presented his findings at a hacker convention in the United States. The
FBI swooped in and arrested him, leading to a lengthy legal battle. Under the law, the complexity of the industry
consumer controls don't matter — it would be technically illegal to reverse engineer or even discuss Pig Latin if it were
used as an industry consumer control. So who are the hackers and who are the crackers now? When laws seem to
interfere with free speech, do the good guys who speak their minds suddenly become bad? I believe that the spirit of
the hacker transcends governmental laws, as opposed to being defined by them. And as in any knowledgeable group,
there will always be some bad people who use this knowledge to conduct bad acts.

The sciences of nuclear physics and biochemistry can be used to kill, yet they also provide us with significant scientific
advancement and modern medicine. There's nothing good or bad about the knowledge itself; the morality lies in the
application of that knowledge. Even if we wanted to, we couldn't suppress the knowledge of how to convert matter
into energy or stop the continual technological progress of society. In the same way, the hacker spirit can never be
stopped, nor can it be easily categorized or dissected. Hackers will constantly be pushing the limits, forcing us to
explore further and further.

Unfortunately, there are many so-called hacker books that are nothing more than compendiums of other people's
hacks. They instruct the reader to use the tools on the included CD without explaining the theory behind those tools,
producing someone skilled in using other people's tools, yet incapable of understanding those tools or creating tools of
their own. Perhaps the cracker and script kiddie terms aren't entirely outmoded.

The real hackers are the pioneers, the ones who devise the methods and create the tools that are packed on those
aforementioned CDs. Putting legality aside and thinking logically, every exploit that a person could possibly read
about in a book has a corresponding patch to defend against it. A properly patched system should be immune to this
class of attack. Attackers who only use these techniques without innovation are doomed to prey only on the weak
and the stupid. The real hackers can proactively find holes and weaknesses in software to create their own exploits. If
they choose not to disclose these vulnerabilities to a vendor, hackers can use those exploits to wander unobstructed
through fully patched and "secure" systems.

So if there aren't any patches, what can be done to prevent hackers from finding new holes in software and exploiting
them? This is why security research teams exist—to try to find these holes and notify vendors before they are
exploited. There is a beneficial co-evolution occurring between the hackers securing systems and those breaking into
them. This competition provides us with better and stronger security, as well as more complex and sophisticated
attack techniques. The introduction and progression of intrusion detection systems (IDSs) is a prime example of this
co-evolutionary process. The defending hackers create IDSs to add to their arsenal, while the attacking hackers
develop IDS evasion techniques, which are eventually compensated for in bigger and better IDS products. The net
result of this interaction is positive, as it produces smarter people, improved security, more stable software, inventive
problem-solving techniques, and even a new economy.

The intent of this book is to teach you about the true spirit of hacking. We will look at various hacker techniques,
from the past through to the present, dissecting them to learn how they work and why they work. By presenting the
information in this way, you will gain an understanding and appreciation for hacking that may inspire you to improve
upon existing techniques or even to invent brand-new ones. I hope this book will stimulate the curious hacker nature in
you and prompt you to contribute to the art of hacking in some way, regardless of which side of the fence you choose
to be on.
Chapter 2: 0x200—Programming
Overview
Hacking is a term used both by those who write code and those who exploit it. Even though these two groups of
hackers have different end goals, both groups use similar problem-solving techniques. And because an understanding
of programming helps those who exploit, and an understanding of exploitation helps those who program, many
hackers do both. There are interesting hacks found in both the techniques used to write elegant code and the
techniques used to exploit programs. Hacking is really just the act of finding a clever and counterintuitive solution to a
problem.

The hacks found in program exploits usually deal with using the rules of the computer in ways never intended, to
achieve seemingly magical results, which are usually focused on bypassing security. The hacks found in the writing of
programs are similar, in that they also use the rules of the computer in new and inventive ways, but the final goal tends
to be achieving the most impressive and best possible way to accomplish a given task. There is actually an infinite
number of programs that can be written to accomplish any given task, but most of these solutions are unnecessarily
large, complex, and sloppy. The few solutions that remain are small, efficient, and neat. This particular quality of a
program is called elegance, and the clever and inventive solutions that tend to lead to this efficiency are called hacks.
Hackers on both sides of programming tend to appreciate both the beauty of elegant code and the ingenuity of clever
hacks.

Because of the sudden growth of computational power and the temporary dot-com economic bubble, less
importance has been put on clever hacks and elegant code, and more importance has been placed on churning out
functional code as quickly and cheaply as possible. Spending an extra five hours to create a slightly faster and more
memory-efficient piece of code just doesn't make business sense when that increase in speed and memory only turns
out to be a few milliseconds on modern consumer processors and less than a single percent of savings in the hundreds
of millions of bytes of memory most modern computers have available. When the bottom line is money, spending time
on clever hacks for optimization just doesn't make sense.

True appreciation of programming elegance is left for the hackers: computer hobbyists whose end goal isn't to make
a profit, but just to squeeze every bit of functionality out of their old Commodore 64 that they possibly can; exploit
writers who need to write tiny and amazing pieces of code to slip through narrow security cracks; and anyone else
who appreciates the pursuit and the challenge of finding the best possible solution. These are the people who get
excited about programming and really appreciate the beauty of an elegant piece of code or the ingenuity of a clever
hack. Because an understanding of programming is a prerequisite to understanding how programs can be exploited,
programming makes a natural starting point.
0x210 What Is Programming?
Programming is a very natural and intuitive concept. A program is nothing more than a series of statements written in a
specific language. Programs are everywhere, and even the technophobes of the world use programs every day.
Driving directions, cooking recipes, football plays, and DNA are all programs that exist in the lives and even the
cellular makeup of people everywhere.

A typical "program" for driving directions might look something like this:

Start out down Main Street headed east. Continue on Main until you see a church on your right. If the street is
blocked because of construction, turn right there at 15th street, turn left on Pine Street, and then turn right on 16th
street. Otherwise, you can just continue and make a right on 16th street. Continue on 16th street and turn left onto
Destination Road. Drive straight down Destination Road for 5 miles and then the house is on the right. The address is
743 Destination Road.

Anyone who knows English can understand and follow these driving directions; they're written in English. Granted,
they're not eloquent, but each instruction is clear and easy to understand, at least for someone who reads English.

But a computer doesn't natively understand English; it only understands machine language. To instruct a computer to
do something, the instructions must be written in its language. However, machine language is arcane and difficult to
work with. Machine language consists of raw bits and bytes, and it differs from architecture to architecture. So to
write a program in machine language for an Intel x86 processor, one would have to figure out the value associated
with each instruction, how each instruction interacts, and a myriad of other low-level details. Programming like this is
painstaking and cumbersome, and it is certainly not intuitive.

What's needed to overcome the complication of writing machine language is a translator. An assembler is one form of
machine-language translator: It is a program that translates assembly language into machine-readable code. Assembly
language is less cryptic than machine language, because it uses names for the different instructions and variables,
instead of just using numbers. However assembly language is still far from intuitive. The instruction names are very
esoteric and the language is still architecture-specific. This means that just as machine language for Intel x86
processors is different from machine language for Sparc processors, x86 assembly language is different from Sparc
assembly language. Any program written using assembly language for one processor's architecture will not work in
another processor's architecture. If a program is written in x86 assembly language, it must be rewritten to run on
Sparc architecture. In addition, to write an effective program in assembly language, one must still know many
low-level details of that processor's architecture.

These problems can be mitigated by yet another form of translator called a compiler. A compiler converts a
high-level language into machine language. High-level languages are much more intuitive than assembly language and
can be converted into many different types of machine language for different processor architectures. This means that
if a program is written in a high-level language, the program only needs to be written once, and the same piece of
program code can be compiled by a compiler into machine language for various specific architectures. C, C++, and
FORTRAN are all examples of high-level languages.

A program written in a high-level language is much more readable and English-like than assembly language or
machine language, but it still must follow very strict rules about how the instructions are worded or the compiler won't
be able to understand it.

Programmers have yet another form of programming language called pseudo-code. Pseudo-code is simply English
arranged with a general structure similar to a high-level language. It isn't understood by compilers, assemblers, or any
computers, but it is a useful way for a programmer to arrange instructions. Pseudo-code isn't well defined. In fact,
many people write pseudo-code slightly differently. It's sort of the nebulous missing link between natural languages,
such as English, and high-level programming languages, such as C. The driving directions from before, converted into
pseudo-code, might look something like this:
Begin going east on Main street;
Until (there is a church on the right)
{
Drive down Main;
}
If (street is blocked)
{
Turn(right, 15th street);
Turn(left, Pine street);
Turn(right, 16th street);
}
else
{
Turn(right, 16th street);
}
Turn(left, Destination Road);
For (5 iterations)
{
Drive straight for 1 mile;
}
Stop at 743 Destination Road;

Each instruction is broken down into its own line, and the control logic of the directions has been broken down into
control structures. Without control structures, a program would just be a series of instructions executed in sequential
order. But our driving directions weren't that simple. They included statements like, "Continue on Main until you see a
church on your right" and "If the street is blocked because of construction …." These are known as control structures,
and they change the flow of the program's execution from a simple sequential order to a more complex and more
useful flow.

In addition, the instructions to turn the car are much more complicated than just "Turn right on 16th street." Turning
the car might involve locating the correct street, slowing down, turning on the blinker, turning the steering wheel, and
finally speeding back up to the speed of traffic on the new street. Because many of these actions are the same for any
street, they can be put into a function. A function takes in a set of arguments as input, processes its own set of
instructions based on the input, and then returns back to where it was originally called. A turning function in
pseudo-code might look something like this:
Function Turn(the_direction, the_street)
{
locate the_street;
slow down;
if(the_direction == right)
{
turn on the right blinker;
turn the steering wheel to the right;
}
else
{
turn on the left blinker;
turn the steering wheel to the left;
}
speed back up
}

By using this function repeatedly, the car can be turned on any street, in any direction, without having to write out
every little instruction each time. The important thing to remember about functions is that when they are called the
program execution actually jumps over to a different place to execute the function and then returns back to where it
left off after the function finishes executing.

One final important point about functions is that each function has its own context. This means that the local variables
found within each function are unique to that function. Each function has its own context, or environment, which it
executes within. The core of the program is a function, itself, with its own context, and as each function is called from
this main function, a new context for the called function is created within the main function. If the called function calls
another function, a new context for that function is created within the previous function's context, and so on. This
layering of functional contexts allows each function to be somewhat atomic.

The control structures and functional concepts found in pseudo-code are also found in many different programming
languages. Pseudo-code can look like anything, but the preceding pseudo-code was written to resemble the C
programming language. This resemblance is useful, because C is a very common programming language. In fact, the
majority of Linux and other modern implementations of Unix operating systems are written in C. Because Linux is an
open source operating system with easy access to compilers, assemblers, and debuggers, this makes it an excellent
platform to learn from. For the purposes of this book, the assumption will be made that all operations are occurring on
an x86-based processor running Linux.
0x220 Program Exploitation
Program exploitation is a staple of hacking. Programs are just a complex set of rules following a certain execution flow
that ultimately tell the computer what to do. Exploiting a program is simply a clever way of getting the computer to do
what you want it to do, even if the currently running program was designed to prevent that action. Because a program
can really only do what it's designed to do, the security holes are actually flaws or oversights in the design of the
program or the environment the program is running in. It takes a creative mind to find these holes and to write
programs that compensate for them. Sometimes these holes are the product of relatively obvious programmer errors,
but there are some less obvious errors that have given birth to more complex exploit techniques that can be applied in
many different places.

A program can only do what it's programmed to do, to the letter of the law. Unfortunately, what's written doesn't
always coincide with what the programmer intended the program to do. This principle can be explained with a joke:

A man is walking through the woods, and he finds a magic lamp on the ground. Instinctively, he picks the lamp up
and rubs the side of it with his sleeve, and out pops a genie. The genie thanks the man for freeing him and offers to
grant him three wishes. The man is ecstatic and knows exactly what he wants.

"First", says the man, "I want a billion dollars."

The genie snaps his fingers, and a briefcase full of money materializes out of thin air.

The man is wide-eyed in amazement and continues, "Next, I want a Ferrari."

The genie snaps his fingers, and a Ferrari appears from a puff of smoke.

The man continues, "Finally, I want to be irresistible to women."

The genie snaps his fingers, and the man turns into a box of chocolates.

Just as the man's final wish was granted based on what he said, rather than what he was thinking, a program will
follow its instructions exactly, and the results aren't always what the programmer intends. Sometimes they can lead to
catastrophic results.

Programmers are human, and sometimes what they write isn't exactly what they mean. For example, one common
programming error is called an off-by-one error. As the name implies, it's an error where the programmer has
miscounted by one. This happens more often than one would think, and it is best illustrated with a question: If you're
building a 100 foot fence, with fence posts spaced 10 feet apart, how many fence posts do you need? The obvious
answer is 10 fence posts, but this is incorrect, because 11 fence posts are actually needed. This type of off-by-one
error is commonly called a fencepost error, and it occurs when a programmer mistakenly counts items instead of
spaces between items, or vice versa. Another example is when a programmer is trying to select a range of numbers or
items for processing, such as items N through M. If N = 5 and M = 17, how many items are there to process? The
obvious answer is M ? N, or 17 ? 5 = 12 items. But this is incorrect, because there are actually M ? N + 1 items, for
a total of 13 items. This may seem counterintuitive at first glance, because it is, and that's exactly how these errors
happen.

Often these fencepost errors go unnoticed because the programs aren't tested for every single possibility, and their
effects don't generally occur during normal program execution. However, when the program is fed the input that
makes the effects of the error manifest, the consequences of the error can have an avalanche effect on the rest of the
program logic. When properly exploited, an off-by-one error can cause a seemingly secure program to become a
security vulnerability.
One recent example of this is OpenSSH, which is meant to be a secure terminal communication program suite,
designed to replace insecure and unencrypted services such as telnet, rsh, and rcp. However there was an off-by-one
error in the channel allocation code that was heavily exploited. Specifically, the code included an if statement that
read:
if (id < 0 || id > channels_alloc) {

It should have been:


if (id < 0 || id >= channels_alloc) {

In plain English, the code read, "If the ID is less than 0 or the ID is greater than the channels allocated, do the
following stuff", when it should have been, "If the ID is less than 0 or the ID is greater than or equal to the channels
allocated, do the following stuff."

This simple off-by-one error allowed further exploitation of the program, so that a normal user authenticating and
logging in could gain full administrative rights to the system. This type of functionality certainly wasn't what the
programmers had intended for a secure program like OpenSSH, but a computer can only do what it's told, even if
those instructions aren't necessarily what was intended.

Another situation that seems to breed exploitable programmer errors is when a program is quickly modified to
expand its functionality. While this increase in functionality makes the program more marketable and increases its
value, it also increases the program's complexity, which increases the chances of an oversight. Microsoft's IIS web
server program is designed to serve up static and interactive web content to users. In order to accomplish this, the
program must allow users to read, write, and execute programs and files within certain directories; however, this
functionality must be limited to those certain directories. Without this limitation, users would have full control of the
system, which is obviously undesirable from a security perspective. To prevent this situation, the program has
path-checking code designed to prevent users from using the backslash character to traverse backward through the
directory tree and enter other directories.

With the addition of support for the Unicode character set, though, the complexity of the program continued to
increase. Unicode is a double-byte character set designed to provide characters for every language, including Chinese
and Arabic. By using two bytes for each character instead of just one, Unicode allows for tens of thousands of
possible characters, as opposed to the few hundred allowed by single byte characters. This additional complexity
meant that there were now multiple representations of the backslash character. For example, %5c in Unicode
translates to the backslash character, but this translation was done after the path-checking code had run. So by using
%5c instead of \, it was indeed possible to traverse directories, allowing the aforementioned security dangers. Both
the Sadmind worm and the Code-Red worm used this type of Unicode conversion oversight to deface web pages.

Another related example of this letter of the law principal, used outside the realm of computer programming, is
known as the "LaMacchia Loophole." Just like the rules of a computer program, the U.S. legal system sometimes has
rules that don't say exactly what was intended. Like a computer program exploit, these legal loopholes can be used to
sidestep the intent of the law. Near the end of 1993, a 21-year-old computer hacker and student at MIT named
David LaMacchia set up a bulletin board system called "Cynosure" for the purposes of software piracy. Those who
had software to give would upload it, and those who didn't would download it. The service was only online for about
six weeks, but it generated heavy network traffic worldwide, which eventually attracted the attention of university and
federal authorities. Software companies claimed that they lost one million dollars as a result of Cynosure, and a federal
grand jury charged LaMacchia with one count of conspiring with unknown persons to violate the wire-fraud statute.
However, the charge was dismissed because what LaMacchia was alleged to have done wasn't criminal conduct
under the Copyright Act, since the infringement was not for the purpose of commercial advantage or private financial
gain. Apparently, the lawmakers had never anticipated that someone might engage in these types of activities with a
motive other than personal financial gain. Later, in 1997, Congress closed this loophole with the No Electronic Theft
Act. Even though this example doesn't involve the exploiting of a computer program, the judges and courts can be
thought of as computers executing the program of the legal system as it was written. The abstract concepts of hacking
transcend computing and can be applied to many other aspects of life involving complex systems.
0x230 Generalized Exploit Techniques
Off-by-one errors and improper Unicode expansion are all mistakes that can be hard to see at the time but are
glaringly obvious to any programmer in hindsight. However, there are some common mistakes that can be exploited in
ways that aren't so obvious. The impact of these mistakes on security isn't always apparent, and these security
problems are found in code everywhere. Because the same type of mistake is made in many different places,
generalized exploit techniques have evolved to take advantage of these mistakes, and they can be used in a variety of
situations.

The two most common types of generalized exploit techniques are buffer-overflow exploits and format-string
exploits. With both of these techniques, the ultimate goal is to take control of the target program's execution flow to
trick it into running a piece of malicious code that can be smuggled into memory in a variety of ways. This is known
as execution of arbitrary code, because the hacker can cause a program to do pretty much anything.

But what really makes these types of exploits interesting are the various clever hacks that have evolved along the way
to achieve the impressive final results. An understanding of these techniques is far more powerful than the end result of
any single exploit, as they can be applied and extended to create a plethora of other effects. However, a prerequisite
to understanding these exploit techniques is a much deeper knowledge of file permissions, variables, memory
allocation, functions, and assembly language.
0x240 Multi-User File Permissions
Linux is a multi-user operating system, in which full system privileges are solely invested in an administrative user
called "root." In addition to the root user, there are many other user accounts and multiple groups. Many users can
belong to one group, and one user can belong to many different groups. The file permissions are based on both users
and groups, so that other users can't read your files unless they are explicitly given permission. Each file is associated
to a user and a group, and permissions can be given out by the owner of the file. The three permissions are read, write
, and execute, and they can be turned on or off in three fields: user, group, and other. The user field specifies what the
owner of the file can do (read, write, or execute), the group field specifies what users in that group can do, and the
other field specifies what everyone else can do. These permissions are displayed using the letters r, w, and x, in three
sequential fields corresponding to user, group, and other. In the following example, the user has read and write
permissions (the first bold field), the group has read and execute permissions (the middle field), and other has write
and execute permissions (the last bold field).
-rw-r-x-wx 1 guest visitors 149 Jul 15 23:59 tmp

In some situations there is a need to allow a non-privileged user to perform a system function that requires root
privileges, such as changing a password. One possible solution is to give the user root privileges; however, this also
gives the user complete control over the system, which is generally bad from a security perspective. Instead, the
program is given the ability to run as if it were the root user, so that the system function can be carried out properly
and the user isn't actually given full system control. This type of permission is called the suid (set user ID) permission
or bit. When a program with the suid permission is executed by any user, that user's euid (effective user ID) is
changed to the uid of the program's owner, and the program is executed. After the program execution completes, the
user's euid is changed back to its original value. This bit is denoted by the s in bold in the following file listing. There is
also a sgid (set group ID) permission, which does the same thing with the effective group ID.

-rwsr-xr-x 1 root root 29592 Aug 8 13:37 /usr/bin/passwd

For example, if a user wanted to change her password, she would run /usr/bin/passwd, which is owned by root and
has the suid bit on. The uid would then be changed to root's uid (which is 0) for the execution of passwd, and it would
be switched back after the execution completes. Programs that have the suid permission turned on and that are
owned by the root user are typically called suid root programs.

This is where changing the flow of program execution becomes very powerful. If the flow of a suid root program can
be changed to execute an injected piece of arbitrary code, then the attacker could get the program to do anything as
the root user. If the attacker decides to cause a suid root program to spawn a new user shell that she can access, the
attacker will have root privileges at a user level. As mentioned earlier, this is generally bad from a security perspective,
as it gives the attacker full control of the system as the root user.

I know what you're thinking: "That sounds amazing, but how can the flow of a program be changed if a program is a
strict set of rules?" Most programs are written in high-level languages, such as C, and when working in this higher
level, the programmer doesn't always see the bigger picture, which involves variable memory, stack calls, execution
pointers, and other low-level machine commands that aren't as apparent in the high-level language. A hacker with an
understanding of the low-level machine commands that the high-level program compiles into will have a better
understanding of the actual execution of the program than the high-level programmer who wrote it without that
understanding. So hacking to change the execution flow of a program still isn't actually breaking any of the program
rules; it's just knowing more of the rules and using them in ways never anticipated. To carry out these methods of
exploitation, and to write programs to prevent these types of exploits, requires a greater understanding of the
lower-level programming rules, such as program memory.
0x250 Memory
Memory might seem intimidating at first, but remember that a computer isn't magical, and at the core it's really just a
giant calculator. Memory is just bytes of temporary storage space that are numbered with addresses. This memory
can be accessed by its addresses, and the byte at any particular address can be read from or written to. Current Intel
x86 processors use a 32-bit addressing scheme, which means there are 232, or 4,294,967,296 possible addresses.
A program's variables are just certain places in memory that are used to store information.

Pointers are a special type of variable used to store addresses of memory locations to reference other information.
Because memory cannot actually be moved, the information in it must be copied. However, it can be computationally
expensive to copy large chunks of memory around to be used by different functions or in different places. This is also
expensive from a memory standpoint, because a new block of memory must be allocated for the copy destination
before the source can be copied. Pointers are a solution to this problem. Instead of copying the large block of
memory around, a pointer variable is assigned the address of that large memory block. Then this small 4-byte pointer
can then be passed around to the various functions that need to access the large memory block.

The processor has its own special memory, which is relatively small. These portions of memory are called registers,
and there are some special registers that are used to keep track of things as a program executes. One of the most
notable is the extended instruction pointer (EIP). The EIP is a pointer that holds the address of the currently executing
instruction. Other 32-bit registers that are used as pointers are the extended base pointer (EBP) and the extended
stack pointer (ESP). All three of these registers are important to the execution of a program and will be explained in
more depth later.

0x251 Memory Declaration


When programming in a high-level language, like C, variables are declared using a data type. These data types can
range from integers to characters to custom user-defined structures. One reason this is necessary is to properly
allocate space for each variable. An integer needs to have 4 bytes of space, while a character only needs a single
byte. This means that an integer has 32 bits of space (4,294,967,296 possible values), while a character has only 8
bits of space (256 possible values).

In addition, variables can be declared in arrays. An array is just a list of N elements of a specific data type. So a
10-character array is simply 10 adjacent characters located in memory. An array is also referred to as a buffer, and a
character array is also referred to as a string. Because copying large buffers around is very computationally expensive,
pointers are often used to store the address of the beginning of the buffer. Pointers are declared by prepending an
asterisk to the variable name. Here are some examples of variable declarations in C:
int integer_variable;
char character_variable;
char character_array[10];
char *buffer_pointer;

One important detail of memory on x86 processors is the byte order of 4-byte words. The ordering is known as little
endian, meaning that the least significant byte is first. Ultimately, this means that the bytes are stored in memory in
reverse for 4-byte words, such as integers and pointers. The hexadecimal value 0x12345678 stored in little endian
would look like 0x78563412 in memory. Even though compilers for high-level languages such as C will account for
the byte ordering automatically, this is an important detail to remember.

0x252 Null Byte Termination


Sometimes a character array will have ten bytes allocated to it, but only four bytes will actually be used. If the word
"test" is stored in a character array with ten bytes allocated for it, there will be extra bytes at the end that aren't
needed. A zero, or null byte, delimiter is used to terminate the string and tell any function that is dealing with the string
to stop operations there.
0 1 2 3 4 5 6 7 8 9
t e s t 0 X X X X X

So a function that copies the above string from this character buffer to a different location would only copy "test",
stopping at the null byte, instead of copying the entire buffer. Similarly, a function that prints the contents of a
character buffer would only print the word "test", instead of printing out "test" followed by several random bytes of
data that might be found afterward. Terminating strings with null bytes increases efficiency and allows display functions
to work more naturally.

0x253 Program Memory Segmentation


Program memory is divided into five segments: text, data, bss, heap, and stack. Each segment represents a special
portion of memory that is set aside for a certain purpose.

The text segment is also sometimes called the code segment. This is where the assembled machine language
instructions of the program are located. The execution of instructions in this segment is non-linear, thanks to the
aforementioned high-level control structures and functions, which compile into branch, jump, and call instructions in
assembly language. As a program executes, the EIP is set to the first instruction in the text segment. The processor
then follows an execution loop that does the following:
1.

Read the instruction that EIP is pointing to.


2.

Add the byte-length of the instruction to EIP.


3.

Execute the instruction that was read in step 1.


4.

Go to step 1.

Sometimes the instruction will be a jump or a call instruction, which changes the EIP to a different address of
memory. The processor doesn't care about the change, because it's expecting the execution to be non-linear anyway.
So if the EIP is changed in step 3, the processor will just go back to step 1 and read the instruction found at the
address of whatever the EIP was changed to.

Write permission is disabled in the text segment, as it is not used to store variables, only code. This prevents people
from actually modifying the program code, and any attempt to write to this segment of memory will cause the program
to alert the user that something bad happened and kill the program. Another advantage of this segment being
read-only is that it can be shared between different copies of the program, allowing multiple executions of the program
at the same time without any problems. It should also be noted that this memory segment has a fixed size, because
nothing ever changes in it.

The data and bss segments are used to store global and static program variables. The data segment is filled with the
initialized global variables, strings, and other constants that are used through the program. The bss segment is filled
with the uninitialized counterparts. Although these segments are writable, they also have a fixed size.

The heap segment is used for the rest of the program variables. One notable point about the heap segment is that it
Another random document with
no related content on Scribd:
saying:
“Life is not sad, but on the contrary most joyful. If you said ‘How sad
is our exile,’ I should understand you. It is erroneous to give the
name, ‘life,’ to that which must end. Only to the things of Heaven, to
that which shall never know death, should the true name of ‘life’ be
given; and in this signification life is not sad but joyful—joyous
exceedingly!...”
Her own gaiety was delightful to witness.
For several days she had been much better and the novices said to
her: “We do not yet know of what malady you will die....”
“But I shall die of death! Did not God tell Adam of what he would die,
saying to him: Thou shalt die of death?” (In the French: “Tu mourras
de mort.”)[113]
counsels and reminiscences
It is not Death that will come to fetch me, it is the good God. Death is
no phantom, no horrible spectre, as represented in pictures. In the
Catechism it is stated that death is the separation of soul and body,
that is all! Well, I am not afraid of a separation which will unite me to
the good God for ever.
counsels and reminiscences
One day she said to the Mother Prioress:
“Mother, I beseech you, give me permission to die.... Let me offer my
life for ...” mentioning the intention.
And this permission being refused:
“Very well,” she resumed, “I know that at this moment the good God
so much desires a little bunch of grapes which no one wishes to
present to Him, that He will certainly be forced to come and steal it....
I ask nothing, for that would be to depart from my way of
abandonment, I merely beg the Blessed Virgin Mary to recall to her
Jesus the title of Thief which He gives Himself in the holy Gospel, so
that He may not forget to come to steal me away.”
hist. d’une ame, ch. xii
“Will the Divine Thief be coming very soon to steal His little bunch of
grapes?” some one asked.
I see Him afar off, and I take good care not to cry out “Stop Thief!!!”
On the contrary I call Him saying: “This way! this way!”
counsels and reminiscences
The Chaplain asked me: “Are you resigned to die?” I said: “Ah!
Father, I find it would be for living that I should need resignation, but
as regards dying, I feel only joy.”
hist. d’une ame, ch. xii
“You will be placed amid the Seraphim in Heaven,” a novice said.
“If that should happen, I shall not imitate them; they cover
themselves with their wings at the sight of God. I shall take good
care not to cover myself with my wings!”
counsels and reminiscences
“Under what name should we pray to you when you are in Heaven?”
they asked her. She answered humbly: “You will call me ‘little
Thérèse.’ (‘petite Thérèse.’)”
counsels and reminiscences
“You will look upon us from the heights of heaven, will you not?”
“No, I shall come down.”
counsels and reminiscences
“After my death I shall let fall a shower of roses.”
hist. d’une ame, ch. xii

FOOTNOTES:
[98] Cf. Wisdom, iv, 12.
[99] Eccles., i, 2.
[100] Imit., I, 1, 3.
[101] Matt., iii, 10.
[102] Judith, xv, 11.
[103] Tobias, xii.
[104] Cf. Isaias, iii, 10.
[105] Cant., ii, I.
[106] Ps., cxviii, 112.
[107] Titus, i, 15.
[108] Apoc., xxi, 4.
[109] Matt., xxvi, 65.
[110] Cant., i, 6.
[111] Cf. Marc., xiii, 3.
[112] Cf. John, xii, 3.
[113] Cf. Gen., ii, 17.
PRAYER FOR THE BEATIFICATION OF
THE SERVANT OF GOD

O Jesus, who, to put our pride to confusion didst will to become a
little child, and who later pronounced that solemn decree: “Unless ye
become as little children ye shall not enter the Kingdom of Heaven,”
deign to listen to our humble prayer in regard to her who lived
perfectly that life of spiritual childhood, and who has so well recalled
to us the way.
O little Babe of Bethlehem, by the ineffable charms of Thy Divine
Infancy, O adorable Face of Jesus, by the humiliations of Thy
Passion, we implore, that if it be for the glory of God and for the
sanctification of souls, the halo of the Blessed may soon irradiate the
pure brow of Thy childlike spouse, Thérèse of the Child Jesus and of
the Holy Face.
O God, who didst inflame with Thy Spirit of Love the soul of Thy
Servant, Thérèse of the Child Jesus, grant that we also may love
Thee and may make Thee greatly loved.
[Adapted from a prayer of Sœur Thérèse.]
100 days’ indulgence.
✠ Card. Bourne, Arch. of Westminster.
August 1, 1912.
Transcriber’s note
Minor punctuation errors have been changed without notice.
Spelling has been retained as published.
The following printer errors have been changed.
CHANGED FROM TO
Table of
“Detatchment 71” “Detachment 71”
Contents:
“marie-françoise- “marie-françoise-
Page 29:
thérése” thérèse”
Footnote 29: “Is., Iiii, 3.” “Is., liii, 3.”
“Some one was “Someone was
Page 144:
speaking to” speaking to”
*** END OF THE PROJECT GUTENBERG EBOOK THOUGHTS OF
THE SERVANT OF GOD, THÉRÈSE OF THE CHILD JESUS ***

Updated editions will replace the previous one—the old editions


will be renamed.

Creating the works from print editions not protected by U.S.


copyright law means that no one owns a United States copyright
in these works, so the Foundation (and you!) can copy and
distribute it in the United States without permission and without
paying copyright royalties. Special rules, set forth in the General
Terms of Use part of this license, apply to copying and
distributing Project Gutenberg™ electronic works to protect the
PROJECT GUTENBERG™ concept and trademark. Project
Gutenberg is a registered trademark, and may not be used if
you charge for an eBook, except by following the terms of the
trademark license, including paying royalties for use of the
Project Gutenberg trademark. If you do not charge anything for
copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such
as creation of derivative works, reports, performances and
research. Project Gutenberg eBooks may be modified and
printed and given away—you may do practically ANYTHING in
the United States with eBooks not protected by U.S. copyright
law. Redistribution is subject to the trademark license, especially
commercial redistribution.

START: FULL LICENSE


THE FULL PROJECT GUTENBERG LICENSE
PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the


free distribution of electronic works, by using or distributing this
work (or any other work associated in any way with the phrase
“Project Gutenberg”), you agree to comply with all the terms of
the Full Project Gutenberg™ License available with this file or
online at www.gutenberg.org/license.

Section 1. General Terms of Use and


Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand,
agree to and accept all the terms of this license and intellectual
property (trademark/copyright) agreement. If you do not agree to
abide by all the terms of this agreement, you must cease using
and return or destroy all copies of Project Gutenberg™
electronic works in your possession. If you paid a fee for
obtaining a copy of or access to a Project Gutenberg™
electronic work and you do not agree to be bound by the terms
of this agreement, you may obtain a refund from the person or
entity to whom you paid the fee as set forth in paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only


be used on or associated in any way with an electronic work by
people who agree to be bound by the terms of this agreement.
There are a few things that you can do with most Project
Gutenberg™ electronic works even without complying with the
full terms of this agreement. See paragraph 1.C below. There
are a lot of things you can do with Project Gutenberg™
electronic works if you follow the terms of this agreement and
help preserve free future access to Project Gutenberg™
electronic works. See paragraph 1.E below.
1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright
law in the United States and you are located in the United
States, we do not claim a right to prevent you from copying,
distributing, performing, displaying or creating derivative works
based on the work as long as all references to Project
Gutenberg are removed. Of course, we hope that you will
support the Project Gutenberg™ mission of promoting free
access to electronic works by freely sharing Project
Gutenberg™ works in compliance with the terms of this
agreement for keeping the Project Gutenberg™ name
associated with the work. You can easily comply with the terms
of this agreement by keeping this work in the same format with
its attached full Project Gutenberg™ License when you share it
without charge with others.

1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside
the United States, check the laws of your country in addition to
the terms of this agreement before downloading, copying,
displaying, performing, distributing or creating derivative works
based on this work or any other Project Gutenberg™ work. The
Foundation makes no representations concerning the copyright
status of any work in any country other than the United States.

1.E. Unless you have removed all references to Project


Gutenberg:

1.E.1. The following sentence, with active links to, or other


immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project
Gutenberg™ work (any work on which the phrase “Project
Gutenberg” appears, or with which the phrase “Project
Gutenberg” is associated) is accessed, displayed, performed,
viewed, copied or distributed:

This eBook is for the use of anyone anywhere in the United


States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it
away or re-use it under the terms of the Project Gutenberg
License included with this eBook or online at
www.gutenberg.org. If you are not located in the United
States, you will have to check the laws of the country where
you are located before using this eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is


derived from texts not protected by U.S. copyright law (does not
contain a notice indicating that it is posted with permission of the
copyright holder), the work can be copied and distributed to
anyone in the United States without paying any fees or charges.
If you are redistributing or providing access to a work with the
phrase “Project Gutenberg” associated with or appearing on the
work, you must comply either with the requirements of
paragraphs 1.E.1 through 1.E.7 or obtain permission for the use
of the work and the Project Gutenberg™ trademark as set forth
in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is


posted with the permission of the copyright holder, your use and
distribution must comply with both paragraphs 1.E.1 through
1.E.7 and any additional terms imposed by the copyright holder.
Additional terms will be linked to the Project Gutenberg™
License for all works posted with the permission of the copyright
holder found at the beginning of this work.

1.E.4. Do not unlink or detach or remove the full Project


Gutenberg™ License terms from this work, or any files
containing a part of this work or any other work associated with
Project Gutenberg™.
1.E.5. Do not copy, display, perform, distribute or redistribute
this electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1
with active links or immediate access to the full terms of the
Project Gutenberg™ License.

1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if
you provide access to or distribute copies of a Project
Gutenberg™ work in a format other than “Plain Vanilla ASCII” or
other format used in the official version posted on the official
Project Gutenberg™ website (www.gutenberg.org), you must, at
no additional cost, fee or expense to the user, provide a copy, a
means of exporting a copy, or a means of obtaining a copy upon
request, of the work in its original “Plain Vanilla ASCII” or other
form. Any alternate format must include the full Project
Gutenberg™ License as specified in paragraph 1.E.1.

1.E.7. Do not charge a fee for access to, viewing, displaying,


performing, copying or distributing any Project Gutenberg™
works unless you comply with paragraph 1.E.8 or 1.E.9.

1.E.8. You may charge a reasonable fee for copies of or


providing access to or distributing Project Gutenberg™
electronic works provided that:

• You pay a royalty fee of 20% of the gross profits you derive from
the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information
about donations to the Project Gutenberg Literary Archive
Foundation.”

• You provide a full refund of any money paid by a user who


notifies you in writing (or by e-mail) within 30 days of receipt that
s/he does not agree to the terms of the full Project Gutenberg™
License. You must require such a user to return or destroy all
copies of the works possessed in a physical medium and
discontinue all use of and all access to other copies of Project
Gutenberg™ works.

• You provide, in accordance with paragraph 1.F.3, a full refund of


any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.

• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.

1.E.9. If you wish to charge a fee or distribute a Project


Gutenberg™ electronic work or group of works on different
terms than are set forth in this agreement, you must obtain
permission in writing from the Project Gutenberg Literary
Archive Foundation, the manager of the Project Gutenberg™
trademark. Contact the Foundation as set forth in Section 3
below.

1.F.

1.F.1. Project Gutenberg volunteers and employees expend


considerable effort to identify, do copyright research on,
transcribe and proofread works not protected by U.S. copyright
law in creating the Project Gutenberg™ collection. Despite
these efforts, Project Gutenberg™ electronic works, and the
medium on which they may be stored, may contain “Defects,”
such as, but not limited to, incomplete, inaccurate or corrupt
data, transcription errors, a copyright or other intellectual
property infringement, a defective or damaged disk or other
medium, a computer virus, or computer codes that damage or
cannot be read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES -


Except for the “Right of Replacement or Refund” described in
paragraph 1.F.3, the Project Gutenberg Literary Archive
Foundation, the owner of the Project Gutenberg™ trademark,
and any other party distributing a Project Gutenberg™ electronic
work under this agreement, disclaim all liability to you for
damages, costs and expenses, including legal fees. YOU
AGREE THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE,
STRICT LIABILITY, BREACH OF WARRANTY OR BREACH
OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH
1.F.3. YOU AGREE THAT THE FOUNDATION, THE
TRADEMARK OWNER, AND ANY DISTRIBUTOR UNDER
THIS AGREEMENT WILL NOT BE LIABLE TO YOU FOR
ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE
OR INCIDENTAL DAMAGES EVEN IF YOU GIVE NOTICE OF
THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If


you discover a defect in this electronic work within 90 days of
receiving it, you can receive a refund of the money (if any) you
paid for it by sending a written explanation to the person you
received the work from. If you received the work on a physical
medium, you must return the medium with your written
explanation. The person or entity that provided you with the
defective work may elect to provide a replacement copy in lieu
of a refund. If you received the work electronically, the person or
entity providing it to you may choose to give you a second
opportunity to receive the work electronically in lieu of a refund.
If the second copy is also defective, you may demand a refund
in writing without further opportunities to fix the problem.

1.F.4. Except for the limited right of replacement or refund set


forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’,
WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied


warranties or the exclusion or limitation of certain types of
damages. If any disclaimer or limitation set forth in this
agreement violates the law of the state applicable to this
agreement, the agreement shall be interpreted to make the
maximum disclaimer or limitation permitted by the applicable
state law. The invalidity or unenforceability of any provision of
this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the


Foundation, the trademark owner, any agent or employee of the
Foundation, anyone providing copies of Project Gutenberg™
electronic works in accordance with this agreement, and any
volunteers associated with the production, promotion and
distribution of Project Gutenberg™ electronic works, harmless
from all liability, costs and expenses, including legal fees, that
arise directly or indirectly from any of the following which you do
or cause to occur: (a) distribution of this or any Project
Gutenberg™ work, (b) alteration, modification, or additions or
deletions to any Project Gutenberg™ work, and (c) any Defect
you cause.

Section 2. Information about the Mission of


Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new
computers. It exists because of the efforts of hundreds of
volunteers and donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the


assistance they need are critical to reaching Project
Gutenberg™’s goals and ensuring that the Project Gutenberg™
collection will remain freely available for generations to come. In
2001, the Project Gutenberg Literary Archive Foundation was
created to provide a secure and permanent future for Project
Gutenberg™ and future generations. To learn more about the
Project Gutenberg Literary Archive Foundation and how your
efforts and donations can help, see Sections 3 and 4 and the
Foundation information page at www.gutenberg.org.

Section 3. Information about the Project


Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-
profit 501(c)(3) educational corporation organized under the
laws of the state of Mississippi and granted tax exempt status by
the Internal Revenue Service. The Foundation’s EIN or federal
tax identification number is 64-6221541. Contributions to the
Project Gutenberg Literary Archive Foundation are tax
deductible to the full extent permitted by U.S. federal laws and
your state’s laws.

The Foundation’s business office is located at 809 North 1500


West, Salt Lake City, UT 84116, (801) 596-1887. Email contact
links and up to date contact information can be found at the
Foundation’s website and official page at
www.gutenberg.org/contact

Section 4. Information about Donations to


the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission
of increasing the number of public domain and licensed works
that can be freely distributed in machine-readable form
accessible by the widest array of equipment including outdated
equipment. Many small donations ($1 to $5,000) are particularly
important to maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws


regulating charities and charitable donations in all 50 states of
the United States. Compliance requirements are not uniform
and it takes a considerable effort, much paperwork and many
fees to meet and keep up with these requirements. We do not
solicit donations in locations where we have not received written
confirmation of compliance. To SEND DONATIONS or
determine the status of compliance for any particular state visit
www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states


where we have not met the solicitation requirements, we know
of no prohibition against accepting unsolicited donations from
donors in such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot


make any statements concerning tax treatment of donations
received from outside the United States. U.S. laws alone swamp
our small staff.

Please check the Project Gutenberg web pages for current


donation methods and addresses. Donations are accepted in a
number of other ways including checks, online payments and
credit card donations. To donate, please visit:
www.gutenberg.org/donate.

Section 5. General Information About Project


Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could
be freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose
network of volunteer support.

Project Gutenberg™ eBooks are often created from several


printed editions, all of which are confirmed as not protected by
copyright in the U.S. unless a copyright notice is included. Thus,
we do not necessarily keep eBooks in compliance with any
particular paper edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,


including how to make donations to the Project Gutenberg
Literary Archive Foundation, how to help produce our new
eBooks, and how to subscribe to our email newsletter to hear
about new eBooks.

You might also like