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. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081