>>>>> 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 <bugsat_private>. 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 ajat_private-neckar.de jaegerat_private-kl.de for pgp-key finger ajaegerat_private-kl.de
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:59:10 PDT