Bug#4190: Bug4190: serious security hole in libc (resolver)
This is why I really wish H.J. Lu would make pure, bug-fix only
releases for the current, stable libcs. Yes, I know Debian isn't
using the latest, stable libc, but this paritcular bug isn't fixed in
the current beta version either.
Marek Michalkiewicz writes:
> I think there are two possible ways to fix it:
> (1) ignore the dangerous environment variables completely (is anyone
> actually using them? I heard about them for the first time from
> the security alert...). If anyone needs these features - create
> a separate full-featured resolver library people can use (for
> non-setuid programs only) by setting LD_PRELOAD.
Supposedly, the NSS support in libc 6 has a much better way of
handling things like this.
> (2) ignore them if (geteuid() != getuid() || getegid() != getgid()).
> Problem: you can pass them to login via telnetd, so telnetd
> needs to be fixed too. Anyway, I think telnetd should do what
> the one in NetKit-0.08 does: allow only a few (known to be safe)
> environment variables, and don't allow the rest. Right now, we
> check for a few variables known to be dangerous - and we can't
> be sure that there are no more. The bash man page mentions
> BASH_ENV in one place, and it's not checked by telnetd.
About the best I can do, without further guidance, is make libc not
echo the problem lines to stderr. Is that acceptable?
David
--
David Engel Optical Data Systems, Inc.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Reply to: