[LWN Logo]
[Timeline]
Date:         Thu, 31 Aug 2000 04:14:23 +0400
From: Solar Designer <solar@FALSE.COM>
Subject:      glibc unsetenv bug
To: BUGTRAQ@SECURITYFOCUS.COM

Hello,

Two distribution vendors have recently issued updated packages and
advisories regarding a glibc bug.  While I don't consider this bug
to be a serious security issue, a more detailed description of the
bug and information on affected glibc versions is needed.

I am forwarding a message I posted to security-audit a week ago
regarding the glibc unsetenv bug.

Unfortunately, there's currently no notification policy for glibc
security fixes.  The bug was reported and fixed months ago, but it's
only now that updated packages start to appear (whether _this_ bug
was worth the updates or not is another question).  What's worse,
there's been more security-related fixes applied to glibc since the
2.1.3 release (which most current GNU/whatever/Linux distributions
are using), including some that I believe are somewhat more serious.
It's very likely that I'm not aware of some (many? most?) of such
bugs/fixes.  Most distribution vendors aren't aware, as well.

The glibc maintainers are taking bug reports seriously (all of what
I've reported got fixed within days), and I respect that.

I still hope that a policy appears to notify at least the major
distribution vendors of security-related fixes being applied to
glibc, so that the vendors know (1) when to issue an updated package
and (2) what exactly was fixed, so that they have the choice to
back-port the fix to whatever glibc version their supported releases
are based on.  The rest of us would become aware of the fixes once
the first vendor update is released.  Of course, I would prefer that
full details on the bugs are also disclosed to the public by glibc
maintainers themselves, but I could live without that.

I am still unsure whether it was appropriate to post my concerns to
Bugtraq at this time.  I am disappointed to see vendors spend their
time and the time of their customers/users on a security update that
has only one of the security-related fixes that have already been
developed (and are in the CVS), so this is what made me do this post.

Regarding those other fixes that I've mentioned, I will be trying to
notify at least some distribution vendors myself now, and am going to
do a second Bugtraq post with full details in a week.

From: Solar Designer <solar@false.com>
Subject: Re: standard libraries (STL, GLib,...)
To: daw at cs.berkeley.edu (David A. Wagner)
Date: Thu, 24 Aug 2000 08:49:58 +0400 (MSD)
Cc: security-audit at ferret.lmh.ox.ac.uk

> > Although, I've found a whopper: putenv() code that failed to delete
> > an env var if it appeared twice successively in environ, thanks to an
> > off-by-one bug.
>
> Someone asked for more details.  Here they are.

Thanks.

> Summary: I was wrong.  It is not yet fixed!  Exploits seem possible.
> glibc 2.1.1 was fully vulnerable; glibc 2.1.2 and 2.1.3 are only half
> fixed (ld.so still vulnerable).  Supposedly, it'll be fixed in 2.2.

I've just checked, -- the fix got into the CVS a few days after your
report in May.  glibc 2.1.3 was already out by the time.  The glibc
"2.1.3" as included in RH 6.2 is based on a later CVS version (so it
isn't really 2.1.3, even without patches included in the SRPM), but
is older than May and thus still has the bug.

I've spent an hour on this and, fortunately, the bug can't be used to
attack the dynamic linker of a SUID/SGID binary directly.  It can,
however, affect poorly written sudo-like applications, if some aren't
smart enough to unset LD_PRELOAD and LD_LIBRARY_PATH (with a working
unsetenv() or, better, by creating a new environ, of course).  So,
an application bug is needed to exploit this glibc bug.

> I misspoke; the bug was in unsetenv(), not in putenv().  The code for

Well, putenv() calls unsetenv() in one of the two possible cases, so
it was affected as well.

> However, in May 2000, I reported that the bug had actually not been
> fully eradicated.  It was fixed only in the copy of unsetenv() found in
> sysdeps/generic/setenv.c, but not in the copy of unsetenv() found in
> sysdeps/generic/dl-environ.c (probably a cut-and-paste of the former
> that had escaped notice).  The maintainers said that it will be fixed
> in glibc 2.2.  See:
>   http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1714

And the patch can be obtained at:

http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/generic/dl-environ.c.diff?cvsroot=glibc&r1=1.1&r2=1.2&f=u

> ObHistoricalNote: By the way, does anyone remember the bug in telnetd
> accepting environment variables?  There was a fascinating bug explained
> there: setenv(name,val) and unsetenv(name) do not behave as expected
> when 'name' contains an '=' character!  setenv("x=y","z") defines the
> environment variable called "x"; unsetenv("x=y") deletes the variable
> called "x=y".  Subtle, eh?

Perhaps it would be nice if setenv() refused to set a variable with
'=' in its name, what do you think?

Signed,
Solar Designer