Type packetstorm
Reporter Packet Storm
Modified 1999-09-21T00:00:00


                                            `Subject: [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock /  
mc / glibc 2.0.x  
First of all, something less or more personal - sorry to all  
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) {  
if (!fork()) {  
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/ /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 [] [link / marchew] [ SYSADM]  
[Marchew Industries] ! [] bash$ :(){ :|:&};:  
[voice phone: +48 (0) 22 813 25 86] ? [cellular phone: (0) 501 4000 69]  
Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch]