From owner-freebsd-security Thu Sep 7 2:53:57 2000 Delivered-To: freebsd-security@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 827BE37B423; Thu, 7 Sep 2000 02:53:52 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id CAA91350; Thu, 7 Sep 2000 02:53:52 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Thu, 7 Sep 2000 02:53:51 -0700 (PDT) From: Kris Kennaway To: Paul Herman Cc: Neil Blakey-Milner , freebsd-security@FreeBSD.ORG, security-officer@freebsd.org Subject: Re: UNIX locale format string vulnerability (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 7 Sep 2000, Paul Herman wrote: > However, this thread only talked about vulnerable Linux programs under > emulation. There were indeed two advisories this last weekend, the > glibc advisory (linux only) and the locale advisory, which AFAIK > affects other platforms (Solaris is affected, for example.) > > I've been following freebsd-security, but I haven't seen any > confirmation one way or the other (except for linux binaries mentioned > in this thread.) Kris, is FreeBSD itself vulnerable to the locale > vuln.? Short answer: sort of, but only in certain third party applications (I don't know of any at the moment). The FreeBSD base system is not believed to be vulnerable. Back on 05 Aug I committed a fix to -current for an exploitable buffer overflow in catopen(). This was merged to 4.1-STABLE on 22 August, because I got distracted and forgot about it :-( I'm still trying to get time to write an advisory. A few weeks later, we were contacted by Ivan Arce of core-sdi about multi-vendor problems with locale functions - we weren't vulnerable to any of these mentioned. During their testing, the glibc guys discovered a further problem wherein a setuid app could be told to look at a user-supplied file for catalog data, which could then be used to execute arbitrary code if the application is badly written and does not make use of the data correctly (this is a typical "missing format string" vulnerability). That one was fixed in -current on September 1, but that has not yet been merged. I only realised this vulnerability yesterday - I'll get it merged ASAP. HOWEVER: no program shipped in the FreeBSD base system is believed to be vulnerable to either of these problems. They both affect catopen(), and we don't use that function at all except in tcsh, which is non-privileged. We don't even have any code which has the required bug needed to exploit the second problem (assuming the first condition were true) - I did a big sweep a month or two back for all such instances of incorrect format string handling, and there were none in privileged programs (and few such real bugs in other programs). I don't know of any ports which install setugid binaries and use catopen(). If they do, they are vulnerable. If not, you have nothing to worry about. I'm going to try and get the advisory out this week which will include a scanning utility to check vulnerability of ports. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message