>>>>> Michal Zalewski writes:
> First of all, something less or more personal - sorry to all secure@...pl
> people for this post. I'm really angry, as this stuff become well-known
> without my knowledge... so, only a few of my own observations, always
> trying to respect other's intellectual property.
> All the best goes to el- :P
> ----------------------------------------------
> glibc 2.1.x and Linux without devpts mechanism
> ----------------------------------------------
Please report glibc problems to the glibc developers first!
/usr/libexec/pt_chown --help outputs:
[...]
Report bugs using the `glibcbug' script to <[EMAIL PROTECTED]>.
I didn't see any report on this on any glibc list! :-(
I'm forwarding this now.
> ------------------------------
> glibc 2.0.x and LC_ALL, noexec
> ------------------------------
> Compromise: locally, doing thins you shouldn't be able to do ;)
> First of all - doing /lib/ld-linux.so.2 /program/on/noexec/partition is
> the simpliest way to bypass noexec option, if only you have glibc 2.0.x.
> Nothing to say, security by obscurity stinks.
> Clean glibc 2.0.x, as distributed in .tar.gz, are vunerable to rather
> seriuos problem with LC_ALL containing '../' tricks (just like in telnetd
> and TERM case). In fact, in some Linux distributions, it has been silently
> fixed, while people upgrading glibc to eg. 2.0.7 'from scratch' are not
> aware of this problem, and many sites are vunerable. Using prepared
> directory with locale specifications, including glibc error messages used
> eg. by perror(), luser will be able to for example read setuid programs
> memory, etc.
AFAIK those problems are fixed in glibc 2.1.x - if not please tell us.
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
