[16005] in bugtraq

home help back first fref pref prev next nref lref last post

Re: i18n issues with format bugs

daemon@ATHENA.MIT.EDU (Theo de Raadt)
Sat Jul 29 15:24:23 2000

Message-Id:  <200007261908.e6QJ89U02769@cvs.openbsd.org>
Date:         Wed, 26 Jul 2000 13:08:09 -0600
Reply-To: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
From: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
X-To:         John Levon <moz@COMPSOC.MAN.AC.UK>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  Your message of "Wed, 26 Jul 2000 16:12:39 BST." 
              <Pine.LNX.4.21.0007261604470.27538-100000@mrbusy.compsoc.man.ac.uk>

> After discussion with David Wheeler (and I noticed some
> on BUGTRAQ had also mentioned this) it seems that there is
> the possibility of format problems for programs naively trusting
> localised strings.
>
> 1) The GNU gettext source doesn't seem to be a problem, with the exception
> of cat-compat.c, where bindtextdomain() checks the environment variable
> $NLSPATH. The question is whether any software out there actually uses
> this code any more
>
> 2) catgets() as specified in SuS can be used to retrieve arbitrary strings
> via $NLSPATH. The SuS specification is here :
>
> http://www.opengroup.org/onlinepubs/007908799/xsh/catopen.html
>
> As it happens, the GNU libc ignores this environment variable in the
> suid/sgid case. I don't know whether this also applies to other vendor's
> implementations ?
>
> I don't actually have a specific piece of code that's under risk, but it
> seems that in general catgets() and friends cannot be trusted. Of course,
> all the code out there doesn't trust outside functions anyway, right ?

Didn't we go over this two years ago?

RCS file: /cvs/src/lib/libc/nls/catopen.c,v
revision 1.6
date: 1996/08/26 00:17:20;  author: deraadt;  state: Exp;  lines: +6 -8
use issetugid() to protect against bad getenv

Oops, we went over this 4 years ago.

That was around the time that Mudge and I were talking, and I made a
bet that almost every unix-like operating system would have problems
in their nls, locale, or time code, mostly probably related to
environment variable problems.  It caused problems in FreeBSD.  Then
in Linux.  Then in Solaris.

Then a few weeks ago something very similar NT.  I was extremely
amused.

I wish I had placed a real bet about it, because then Mudge would have
to buy me some double whiskey sours.  But I suspect he's going to
force them on me anyways..

John -- four years ago, there was an extended BUGTRAQ discussion on
the use and misuse of environment variables inside libraries.  We also
discussed why safety checking with uid/euid & gid/egid comparisons
might not be sufficient.  Go search for it.

For the record, we've fielded zero complaints about these environment
variables not working in unsafe situations.

home help back first fref pref prev next nref lref last post