From owner-freebsd-audit Wed Feb 6 17: 2: 3 2002 Delivered-To: freebsd-audit@freebsd.org Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by hub.freebsd.org (Postfix) with ESMTP id 2DA9037B404 for ; Wed, 6 Feb 2002 17:02:00 -0800 (PST) Received: from there ([4.61.185.117]) by out008.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020207010159.EFLX12982.out008.verizon.net@there> for ; Wed, 6 Feb 2002 19:01:59 -0600 Content-Type: text/plain; charset="iso-8859-1" From: biometrix Reply-To: bio.metrix@gte.net Organization: NAIS To: audit@freebsd.org Subject: tmpfile() libc call causes buffer overflow? Date: Tue, 5 Feb 2002 19:05:30 +0000 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020207010159.EFLX12982.out008.verizon.net@there> Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I found if I altered TMPDIR exported variable to an a long string (X50 "G") /usr/bin/pr would exit with a segmentation fault. export TMPDIR=`perl -e 'print "G" x 50'` bash-2.05# pr Cannot defer diagnostic messages Segmentation fault (core dumped) The code executed just before the segmentation fault is : if ((err = tmpfile()) == NULL) { (void)fputs("Cannot defer diagnosticm essages\n",stderr); return(1); } In : /usr/src/lib/libc/stdio/tmpfile.c there is a call for "tmpdir = getenv("TMPDIR");" so it returns a filename based on the enviroment variable "TMPDIR" so the result of tmpfile() can be poisoned by altering TMPDIR ? I tested it using most of the code found in "tmpfile.c" and got the result: ./test GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG/tmp.XXXXXX gdb says the error occurs in: #0 0x280dca59 in __sfvwrite () from /usr/lib/libc.so.4 when pr crashes and the core file contains the string: strings pr.core | grep -i tmp GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG/tmp.XXXXXX GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG/tmp.GIvbJl TMPDIR /tmp TMPDIR=GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG pr is the only binary I can find in the source tree that uses the tmpfile() call so cannot test against anything else. Am I incorrect that this problem is caused by the getenv() for TMPDIR in tmpfile.c? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message