_________________________________________________________
Guide to (mostly) Harmless Hacking
Vol. 5 Programmers' Series
No. 4: How to Program in C, part 2
_________________________________________________________
Common Problems in Getting C Programs to Compile and Run
Now, on to some common problems with getting C programs to compile and run.
In the case of exploit programs, there often are references to other
programs on your target computer. For example, in Leshka's sendmail
exploit, the sendmail program is assumed to exist in /usr/sbin/sendmail.
This works fine for a Linux computer. However, on the Sun OS computer I
like to use, sendmail is in /usr/lib/sendmail. So you can see that an
important first check on an exploit is to make sure all the locations of
files match those of the operating system you are targeting.
His exploit also assumes the command to run the C compiler is "cc".
However, your victim computer may have the GNU C compiler, and it may
require that you give the command "gcc" instead of "cc".
Another problem is that sometimes hackers purposely cripple their exploit
code in order to keep total idiots from running them. For example, the syn
flood exploit program written by Daemon9 and released in the fall, 1996
issue of Phrack had a crucial line of code commented out.
*****************************************************
Newbie note: "Comments" are parts of a program meant for humans to read, not
for the compiler to work on. Comments help people understand a program.
Sometimes a part of a program might be something that you don't always want
to run, in which case it is "commented out" by marking it as a comment to
make it so the compiler can't compile it.
*****************************************************
So if you see something that looks like code between a "/*" and "*/" (which
denote comments in C programs) try removing these comment marks and then run
the program. However, a lot of code commented out may be simply debugging
code the programmer used to make sure it was running properly. You might be
able to use that debugging code to figure out what your problem (bug) is.
Another reason why many people were unable to run that syn flood program
was that it had to be installed with root permissions. As mentioned above
when we were discussing the commands "setuid(0); setgid(0", normally you
only have the right to set root permissions on a program when you are root.
A syn flood program needs root permission in order to manipulate the
creation of packets so as to send floods of them out to the victim with only
the syn flag set, never an ack flag.
Another of your problems may be the include files at the beginning of a C
program. For example, you might find something like this:
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in_systm.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/tcp.h>
#include <netinet/ip_icmp.h>
#include <netdb.h>
If you try to find the file sys/socket.h, you will see it is not a list of
ports, nor is it a table of active sockets. It is merely a C header file.
It contains system specific information which is needed to write network
programs. It varies slightly among different variants of Unix.
There are many types of files that might need to be included in a C program
before it can run. You can get an idea of they type of file by the
extension (the character(s) that follow the period).
.h = header file
.a = archive (library) file
.c = source file
.h = header file
.o = object module (compiled from a .c file)
.sa = shared library stubs linked to your program
What if your shell account doesn't have all the include files? First, you
have to find the missing library functions. Don't email me if you don't
know where they are! First try a search within the computer you are using
with commands such as whereis, which, apropos, man -a and man -k. If that
doesn't work, ask tech support at your ISP. If you have a free shell
account, it probably doesn't offer free tech support. To do serious
programming, it helps to get a commercial shell account. Then tech support
can come to your aid.
If this doesn't work, stand on a street corner holding a sign that reads
"Will work for include files." Whatever you do, DON'T EMAIL ME about this
problem. I can't help you on this!
OK, OK, I feel sorry for you. Meino Christian Cramer has a solution for
the problem of finding where library functions might be. He has written a
bash shell script to automatically find them in Linux computers. (This
script may not work in other shells on other operating systems.) Save the
code below in a file named obcheck.sh and remember to make it executable.
#!/bin/sh
#
# scan libraries for a certain function
#
######################################################
if [ -z $1 ]
then
echos "usage: obcheck <function to search for>
exit
fi
for i in $( cat /etc/ld.so.conf )
do
for j in $( find "$i" -type f -name 'lib*.so.*' )
do
if nm -D "$j" | grep "$1" | egrep "^[0-9A-Fa-f]"
then
echo "$j"
fi
done
done
---------------------------------------------------------
How do you use this script? For example, if you are searching for "printf"
call the script by giving the command:
-> obcheck ' printf '
Reports Cramer, "This will display a couple of messages. Because this only
works on shared libraries, all other libraries are printed with an error
message. Why use ' printf ' instead of simply printf? Cause there are more
functions, all with a "printf" inside their names. But you are only
searching for THE printf."
Now suppose you have found each and every include file your C program needs
to run. The next trick is, you have to tell your compiler where to look for
them. You will use a shell command such as this:
cc -o myhardprogram myhardprogram.c -L/library1/lib -lmylibrary
Where "/mylibrary" is where you put those include files that your compiler
didn't automatically find in the standard libraries of your computer. Be
sure to have this command all on one line without a return, or it won't work!
How to Program C Securely
Probably the largest class of computer break-in techniques is C programs
running on Unix type operating systems that suffer from buffer overflows.
Even if you are just beginning to learn how to program in C, it may be wise
to get an early understanding of this major weakness in the language.
Is your goal to break into computers? The single most important thing
about C is that it allows buffer overflows. "Segmentation fault,"
anyone?;^) OK, OK, you nitpickers, I know not all buffer overflows cause a
"segmentation fault" error messages, but give me a break, I'm trying to make
this chapter funny. Trust me on this, there will be days when you will need
every bit of humor you can muster to endure sorting out why your C program
won't compile.
**********************************************************
Newbie note: Buffer overflow? Here's the easy explanation. A buffer is a
place in memory where data is briefly stored while a program is running. A
buffer overflow is when a program tries to put data into a place in the
victim computer's memory where there isn't enough room for it. It's like
pouring two liters of water into a one liter container. The extra water
overflows.
If data that overflows a buffer in a C program contains the right commands
-- in assembly language -- and if it leaks into the right place, voila! You
get a root shell!
**********************************************************
Here's the technical explanation of a buffer overflow exploit. A buffer is
a contiguous block of computer memory that, while a program is running,
holds a given type of data. The problem comes with "dynamically allocated
variables" (a variable is a name in a program that holds data that may
vary). In order to not use up too much memory, a program with dynamically
allocated variables does not decide how much memory to give to these
variables until it is already running.
What happens if a program pours too much data into this dynamically
allocated buffer? It overflows, leaking out somewhere else. A buffer
overflow exploit uses this leaking data to put assembly language code
elsewhere into the victim computer's memory -- often somewhere that will
create a root shell.
The C programming language allows buffer overflow exploits because some of
its functions for copying or appending strings fail to check whether doing
so would overflow a buffer. These include sprintf(), strcat(), strcpy(),and
vsprintf().
A buffer overflow alone is not enough to take over a computer. It must be
in a program that would send the overflow to a location that would enable it
to run a command to create a shell with root privileges. Then an exploit
program must be run that will pour into that buffer the exact number of bits
needed to insert these instructions, which may be in assembly language, into
the right memory location.
Assembly languages are the commands that the central processing units (CPU)
of computers understand. Because there are many different kinds of CPUs
(SPARCs for Suns, MIPS for SGIs etc.), you may have to make sure the exploit
you want to run will work on that kind of CPU.
**********************************************************
Wizard tip: Do you want to become an Uberhacker? Do you want to become one
of those almost mythological beings who are said to flow through cyberspace
as if there were no walls? Write your own buffer overflow exploits!
For a detailed explanation of how to search for these security holes and
design code to exploit them, see "Smashing the Stack," by Aleph One, at
http://www.netspace.org/lsv-archive/bugtraq.html.
Better yet, don't write buffer overflow exploits. As my secret super hacker
friend says, "Overflows have become annoying. Since the screen exploit for
Linux (almost 3 years ago) that's most of what's been coming out. It's
boring! It's the same damn bug over and over again. WE GET THE POINT
ALREADY! Seriously, if someone came up with
three overflow bugs and someone else came up with 1 non-overflow root
exploit, I'd have more respect for the second person."
**********************************************************
It can be embarrassing, however, if you are the programmer who writes
software that someone else uses to create a buffer overflow exploit. How
can you learn to write C code that avoids this nasty problem?
Aleph One <aleph1@DFW.NET>, who runs the Bugtraq computer security list,
has come up with a list of references for those of us who want to learn how
to write secure C code. (Our apologies if these links go out of date.)
http://www.sun.com/sunworldonline/swol-04-1998/swol-04-unixsecurity.html
http://www.sun.com/sunworldonline/swol-04-1998/swol-04-security.html
http://www.homeport.org/~adam/review.html
http://olympus.cs.ucdavis.edu/~bishop/secprog.html
http://www.research.att.com/~smb/talks/odds.[ps|pdf]
http://www.pobox.com/~kragen/security-holes.txt
http://www.amazon.com/exec/obidos/ISBN=0131103628/noworries00A/
Chapter 22 in the book Practical UNIX & Internet Security by Simson
Garfinkel, Gene Spafford (O'Reilly & Associates, 1996) is called "Writing
Secure SUID and Network Programs".
Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C
Programs
, by Steve Maguire, (Microsoft Press, 1993). The book focuses on
writing bug-free software.
Take the SANS course "Writing Secure Programs," taught by Matt Bishop.
http://www.sans.org
Conclusion
Honest, C programming really is easy and fun. You just have to have the
ability to look at it as an adventure when your !@#$@##$% program doesn't
compile! Joker can tell you that's true, right, Joker?:^)
**********************************************************
You can go to jail warning: It is illegal to break into a computer even if
you do no harm. The only Uberhackers I know of are so talented, and also so
careful to do no harm, that only another Uberhacker would ever know one had
broken into a computer. But if you are reading this to find out how to
break into computers, you probably aren't good enough to keep from getting
caught. Leshka's sendmail exploit program only does a tiny bit of cleanup,
so you still are likely to get caught if you run it against a computer whose
owner has not given you permission to break in. You also are likely to
accidentally do damage while root on the victim computer. Do this to your
own computer so you are the one who has to figure out what you did as root, OK?
*********************************************************
_______________________________________________________________________
Where are those back issues of GTMHHs and Happy Hacker Digests? Check out
the official Happy Hacker Web page at http://www.happyhacker.org.
We are against computer crime. We support good, old-fashioned hacking of the
kind that led to the creation of the Internet and a new era of freedom of
information. But we hate computer crime. So don't email us about any crimes
you have committed!
To subscribe to Happy Hacker and receive the Guides to (mostly) Harmless
Hacking, please email hacker@techbroker.com with message "subscribe
happy-hacker" in the body of your message.
Copyright 1998 Carolyn Meinel. You may forward, print out or post this
GUIDE TO (mostly) HARMLESS HACKING on your Web site as long as you leave
this notice at the end.
_________________________________________________________
Carolyn Meinel
M/B Research -- The Technology Brokers
http://techbroker.com
|
