What's New!

Chat with

How to Defend
Your Computer 

The Guides
to (mostly) 
Harmless Hacking

Happy Hacker 
Digests (old stuff) 

Hacker Links 


Meet the 
Happy Hacksters 

Help for 



It Sucks 
to Be Me!

How to Commit
Computer Crime (not)! 

What Is a 
Hacker, Anyhow? 

Have a 
Great Life! 

News from the 
Hacker War Front

Carolyn's most
popular book,
in 4th edition now!

For advanced
hacker studies,
read Carolyn's
Google Groups
Subscribe to Happy Hacker
Visit this group

Apr. 6, 1999
See the Happy Hacker web site at http://www.happyhacker.org
URL of the day: http://www.o2.net/~gromitkc/winmodem.html - WinModems

Editor's Comments
Poll Results
Nuggets of Info
Reader Questions
Reader Submissions
Race Conditions
Future Issues

      *** Editor's Comments

I was planning on doing some more in-depth articles, but I got some really
good submissions and I thought I'd put those in before I start hogging
space. I realized I wrapped up the whole buffer overflow discussion rather
quickly in the last digest, and for that I am sorry. If there's enough
interest, I'll try to explain some points better that I may have been
unclear on. 

      *** URLs

Help for UNIX administrators of any flavor

The UNIX Guru Universe

List of all Internet-related "assigned numbers" and more

MAC address info (in first few lessons)

      *** Poll Results

Here are the somewhat sparse results of the Poll about which books are the
best for Learning Linux and Network Security.

Books for Learning Linux:
Running Linux            2 votes
Linux Unleashed          2 votes (UNIX Ed's vote)
Linux in a Nutshell      2 votes
Unix for Dummies         1 vote
The no BS Guide to Linux 1 vote
Instant UNIX             1 vote
Honorable Mention: man pages. While not a book, they are a great place to
learn what's going on in Linux. We had a couple votes for them.

Books for Learning Network Security:
Firewalls and Internet Security      1 vote
Practical UNIX and Internet Security 1 vote (UNIX Ed's vote)
Maximum Security                     1 vote

Also, the modem poll has been closed since I was informed of a good list
of modems (see the URL of the day). A quick note: external modems are a
good choice. They're not generally OS-dependent.

      *** Nuggets of Info

1) If you want to find a site that offers Linux, search for it. I've
   listed many possibilities in previous digests. Go start there.

2) Trying to set up a Plug and Play device? Try "man isapnp", "man
   pnpdump", "man isapnp.conf" and the Sound-HOWTO.

      *** Reader Questions

Willen van Wyk <willemvw@nscfw.iafrica.com> wrote:

Hi Carolyn!

I have the opportunity to get hold of Redhat linux. Apparently (this I
only know from hear-say) Redhat is quite nifty in the sense that it
automatically detects your hardware. From that I assume the OS is quite
easy to install.

On the other hand, I understand that the older versions of Linux are quite
difficult to install and does not have much updated drivers. Now I don't
want to have redhat linux which you (like winblows) just pop the cd into
the drive, run setup, it does everything for you and voila! your pc has a
linux OS and now you just (like with DOS) learn the commands. I want to
know what to do to initialise your HDD (like partition the drive) for
Linux as well as go thru all the "blood, sweat and tears" of going thru
all the procedures of installing Linux from scratch.

But, I also want a Linux OS that is compatible with the utilities programs
which you get with Linux. (i.e. if I have Linux 2 for argument sake, will
I be able to load some utilities from say linux 4 or 5 or whatever.)

So basically, what I'm after is the best of both worlds. I want a Linux
version which is compatible with later utilities, but is also quite a
"devil" to install. (Like Carolyn said in her happy hacker site that you
must first take a drink or two!)

Any help regarding this will be appreciated.

Thank You

P.S. Thank You for the wonderful Happy Hacker documentation that is
published on the web!!!! I think it's brilliant. I'm still enjoying
reading the information presented in there. (I'm almost aquarter way
reading thru it after almost a week of having the info.)

[Ed- If you want to get "Down and Dirty", want to have some help, and alot
of flexibility, I'd suggest Debian. Slackware might not be a bad choice,
either. I started with Slackware, but quickly became a Debian convert. I'm
sure we'll have other opinions here.]


FuzzyFlup <flup@telekabel.nl> wrote:


I was wondering is there is a little program or script out there, which
does the following:

- Check a file content for several certain words or numbers, to specify by
   the user
- Gives a beep or another alert when it finds it
- Deletes and remakes the file when it reaches a certain size, also to
   specify by the user

I'd like to use it with tcpdump > outputfile, because I don't always watch
my tcpdump, and the connects scroll by very fast too.

[Ed- I don't know of one offhand, though it shouldn't be too difficult to
write yourself. Periodically grep the file for whatever, and if grep
returns something, trigger your alarm. After that's been done, check the
file size and delete if above a threshold. Here's something for your Perl
corner, Windows Ed!]


Marc Childress <marc.childress@lownotes.org> wrote:


As I understand it, RedHat's default installation is rather "insecure".
For example - it has issue recently pointed out to me is that sendmail
(which is started at boot) relays by default.  Is it correct that,
without sufficient prevention (hosts.allow/deny, firewalling, disallowing
sendmail to run at boot), anyone can use my sendmail to send messages
from my computer - in my name?  Spammers could use that to their
advantage.  I am sure that this isn't the only insecure program / obvious
hole present after the default installation - could you please list
others and links on how to fix?


Marc Childress

[Ed- I've gotten many questions about "out of the box" configurations. My
first piece of advice would be to check out Redhat's errata page at
Then I'd say to turn off all network services you're not using. That
should help quite a bit.]

      *** Reader Submissions

Anonymous wrote:

Mac addresses are assigned to Network Interface Cards, each one being 
entirely unique, unless you buy a pirated one with the same mac address 
in each as they did in china, but they are essentail for talking any 
protocol.  What very simply happens is that the mac address is the final 
destination of a computer, regardless of any IP address.  The mac address 
is requested/broadcasted to each computer by an arp request, such as

arp: whohas tell scooby
and will follow with a reply with a mac address, etc.

All routing is done eventually thru mac addresses, which operate at the 
2nd layer of the OSI model.  Routers operate on the 3rd and help with IP 
addressing, etc.

Hope this is of some interest.


Bluelead wrote:

I have a book which I have found very useful, as it is 
small enough to slip into my toolkit/backpack.  It's 
"The Hip Pocket Guide to Unix" by Michele Petrovsky and 
Tom Parkinson, pub. IDG Books, ISBN 0-7645-3226-X.  Its 
list price is $14.99, I found it for about $11.00 at a 
book discounter in my local area.


Ande Vitko <mountain_bike@rocketmail.com> wrote:

     So far I have read all of the digests only to wonder when we are
going to talk about security issues.  I always believed that turning
on your syslogs was something important.  Or how about talking about
rhosts or any "r" command.  Here is one, editing the inetd.conf file
in /etc so that you can turn on/off ports that you do not need.  I
heard that secure shell was pretty good.  If this is a security digest
then why are we talking about shell scripting and modems instead of
the basics.  Start with securing your own box before getting into
scripting.  I have seen numerous people write about the "ps" command. 
It is unix folks and everybody has their own preference.  That is like
talking about the ls command.  "ls -al" "ls -F" "ls -a"....which do
you prefer.  Here is something that hasn't been mentioned.....backup
and recovery.  If your system get hacked and they were destructive
don't you think it would be nice to know how to recover your system
from a recent backup that you learned how to do.  For future reference
folks....use the man pages.  You would be surprised at what you could

Teamwork is essential.  It gives the enemy someone else to shoot at.

[Ed- Hee hee...great quote.]

                        Andrew J Vitko 

[Ed- There is a perfectly good reason why I'm not starting from scratch
and doing just newbie explanations and building up. First, because there
are plenty of people here who would be absolutely bored by it. Second, if
someone joined the list in the middle of one of the 'steps', they would
probably be confused. As for the preferences, many people write because
they don't know what a particular command does enough to establish their
preferences. Hearing what other people use and like may help them. As for
all your suggestions, I totally agree. Here's a formal request for
readers: Feel free to write about anything Ande mentioned above. If you
want to know about something he mentioned above, clearly email me at
unixeditor@cmeinel.com and I'll try to tackle it myself if it hasn't
yet been answered.]


Lance Spitzner <spitzner@dimension.net> wrote:


I've whipped a little goodie you might be interested in :)
I've written a whitepaper titled "Know Your Enemy".  It
focuses on the tools and methodologies of the Script Kiddie.
I focus on the technical how of what they are doing, 
including what tools they are using and how.  The paper
is based on several months research, including some actual
Kiddies I have caught.

I thought you might be interested :)  You can find the paper

Thanks, and keep those digests coming!!

Lance Spitzner
Internetworking & Security Engineer
Dimension Enterprises Inc


mechanic@javanet.com wrote:

in reply to:

>[Ed- A MAC address is a unique ID number assigned to every network card
>manufactured. There are a number of reasons for their existence, probably
>the most important being the ability to identify a computer on a network
>according to this number. Anyone care to elaborate?]

yes, as ed said, it is a unique hardware address assigned to network
interfaces. MAC addresses are not perm though, there are programs out
there that allow you to change and 'spoof' someone else's MAC address. 

Other ways MAC addresses are used? Companies that now offer cable modem
access, use the MAC address of a card to identify who's computer it is,
since essentially, you are just on one large network, and so not just
anybody can hook up a cable modem and get free service, if you change
NIC's you have to register your new MAC address with the cable modem
provider, so you can use the service. 

How can you tell your MAC address under linux? type 'ifconfig [device]',
example being 'ifconfig eth0' which would output this:

eth0      Link encap:Ethernet  HWaddr 00:60:97:22:25:1A
          inet addr:  Bcast:  Mask:
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Interrupt:11 Base address:0x6100

where the HWaddr is the hexidecimal MAC address of your NIC.


Joshua D. Knarr <tiberian@icdc.com> wrote:

>carl shikic <shiki11@yahoo.com> wrote:
>Hi there,
>In the last editon of the digest you mentioned that you might add C++
>corner. I think that is an awesome idea (even for a windows digest as
>well) A few issues ago 'netstat' command was mentioned, and my
>question is sort of related to that. after (one of the times that) I
>issued the command this is what i got:
>Since I don't know the process id#, how can I 'kill' just that TCP
>connection ( on port 1035 )?Is there a way for me to see what kind of
>info is going on through that port? Also what is the meaning of the
>UDP protocol being open on port 1025?

D'oh!  Here is another question that could have been answered if you
zelots experimented a bit with what you find <grin>.  First off, this is
Just Plain Wrong (tm) for the UNIX version of the digest (wha?  NetStat
in UNIX?).

[Ed- Come again? netstat works perfectly fine on my Linux box here. He may
have been on a Windows box, but I thought it was relevant.]

Down to buisness....  ICQ uses port 1025 for it's outgoing messages.  It
also chooses a random port for incoming messages.  I have not decompiled
ICQ, but I think that the server, when you log on, your whole contact list
gets a special message informing them of what port your ICQ is on, at
which point all the people's icq "remembers".  The port 1035 is probably
your random incoming ICQ port, and you really don't wanna give this out
to ppl, because it leaves you open to a whole slew of attacks via
emulated messages and whatnot.  You can play total havoc if you really
feel like a jerk that day if you have this.  That's the second problem,
ICQ always chooses a port between 1024 and 4000, so anyone with a port
scanner, your IP, and a wee bit of luck can track the other port down in
about 15 minutes (assuming your scanning at a reasonable speed).


[Ed- Note: It may not necessarily be ICQ on this port. It could be one of
any number of programs, though I concur with TS that ICQ is the most
likely culprit.]

      *** Race Conditions, et al

Thanks to Mario Hoerich <Mario_Hoerich@t-online.de> for the following
reply and article!

> bandix <bandix@id-base.com> wrote:

> quite excited to see a *n?x publication added to the collection.
> However the first few issues of the UNIX Digest have really disappointed
> me.


> Let us not act like the 13 year olds on SlashDot, you are supposed
> to be aspiring computer security professionals, not holy crusaders.  

ACK. Let's rather write some nice stuff, which actually contains 
some valuable information instead of flaming. Personally, I'd love
to see more about programming issues, certainly C (and C++) contain
more than enough things to confuse programmers. 

> is "hmm..I wonder what programs run as root?" Well, you can see that on
> your local machine pretty easily by typing 

> ps aux | grep root

If you have zsh on your machine, you might want to use the following
shell builtin:

$cd /bin
$ls -l *(s)
-rwsr-xr-x   1 root     root        37468 Jul 17  1998 login*
-rwsr-xr-x   1 root     root        38476 Jun  8  1998 mount*
-rwsr-xr-x   1 root     root        14308 Jul 15  1998 ping*
-rwsr-xr-x   1 root     root        11036 Nov  4  1997 su*
-rwsr-xr-x   1 root     root        19028 Jun  8  1998 umount*
which lists all setuid programs. 

> Without looking at the source code to a program, it somewhat 
> difficult to determine where a buffer overflow exists. 

However, if you enter 1000 a's and the programm responds with
`segmentation fault', voilà, your vulnerable buffer. 

[Ed- Good point. Though without the source code, it's going to be
much more difficult to exploit that buffer.]

> prevented it. So crack out some sendmail source code and find those
> overflows in the meantime! ;)


While `speaking' of insecure code, there's another thing to look after,
the so-called

Race Conditions
Let me try to explain this. 

[Ed- Good call! I've had a bunch of people asking about this, and I was
going to write something up myself in a future digest, but you beat me to

Imagine you have some setuid root program, called suidp, which is 
mode 755. You know that it creates a file in tmp, called  `/tmp/suidp'. 

Further, suppose you create the following link;

    $ ln -s /boot/vmlinuz /tmp/suidp

Now, what happens when you start the program? It will start, and
at some time open(2) it's tmpfile:

    fd = open("/tmp/suidp", O_WRONLY);

Well, after this, it will write some data to the file, which 
is a link to the kernel image. Since the processes euid is 0,
it will happily write some bytes into the kernel, which most
likely will not improve it, after all...

[Ed- Writing to the kernel? That's kinda mean. :)]

BTW, this does not only apply to setuid root programs, but 
rather to every process run with root privileges. 

To prevent this, the programmer should first make sure that
the tmpfilename is non-predictable, or in a mode 755 directory.
( non-predictable usually means that several pseudorandom-digits 
  are appended to the filename, e.g.: `/tmp/suip-00343657' ).
Second, and even more important, the file must not be open(2)ed
with above mode, but rather with the following call:

 fd = open(tmpfile, O_RDWR | O_CREAT | O_EXCL);

which will open the tmpfile in read/write mode ONLY if it does not
already exist. 

Well, is this secure now? No. To make matters worse, there is
another possibility, which is all but not obvious.

Imagine the following situation:

Above program has mode 755 and you can execute it. You do, and
watch /tmp. Once the process has created its tmpfile, you send
either a SIGSTOP or a SIGTSTP to the process (SIGSTOP is a lot
like SIGKILL, it can neither be caught, nor ignored nor can it 
be blocked. AFAIK SIGTSTP _can_ be caught, so don't waste your
time with Ctrl+Z, but use kill -STOP instead.). Now, you have 
*plenty* of time to replace the tmpfile with a link to the 
kernel image. Since the program assumes the file to be secure, 
it will happily write in your kernel image. 

[Ed- Correct. According to Stevens' "Unix Network Programming" "The two
signals SIGKILL and SIGSTOP cannot be ignored." All the rest can be

In order to prevent stuff like that, you may want to create 
either a lock, or reduce the permissions. 

(1) Creating a lock

An exclusively locked file may not be accessed by a process,
other than the one creating the lock. unlink(2) might still
be able to access the file, but --according to the man page--
the file will not be deleted until the file descriptor is 

fd = open(tmpfile, O_RDWR | O_CREAT | O_EXCL);
flock(fd, LOCK_EX);

This should be the most secure way to do this. 
You may consider to use fcntl(2) to create the lock, 
but then, fcntl(2) is just _too_ overloaded with options. 

(2) Reducing the permissions

This is something you should do whenever writing setuid programs.
Start your program with 

int euid;

int main(int argc, char **argv)
     /* Declarations */

     /* store the effective uid */
 euid = geteuid();
     /* set the euid to the real uid */
        seteuid( getuid());

     /* Rest of code */

Whenever you need the higher privileges, and ONLY if you
REALLY need them, use:

     /* privileged code */

This might prevent above case, too, but it is always better 
to use a lock.

Hm. Questions? Comments? Feel free to educate me, in case I 
got anything wrong.

[Ed- It works for me!]

[kernel recompiling] 
> It might not be a bad idea to back up your old kernel (generally
> /vmlinuz or /zImage directory) and your modules directory in case something
> messes up. Don't get frustrated if you end up reinstalling Linux or
> having to recompile the kernel if things go wrong. It's happened to
> me and is probably the best way to learn.

I think it is better to create (if not already available) the directory
/boot and just copy the kernel images in there. For example, my /boot
directory contains 9 kernel images at the moment (e.g.
vmlinuz.2.2.0pre9-4). Inside the directory are 3 links (backup, stable &
new) which all point to a different image. Whenever I recompile the
kernel, I adjust the `new'-link to the new image, and `stable' to an
image that ran well before.

Afterwards, I rerun lilo. If the kernel fails to boot,well, I have
a stable kernel on disk and if *that* fails, too (maybe due to missing
modules) I still have a `backup' kernel, which at the moment is 2.0.37ac3.
The modules of this reside in a different directory, and therefore the 
machine WILL boot. Did I mention that I'm somewhat paranoid? ;) 

Now, look at my /etc/lilo.conf, it isn't hard to set your machine up
the way I did.

boot=/dev/fd0        ## I'm REALLY paranoid. ;) 
### DOS Partition
  other = /dev/hda1
  label = dos
  table = /dev/hda
  alias = 1
### Linux 1
  image = /boot/stable
  root = /dev/hdb1 
  label = stable
  alias = 2
### Linux 2
  image = /boot/new
  root =  /dev/hdb1
  label = new
  alias = 3
### Linux 3
  image = /boot/backup
  root = /dev/hdb1
  label = backup
  alias = 4
My apologies for the length of this, but with this,
you needn't pray after every kernel recompililation.  

(Sorry to the original writer, this is meant as
 a minor improvement to your article and _not_ as flame.)

[Ed- Quite OK! This kind of article is the best. I missed some important
points, and you weren't afraid to explain in detail.]

> Hopefully this is enough to get you all started
> down the path of the kernel hacker. :)

Apropos `kernel hacker', does anyone know a good book about
operating systems in general? (I found a nice book covering 
the Linux Kernel, but first of all, I'd prefer to have some
kind of basic introduction to OS design. Afterwards, the 
implementation will be much easier to grasp, I think. )

[Ed- The book I used for my OS class in college was called "Operating
Systems Concepts" by Silverschatz and Galvin, published by Addison-Wesley.
It goes over many important details of operatings systems and it gets my


      *** Future Issues

Setting up your own Wargame
Onion Routing
How Private is it?



This is a list devoted to *legal* hacking! If you plan to use any
information in this Digest or at our Web site to commit crime, go away!
Foo on you! Don't email us bragging about any crimes you may have committed.
We mean it. 

For Windows questions, email keydet89@yahoo.com or editor@cmeinel.com
For Unix questions, contact unixeditor@cmeinel.com.
For Macs, email Strider <s.corinth@iname.com> 

Happy Hacker staff: Unix editor, <unixeditor@cmeinel.com>;
Windows editor, Keydet89 <editor@cmeinel.com>; postmasters Jonathan D.
Zerulik and William Lewis <>; Hacker Wargame Director,
Vincent Larsen <vincent@sage-inc.com>; Wargame Sysadmin, Satori
<Satori@rt66.com>; Webmaster, Diode <webmaster@happyhacker.org>; Clown
Princess: Carolyn Meinel <>

Happy Hacker is a 501 (c) (3) tax deductible organization 
in the United States operating under Shepherd's Fold Ministries. Yes! 
This is all a plot to save your immortal souls!

 © 2013 Happy Hacker All rights reserved.